Un altro tipo di attacco molto comune è l’XSS injection. SI tratta di un tipo di attacco in cui si inietta nella pagina obiettivo del codice malevolo. E’ bene evidenziare che l’XSS Injection è diretto non tanto al sito ma quanto all’utente finale. In genere un malintenzionato inietta il codice malevolo che poi viene eseguito dalla vittima in maniera inconsapevole.
Esistono essenzialmente tre grosse categorie di attacchi XSS:
- Non persistent o reflected
- Persistent o stored
- DOM Based
XSS Injection tipo Non persistent o Reflected
In questo tipo di attacco il codice malevolo viene fornito da un utente malintenzionato all’tente vittima che lo esegue a sua insaputa. Supponiamo ad esempio di fornire ad ua vittima la seguente url
[code]www.sitodiesempio/?userName=<script type="text/javascript">
alert("Questa è una bella vulnerabilità XSS")
<script/>[/code]
Se l’utente vittima carica quella url e il sito ovviamente è vulnerabile all’XSS Injection vedrà un popup con la scritta Questa è una bella vulnerabilità XSS.
XSS Injection Persistent o Stored
In questo tipo di vulerabilità il codice malevole è iniettato in maniera permanente dal malinentenzionato in modo che richiamando la funzione oggetto della vulnerabilità l’exploit si manifesta. Supponiamo di avere un forum con la possibilità di inserire dei commenti senza alcun controllo sugli stessi e supponiamo di inserire come commento del codice malevolo tipo
[code]
<script type="text/javascript">
alert(“Cookie”+document.cookie)
</script>
[/code]
Ogni volta che un qualsiasi utente vedrà la discussione a cui è legato il commento malevolo, quel codice verrà richiamato, inserito nella pagina ed eseguito. In questo caso vedremo un popup con i cookie creati dal sito
XSS Injection di tipo DOM
Questo tipo di vulnerabilità è simile a quella non stored. La differenza consiste nel fatto che mentre quella non stored l’utente visita un link elaborato dal web server che fornisce la pagina con lo script malevolo, negli attachi XSS di tipo DOM il codice rimane sempre nel client, cioè viene elaborato dal browser dell’utente stesso senza la necessità del web server. Questi tipi di attacchi sono particolarmente efficaci nella applicazioni moderne in cui la pagina risponde alle sollecitazioni degli utenti senza la necessità di chiedere dati al server
Esempi di XSS Injection
Per alcuni esempi di attacchi potete far riferimento alla pagina di Owasp
Ve re riporto alcuni:
- <script>alert(“Questa è una vulnerabilità XSS”)</script>
- ”;!–“=&{()}
- <img alt=”” src=”javascript:alert(String.fromCharCode(88,83,83))” />
- </title><script>alert(“XSS”);</script>
- <body onload=alert(‘XSS’)>
Come prevenire l’XSS Injection
Anche in questo caso, come per l’SQL injection, il problema risiede nel fatto che l’applicazione considera validi tutti i dati senza controllarli opportunamente. Validazione da effettuare sempre, sia per quei dati che vengono poi salvati in maniera persistente (database o file) sia per quei dati che non vengono salvati.
Filtriamo i dati che provengono dagli utente o comunque dall’esterno (lo stesso discorso vale anche nel caso in cui i dati di ingresso vengono fornite da altra applicazioni) tramite una white list, cioè una lista di caratteri ammessi, ovviamente in questa lista non ci saranno elementi come
- <
- >
- ‘
- “
- ?
- //
- /*
- &
Codifichiamo le stringhe in HTML in modo che gli eventuali dati malevoli vengono codificati. Evitiamo, poi, di far inserire degli elementi che possono essere interpretati da Javascript come onmouseover
Usiamo solo cookies con l’attributo HTTPOnly, in questo modo il cookie sarà accessibile solo dal server e non da dagli script lato client mitigando il rischio dei furti dei cookies.
Per controllare se un sito è vulnerabile all’XSS injection potete usare l’addon Firefox XSS-ME
