La grande diffusione dei siti a contenuto dinamico che utilizzano
linguaggi lato server (come ASP e PHP) ha favorito lo sviluppo di particolari
tecniche di hacking ideate per colpire gli utilizzatori delle applicazioni
web. Una delle tecniche più conosciute prende il nome di Cross
Site Scripting, spesso abbreviata con CSS (oppure XSS, per
non confondere la sigla con quella dei fogli di stile nelle pagine web).
Il CSS permette ad un aggressore di inserire codice arbitrario
come input di una web application, così da modificarne il comportamento
per perseguire i propri fini illeciti. Se uno script consente questo
tipo di attacco, è facile confezionare un URL ad hoc e inviarlo
all'utente che sarà vittima del sotterfugio. All'utente, ignaro
di questa modifica, sembrerà di utilizzare il normale servizio
offerto dal sito web vulnerabile. Pagine web o e-mail sono i mezzi ideali
per portare a termine l'attacco.
I pericoli del Cross Site Scripting
Quando utilizziamo un servizio che richiede l'inserimento di username
e password, spesso questi dati vengono registrati sul nostro computer
sotto forma di Cookie (un file di testo) per non doverli
digitare ogni volta. Per ovvi motivi di sicurezza, i dati contenuti
nel cookie sono accessibili solo dal sito web che li ha creati. Ma supponiamo
che il sito in questione utilizzi una applicazione vulnerabile al CSS:
l'aggressore potrà iniettare un semplice JavaScript che legge
il cookie dell'utente e lo riferisce. Il browser dell'utente permetterà
la lettura, perchè in effetti il JavaScript viene eseguito da
un sito autorizzato a leggere il cookie!
Il risultato immediato è evidente: l'aggressore avrà accesso
al cookie e, a seconda delle informazioni contenute, sarà in
grado di leggere la nostra posta, oppure di utilizzare il nostro nickname
nel forum che frequentiamo (e i nostri privilegi, se ad esempio siamo
amministratori), e così via.
Oltre al danno, la beffa: il Cross Site Scripting solitamente richiede
un intervento attivo da parte della vittima per poter funzionare: anche
il click su un link in una pagina web o in un messaggio di posta elettronica
può nascondere insidie di questo tipo. Facciamo dunque attenzione
ai link sospetti: se contengono i tag <script>
all'interno, o se troviamo codice esadecimale (utilizzato perchè
viene interpretato normalmente dal server ma nasconde agli occhi dell'utente
gli indizi che potrebbero allarmarlo), pensiamoci due volte prima di
aprirli!
Qualsiasi tipo di applicazione web può essere a rischio, se non
implementa opportuni controlli sull'input degli utenti. Vediamo una semplice
classificazione in base all'origine del programma:
- Script casalinghi:
dei moderni linguaggi lato server permette la creazione di script
da utilizzare sui siti web personali. Spesso però le tecniche
basilari della programmazione sicura non sono conosciute e gli script
offrono molti punti vulnerabili agli attacchi di CSS. - Applicazioni web diffuse:
appositamente per essere diffuse e utilizzate in migliaia di siti
(forum, chat, sistemi di gestione dei portali) solitamente sono sviluppate
con un maggiore attenzione ai problemi della sicurezza. Ciò
non esclude la scoperta periodica di nuove sviste nella programmazione
che aprono le porte al Cross Site Scripting. - Server web:
bug XSS quando riguardano i server web, applicazioni molto diffuse
e che solitamente non lasciano presagire la vulnerabilità a
questo tipo di attacco. L'unico vantaggio in questo caso è
la possibilità di accorgersi tempestivamente dell'attacco in
corso, tramite l'analisi dei log del server.
Esempi di attacchi reali
Per meglio comprendere i meccanismi del Cross Site Scripting, vediamo
due esempi reali riguardanti uno dei forum in PHP più diffusi e
il server web di Microsoft. Per il primo esempio consideriamo l'advisory
per vBulletin 2.2.6 e 2.2.7 pubblicata su NTBugtraq.
Il forum in questione consente di interagire con il programma di messaggistica
AOL Instant Messenger, ma il parametro "aim" dell'URL
(che viene stampato poi nella pagina) non è filtrato in alcun modo.
Proviamo dunque a inserire un JavaScript come valore della variabile e
vediamo cosa succede:
Lo script viene inserito nel codice html della pagina e quindi interpretato
dal browser dell'utente. Il risultato sarà una popup contenente
tutti i dati contenuti nel cookie salvato dal forum: username, password,
ultima visita e così via. Anche se i valori sono in forma cifrata,
possono essere utilizzati dall'aggressore per sostituirsi a noi.
Sicuramente i tag all'interno dell'indirizzo possono destare sospetti.
Ma se li sostituiamo con un più criptico codice esadecimale (ad
esempio il tag <script> si traduce in %73%63%72%69%70%74) sarà
più difficile che la vittima si accorga dell'inganno. Attenzione
dunque agli indirizzi che presentano una quantità anomala di segni
percentuale "%".
Neanche i web server sono immuni dagli attacchi di Cross Site Scripting,
anche se in questo caso si tratta di bug più difficili da scoprire
e da sfruttare. Il server web di Microsoft IIS 5.0, uno
dei più utilizzati, ha avuto in passato vari problemi con l'interpretazione
delle estensioni supportate per default. Uno di questi riguardava la possibilità
di un attacco XSS tramite la preparazione di un indirizzo URL molto lungo
che il server non riusciva a gestire (SecurityFocus
Bugtraq) .
Normalmente la richiesta di una pagina inesistente con estensione .IDC
dovrebbe generare un errore di codice 404. Il bug però faceva in
modo che il server restituisse una pagina di errore non standard, contenente
l'intero URL richiesto senza alcun controllo sull'input. Come abbiamo
visto, quando un JavaScript viene inserito in una pagina html, il browser
dell'utente lo interpreta come se facesse parte della pagina originale.
Bastava quindi inserire lo script all'interno dell'URL per vederlo eseguito:
http://www.host.com/<long_buffer><script>alert(document.cookie)</script>
Il parametro <long_buffer> sta per un insieme di caratteri casuali,
in modo che la lunghezza totale dell'URL superi i 334 caratteri. Questa
è la lunghezza minima del buffer per la quale il server inizia
a mostrare il comportamento anomalo. Consideriamo che il JavaScript è
solo uno dei linguaggi che si possono iniettare nelle pagine tramite il
CSS: anche VBScript, ActiveX, Flash si prestano al "gioco".
Contromisure
I bug riscontrati nelle applicazioni web solitamente vengono risolti in
breve tempo e le patch sono integrate nelle versioni successive degli
script. Per la falla di vBulletin che abbiamo analizzato è necessario
scaricare una versione successiva del forum dal sito ufficiale di Jelsoft
Enterprises.
Per risolvere il bug di IIS 5.0 è necessario installare il Service
Pack 3 di Windows 2000 oppure eliminare l'estensione IDC dal mapping
delle applicazioni nel pannello di controllo del servizio Internet Microsoft.
Molti dei bug relativi al Cross Site Scripting possono
essere risolti implementando una procedura di validazione dell'input
negli script. Gli sviluppatori dovrebbero quindi cercare di essere sensibili
ai temi della sicurezza, anche se non indispensabili al fine dell'applicazione.
In qualità di utenti possiamo fare attenzione ai link che apriamo
e alla presenza di anomalie. La disattivazione del supporto JavaScript
o l'impostazione del livello Alto di protezione possono contrastare
i codici nocivi ma creano problemi alla normale navigazione.
Ricordiamo inoltre che le connessioni criptate tramite SSL (riconoscibili
dall'url che inizia con https) non offrono una protezione
aggiuntiva per queste falle.
Ulteriori informazioni:
HOWTO: Prevent Cross-Site Scripting Security Issues
http://support.microsoft.com/default.aspx?scid=kb;en-us;252985&sd=tech
Cross-site Scripting Overview
http://www.microsoft.com/technet/security/news/csoverv.mspx
Cross-Site Scripting: Frequently Asked Questions
http://www.microsoft.com/technet/security/news/crsstfaq.mspx
Quick Start: What Customers Can Do to Protect Themselves from Cross-Site
Scripting
http://www.microsoft.com/technet/security/news/crsstqs.mspx
Hacker! 4.0 - Nuove tecniche di protezione, ed. Apogeo, pp. 612 - 613
