Che cos'è il test di fuzzing?

Il test di fuzzing, o fuzzing dell'applicazione, è una tecnica di test del software che consente ai team di rilevare vulnerabilità di sicurezza o bug nel codice sorgente delle applicazioni software. A differenza delle tradizionali metodologie di test del software, come SAST, DAST o IAST, il fuzzing consiste sostanzialmente nel "pingare" il codice con input casuali nel tentativo di provocare un arresto anomalo e poter quindi individuare errori che altrimenti non sarebbero percepibili. Tali errori di codice (o problemi legati alla logica di business) rappresentano aree potenzialmente ad alto rischio per le minacce alla sicurezza.

Quando viene rilevato un errore o una vulnerabilità, è possibile utilizzare un fuzzer (uno strumento che individua le possibili cause dell'arresto anomalo), per concentrarsi su vulnerabilità specifiche nel codice sorgente. I fuzzer sono particolarmente utili per scoprire vulnerabilità che potrebbero essere sfruttate da attacchi come SQL injection e cross-site scripting, nei quali gli hacker compromettono la sicurezza per rubare informazioni o mettere fuori uso un sistema. Tuttavia, non sono altrettanto efficaci quando si tratta di rilevare vulnerabilità che sono legate agli arresti anomali del sistema, come nel caso degli spyware o dei trojan.

Se da un lato il test di fuzzing è molto apprezzato per essere completamente automatizzato e in grado di trovare i punti deboli più nascosti, dall'altro c'è chi sostiene che sia difficile da configurare e che tenda a fornire risultati inaffidabili.

Per capire meglio l'origine del test di fuzzing, può essere utile andare un po' indietro nel tempo per scoprire com'è stato scoperto il concetto. Nel 1988, il professor Barton Miller dell'Università del Wisconsin-Madison stava cercando di accedere al codice da remoto utilizzando un sistema dial-up, ma le interferenze provocate da un temporale continuavano a causare l'arresto anomalo del programma. Il sospetto che il codice non tollerasse "rumori" esterni contribuì a ispirare il lavoro di Miller e del suo studente, i quali scoprirono che i programmi Unix, Mac e Windows si bloccavano regolarmente quando venivano sottoposti a input imprevisti casuali. Miller è uno degli autori del libro Fuzzing for Software Security Testing and Quality Assurance.

Esistono due tipi principali di fuzzing: uno basato sulla copertura del codice e uno sul comportamento.

Il fuzzing basato sulla copertura del codice si concentra sul codice sorgente mentre l'app è in esecuzione, sondandolo mediante input casuali nel tentativo di trovare eventuali bug. Vengono costantemente generati nuovi test con l'obiettivo di provocare un arresto anomalo dell'app. Se questo si verifica, implica la presenza di un potenziale problema. Inoltre, i dati ottenuti dal processo di fuzzing basato sulla copertura del codice consentiranno a un tester di riprodurre l'arresto anomalo come strategia per individuare codice esposto a rischi.

Il fuzzing basato sul comportamento funziona in modo diverso. Utilizzando delle specifiche per mostrare come dovrebbe funzionare un'applicazione, invia input casuali per determinare il reale funzionamento dell'app. Di norma, la differenza tra il comportamento previsto e quello effettivo è il punto in cui possono emergere bug o altri potenziali rischi per la sicurezza.

Perché il test di fuzzing è importante per il DevSecOps? A causa della natura casuale del test di fuzzing, secondo gli esperti si tratta della metodologia con maggiori probabilità di rilevare bug che altri test non trovano. È considerata anche una metodologia di test che richiede uno sforzo davvero minimo, e che una volta configurata funziona in maniera indipendente. Una volta creato il test harness, il test di fuzzing funziona in maniera totalmente automatizzata e a tempo indeterminato. Di facile scalabilità grazie all'avvio di più macchine, è anche un'ottima soluzione per i test di regressione. Inoltre, il fuzzing accelera il processo di sviluppo massimizzando la copertura del codice, ovvero la quantità di codice eseguita dal fuzzer, senza introdurre falsi positivi. Una maggiore copertura del codice garantisce test più approfonditi.

Il test di fuzzing è ideale anche per lavorare accanto a un team di test manuali, poiché gli input dei due si istruiranno a vicenda.

I professionisti che desiderano implementare il test di fuzzing devono affrontare due sfide principali: la configurazione e l'analisi dei dati. Per quanto riguarda la configurazione, questa può rivelarsi più difficile di quanto di pensi, in quanto richiede complessi test harness, la cui creazione può essere ancora più complicata se il test di fuzzing non si trova effettivamente all'interno di una toolchain esistente. Inoltre, il test di fuzzing può generare molti dati, inclusi possibili falsi positivi. Per questo motivo, è fondamentale assicurarsi che il team di test sia preparato a gestire l'elevato numero di informazioni che riceverà.

Infine, sebbene siano meno facili da documentare, tra i professionisti della QA continuano ad esserci attitudini negative nei confronti della natura "vaga" del fuzzing.