Testing on My personal blog

Fuzzing: trovare i bug che non hai immaginato

Tue, 12 May 2026 09:00:00 +0200

Perché conta

Ogni controllo visto finora — SAST, DAST, IAST — cerca problemi che sappiamo descrivere. I test unitari verificano i casi che immaginiamo. Ma gli attaccanti vivono nei casi che non abbiamo immaginato: l’input malformato, la lunghezza assurda, la sequenza impossibile. Il fuzzing esplora proprio quello spazio, generando input anomali a milioni e osservando cosa rompe.

Dall’input casuale alla copertura guidata

Il fuzzing ingenuo lancia byte casuali e spera in un crash: inefficiente, perché quasi tutti gli input vengono rifiutati subito dal parsing. Il salto di qualità è il coverage-guided fuzzing: il fuzzer osserva quali rami di codice ogni input attiva e tiene gli input che esplorano codice nuovo, mutandoli per andare più in profondità.

  flowchart LR
    SEED[Corpus iniziale<br/>input validi] --> MUT[Muta l'input<br/>bit flip, splice]
    MUT --> RUN[Esegue la funzione<br/>sotto test]
    RUN --> COV{Copre codice<br/>nuovo?}
    COV -->|sì| KEEP[Aggiungi al corpus<br/>→ base per altre mutazioni]
    COV -->|no| DROP[Scarta]
    RUN -->|crash / hang| BUG[Salva l'input:<br/>bug riproducibile]
    KEEP --> MUT
    style BUG fill:#fde2e4,stroke:#e63946

Guidato dalla copertura, il fuzzer “impara” a superare i controlli di validazione e a penetrare in profondità nel codice, trovando in ore ciò che input casuali non troverebbero in anni.

Cosa trova

Il fuzzing eccelle sul codice che interpreta input non fidati: parser, decoder, deserializzatori, protocolli di rete, elaborazione di file. Scopre:

Crash: dereferenze null, buffer overflow (in C/C++), eccezioni non gestite.
Corruzioni di memoria: potenti vettori di exploit, rilevate se si combina il fuzzing con i sanitizer (ASan, UBSan) che rendono visibile una corruzione altrimenti silenziosa.
Hang e consumo di risorse: input che mandano l’app in loop o esauriscono la memoria (DoS).

Il fuzz target

Il cuore pratico è scrivere una piccola funzione che riceve i byte del fuzzer e li passa al codice da testare:

int LLVMFuzzerTestOneInput(const uint8_t *data, size_t size) {
    // il fuzzer fornisce 'data'; noi lo passiamo al parser sotto test
    parse_config(data, size);   // ← se crasha, abbiamo un bug riproducibile
    return 0;
}

La riga evidenziata è tutto: dai l’input non fidato alla funzione critica e lasci che il fuzzer trovi l’input che la rompe. Lo stesso pattern esiste per i linguaggi gestiti (Go testing.F, Jazzer per la JVM, Atheris per Python).

Continuo, non una tantum

Il fuzzing dà di più col tempo: più gira, più in profondità arriva. Per questo in DevSecOps è continuo — gira in background su un corpus che cresce, non in un singolo passaggio di pipeline che deve finire in cinque minuti. Progetti come OSS-Fuzz dimostrano il modello: fuzzing 24/7, con i bug che aprono automaticamente ticket. Nella CI si esegue un fuzzing breve di regressione sul corpus noto (per non reintrodurre crash già risolti) e si lascia il fuzzing profondo all’infrastruttura dedicata.

Domanda: il fuzzing sembra utile solo per codice in C/C++ che fa parsing di basso livello; ha senso per una tipica app web in un linguaggio gestito?

Ha senso, ma cambia cosa trova e dove conviene puntarlo. È vero che il raccolto più ricco del fuzzing — corruzioni di memoria sfruttabili — vive in C/C++, dove un buffer overflow diventa un exploit; in un linguaggio gestito la memoria è protetta dal runtime, quindi quella classe sparisce. Ma non sparisce il resto: eccezioni non gestite che diventano DoS o errori 500 informativi, loop e allocazioni che esauriscono le risorse (una "zip bomb" o un input che fa esplodere un parser in tempo quadratico), bug logici nei deserializzatori, differenze di parsing tra due librerie che portano a confusione di tipo o a bypass di validazione. E soprattutto conta dove lo punti: non sulla logica di business, ma su ogni punto in cui l'app ingoia input non fidato e lo struttura — l'endpoint che accetta JSON o XML, il decoder di immagini, il parser di un formato proprietario, il layer che gestisce upload di file. Lì il fuzzing coverage-guided trova casi limite che nessun test scritto a mano copre, perché nessuno pensa a un JSON annidato diecimila livelli o a un campo numerico con un valore che fa overflow in una conversione. In più le dipendenze native sotto a un'app gestita (una libreria di compressione, un codec) sono spesso C/C++ sotto mentite spoglie, e lì il raccolto classico torna. La regola pratica: se un componente parsa qualcosa che arriva dall'esterno, è un candidato al fuzzing, qualunque sia il linguaggio.

Conclusione

Il fuzzing esplora lo spazio degli input che non abbiamo immaginato; guidato dalla copertura, impara a penetrare in profondità e trova crash e corruzioni riproducibili, specie nei parser di input non fidato. È continuo per natura. Con questo chiudiamo i controlli sul codice e sul comportamento. Ma il software che spediamo non è solo codice: è un artefatto costruito da una catena di strumenti, e di quella catena dobbiamo poterci fidare. Comincia la parte sulla supply chain, con l’inventario di ciò che spediamo: la SBOM, prossimo capitolo.

DAST: testare l'applicazione viva

Tue, 28 Apr 2026 09:00:00 +0200

Perché conta

Il SAST e la SCA guardano il codice fermo. Ma un’applicazione in esecuzione è più della somma del suo sorgente: ha una configurazione, un web server, header HTTP, sessioni, un ambiente. Il DAST (Dynamic Application Security Testing) la testa viva, attaccandola dall’esterno come farebbe un avversario, senza vedere il codice. Trova ciò che esiste solo a runtime.

Black box: la prospettiva dell’attaccante

Il DAST non sa nulla del codice: manda richieste, osserva le risposte, deduce.

  flowchart LR
    Z[Scanner DAST] -->|crawl: scopre<br/>URL e form| APP[App in esecuzione<br/>staging]
    Z -->|payload malevoli:<br/>', < script >, ../| APP
    APP -->|risposte,<br/>codici, errori| Z
    Z --> R[Report:<br/>XSS, injection,<br/>header mancanti,<br/>config errata]
    style R fill:#fde2e4,stroke:#e63946

Prima esplora (crawl) per scoprire URL, parametri e form; poi attacca iniettando payload e osservando se l’app reagisce in modo rivelatore. Trova:

Configurazioni errate: header di sicurezza assenti, cookie senza flag, pagine di errore troppo verbose, metodi HTTP pericolosi abilitati.
Vulnerabilità confermate a runtime: una XSS che si attiva davvero, un’injection che restituisce dati, un redirect aperto.
Problemi di sessione e autenticazione osservabili dall’esterno.

Il vantaggio: pochi falsi positivi

Dove il SAST dice “questo potrebbe essere sfruttabile”, il DAST spesso dimostra lo sfruttamento: ha inviato il payload e ha visto la risposta. Un finding DAST confermato è quasi sempre reale, perché riproduce l’attacco. Questo lo rende prezioso come controprova dei sospetti del SAST.

I limiti, da conoscere

Limiti strutturali del DAST:
  - Copertura parziale: testa solo i percorsi che riesce a RAGGIUNGERE
  - Lento: una scansione completa può durare ore
  - Non localizza: dice "c'è una XSS qui", non "riga 42 del file X"
  - Richiede un ambiente in esecuzione, simile a produzione

La copertura è il limite più sottile: se lo scanner non riesce a navigare un flusso complesso (un wizard multi-step, un’area dietro login), non lo testa. Per questo si fornisce al DAST l’autenticazione e, idealmente, la mappa degli endpoint (una definizione OpenAPI), così attacca anche le API, non solo le pagine che riesce a cliccare.

Nel flusso di lavoro

La lentezza impone una collocazione diversa dal SAST:

Scansione “baseline” veloce su ogni deploy in staging: pochi minuti, solo i controlli passivi e rapidi, come gate leggero.
Scansione completa notturna o settimanale, fuori dal percorso critico della pipeline.
Mai in produzione senza cautela: il DAST invia payload reali; girarlo su produzione può creare dati spazzatura o, peggio, innescare azioni. Si usa uno staging fedele.

Domanda: se il DAST trova vulnerabilità confermate e con pochi falsi positivi, non è semplicemente migliore del SAST? Perché tenere entrambi?

"Migliore" dipende da cosa misuri, e sulle due metriche che contano di più i due si invertono. Il DAST vince su precisione (i suoi finding sono spesso dimostrati) e su realismo (vede l'app come un attaccante, con la sua configurazione e il suo ambiente). Ma perde su copertura e tempismo, che per un difetto grave contano quanto la precisione. Copertura: il DAST testa solo i percorsi che riesce a raggiungere navigando; un ramo di codice che si attiva solo con un input raro non verrà mai esercitato, mentre il SAST lo legge comunque. Tempismo: il DAST richiede un'app in esecuzione in staging, quindi arriva a codice già scritto e integrato, mentre il SAST dà feedback sulla pull request, riga per riga, quando correggere costa un commento invece di un ciclo di rilascio. E c'è una classe di difetti che il DAST non localizza: ti dice "c'è una XSS raggiungendo questo URL", non "nasce da questa funzione" — per il fix serve comunque risalire al codice. Il modello mentale giusto non è una gara ma una pipeline di reti progressivamente più fini e più tardive: SAST e SCA ampi e precoci sul codice, DAST realistico e confermante sull'app viva, poi i controlli di runtime in produzione. Scartarne uno non ti dà più precisione, ti dà un buco in un punto preciso della timeline.

Conclusione

Il DAST attacca l’applicazione viva dall’esterno: trova configurazioni errate e difetti di runtime che il codice fermo nasconde, con pochi falsi positivi ma copertura parziale e tempi lunghi. SAST e DAST insieme coprono codice e comportamento. Esiste però un terzo punto di vista, ibrido: strumentare l’app dall’interno mentre viene testata, per unire visibilità sul codice e realismo del runtime. Sono IAST e RASP, prossimo capitolo.