Come diventare un vulnerability researcher

L'immagine del vulnerability researcher è quella di un genio col cappuccio che tira fuori 0-day dal nulla. La realtà è più noiosa e molto più raggiungibile: è un metodo, non un dono. Non devi essere la persona più intelligente nella stanza - devi capire un sistema più a fondo di chi l'ha scritto, e avere la pazienza di guardare dove nessun altro guarda. Ecco il percorso onesto per diventarlo.

La mentalità, prima degli strumenti

Il tratto che conta più di ogni linguaggio o tool è una curiosità che non si ferma a "funziona". Lo sviluppatore si chiede "come faccio a farlo funzionare?"; il ricercatore si chiede "cosa succede se faccio la cosa che non ti aspettavi?". È un ribaltamento di prospettiva: ogni assunzione di fiducia è sbagliata finché non dimostri il contrario, ogni input è ostile, ogni "non dovrebbe mai succedere" è un invito. I bug non vivono nel codice che fa quello che deve - vivono nel divario tra quello che la specifica dice e quello che il codice fa davvero.

Le basi che servono davvero

Dimentica la lista infinita di "impara tutto". Quello che serve per iniziare è poco e concreto: saper leggere il codice con scioltezza (passerai più tempo a leggere che a scrivere), capire i fondamentali del web - origine, redirect, autenticazione, encoding - perché è lì che vive la maggior parte dei bug moderni, conoscere un linguaggio abbastanza a fondo da leggerne l'ecosistema (JavaScript, Go, Python: scegline uno), e capire come i sistemi si parlano (protocolli, serializzazione). Le categorie OWASP servono, ma non come checklist da spuntare: come pattern da riconoscere. Non ti serve tutto il primo giorno; ti serve abbastanza per partire, e poi approfondisci su domanda.

Scegli un terreno stretto e diventa il più esperto lì

È la leva più grande, e quasi nessuno la usa: profondità, non ampiezza. Non provare a "trovare bug" in generale - è troppo vasto, e competi con tutti. Scegli una classe ristretta: un protocollo, una categoria di librerie, un formato di file, un flusso di autenticazione. E poi capiscila meglio di chi la mantiene. Il mio lavoro più produttivo è nato così: una sola domanda - come gestiscono le credenziali i client HTTP quando seguono un redirect? - portata libreria dopo libreria. Non è stata l'ampiezza a trasformare un singolo bug in una classe trovata su molti progetti: è stata la profondità su un punto.

Leggi il codice come un attaccante

In concreto: clona il repository e vai dritto al codice che gestisce un confine di fiducia - autenticazione, parsing, redirect, deserializzazione. Cerca l'assunzione che l'autore ha fatto e non ha verificato. Confronta il codice con la specifica: dove diverge, spesso c'è il bug. E guarda i test - non quello che testano, ma quello che non testano: i casi limite che nessuno ha scritto sono esattamente dove si nasconde il problema.

Automatizza ciò che si ripete

Quando trovi un pattern, non fermarti al singolo caso: costruisci un piccolo harness che testi la stessa ipotesi su molti bersagli. È il moltiplicatore che trasforma una scoperta manuale in una campagna. È la differenza tra cercare a caso e fare ingegneria della ricerca: un'ipotesi precisa, uno strumento che la verifica su scala, una lista di conferme da analizzare a mano.

Dove esercitarti, legalmente

Una regola prima di tutto: si testa solo ciò che si è autorizzati a testare. Detto questo, i terreni per allenarsi non mancano: le CTF (capture the flag) per imparare le tecniche in gara, le applicazioni volutamente vulnerabili come OWASP Juice Shop o DVWA per esercitarti senza rischi, il codice open source per leggere bug veri in software vero, e i programmi di bug bounty - dove però scope e autorizzazione vanno rispettati alla lettera. Il confine tra ricerca e reato è l'autorizzazione: non superarlo mai.

Poi viene la parte che nessuno insegna: segnalare

Trovare il bug è metà del lavoro. L'altra metà - quella su cui si costruisce davvero una reputazione - è segnalarlo bene. Una scoperta che nessuno riesce ad azionare non vale niente; una scoperta riportata in modo chiaro e responsabile costruisce il tuo nome. È un mestiere a sé, con regole precise, e l'ho raccontato per intero nel pezzo su cosa succede davvero quando segnali una vulnerabilità. Studialo prima di mandare la tua prima segnalazione, non dopo.

Una checklist per iniziare davvero

• Scegli un solo bersaglio ristretto questo mese: un protocollo, una libreria, un formato.
• Leggi la sua specifica E il suo codice, fianco a fianco.
• Trova un'assunzione che fa e non verifica.
• Scrivi un test minimo di quell'assunzione. Se si rompe, riproduci nel modo più piccolo possibile.
• Segnala bene (vedi il pezzo sulla disclosure).
• Automatizza il test su bersagli simili. Ripeti.

La lezione

Nessuno nasce vulnerability researcher. Lo si diventa un bersaglio stretto alla volta, da persone abbastanza curiose da leggere ciò che gli altri saltano e abbastanza pazienti da segnalarlo come si deve. Il genio è una leggenda; il metodo si impara. Comincia da un sistema solo, questa settimana - e fallo fino in fondo.