Testare i bug web comuni con l'aiuto dell'IA

Con una lista verificata di endpoint da la lettura del JavaScript, puoi iniziare a testare bug reali. Questo post copre quattro classi che chi inizia trova presto: IDOR, cross-site scripting, server-side request forgery e autenticazione rotta. Il modello ti aiuta a leggere le response e a decidere il test successivo. Esegui ogni request e confermi ogni finding a mano. Tieni tutto il test sugli host che il programma elenca, e usa una copia locale dell'app per qualsiasi cosa rumorosa.

#Come usare il modello mentre testi

Il modello è un secondo paio di occhi su una response. Incolla una request e la sua response e chiedi cosa sembra fare il server con il tuo input, cosa restituirebbe invece un'app sicura e quale singolo cambiamento ti direbbe di più. È veloce in questo e a volte sarà sicuro e sbagliato, quindi ogni risposta è un'ipotesi che testi, non una conclusione che riporti. L'OWASP Web Security Testing Guide ha la procedura completa per ogni classe qui sotto.

Classe	La domanda che fai	Come verifichi
IDOR	Posso raggiungere l'oggetto di un altro utente?	Due account, scambi l'id, confronti le response
XSS	Il mio input gira come codice?	L'input riflesso viene eseguito in un browser reale
SSRF	Il server scarica un URL che scelgo io?	Un host che controlli registra la request del server
Auth rotta	Posso agire senza la sessione giusta?	Una request senza token o col ruolo sbagliato riesce

#IDOR: cambia l'identificatore, leggi la response

L'insecure direct object reference è il bug più amichevole per chi inizia. Trova una request con un identificatore dentro, come /api/orders/1051, e cambia il numero. Se ti torna l'ordine di un altro utente, l'app non controlla chi lo possiede. Il modo pulito per provarlo è con due account che controlli: scarica il tuo oggetto, poi prova l'identificatore dell'altro account dalla tua sessione, e confronta. Il modello ti aiuta a individuare quali campi sono identificatori e quali response differiscono in un modo che conta.

#XSS: dove l'input torna come codice

Il cross-site scripting avviene quando l'input che invii viene restituito a una pagina senza essere codificato, così il browser lo esegue come script. Il tuo compito nel test è trovare un punto dove l'input si riflette nella response e controllare se resta dato o diventa codice. Una stringa marcatore innocua ti dice se, e come, il tuo input viene codificato. Il cross-site scripting spiegato ha il dettaglio. Il modello è utile per leggere come un valore si riflette e dove manca la codifica, ma solo un browser reale prova l'esecuzione, quindi conferma lì.

#SSRF: dove il server scarica un URL

Il server-side request forgery avviene quando l'app prende un URL da te e il server lo scarica. Cerca funzioni che tirano una risorsa remota: un'immagine per URL, un webhook, un'anteprima di link. Per testare in sicurezza, punta la funzione su un host che controlli e osserva i tuoi log per la request del server. Se il server si connette, hai confermato il comportamento, e l'impatto dipende da cosa può raggiungere la rete del server. Descrivi solo ciò che hai provato, e non andare a caccia di servizi interni oltre ciò che il programma permette.

#Autenticazione e controllo degli accessi rotti

Questa classe copre le request che dovrebbero richiedere una sessione valida o un ruolo specifico e non lo fanno. Prendi una request autenticata, togli il token o scambia un account a privilegi inferiori, e vedi se funziona ancora. I bug di controllo degli accessi sono comuni, spesso ad alto impatto e facili da provare con due account. Il modello può aiutarti a enumerare quali azioni ritentare senza sessione, dalla lista di endpoint che hai costruito prima.

#Verifica prima di crederci

La maggior parte del tempo sprecato nel primo mese di chi inizia va ai falsi positivi che il modello ha incoraggiato. Tre abitudini lo evitano. Riproduci il bug da uno stato pulito così sai che è reale e non una stranezza di cache. Cambia una variabile per volta così sai cosa ha causato il risultato. Tieni la request e la response esatte che lo provano, perché è ciò che al report serve e ciò che il triager rieseguirà. Se non riesci a riprodurlo a comando, non è ancora un finding.

#A seguire in questa serie

Le API meritano un metodo a parte. Il test delle API con l'IA copre OpenAPI e GraphQL. L'OWASP Top 10 e la PortSwigger Web Security Academy sono i riferimenti da lavorare per ogni classe.