Individuazione dei bug comuni

Alcune classi di vulnerabilità generano la maggior parte dei compensi dei bug bounty perché sono comuni e hanno un impatto significativo. Imparate prima a fondo queste tre:

• IDOR — accesso ai dati di altri utenti tramite ID prevedibili
• XSS — inserimento di script in una pagina
• SSRF — costringere il server a recuperare URL scelti dall'attaccante

Questa lezione mostra come cercarle tutte in modo sistematico.

La Insecure Direct Object Reference (IDOR) si verifica quando un'app usa un identificatore fornito dall'utente per recuperare un oggetto senza verificare che l'utente ne sia il proprietario.

Basta cambiare l'ID per accedere ai dati di qualcun altro. È una vulnerabilità di controllo degli accessi, non un'iniezione.

Per trovare una IDOR, create due account e confrontateli. Qualsiasi elemento che faccia riferimento a un oggetto tramite un ID è un potenziale candidato.

• Acquisite una richiesta dall'account A che recupera i dati di A
• Ripetetela usando la sessione dell'account B, ma l'ID dell'oggetto di A
• Se B visualizza i dati di A, si tratta di una IDOR

Cercate gli ID negli URL, nei corpi JSON, negli header e persino nei formati base64/UUID.

La Cross-Site Scripting (XSS) consiste nell'inserire JavaScript che viene eseguito nel browser di un altro utente. Esistono tre tipi principali:

• Reflected — il payload viene restituito nella risposta immediata
• Stored — il payload viene salvato e inviato ad altri utenti (impatto massimo)
• Basata sul DOM — il JavaScript lato client inserisce in modo non sicuro l'input dell'attaccante nel DOM

Inserite prima un marcatore univoco per vedere dove e come viene riflesso il vostro input, quindi create un payload adatto al contesto (corpo HTML, attributo o script).

Il contesto determina quale payload permette di uscire dal contesto previsto ed eseguire il codice.

Un semplice alert(1) dimostra l'esecuzione, ma i revisori vogliono conoscere l'impatto. Dimostrate cosa potrebbe effettivamente sottrarre o fare un attaccante.

• Leggere un token CSRF o informazioni sulla sessione accessibili a JavaScript
• Mostrare document.domain per dimostrare l'origine
• Per una XSS memorizzata, mostrarne l'esecuzione nell'account di una vittima

Non sottraete mai realmente le sessioni di utenti reali: dimostrate soltanto la capacità.

Nel contesto dei bug bounty, la SSRF consiste nell'individuare una funzionalità che recupera un URL sotto il vostro controllo. I candidati più probabili sono:

• URL di webhook e URL di callback
• Generatori di immagini/PDF che recuperano risorse remote
• Funzionalità di anteprima degli URL o di espansione dei link
• Funzionalità di importazione da URL

Indirizzateli verso endpoint interni o di metadati per dimostrare l'impatto.

Quando la risposta non mostra il contenuto recuperato, usate un server fuori banda per confermare che l'obiettivo abbia effettuato una richiesta. Una callback di interazione dimostra una SSRF cieca.

Strumenti come Burp Collaborator o interactsh forniscono un URL univoco che registra gli accessi.

Tutte e tre le classi di vulnerabilità si individuano intercettando e manomettendo le richieste. Un proxy di intercettazione è lo strumento fondamentale.

• Burp Suite o OWASP ZAP per acquisire e modificare il traffico
• Repeater per ripetere e modificare singole richieste
• Intruder/fuzzer per testare molti ID o payload

Conoscere a fondo il vostro proxy vi sarà più utile di qualsiasi singola tecnica.

I compensi più elevati derivano dal concatenamento delle vulnerabilità. Una vulnerabilità di gravità media, combinata con un'altra, può diventare critica.

• Una SSRF che raggiunge i metadati cloud può portare al furto di credenziali e alla compromissione dell'account
• Una IDOR che espone token può portare alla compromissione completa dell'account
• Una XSS memorizzata in un pannello di amministrazione può portare alla compromissione dell'account amministratore

Chiedetevi sempre: con cosa è possibile combinare questa vulnerabilità?

Queste vulnerabilità coinvolgono dati e utenti reali. Agite eticamente:

• Usate i vostri account di test e non visualizzate dati di utenti reali oltre quanto necessario per dimostrare il problema
• Evitate payload XSS memorizzati che potrebbero attivarsi per utenti reali; limitateli al vostro account
• Per le SSRF, non addentratevi nei sistemi interni: dimostrate la funzionalità di base e fermatevi

Dimostrare l'impatto in modo responsabile vi mantiene nell'ambito del safe harbor.

Effettuate l'accesso come utente B, ripetete una richiesta usando la sessione di B ma l'ID dell'oggetto dell'utente A e ricevete i dati privati di A. Di quale vulnerabilità si tratta?

Avete imparato a cercare le tre classi di vulnerabilità di maggior valore.

• IDOR: confrontare due account, manomettere gli ID degli oggetti e verificare l'applicazione dei controlli di proprietà
• XSS: verificare la riflessione, adattare il payload al contesto e dimostrare l'impatto reale
• SSRF: trovare le funzionalità che recuperano URL e confermare fuori banda i casi ciechi
• Concatenate le vulnerabilità per ottenere un impatto critico (ad esempio, SSRF verso i metadati cloud)
• Usate un proxy di intercettazione e rimanete nell'ambito previsto

Prossimo argomento: trasformare i risultati in report che ottengono un compenso.