Il Cross-site Scripting (XSS) è una vulnerabilità dei siti Web dinamici in cui l’attaccante utilizza del codice malevolo al fine di raccogliere, manipolare e reindirizzare informazioni riservate di utenti ignari che navigano e utilizzano i servizi pubblici o privati disponibili su Internet.
Originariamente, la sigla venne utilizzata per definire tutti gli attacchi compiuti mediante applicazioni che sfruttavano il linguaggio javascript. Nel tempo tale definizione si è ampliata anche per comprendere altri modi di iniezione di codice malevolo tra cui ActiveX, Java, VBscript, Flash e anche HTML.
Indice degli argomenti
Cross-site Scripting: come funziona
La tecnica di funzionamento del Cross-site Scripting è abbastanza semplice. In pratica, un eventuale attaccante remoto potrebbe “iniettare” del codice malevolo nella barra degli indirizzi insieme alla URL digitata dall’ignara vittima in modo tale da far eseguire al server Web su sui è ospitato il sito che sta visitando alcuni comandi che verranno eseguiti solo se il server stesso è stato mal configurato dagli sviluppatori del sito.
Inserendo per esempio del codice javascript, un attaccante è in grado di rubare dati sensibili contenuti nei cookie di sessione, nei token di sessione e via dicendo.
I cookie di sessione, in particolare, sono dei semplici file di testo utilizzati per autenticarsi nei servizi utilizzati dalla vittima. Un attaccante che riuscisse a leggerne il contenuto sarebbe poi in grado di impersonificarla e utilizzare i vari servizi al suo posto.
Per fare un esempio pratico, immaginiamo di andare in una discoteca in cui la biglietteria è mal gestita a tal punto che, quando acquistiamo il nostro biglietto ci viene dato in mano un foglietto di carta con sopra i nostri nome e cognome. Dopo un po’, entra un altro tizio che ci ha spiato e sentito mentre parlavamo col bigliettaio: si avvicina a lui e, invece di pagare il biglietto, gli fornisce le nostre generalità dicendogli di aver perso il biglietto e chiedendogli di timbrarne uno nuovo. A quel punto, il bigliettaio sbadato gli stampa un biglietto uguale al nostro e lo fa entrare.
Paragoniamo ora questo esempio al caso in cui ci colleghiamo al sito di home banking o a un qualsiasi altro tipo di servizio pubblico o privato al quale siamo già registrati e che normalmente utilizziamo per i nostri scopi privati. È facile immaginare quali potrebbero essere le conseguenze.
Analisi tecnica di un attacco
Per scongiurare un attacco di tipo Cross-site Scripting è sempre bene analizzare gli header dei messaggi che riceviamo da un server quando effettuiamo una richiesta di visualizzazione di una pagina Web.
Per farlo, non c’è bisogno di utilizzare strumenti software evoluti: basta anche il browser Chrome, ad esempio.
Una volta aperta la pagina Web che ci interessa, premiamo il tasto F12 per entrare in modalità Sviluppatore. Nella schermata che appare spostiamoci nel tab Network ed eseguiamo uno scan dei contenuti della pagina per analizzare proprio i flag dei cookie: la mancanza di flag come HttpOnly, SameSite e Secure sono sicuramente indice di scarsa sicurezza del sito visitato. Vediamo perché:
- innanzitutto, se il flag Httponly è attivo allora non si può accedere a un cookie attraverso uno script lato client (da valutare se il browser lo supporta), quindi anche se la vulnerabilità XSS fosse presente e un utente dovesse accidentalmente cliccare sul link malevolo, il browser stesso non rivelerebbe il cookie di sessione a un utente non autorizzato;
- il flag Samesite, invece, impedisce agli attacchi di tipo Cross site request forgery. La sua attivazione rappresenta un altro modo utile per prevenire altre attività ingannevoli con lo scopo stavolta di usare il browser stesso dell’utente senza bisogno di rubare il cookie di sessione;
- infine l’attributo Secure. Attivando il flag corrispondente, si forzano i browser ad usare il protocollo HTTPS, connessione cifrata che rende il cookie illeggibile dall’ attaccante.
Il flag Secure, però, non è totalmente sicuro.
Molti siti a volte dispongono di connessioni sia in HTTPS sia in HTTP. Il protocollo HTTPS, in particolare, prevede la cifratura del traffico Internet che impedisce a un attaccante di vedere un cookie con un testo leggibile e in chiaro.
Se il sito dispone anche della versione HTTP, però, un attaccante potrebbe forzare l’utente ad autenticarsi al sito mediante connessione non criptata manipolando l’header set cookie nella richiesta fornita al client dal server e sovrascrivendo il cookie di sessione contenente il flag Secure.
Questo cookie modificato sarà poi usato nelle richieste successive mandate in HTTPS ed ecco come l’XSS ha ancora avuto modo di avere la meglio, sempre che non vengano rigenerate le sessioni dopo un’autenticazione che ha avuto successo.
Supponiamo, adesso, di avere un sito che non abbia nessuna di queste protezioni attive.
Immaginiamo di avere nel sorgente della nostra pagina un codice in PHP come il seguente:
<?php echo $_GET[‘id’]; ?>
Il comando get, ipotizzando di avere una pagina dinamica chiamata index.php, consente di visualizzare informazioni diversificate sul contenuto del sito per esempio di ricette, tipi di automobili e via dicendo.
Se il link all’home page è www.sitoesempio.it/index.php, un eventuale attaccante remoto sfruttando il metodo get potrebbe inserire direttamente all’interno della URL della pagina alcune istruzioni preceduta da un punto di domanda. Un esempio banale è il seguente:
www.sitoesempio.it/index.php?id=10
Banalmente, grazie a questa istruzione l’interprete PHP risponderà che si sta visualizzando l’articolo numero 10.
Analogamente, un attaccante potrebbe aggiungere alla URL un ben più pericoloso codice javascript:
www.sitoesempio.it/index.php?id=<script>alert(document.cookie);</script>
Nel momento in cui il server elabora la richiesta per la pagina Web indicata, il comando viene eseguito e il codice iniettato viene interpretato normalmente dal browser dell’utente in quanto lo sviluppatore del sito non ha pensato di prevedere o di impedire in qualche modo questa possibilità.
Il risultato è che lo script document.cookie abbinato alla variabile alert metterà in evidenza i cookie sottoforma di un messaggio di avviso.
Consigli per difendersi dal Cross-site Scripting
Ovviamente, questo è solo un semplice test per comprendere il funzionamento di un attacco XSS. Un eventuale criminal hacker potrebbe sostituire questo script implementando tecniche ovviamente non visibili all’utente per impedirgli di capire cosa sta succedendo.
Oltre a verificare che il web server sia configurato correttamente, quindi, dobbiamo noi stessi in quanto sviluppatori Web renderci conto che dobbiamo proteggere il codice che sviluppiamo per le app rivolte ai nostri clienti e prevenirne la manomissione da parte di utenti malintenzionati.
Per questo è importante conoscere bene le best practice riguardanti la validazione del codice, la sanitizzazione e l’escaping e quindi tutelare efficacemente i dati sensibili dei nostri clienti anche da attacchi di tipo XSS.
Lato utente, invece, per impedire e proteggersi da un attacco di tipo Cross-site Scripting è necessario, innanzitutto, un buon antivirus sul proprio computer e tenerlo sempre aggiornato con le ultime firme virali disponibili.
È importante, poi, tenere sempre aggiornato anche il browser che usiamo per navigare su Internet ed eventualmente installare uno strumento di analisi in grado di verificare la presenza di vulnerabilità nel codice di un sito Web.
