Ti è mai capitato di visitare una pagina web e trovare, al posto del contenuto atteso, un messaggio di errore pieno di dettagli tecnici?
Magari il percorso di un file sul server, il nome di una libreria, una query SQL o persino una parte della configurazione dell'applicazione.
Queste informazioni possono sembrare innocue, soprattutto se non permettono direttamente di accedere ai dati. In realtà, quando un'applicazione rivela dettagli che dovrebbero rimanere interni, può rendere più semplice individuare altri problemi di sicurezza.
Questo fenomeno è conosciuto come information disclosure, ovvero divulgazione involontaria di informazioni.
Che cos'è l'information disclosure?
Si parla di information disclosure quando un sistema rende disponibili informazioni che non dovrebbero essere accessibili a quel pubblico o in quel contesto.
Non significa necessariamente che ci sia stata una violazione dei dati. A volte si tratta di dettagli tecnici apparentemente secondari; altre volte possono essere informazioni riservate o credenziali che richiedono un intervento immediato.
La gravità dipende soprattutto da cosa viene esposto e da come quelle informazioni potrebbero essere utilizzate.
Per esempio, un'applicazione potrebbe mostrare:
Errore durante il caricamento della pagina.
File: /var/www/example/app/Database.php
Riga: 142
Database: produzione
Questo messaggio rivela il percorso interno di un file, il nome di un componente e un riferimento all'ambiente utilizzato.
Non dimostra che il database sia accessibile dall'esterno. Tuttavia, comunica dettagli che normalmente non servono all'utente finale.
Quali informazioni può rivelare un sito web?
Le informazioni esposte possono essere molto diverse.
Versioni di software e librerie
Una risposta HTTP, un messaggio di errore o una pagina informativa potrebbero indicare quale server web o framework viene utilizzato.
Per esempio:
Server: esempio-server/1.2.3
Questo è un valore illustrativo, non il banner di un prodotto specifico.
Conoscere una versione può aiutare a verificare se esistono vulnerabilità note che la riguardano. Non significa però che il sistema sia automaticamente vulnerabile: bisogna considerare configurazione, patch applicate e condizioni necessarie per sfruttare il problema.
Percorsi interni e struttura dei file
Messaggi di errore troppo dettagliati possono mostrare percorsi come:
/var/www/app/controllers/UserController.php
Questi dettagli possono suggerire la struttura del progetto e aiutare a comprendere come è organizzata l'applicazione.
Il percorso, da solo, non consente necessariamente di leggere il file. È comunque preferibile non divulgarlo senza motivo.
Query e informazioni sul database
Un errore SQL potrebbe mostrare nomi di tabelle, colonne o dettagli dell'operazione fallita.
Per esempio:
SQLSTATE: errore durante la query
Tabella: users
Colonna: email
In questo caso l'applicazione sta comunicando informazioni sulla struttura del database.
Se vengono mostrati anche dati personali, valori delle query o altri dettagli sensibili, il problema può essere più serio.
Credenziali e segreti
Il caso più delicato riguarda la divulgazione di informazioni come:
- password;
- token di accesso;
- chiavi API;
- stringhe di connessione;
- chiavi private;
- variabili di configurazione riservate.
Se un segreto viene esposto, non basta nascondere il messaggio che lo conteneva. È necessario verificare se sia stato utilizzato da soggetti non autorizzati e valutare la revoca o la rotazione della credenziale.
Informazioni sull'ambiente
Anche indicazioni come development, staging o production possono aiutare a distinguere gli ambienti di un'organizzazione.
Il rischio aumenta quando questi dettagli sono accompagnati da informazioni su servizi interni, configurazioni temporanee o componenti non aggiornati.
Come vengono esposte queste informazioni?
Spesso non è necessario un attacco particolarmente sofisticato. La divulgazione può essere causata da normali errori di sviluppo o configurazione.
Tra i casi più comuni troviamo:
- modalità di debug lasciata attiva in produzione;
- eccezioni non gestite;
- pagine di errore predefinite troppo dettagliate;
- directory di test pubblicamente accessibili;
- file di backup raggiungibili via web;
- header HTTP eccessivamente descrittivi;
- log o report pubblicati per errore;
- risposte API che includono campi non necessari.
Il problema può quindi coinvolgere il codice dell'applicazione, il server web, il CMS oppure i servizi che si trovano dietro l'interfaccia pubblica.
Perché le informazioni tecniche possono essere utili a un attaccante?
Immagina di dover valutare la sicurezza di un'applicazione senza conoscerne l'architettura.
Se il sito non rivela alcun dettaglio, dovrai raccogliere informazioni attraverso altre verifiche.
Se invece una risposta comunica il framework utilizzato, la versione del server e il nome di un componente, parte del lavoro è già stata fatta.
Le informazioni divulgate possono aiutare a:
- restringere la ricerca di vulnerabilità note;
- riconoscere tecnologie obsolete;
- comprendere la struttura dell'applicazione;
- individuare endpoint o componenti da verificare;
- preparare tentativi di attacco più mirati.
È importante non confondere questa utilità con una vulnerabilità automaticamente sfruttabile. La divulgazione può aumentare le informazioni disponibili senza compromettere direttamente il sistema.
Come verificare se un sito rivela informazioni eccessive?
Un primo controllo consiste nell'osservare le risposte del sito, utilizzando un browser o strumenti HTTP su sistemi che si è autorizzati a verificare.
Per esempio:
curl -sS -D - -o /dev/null https://example.com/
Il comando mostra gli header HTTP restituiti dal server e scarta il corpo della risposta.
Tra gli elementi da esaminare ci sono:
- header
Server; - header
X-Powered-By; - eventuali identificatori di versione;
- informazioni restituite in caso di errore;
- differenze tra risposte valide e non valide.
Non tutti questi header sono necessariamente presenti e non tutti rappresentano un problema.
Per verificare gli errori applicativi, è utile eseguire test controllati su percorsi non esistenti e sulle funzionalità accessibili senza autenticazione. I test non dovrebbero provocare modifiche ai dati né coinvolgere sistemi di terze parti senza autorizzazione.
Come prevenire l'information disclosure
Disattivare il debug in produzione
Le modalità di debug sono utili durante lo sviluppo, ma possono esporre dettagli interni se lasciate attive nell'ambiente pubblico.
In produzione, gli errori dovrebbero essere registrati nei log protetti e presentati agli utenti attraverso messaggi generici.
Separare gli errori pubblici dai log interni
Un visitatore non ha bisogno di conoscere il percorso di un file PHP o la struttura di una query SQL.
È preferibile mostrare un messaggio come:
Si è verificato un errore.
Riprova più tardi o contatta l'assistenza.
Nei log interni, invece, il team tecnico può conservare i dettagli necessari alla diagnosi, proteggendoli da accessi non autorizzati.
Ridurre i dettagli tecnici non necessari
Quando possibile, è utile limitare la divulgazione di versioni e informazioni identificative nei banner HTTP.
Questa misura riduce i dettagli disponibili, ma non sostituisce aggiornamenti, autenticazione e configurazioni corrette.
Proteggere file e configurazioni
Backup, log, file di configurazione e documentazione interna non dovrebbero essere pubblicati accidentalmente nella directory accessibile via web.
È preferibile conservare i segreti fuori dalla directory pubblica e applicare permessi adeguati.
Verificare le risposte delle API
Un'API potrebbe restituire più campi del necessario, includendo dettagli interni o dati che l'utente non dovrebbe ricevere.
È opportuno definire esplicitamente quali informazioni ogni endpoint può restituire e verificare i permessi prima di fornire dati sensibili.
Information disclosure: come stabilire la priorità?
Non tutti i casi hanno la stessa gravità.
| Informazione esposta | Valutazione iniziale | | ----------------------------------------------- | --------------------------------------------------------- | | Nome generico del server | Generalmente bassa, da valutare nel contesto | | Versione precisa di un componente obsoleto | Approfondire la presenza di vulnerabilità note | | Percorso interno di un file | Verificare cosa rivela e se è associato ad altri problemi | | Dettagli di una query SQL | Verificare error handling e dati esposti | | Token o credenziali valide | Priorità elevata: proteggere e valutare la revoca | | Dati personali accessibili senza autorizzazione | Problema potenzialmente grave da gestire tempestivamente |
Questa tabella è orientativa: la priorità effettiva dipende dalla sensibilità delle informazioni, dalla loro validità e dall'impatto possibile.
In sintesi
L'information disclosure è un problema spesso sottovalutato perché non sempre produce un effetto immediatamente visibile.
Un messaggio di errore troppo dettagliato o un header HTTP possono sembrare aspetti secondari, ma contribuiscono a descrivere l'architettura di un sistema e, in alcuni casi, possono esporre informazioni riservate.
La soluzione consiste nel ridurre le informazioni pubbliche non necessarie, gestire correttamente gli errori e verificare periodicamente le risposte dell'applicazione.
MiHakero può aiutare a individuare alcuni segnali osservabili dall'esterno, come informazioni tecniche e configurazioni esposte, offrendo un punto di partenza per approfondire i casi che meritano attenzione.