Vulnerabilità XSS: scopriamo perché sono pericolose

• Howto

Parliamo di attacchi cross site scripting, una tipologia di aggressione che gli utenti, in generale, ancora conoscono molto poco e che è oggi utilizzata da molti malintenzionati per rubare credenziali d’accesso ai vari servizi online, compresi quelli per la gestione di conti correnti bancari e carte di credito.

Le vulnerabilità cross site scripting, spesso identificate con l’acronimo XSS, possono affliggere molti siti web, compresi quelli gestiti da aziende di gran fama. Ed, anzi, sono proprio i siti web di realtà ormai consolidate e più conosciute dagli utenti ad essere maggiormente prese di mira per questo genere di attacchi.

Ogniqualvolta facciamo clic su un collegamento ipertestuale, presente in una pagina web, il nostro browser (client) invia una richiesta al server web, attraverso il protocollo HTTP. I metodi di richiesta di una pagina web possono essere diversi sebbene i principali, ai quale i tecnici si riferiscono prevalentemente, siano GET e POST.
In HTML, nel momento in cui si vogliano trasmettere delle informazioni al server, ad esempio i dati inseriti in un comune modulo online (“form”), si utilizza solitamente il metodo POST: i dati vengono codificati dal browser sotto forma di un URL. Nel caso di GET, invece, il contenuto delle variabili trasmesse ad una pagina web, verrà visualizzato direttamente nella barra degli indirizzi del browser.
I dati inviati al server attraverso richieste GET o POST verranno elaborati per rispondere opportunamente alle richieste specifiche dell’utente. In tutte le pagine web dinamiche, il cui contenuto, cioè, viene generato dal server al momento della richiesta proveniente dal sistema client collegato e che quindi, di volta in volta, può differire, si analizzano le richieste GET e POST per visualizzare il materiale richiesto dall’utente (client). In particolare, i dati ricevuti attraverso richieste GET e POST viene solitamente impiegato, previa analisi ed eventuali rielaborazione, per effettuare interrogazioni su una base dati. Ad esempio, se una certa pagina web è stata studiata per visualizzare l’elenco degli articoli appartenenti a diverse categorie, attraverso l’uso di GET e POST, si possono estrarre da un database collegato e quindi visualizzare solo i contenuti che si riferiscono alla specifica categoria indicata dall’utente.

Coloro che intentano attacchi di tipo cross site scripting sfruttano delle vulnerabilità presenti nelle pagine web dinamiche per modificare il codice della pagina web successivamente proposta al visitatore oppure per effettuare reindirizzamenti verso altri siti web, diversi da quello realmente richiesto.
Vulnerabilità di questo tipo derivano da una imperfetta gestione del contenuto delle variabili utilizzate dalla pagina dinamica. In queste circostanze, un aggressore può “inettare” del codice javascript “maligno” all’interno di una pagina web.

Precisiamo subito che gli attacchi cross site scripting non agiscono assolutamente “lato server”. In altre parole, non è il server che ospita la pagina dinamica ad essere violato.

Vediamo più da vicino il funzionamento di uno dei più comuni attacchi di tipo cross site scripting.

Supponiamo che un aggressore individui una pagina web dinamica che può essere oggetto di attacco. L’aggressore nota come tale pagina sembri elaborare numerosi parametri. Se, modificando il contenuto dei vari parametri elencati nella barra degli indirizzi del browser, la pagina web sembra riutilizzarne uno o più di essi ripubblicandone il contenuto nella pagina generata dinamicamente, è possibile tentare un attacco cross site scripting.
L’aggressore, allora, proverà ad inserire, in calce al contenuto di un parametro visualizzato nella barra degli indirizzi (i più “papabili” sono solitamente i valori che appaiono essere di tipo stringa), del codice javascript.
Qualora il programmatore della pagina dinamica non abbia opportunamente provveduto a scrivere una funzione che “depuri” i parametri in ingresso degli elementi potenzialmente nocivi (i.e. tag HTML, apici, simboli utilizzati dal linguaggio di programmazione,…) e provveda a riscrivere il contenuto del “parametro vulnerabile” sulla pagina successivamente proposta all’utente, può succedere che il codice maligno venga “iniettato” nel corpo della pagina.

Fonte: Microsoft MSDN

Ovviamente, l’aggressore – una volta scoperta la vulnerabilità – dovrà indurre gli utenti del sito che ospita pagina vulnerabili ad attacchi XSS, a cliccare su un link contenente lo script nocivo.

Facciamo un esempio:
Supponiamo che la pagina seguente del sito nomedominio.xx venga così richiamata:

http://www.nomedominio.xx/paginavulnerabile.php?p1=ciao&p2=123&p3=abc

L’aggressore scopre che il contenuto del parametro “p1” viene riscritto sulla pagina dinamica generata senza alcun controllo preventivo.
Egli, allora, provvede a richiamare la pagina dinamica posponendo al contenuto ciao del parametro “p1” il codice javascript “maligno”, ad esempio nella forma <script>...codice javascript nocivo...</script>
Il codice javascript può anche contenere riferimenti a file .js dannosi memorizzati su siti web remoti, completamente diversi da quello visitato dall’utente.

La vulnerabilità XSS di YouTube mostrata in questa immagine è stata risolta.

Poiché il codice javascript dannoso, in forza della vulnerabilità legata alla non corretta gestione del contenuto del parametro in ingresso, viene eseguito all’interno dello stesso contesto del sito web visitato, se l’aggressore riuscirà ad indurre un utente a visitare il link da lui prodotto, potrà – per esempio – rubare credenziali di accesso o leggere e trasmettere altrove il contenuto dei cookie legati al sito web oggetto dell’attacco XSS.

Supponiamo di avere aperto più finestre (o schede) con il medesimo browser. L’eventuale sito “maligno” visualizzato nella prima finestra o scheda non può essere in grado di accedere ai dati visualizzati in un’altra delle finestre del browser aperte. E ciò grazie ad una particolare policy introdotta nei browser web che impedisce questi scenari.
L’attacco cross site scripting tenta, in qualche modo, di aggirare questo aspetto tecnico: allorquando l’aggressore dovesse riuscire ad “inettare” codice javascript “maligno” all’interno di una pagina web, tale codice verrebbe regolarmente eseguito poiché il browser lo considera come proveniente dal medesimo contesto (la stessa finestra o scheda del browser).

Servizi famosissimi come MySpace, YouTube e PayPal sono stati, nel corso del tempo, vittime di attacchi XSS.
Emblematico il recente caso di un istituto di credito nostrano, ripreso anche da Netcraft (ved. questa pagina).
Gli aggressori, dopo aver individuato una pagina affetta da vulnerabilità XSS, hanno iniziato ad inviare una pesante campagna di spam, nell’intento di “intercettare” clienti della banca in questione. Nell’e-mail “phishing” veniva inserito un link contenente anche un javascript “maligno”. La pagina oggetto della vulerabilità XSS utilizzava un certificato SSL: gli aggressori, grazie all’URL modificato trasmesso via e-mail, sono stati in grado di “iniettare” un IFRAME all’interno della pagina di login dell’istituto di credito. L’incauto utente che avesse provveduto a cliccare sul link ricevuto via e-mail avrebbe ritenuto di essere sul sito della banca. Inserendo i propri dati di autenticazione, questi sarebbero però stati trasmessi su un server “maligno” sito a Taiwan e ciò in forza della presenza dell’IFRAME maligno aggiunto via javascript.

Come sottolineò già a suo tempo il team di Kaspersky, è bene non fidarsi troppo delle connessioni ritenute sicure (https:). Anche in questi casi, se la pagina web è vulnerabile ad attacchi XSS il suo contenuto può essere infatti modificato.

Gli attacchi XSS sono insomma una “manna dal cielo” per coloro che si macchiano di truffe online (“phishing”). L’utente, infatti, spesso non sospetta dell'”agguato” rassicurandosi nell’osservare che subito dopo il riferimento al protocollo utilizzato (http:// od https://) sia indicato il nome a dominio di un sito web conosciuto e legittimo.

Per difendersi da attacchi XSS è sempre bene diffidare di link trasmessi attraverso la posta elettronica o via “instant messaging”, soprattutto se arrivano da mittenti sconosciuti oppure non fidati.