PortSwigger Academy – Information disclosure vulnerabilities
Continua il percorso di apprendimento suggerito da “PortSwigger Academy”.
Information disclosure vulnerabilities
In questa sezione spiegheremo le nozioni di base sulle vulnerabilità legate alla divulgazione di informazioni e descriveremo come trovarle e sfruttarle. Offriremo anche alcune indicazioni su come prevenire le vulnerabilità legate alla divulgazione di informazioni nei tuoi siti web.
Imparare a trovare e sfruttare la divulgazione delle informazioni è un’abilità vitale per qualsiasi tester. È probabile che lo incontri regolarmente e, una volta che sai come sfruttarlo in modo efficace, può aiutarti a migliorare l’efficienza dei test e consentirti di trovare bug aggiuntivi di elevata gravità.
Che cos’è la divulgazione delle informazioni?
La divulgazione di informazioni, nota anche come fuga di informazioni, avviene quando un sito Web rivela involontariamente informazioni sensibili ai propri utenti. A seconda del contesto, i siti Web possono divulgare tutti i tipi di informazioni a un potenziale utente malintenzionato, tra cui:
- dati su altri utenti, come nomi utente o informazioni finanziarie;
- dati commerciali o aziendali sensibili;
- dettagli tecnici sul sito web e sulla sua infrastruttura.
I pericoli derivanti dalla fuga di dati aziendali o utente sensibili sono abbastanza ovvi, ma la divulgazione di informazioni tecniche a volte può essere altrettanto grave. Anche se alcune di queste informazioni saranno di utilità limitata, possono potenzialmente essere un punto di partenza per esporre un’ulteriore superficie di attacco, che potrebbe contenere altre vulnerabilità interessanti. La conoscenza che sarai in grado di raccogliere potrebbe persino fornire il pezzo mancante del puzzle quando cerchi di costruire attacchi complessi e ad alta gravità.
Occasionalmente, informazioni sensibili potrebbero essere divulgate incautamente agli utenti che stanno semplicemente navigando nel sito Web in modo normale. Più comunemente, tuttavia, un utente malintenzionato deve ottenere la divulgazione di informazioni interagendo con il sito Web in modi inaspettati o dannosi. Studieranno quindi attentamente le risposte del sito Web per cercare di identificare comportamenti interessanti.
Esempi di divulgazione di informazioni
Alcuni esempi fondamentali di divulgazione di informazioni sono i seguenti:
- rivelare i nomi delle directory nascoste, la loro struttura e i loro contenuti tramite un file robots.txt o un elenco di directory;
- fornire accesso ai file del codice sorgente tramite backup temporanei;
- menzione esplicita dei nomi di tabelle o colonne del database nei messaggi di errore;
- esporre inutilmente informazioni altamente sensibili, come i dettagli della carta di credito;
- chiavi API hardcoding, indirizzi IP, credenziali del database e così via nel codice sorgente;
- suggerendo l’esistenza o l’assenza di risorse, nomi utente e così via attraverso sottili differenze nel comportamento dell’applicazione.
In questo argomento imparerai come trovare e sfruttare alcuni di questi esempi e altro ancora.
Come nascono le vulnerabilità legate alla divulgazione delle informazioni?
Le vulnerabilità legate alla divulgazione di informazioni possono presentarsi in innumerevoli modi diversi, ma queste possono essere classificate a grandi linee come segue:
- Mancata rimozione dei contenuti interni dai contenuti pubblici. Ad esempio, i commenti degli sviluppatori nel markup sono talvolta visibili agli utenti nell’ambiente di produzione.
- Configurazione non sicura del sito web e delle tecnologie correlate. Ad esempio, la mancata disabilitazione delle funzionalità di debug e diagnostica può talvolta fornire agli aggressori strumenti utili per aiutarli a ottenere informazioni sensibili. Le configurazioni predefinite possono anche rendere vulnerabili i siti Web, ad esempio visualizzando messaggi di errore eccessivamente dettagliati.
- Design e comportamento difettosi dell’applicazione. Ad esempio, se un sito Web restituisce risposte distinte quando si verificano diversi stati di errore, ciò può anche consentire agli aggressori di enumerare dati sensibili, come credenziali utente valide.
Qual è l’impatto delle vulnerabilità legate alla divulgazione delle informazioni?
Le vulnerabilità nella divulgazione di informazioni possono avere un impatto sia diretto che indiretto a seconda dello scopo del sito web e, quindi, delle informazioni che un utente malintenzionato è in grado di ottenere. In alcuni casi, il solo atto di divulgazione di informazioni sensibili può avere un impatto elevato sulle parti interessate. Ad esempio, un negozio online che divulga i dati della carta di credito dei propri clienti potrebbe avere gravi conseguenze.
D’altro canto, la fuga di informazioni tecniche, come la struttura delle directory o i framework di terze parti utilizzati, potrebbe avere un impatto diretto minimo o nullo. Tuttavia, nelle mani sbagliate, queste potrebbero rivelarsi le informazioni chiave necessarie per realizzare numerosi altri exploit. La gravità in questo caso dipende da ciò che l’aggressore è in grado di fare con queste informazioni.
Come valutare la gravità delle vulnerabilità legate alla divulgazione delle informazioni
Sebbene l’impatto finale possa essere potenzialmente molto grave, è solo in circostanze specifiche che la divulgazione di informazioni costituisce di per sé un problema di elevata gravità. Durante i test, in particolare, la divulgazione di informazioni tecniche è spesso interessante solo se si è in grado di dimostrare come un utente malintenzionato potrebbe utilizzarle per fare qualcosa di dannoso.
Ad esempio, sapere che un sito Web utilizza una particolare versione del framework è di utilità limitata se tale versione è completamente aggiornata. Tuttavia, queste informazioni diventano significative quando il sito Web utilizza una versione precedente che contiene una vulnerabilità nota. In questo caso, eseguire un attacco devastante potrebbe essere semplice come applicare un exploit documentato pubblicamente.
È importante esercitare il buon senso quando si scopre che vengono divulgate informazioni potenzialmente sensibili. È probabile che dettagli tecnici minori possano essere scoperti in numerosi modi su molti dei siti Web testati. Pertanto, l’attenzione principale dovrebbe essere rivolta all’impatto e alla sfruttabilità delle informazioni trapelate, non solo alla presenza della divulgazione di informazioni come problema a sé stante. L’ovvia eccezione a ciò avviene quando le informazioni trapelate sono così sensibili da meritare attenzione di per sé.
Come prevenire le vulnerabilità legate alla divulgazione di informazioni
Impedire completamente la divulgazione delle informazioni è complicato a causa dell’enorme varietà di modi in cui può verificarsi. Tuttavia, esistono alcune best practice generali che puoi seguire per ridurre al minimo il rischio che questo tipo di vulnerabilità si insinui nei tuoi siti web.
- Assicurati che tutti coloro che sono coinvolti nella realizzazione del sito web siano pienamente consapevoli di quali informazioni siano considerate sensibili. A volte informazioni apparentemente innocue possono essere molto più utili per un utente malintenzionato di quanto si creda. Evidenziare questi pericoli può aiutare a garantire che le informazioni sensibili vengano gestite in modo più sicuro in generale dalla tua organizzazione.
- Controlla qualsiasi codice per la potenziale divulgazione di informazioni come parte del tuo QA o dei processi di creazione. Dovrebbe essere relativamente semplice automatizzare alcune delle attività associate, come l’eliminazione dei commenti degli sviluppatori.
- Utilizzare il più possibile messaggi di errore generici. Non fornire inutilmente agli aggressori indizi sul comportamento dell’applicazione.
- Ricontrolla che tutte le funzionalità di debug o diagnostica siano disabilitate nell’ambiente di produzione.
- Assicurati di comprendere appieno le impostazioni di configurazione e le implicazioni sulla sicurezza di qualsiasi tecnologia di terze parti che implementi. Prenditi il tempo necessario per indagare e disattivare eventuali funzionalità e impostazioni di cui non hai effettivamente bisogno.
Come individuare e sfruttare le vulnerabilità legate alla divulgazione di informazioni
In questa sezione forniremo consigli pratici su alcune tecniche e strumenti che è possibile utilizzare per identificare la divulgazione di informazioni in un’ampia gamma di contesti. Abbiamo anche fornito diversi laboratori in modo che tu possa esercitarti nell’estrazione di diversi tipi di informazioni che potrebbero essere utilizzate come parte di un ulteriore attacco.
- test per le vulnerabilità legate alla divulgazione di informazioni;
- fonti comuni di divulgazione delle informazioni LABS;
Come testare le vulnerabilità legate alla divulgazione di informazioni
In generale, è importante non sviluppare la “visione a tunnel” durante i test. In altre parole, dovresti evitare di concentrarti troppo su una particolare vulnerabilità. I dati sensibili possono essere divulgati ovunque, quindi è importante non perdere nulla che potrebbe essere utile in seguito. Troverai spesso dati sensibili durante i test per qualcos’altro. Un’abilità chiave è essere in grado di riconoscere informazioni interessanti quando e dove le trovi.
Di seguito sono riportati alcuni esempi di tecniche e strumenti di alto livello che è possibile utilizzare per identificare le vulnerabilità legate alla divulgazione di informazioni durante i test.
- Fuzzing
- Utilizzando Burp Scanner
- Utilizzando gli engagement tools di Burp
- Risposte informative ingegneristiche
Fuzzing
Se identifichi parametri interessanti, puoi provare a inviare tipi di dati inaspettati e stringhe fuzz appositamente predisposte per vedere quale effetto ha. Presta molta attenzione; sebbene le risposte a volte rivelino esplicitamente informazioni interessanti, possono anche suggerire in modo più sottile il comportamento dell’applicazione. Ad esempio, potrebbe trattarsi di una leggera differenza nel tempo impiegato per elaborare la richiesta. Anche se il contenuto di un messaggio di errore non rivela nulla, a volte il fatto che si sia verificato un caso di errore invece di un altro è di per sé un’informazione utile.
Puoi automatizzare gran parte di questo processo utilizzando strumenti come Burp Intruder. Ciò offre numerosi vantaggi. In particolare, puoi:
- aggiungere le posizioni del payload ai parametri e utilizzare elenchi di parole predefiniti di stringhe fuzz per testare un volume elevato di input diversi in rapida successione;
- identificare facilmente le differenze nelle risposte confrontando codici di stato HTTP, tempi di risposta, lunghezze e così via;
- utilizzare le regole di corrispondenza grep per identificare rapidamente le occorrenze di parole chiave, come
error, invalid, SELECT, SQLe così via; - applicare le regole di estrazione grep per estrarre e confrontare il contenuto di elementi interessanti all’interno delle risposte.
Puoi anche utilizzare l’estensione Logger++, disponibile nello store BApp. Oltre a registrare richieste e risposte da tutti gli strumenti di Burp, ti consente di definire filtri avanzati per evidenziare le voci interessanti. Questa è solo una delle tante estensioni Burp che possono aiutarti a trovare tutti i dati sensibili trapelati dal sito web.
Utilizzando Burp Scanner
Gli utenti di Burp Suite Professional hanno il vantaggio di Burp Scanner. Ciò fornisce funzionalità di scansione in tempo reale per il controllo degli elementi durante la navigazione oppure puoi pianificare scansioni automatizzate per eseguire la scansione e controllare il sito di destinazione per tuo conto. Entrambi gli approcci contrassegneranno automaticamente molte vulnerabilità legate alla divulgazione di informazioni. Ad esempio, Burp Scanner ti avviserà se trova informazioni sensibili come chiavi private, indirizzi e-mail e numeri di carta di credito in una risposta. Identificherà inoltre eventuali file di backup, elenchi di directory e così via.
Utilizzando gli engagement tools di Burp
Burp fornisce diversi engagement tools che puoi utilizzare per trovare più facilmente informazioni interessanti nel sito Web di destinazione. Puoi accedere agli engagement tools dal menu contestuale: fai semplicemente clic con il pulsante destro del mouse su qualsiasi messaggio HTTP, voce Burp Proxy o elemento nella mappa del sito e vai su “Engagement tools”.
I seguenti strumenti sono particolarmente utili in questo contesto.
Ricerca
Puoi utilizzare questo strumento per cercare qualsiasi espressione all’interno dell’elemento selezionato. Puoi ottimizzare i risultati utilizzando varie opzioni di ricerca avanzata, come la ricerca regex o la ricerca negativa. Ciò è utile per trovare rapidamente occorrenze (o assenze) di specifiche parole chiave di interesse.
Trova commenti
Puoi utilizzare questo strumento per estrarre rapidamente eventuali commenti degli sviluppatori trovati nell’elemento selezionato. Fornisce inoltre schede per accedere immediatamente al ciclo di richiesta/risposta HTTP in cui è stato trovato ciascun commento.
Scopri i contenuti
Puoi utilizzare questo strumento per identificare contenuti e funzionalità aggiuntivi non collegati ai contenuti visibili del sito web. Questo può essere utile per trovare directory e file aggiuntivi che non necessariamente verranno visualizzati automaticamente nella mappa del sito.
Risposte informative ingegneristiche
I messaggi di errore dettagliati a volte possono rivelare informazioni interessanti durante il normale flusso di lavoro dei test. Tuttavia, studiando il modo in cui i messaggi di errore cambiano in base ai tuoi input, puoi fare un ulteriore passo avanti. In alcuni casi, sarai in grado di manipolare il sito web per estrarre dati arbitrari tramite un messaggio di errore.
Esistono numerosi metodi per farlo a seconda dello scenario particolare che incontri. Un esempio comune è fare in modo che la logica dell’applicazione tenti un’azione non valida su un elemento di dati specifico. Ad esempio, l’invio di un valore di parametro non valido potrebbe portare a un’analisi dello stack o a una risposta di debug che contiene dettagli interessanti. A volte è possibile che i messaggi di errore rivelino il valore dei dati desiderati nella risposta.
Fonti comuni di divulgazione delle informazioni
La divulgazione di informazioni può avvenire in un’ampia varietà di contesti all’interno di un sito web. Di seguito sono riportati alcuni esempi comuni di luoghi in cui è possibile verificare se vengono esposte informazioni sensibili.
- File per crawler web
- Elenchi di directory
- Commenti degli sviluppatori
- Messaggi di errore
- Debug dei dati
- Pagine dell’account utente
- File di backup
- Configurazione non sicura
- Cronologia del controllo della versione
File per crawler web
Molti siti Web forniscono file in /robots.txt e /sitemap.xml per aiutare i crawler a navigare nel sito. Tra l’altro, questi file spesso elencano directory specifiche che i crawler dovrebbero ignorare, ad esempio perché potrebbero contenere informazioni riservate.
Dato che questi file non sono solitamente collegati all’interno del sito web, potrebbero non apparire immediatamente nella mappa del sito di Burp. Tuttavia, vale la pena provare a navigare manualmente su /robots.txt o /sitemap.xml per vedere se trovi qualcosa di utile.
Elenchi di directory
I server Web possono essere configurati per elencare automaticamente il contenuto delle directory che non dispongono di una pagina indice presente. Ciò può aiutare un utente malintenzionato consentendogli di identificare rapidamente le risorse in un determinato percorso e procedere direttamente all’analisi e all’attacco di tali risorse. Aumenta in particolare l’esposizione dei file sensibili all’interno della directory che non devono essere accessibili agli utenti, come file temporanei e dump di arresti anomali.
Gli stessi elenchi di directory non rappresentano necessariamente una vulnerabilità della sicurezza. Tuttavia, se anche il sito Web non riesce a implementare un adeguato controllo degli accessi, la divulgazione dell’esistenza e dell’ubicazione delle risorse sensibili in questo modo rappresenta chiaramente un problema.
Commenti degli sviluppatori
Durante lo sviluppo, a volte vengono aggiunti commenti HTML in linea al markup. Questi commenti vengono in genere rimossi prima che le modifiche vengano distribuite nell’ambiente di produzione. Tuttavia, a volte i commenti possono essere dimenticati, persi o addirittura lasciati deliberatamente perché qualcuno non era pienamente consapevole delle implicazioni sulla sicurezza. Sebbene questi commenti non siano visibili sulla pagina renderizzata, è possibile accedervi facilmente utilizzando Burp o anche gli strumenti di sviluppo integrati nel browser.
Talvolta questi commenti contengono informazioni utili a un utente malintenzionato. Ad esempio, potrebbero suggerire l’esistenza di directory nascoste o fornire indizi sulla logica dell’applicazione.
Messaggi di errore
Una delle cause più comuni di divulgazione di informazioni sono i messaggi di errore dettagliati. Come regola generale, dovresti prestare molta attenzione a tutti i messaggi di errore che incontri durante il controllo.
Il contenuto dei messaggi di errore può rivelare informazioni su quale input o tipo di dati è previsto da un determinato parametro. Questo può aiutarti a restringere il campo dell’attacco identificando i parametri sfruttabili. Potrebbe anche semplicemente impedirti di perdere tempo cercando di iniettare payload che semplicemente non funzioneranno.
Messaggi di errore dettagliati possono anche fornire informazioni sulle diverse tecnologie utilizzate dal sito web. Ad esempio, potrebbero nominare esplicitamente un motore di modello, un tipo di database o un server utilizzato dal sito Web, insieme al numero di versione. Queste informazioni possono essere utili perché puoi cercare facilmente eventuali exploit documentati che potrebbero esistere per questa versione. Allo stesso modo, puoi verificare se sono presenti errori di configurazione comuni o impostazioni predefinite pericolose che potresti essere in grado di sfruttare. Alcuni di questi potrebbero essere evidenziati nella documentazione ufficiale.
Potresti anche scoprire che il sito Web utilizza una sorta di framework open source. In questo caso, puoi studiare il codice sorgente disponibile al pubblico, che è una risorsa inestimabile per costruire i tuoi exploit.
Le differenze tra i messaggi di errore possono anche rivelare un diverso comportamento dell’applicazione che si verifica dietro le quinte. Osservare le differenze nei messaggi di errore è un aspetto cruciale di molte tecniche, come l’iniezione SQL, l’enumerazione dei nomi utente e così via.
Debug dei dati
A scopo di debug, molti siti Web generano messaggi di errore e log personalizzati che contengono grandi quantità di informazioni sul comportamento dell’applicazione. Sebbene queste informazioni siano utili durante lo sviluppo, sono anche estremamente utili per un utente malintenzionato se trapelano nell’ambiente di produzione.
I messaggi di debug a volte possono contenere informazioni vitali per lo sviluppo di un attacco, tra cui:
- valori per variabili di sessione chiave che possono essere manipolate tramite input dell’utente;
- nomi host e credenziali per i componenti back-end;
- nomi di file e directory sul server;
- chiavi utilizzate per crittografare i dati trasmessi tramite il client.
Talvolta le informazioni di debug possono essere registrate in un file separato. Se un utente malintenzionato riesce ad accedere a questo file, può fungere da utile riferimento per comprendere lo stato di runtime dell’applicazione. Può anche fornire diversi indizi su come fornire input elaborati per manipolare lo stato dell’applicazione e controllare le informazioni ricevute.
Pagine dell’account utente
Per loro stessa natura, il profilo o la pagina dell’account di un utente contiene solitamente informazioni sensibili, come l’indirizzo e-mail, il numero di telefono, la chiave API e così via. Poiché normalmente gli utenti hanno accesso solo alla pagina del proprio account, ciò non rappresenta di per sé una vulnerabilità. Tuttavia, alcuni siti Web contengono difetti logici che potenzialmente consentono a un utente malintenzionato di sfruttare queste pagine per visualizzare i dati di altri utenti.
Ad esempio, considera un sito Web che determina quale pagina dell’account utente caricare in base a un parametro utente.
GET /user/personal-info?user=carlos
La maggior parte dei siti Web adotta misure per impedire a un utente malintenzionato di modificare semplicemente questo parametro per accedere alle pagine degli account di utenti arbitrari. Tuttavia, a volte la logica per caricare singoli elementi di dati non è così solida.
Un utente malintenzionato potrebbe non essere in grado di caricare interamente la pagina dell’account di un altro utente, ma la logica per recuperare e visualizzare l’indirizzo e-mail registrato dell’utente, ad esempio, potrebbe non verificare che il parametro utente corrisponda all’utente attualmente connesso. In questo caso , la semplice modifica del parametro utente consentirebbe a un utente malintenzionato di visualizzare indirizzi email di utenti arbitrari sulla pagina del proprio account.
Esamineremo questo tipo di vulnerabilità in modo più dettagliato quando tratteremo il controllo degli accessi e le vulnerabilità IDOR.
Divulgazione del codice sorgente tramite file di backup
Ottenere l’accesso al codice sorgente rende molto più semplice per un utente malintenzionato comprendere il comportamento dell’applicazione e costruire attacchi ad alta gravità. I dati sensibili a volte sono addirittura codificati all’interno del codice sorgente. Esempi tipici di ciò includono chiavi API e credenziali per l’accesso ai componenti back-end.
Se riesci a identificare che viene utilizzata una particolare tecnologia open source, ciò fornisce un facile accesso a una quantità limitata di codice sorgente.
Occasionalmente, è anche possibile fare in modo che il sito web esponga il proprio codice sorgente. Durante la mappatura di un sito Web, potresti scoprire che ad alcuni file di codice sorgente viene fatto riferimento esplicitamente. Sfortunatamente, richiedendoli di solito non si rivela il codice stesso. Quando un server gestisce file con una particolare estensione, come .php, in genere esegue il codice, anziché semplicemente inviarlo al client come testo. Tuttavia, in alcune situazioni, puoi indurre un sito Web a restituire il contenuto del file. Ad esempio, gli editor di testo spesso generano file di backup temporanei mentre il file originale viene modificato. Questi file temporanei vengono solitamente indicati in qualche modo, ad esempio aggiungendo una tilde (~) al nome del file o aggiungendo un’estensione di file diversa. La richiesta di un file di codice utilizzando un’estensione di file di backup a volte può consentire di leggere il contenuto del file nella risposta.
Una volta che un utente malintenzionato ha accesso al codice sorgente, questo può rappresentare un enorme passo avanti verso la possibilità di identificare e sfruttare ulteriori vulnerabilità che altrimenti sarebbero quasi impossibili. Uno di questi esempi è la deserializzazione non sicura. Esamineremo questa vulnerabilità più avanti in un argomento dedicato.
Divulgazione di informazioni a causa di una configurazione non sicura
I siti Web talvolta sono vulnerabili a causa di una configurazione errata. Ciò è particolarmente comune a causa dell’uso diffuso di tecnologie di terze parti, la cui vasta gamma di opzioni di configurazione non è necessariamente ben compresa da coloro che le implementano.
In altri casi, gli sviluppatori potrebbero dimenticare di disabilitare varie opzioni di debug nell’ambiente di produzione. Ad esempio, il metodo HTTP TRACE è progettato per scopi diagnostici. Se abilitato, il server web risponderà alle richieste che utilizzano il metodo TRACE riportando nella risposta l’esatta richiesta ricevuta. Questo comportamento è spesso innocuo, ma occasionalmente porta alla divulgazione di informazioni, come il nome delle intestazioni di autenticazione interne che potrebbero essere aggiunte alle richieste dai proxy inversi.
Cronologia del controllo della versione
Praticamente tutti i siti Web sono sviluppati utilizzando una qualche forma di sistema di controllo della versione, come Git. Per impostazione predefinita, un progetto Git archivia tutti i dati di controllo della versione in una cartella denominata .git. Occasionalmente, i siti Web espongono questa directory nell’ambiente di produzione. In questo caso, potresti riuscire ad accedervi semplicemente accedendo a /.git.
Anche se spesso non è pratico sfogliare manualmente la struttura e i contenuti dei file grezzi, esistono vari metodi per scaricare l’intera directory .git. Puoi quindi aprirlo utilizzando l’installazione locale di Git per accedere alla cronologia del controllo della versione del sito Web. Ciò può includere registri contenenti modifiche apportate e altre informazioni interessanti.
Questo potrebbe non darti accesso al codice sorgente completo, ma confrontare le differenze ti consentirà di leggere piccoli frammenti di codice. Come con qualsiasi codice sorgente, potresti anche trovare dati sensibili codificati all’interno di alcune delle righe modificate.