DAST: 7 casi d'uso, esempi, vantaggi e svantaggi
La capacità di DAST di simulare attacchi informatici reali e di individuare vulnerabilità in tempo reale lo rende uno strumento prezioso per la sicurezza informatica. Come si evince dal grafico, la popolarità di DAST è aumentata significativamente negli ultimi cinque anni.
Considerando che una parte significativa degli attacchi software sfrutta il livello applicativo 1 L'attenzione di DAST sui test esterni diventa ancora più cruciale.
Di seguito, scopri come DAST si integra nelle pipeline DevSecOps, soddisfa i requisiti di conformità e individua le vulnerabilità in fase di esecuzione che gli strumenti statici non rilevano.
Vantaggi e svantaggi di DAST
Come funziona DAST?
DAST segue una sequenza ripetibile ogni volta che viene eseguito su un'applicazione target.
- Identificazione del target: lo scanner è puntato su un URL o un insieme di endpoint API. Negli ambienti CI/CD, questa operazione viene in genere configurata una sola volta e poi attivata automaticamente a ogni build.
- Scansione: lo strumento mappa la superficie di attacco dell'applicazione seguendo i link, inviando moduli e analizzando il codice JavaScript, creando un inventario di ogni input ed endpoint raggiungibile. Gli scanner moderni utilizzano uno spider AJAX insieme al crawler standard per gestire le applicazioni a pagina singola che caricano i contenuti dinamicamente.
- Simulazione di attacco: per ogni input rilevato, lo scanner lancia payload di attacco: stringhe di SQL injection, vettori XSS, sequenze di path traversal, intestazioni malformate e altri tratti dalla OWASP Top 10 e oltre. Tre tecniche principali sono alla base di questa fase:
- Il fuzzing invia dati inattesi o malformati per generare errori non gestiti.
- Manomissione dei parametri, modifica dei valori negli URL, nei cookie e nei corpi delle richieste per testare la convalida dell'input
- Test di autenticazione che tentano di fissare la sessione, prevedere il token e ottenere privilegi elevati attraverso i ruoli utente.
- Analisi della risposta: lo scanner valuta ogni risposta alla ricerca di indicatori di una vulnerabilità reale, come stack trace, messaggi di errore del database, reindirizzamenti a risorse non previste o dati restituiti che dovrebbero essere soggetti a controllo degli accessi. Gli strumenti che utilizzano la scansione basata su prove confermano la sfruttabilità prima di segnalare un problema, riducendo così i falsi positivi.
- Reportistica: I risultati vengono raccolti in un report classificato per gravità, con l'endpoint interessato, il payload che ha causato il problema e le indicazioni per la risoluzione. La maggior parte degli scanner aziendali invia i risultati direttamente a Jira, GitHub Issues o piattaforme SIEM, in modo che i risultati vengano indirizzati al team competente senza necessità di una valutazione manuale.
- Ritest: una volta implementata una correzione, lo scanner esegue nuovamente il test sull'endpoint precedentemente vulnerabile per confermare che la vulnerabilità sia stata chiusa; questo passaggio funge anche da prova documentale per gli audit di conformità.
I 7 principali casi d'uso di DAST
1-Integrazione con il ciclo di vita dello sviluppo
DAST si inserisce nelle fasi di test e staging del ciclo di vita dello sviluppo software, dove le applicazioni sono in esecuzione ma non hanno ancora raggiunto la produzione. In questa fase, le vulnerabilità sono più economiche da correggere e non comportano rischi per il cliente. Nelle pipeline CI/CD, le scansioni possono essere attivate automaticamente a ogni build, rendendo la sicurezza parte integrante del processo di rilascio anziché un controllo finale.
Esempio tratto dalla vita reale
Prima dell'integrazione, il team di sicurezza eseguiva scansioni manuali che non riuscivano a tenere il passo con il programma di rilascio di Park 'N Fly. Dopo aver collegato Invicti ai flussi di lavoro esistenti di Azure DevOps e Jira, le scansioni si sono attivate automaticamente a ogni build, spostando i controlli di sicurezza da una revisione trimestrale a un controllo per ogni rilascio. Il team ha recuperato l'equivalente del carico di lavoro manuale di un dipendente a tempo pieno. 2
2-Simulazione di attacco nel mondo reale
Gli strumenti DAST simulano attacchi reali a un'applicazione web, fornendo una valutazione pratica del suo livello di sicurezza.
Esempio tratto dalla vita reale
Nel maggio 2023, una vulnerabilità di SQL injection nella piattaforma MOVEit Transfer di Progress Software, un'applicazione ampiamente utilizzata per il trasferimento gestito di file, è stata sfruttata prima che il fornitore ne venisse a conoscenza. La violazione ha compromesso 11,3 milioni di cartelle cliniche di pazienti presso Maximus e ha colpito decine di agenzie governative e aziende in diversi paesi, tra cui la BBC, la società britannica di software per le risorse umane Zellis e il governo della Nuova Scozia. 3
Progress Software è venuta a conoscenza della vulnerabilità solo perché era già sotto attacco. L'azienda l'ha confermata, ha rilasciato una patch e ha avvisato i clienti lo stesso giorno, ma lo sfruttamento della vulnerabilità era già iniziato prima della divulgazione. 4
Uno scanner DAST in esecuzione sull'applicazione web di MOVEit in un ambiente di staging avrebbe inviato payload di SQL injection ai campi di input dell'applicazione e segnalato la risposta anomala del database, utilizzando la stessa tecnica impiegata dagli aggressori. A quel punto, la correzione sarebbe stata un'attività di sviluppo. Senza quel test, la stessa vulnerabilità sarebbe rimasta presente in un sistema di produzione utilizzato da centinaia di organizzazioni.
3. Requisiti di conformità e normativi
Le normative, tra cui PCI DSS, HIPAA e GDPR, richiedono test di sicurezza periodici per le applicazioni che gestiscono dati sensibili. La parola chiave è " dimostrare ": gli auditor richiedono prove documentate dell'individuazione e della correzione delle vulnerabilità, non solo la conferma dell'avvenuta esecuzione dei test. DAST produce proprio questo: i report di scansione mostrano quali vulnerabilità erano presenti nell'applicazione in produzione, quando sono state rilevate e se la loro risoluzione è stata verificata.
- Le organizzazioni devono proteggere le applicazioni web accessibili al pubblico attraverso valutazioni periodiche delle vulnerabilità o un WAF (Web Application Firewall). DAST soddisfa l'opzione di valutazione testando l'applicazione distribuita rispetto ai vettori di attacco che i revisori ricercano per SQL injection, XSS e falle di autenticazione, generando un output con timestamp pronto per la verifica.
- Le organizzazioni devono eseguire controlli automatici settimanali per rilevare modifiche non autorizzate agli script delle pagine di pagamento e alle intestazioni HTTP. I report di scansione DAST supportano questa procedura fornendo prove continue a livello applicativo che l'ambiente più ampio che circonda le pagine di pagamento non è stato compromesso.
Esempio tratto dalla vita reale
Channel 4, l'emittente commerciale pubblica del Regno Unito, gestisce la piattaforma di streaming All 4 con 24 milioni di utenti registrati, tutti soggetti ai requisiti di sicurezza dei dati del GDPR. Per dimostrare la conformità, il team di sicurezza ha precedentemente commissionato diversi test di penetrazione esterni per ogni progetto. Ogni test ha prodotto risultati, il team ha provveduto alle correzioni e poi ha pagato per un nuovo test. Il CISO Brian Brackenborough ha descritto il costo cumulativo: ogni progetto poteva richiedere diversi cicli a seconda della complessità.
Dopo aver integrato la piattaforma DAST automatizzata di Invicti, Channel 4 è passata alla scansione continua a intervalli prestabiliti di progetto, sostituendo il ciclo di ritest con una verifica automatizzata interna. La spesa annuale per i penetration test è diminuita di circa il 60% nel primo anno e si è ridotta a circa il 20% della spesa iniziale entro il secondo anno. 5
4- Copertura completa
DAST testa ogni interfaccia che l'applicazione espone all'esterno, dai moduli di login ai token di sessione, dagli endpoint API ai parametri URL e alle intestazioni HTTP, senza accedere al codice sorgente. Autenticazioni errate, session fixation, riferimenti diretti a oggetti non sicuri e controlli di accesso configurati in modo errato non sono pattern statici nel codice; emergono dal comportamento dell'applicazione quando un utente o un malintenzionato le invia input specifici.
DAST analizza gli endpoint che gli sviluppatori potrebbero non aver esposto intenzionalmente. Le API shadow, i percorsi deprecati lasciati attivi dopo una modifica delle funzionalità e le interfacce di amministrazione raggiungibili dalla rete pubblica non vengono rilevati durante una revisione del codice, ma compaiono in una scansione DAST.
5- Monitoraggio continuo
Le applicazioni non rimangono statiche dopo la distribuzione. Le librerie vengono aggiornate, vengono aggiunti nuovi endpoint, vengono apportate modifiche alla configurazione e vengono caricati script di terze parti da domini esterni, ognuno dei quali può introdurre una vulnerabilità assente nell'ultima scansione. I test annuali o trimestrali non possono rilevare una falla introdotta in una distribuzione del martedì. DAST, integrato in una pipeline CI/CD, viene eseguito su ogni nuova build, il che significa che la postura di sicurezza dell'applicazione viene verificata in modo continuo anziché periodico.
Le dipendenze da terze parti rendono questo aspetto particolarmente importante. Gli attacchi alla catena di fornitura, in cui un componente esterno affidabile viene compromesso e utilizzato per iniettare comportamenti dannosi nelle applicazioni a valle, si classificano ora al terzo posto tra i rischi più elevati per le applicazioni web nella OWASP Top 10:2025. DAST rileva questi attacchi in fase di esecuzione, dove il comportamento iniettato si manifesta effettivamente, anziché nel codice sorgente, dove la dipendenza potrebbe apparire invariata.
Esempio tratto dalla vita reale
Nel giugno 2024, il dominio e il repository GitHub di Polyfill.js sono stati acquistati da un nuovo proprietario che ha modificato lo script per reindirizzare gli utenti mobili a siti dannosi. Oltre 100.000 applicazioni web caricavano Polyfill direttamente dalla CDN, il che significa che una dipendenza considerata affidabile si è trasformata silenziosamente in un vettore di attacco senza alcuna modifica al codice di tali applicazioni. Gli strumenti DAST hanno segnalato il comportamento dannoso poco dopo la sua scoperta, identificando le applicazioni che caricavano lo script compromesso e generando risultati concreti per la risoluzione del problema. 6
6-Identificazione dei problemi di runtime
Alcune classi di vulnerabilità non sono presenti nel codice sorgente, ma emergono dal comportamento di un'applicazione distribuita in condizioni reali. Le condizioni di gara (race condition) si verificano quando richieste concorrenti accedono simultaneamente alla stessa risorsa. Le falle nella logica di business emergono quando un utente malintenzionato attraversa un flusso di lavoro a più fasi nell'ordine sbagliato. La falsificazione delle richieste lato server (SSRF) si manifesta solo quando l'applicazione effettua attivamente connessioni in uscita verso altri sistemi. Le perdite di memoria, i timeout di sessione e la deserializzazione non sicura richiedono tutti un'applicazione attiva e funzionante per essere attivati.
DAST affronta questi problemi interagendo con l'applicazione esattamente come farebbe un utente o un attaccante, inviando input, osservando le risposte e testando il comportamento del sistema in condizioni che l'analisi statica non può simulare.
7. Complementare ad altri metodi di prova
Nessun singolo metodo di test copre l'intera superficie di attacco di un'applicazione moderna. I team di sicurezza in genere combinano DAST con:
- SAST analizza il codice sorgente prima della distribuzione, individuando precocemente, durante lo sviluppo, problemi come segreti hardcoded, chiamate di funzioni non sicure e concatenazioni di stringhe vulnerabili alle injection. Non è in grado di testare il comportamento in fase di esecuzione.
- IAST strumenta l'applicazione dall'interno durante l'esecuzione, monitorando il flusso dei dati attraverso il codice in esecuzione. Mentre DAST osserva il comportamento esterno dell'applicazione, IAST ne osserva il comportamento interno durante la stessa richiesta; i due metodi producono risultati complementari da punti di vista opposti.
- SCA analizza le librerie di terze parti e open source alla ricerca di CVE note, segnalando le dipendenze vulnerabili prima che raggiungano l'ambiente di produzione. L'incidente di Polyfill illustra questa lacuna: SCA non avrebbe rilevato l'attacco perché la libreria stessa non presentava CVE al momento della compromissione del dominio che la ospitava. DAST ha individuato il comportamento dannoso in fase di esecuzione che SCA non era in grado di rilevare.
- Gli scanner di rete e di vulnerabilità identificano porte aperte, servizi obsoleti e configurazioni errate dell'infrastruttura a livello di host e di rete, al di sotto dell'applicazione stessa.
Limitazioni da tenere in considerazione quando si utilizza DAST
1. Nessuna visibilità sul codice interno
DAST verifica ciò che l'applicazione espone: endpoint, moduli, intestazioni, risposte. Non può leggere il codice sorgente, quindi le vulnerabilità che non emergono tramite interazione esterna rimangono non rilevate. Una credenziale hardcoded nascosta nella logica lato server, ad esempio, non verrà rilevata da una scansione DAST a meno che non produca una risposta osservabile. Per individuarle è necessario un test SAST o una revisione del codice.
2. Scoperta in fase avanzata
DAST richiede un'applicazione in esecuzione, il che significa che non può essere utilizzato fino alla fase di test o di staging. Una vulnerabilità introdotta nelle prime fasi dello sviluppo può sopravvivere a diversi cicli di compilazione prima che una scansione DAST la rilevi. Più tardi viene scoperta una vulnerabilità, maggiore è la quantità di codice già presente al di sopra di essa, aumentando sia i costi di correzione sia il rischio che una soluzione introduca nuovi problemi.
3. Falsi positivi e falsi negativi
Gli strumenti DAST deducono le vulnerabilità dalle risposte delle applicazioni, il che significa che possono segnalare un comportamento innocuo come una vulnerabilità (falso positivo) o non rilevare una vulnerabilità che richiede una sequenza specifica di input (falso negativo). I falsi positivi fanno perdere tempo prezioso per la risoluzione dei problemi; i falsi negativi creano una falsa sicurezza. Gli strumenti moderni riducono i falsi positivi attraverso la scansione basata su prove, che conferma che una vulnerabilità è sfruttabile prima di segnalarla, ma permangono delle lacune nella copertura, soprattutto nei flussi di lavoro complessi che richiedono l'autenticazione.
4. Errori nella logica aziendale
DAST identifica le vulnerabilità che producono anomalie rilevabili come SQL injection, XSS e bypass dell'autenticazione. Non è in grado di rilevare difetti in cui l'applicazione si comporta esattamente come previsto dal codice, ma la logica stessa è insicura. A partire dal 2026, Broken Object Level Authorization (BOLA) e Broken Function Level Authorization (BFLA) rappresentano i principali rischi per la sicurezza delle API; entrambi implicano che l'applicazione elabori correttamente una richiesta che avrebbe dovuto rifiutare. Nessuno scanner automatico può determinare se una regola aziendale è errata, ma solo se è stata violata.
5. Rischio di scansione della produzione
DAST invia attivamente payload di attacco a un'applicazione in produzione. Nell'ambiente di staging, questo è il comportamento previsto. In produzione, la stessa scansione può attivare stati di errore, corrompere i dati di test, bloccare gli account o generare un carico che degrada le prestazioni per gli utenti reali. La maggior parte dei team limita le scansioni DAST complete agli ambienti di pre-produzione e utilizza un monitoraggio passivo più leggero in produzione, accettando una lacuna nella copertura in cambio della sicurezza operativa.
6. Nessuna localizzazione a livello di codice
DAST identifica una vulnerabilità in un determinato endpoint, ma non è in grado di indicare la riga di codice responsabile. Uno sviluppatore che riceve un risultato da DAST deve riprodurre il problema, tracciare la richiesta attraverso lo stack applicativo e individuare manualmente la fonte. L'integrazione dell'output di DAST con i risultati di SAST o l'utilizzo di IAST, che strumenta l'applicazione dall'interno, può ridurre questo divario correlando il risultato a runtime con la posizione del codice.
7. Lacune di copertura nelle architetture applicative moderne
DAST analizza un'applicazione seguendo i link e inviando i moduli. Le applicazioni a pagina singola basate su React, Angular o Vue renderizzano i contenuti dinamicamente tramite JavaScript dopo il caricamento iniziale della pagina, una funzionalità che i crawler tradizionali non sono in grado di esplorare completamente. Anche le API che richiedono token di autenticazione specifici, flussi di lavoro a più fasi o formati di input non standard potrebbero non essere testate, a meno che lo strumento DAST non sia configurato esplicitamente per gestirle. La copertura è completa solo nella misura in cui lo scanner è in grado di navigare all'interno dell'applicazione.
FAQ
Il Dynamic Application Security Testing (DAST) testa un'applicazione in esecuzione dall'esterno verso l'interno, senza accedere al suo codice sorgente. Invia input dannosi, payload di SQL injection, stringhe XSS, tentativi di bypass dell'autenticazione alle interfacce esposte e segnala risposte inattese come potenziali vulnerabilità. Poiché opera esattamente come farebbe un attaccante esterno, il DAST individua difetti che si manifestano solo in fase di esecuzione e che l'analisi statica del codice non è in grado di rilevare.
Nelle moderne pratiche di sviluppo software, in particolare quelle che seguono le metodologie DevOps, le best practice e gli strumenti DAST possono essere integrati nelle pipeline di integrazione continua/distribuzione continua (CI/CD). Questa integrazione garantisce una sicurezza costante durante l'intero ciclo di vita dell'applicazione.
Per scegliere uno strumento DAST, consulta l'elenco delle migliori soluzioni DAST .
Gli strumenti DAST, gli strumenti di scansione delle vulnerabilità, gli strumenti per la sicurezza delle API e gli strumenti per la sicurezza delle applicazioni svolgono funzioni specifiche nel contesto più ampio della sicurezza informatica, sebbene vi sia una certa sovrapposizione.
Gli strumenti DAST sono specializzati nel testare la sicurezza delle applicazioni web durante il loro funzionamento, simulando attacchi esterni per scoprire vulnerabilità che si manifestano solo durante l'esecuzione.
Gli strumenti di scansione delle vulnerabilità offrono un servizio più ampio, analizzando sistemi, reti o applicazioni alla ricerca di diverse problematiche di sicurezza, comprese le debolezze che potrebbero non essere limitate al software stesso, ma riguardare configurazioni o sistemi obsoleti.
Gli strumenti di sicurezza per le API sono progettati specificamente per proteggere le API, ovvero le interfacce critiche tra diverse applicazioni software. Questi strumenti si concentrano sulle problematiche di sicurezza peculiari delle API, come la protezione degli endpoint, l'autenticazione e la gestione delle chiamate API e la garanzia dell'integrità dei dati durante la trasmissione.
Gli strumenti per la sicurezza delle applicazioni comprendono una vasta gamma di strumenti, inclusi quelli sopra menzionati, e hanno lo scopo di proteggere le applicazioni durante tutto il loro ciclo di vita. Questa categoria include strumenti e pratiche che affrontano la sicurezza in diverse fasi, dallo sviluppo alla distribuzione e alla manutenzione.
Queste categorie, tuttavia, si sovrappongono:
Gli strumenti DAST sono un sottoinsieme degli strumenti di sicurezza delle applicazioni, specificamente progettati per identificare le vulnerabilità nelle applicazioni web in produzione tramite la simulazione di attacchi esterni.
Anche gli strumenti di sicurezza delle API rientrano nella più ampia categoria degli strumenti di sicurezza delle applicazioni, ma si concentrano specificamente sulla sicurezza delle interfacce API, affrontando sfide uniche come la sicurezza degli endpoint e l'autenticazione.
Gli strumenti di scansione delle vulnerabilità hanno una portata più ampia, che comprende controlli di sicurezza su interi sistemi, incluse reti e applicazioni. Spesso includono funzionalità per identificare vulnerabilità in applicazioni web e API, sovrapponendosi quindi agli strumenti DAST e di sicurezza delle API.
Collegamenti di riferimento
Sii il primo a commentare
Il tuo indirizzo email non verrà pubblicato. Tutti i campi sono obbligatori.