Il cross-site scripting (XSS) rappresenta uno degli attacchi informatici più comuni, anche per via della semplicità con cui può essere eseguito. Attraverso un code injection nei contenuti di un sito attendibile, è possibile ingannare il browser della vittima per rubare cookie o indurlo a scaricare software malevolo da un fake URL.
Le conseguenze di un cross-site scripting possono essere molteplici. Attraverso varie modalità di esecuzione, un exploit XSS genera una violazione delle policy di sicurezza e protezione dei dati, con la possibilità di coinvolgere informazioni sensibili in merito a transazioni bancarie, fascicoli sanitari o altre operazioni di rilevanza critica, con conseguenze facilmente immaginabili.
I rischi aumentano logicamente in funzione del livello di privilegi dell’utente che subisce la violazione, dal momento che l’attaccante può reindirizzarli a proprio piacimento per ottenere i suoi intenti criminali. In molti contesti le conseguenze di uncross-site scripting (XSS) potrebbero anche apparire irrilevanti, ma se un’azienda dovesse cadere vittima di una violazione di questo genere, rischierebbe concretamente di compromettere la privacy o perdere dati sensibili dei propri clienti, causando inevitabili ricadute a livello reputazionale e possibili azioni di rivalsa legale.
Anche se a prima vista potrebbe apparire meno micidiale rispetto ad altre forme di attacco alla sicurezza informatica, il cross-site scripting non andrebbe in alcun modo sottovalutato. È pertanto opportuno prendere tutte le precauzioni necessarie affinché il codice malevolo inserito dall’attaccante non venga eseguito o la sua azione venga neutralizzata prima che riesca a mettere a rischio l’integrità dei dati della vittima. Come vedremo, si tratta di una missione tutt’altro che impossibile, in cui è spesso la semplice attenzione a fare differenza, soprattutto per quanto riguarda il comportamento degli utenti durante la navigazione su Internet.
Cos’è un attacco cross site scripting o XSS
Come accennato in sede di premessa, il cross-site scripting (XSS) rappresenta un attacco di code injection in cui l’attaccante inserisce uno script malevolo nel contenuto di un sito web attendibile, ingannando il browser web della vittima. Il linguaggio più comune per generare gli script è rappresentato da JavaScript, ma in tempi più recenti si è diffuso il XSS basato su codice sviluppato con altri linguaggi di programmazione, come HTML, Java o Ajax.
In estrema sintesi, il cross-site scripting consente all’attaccante di eseguire script malevoli nel browser di una vittima. Non si tratta, come accade in molti altri casi, di un attacco informatico condotto in maniera diretta, in quanto viene sfruttata una vulnerabilità di un sito web. Quando la vittima visita il sito in questione, il suo browser esegue il codice malevolo presente al suo interno e se questo non viene riconosciuto come tale da uno script blocker o da un antivirus, finisce per subirne inevitabilmente gli effetti.
In maniera analoga ad altri attacchi code injection, ilcross-site scripting (XSS) sfrutta l’incapacità di un browser di riconoscere un markup legittimo da uno malevolo, dal momento che durante la navigazione questi tende ad eseguire qualsiasi script per soddisfare la richiesta dell’utente. Il cross-site scripting è inoltre in grado di aggirare la Same Origin Policy (SOP), una misura di sicurezza che impedisce agli script di un sito web di interagire con quelli di un altro sito web.
Secondo la logica di protezione del SOP, i contenuti di una pagina web dovrebbero infatti provenire dalla medesima fonte, non da situazioni eterogenee, proprio per evitare una pericolosa promiscuità di codice. Il XSS riesce ad impedire l’applicazione di questa misura di protezione e pertanto mandare a buon fine l’inserimento di uno script in una pagina web altrimenti del tutto attendibile agli occhi di un qualsiasi browser. In questo modo, l’attaccante può ad esempio esfiltrare i cookie di navigazione e bypassare le procedure di autenticazione di servizi finanziari o altre attività che prevedono la presenza di dati sensibili, sostituendosi a tutti gli effetti alla vittima, che rimane del tutto ignara di aver subito un attacco di questo genere, se non quando si ritrova di fronte al fatto compiuto, quando ormai è troppo tardi per porvi rimedio.
Gli exploit XSS vengono dunque utilizzati molto spesso per esfiltrare i cookie di sessione, ma possono in realtà eseguire molte altre azioni nocive. Oltre ai data breach nudi e crudi, un XSS potrebbe ad esempio dirottare il browser verso link in grado di diffondere malware. È inoltre possibile causare un defacing dei siti web violati. Il cross-site scripting è altrimenti molto utilizzato in sinergia con le tecniche di social engineering, su tutte il famigerato phishing, per facilitare oltremodo la procedura di inganno della vittima.
La varietà creativa che un attacco basato sul code injection concede agli attaccanti è incredibilmente ampia, al punto di costringere sia i proprietari dei siti vulnerabili che gli utenti che si accingono a visitarli ad alcune accortezze, onde evitare spiacevoli sorprese.
Come viene condotto
Le modalità d’azione di un cross-site scripting sono molte, ma per praticità divulgativa possiamo riassumere tre tipologie di riferimento: il reflected XSS, il persistent XSS e il DOM-based XSS. Vediamo nel dettaglio in cosa consistono.
Reflected XSS
Il reflected XSS rappresenta la tipologia di più diffusa tra i cross-site scripting. Questo genere di attacchi prevede l’inserimento di script dannosi all’interno di un sito verso cui si cerca di indirizzare un visitatore mediante phishing. Se la vittima cade nell’inganno di questa tecnica di social engineering finisce per scaricare inconsapevolmente un payload che viene eseguito dal browser innescando la procedura malevola prevista dall’attaccante.
Persistentcross-site scripting (XSS)
Altrimenti noto come stored XSS, rappresenta la tipologia di cross-site scripting potenzialmente più pericolosa in assoluto. La dinamica prevede che l’attaccante esegua un code injection nella risorsa di destinazione, laddove, a differenza di un reflected XSS, agisce in maniera persistente.
Gli script possono essere infatti collocati in sistemi come i database, i blog, i forum e in applicazioni web come i form per commentare i post, giusto per citare alcune dei target preferiti dagli attaccanti. Tali sistemi sono perennemente in esecuzione per cui quando il browser di un utente accede all’applicazione web finisce per scaricare ed eseguire lo script malevolo, innescando la procedura prevista dall’attaccante.
DOM-based XSS
DOM rappresenta l’acronimo di Document Object Model. Un DOM-based cross-site scripting sfrutta una vulnerabilità presente nel DOM stesso per iniettare lo script malevolo. A differenza del reflected XSS e del persistent XSS, non viene coinvolto il server web, ma soltanto il client, ragion per cui si utilizza altrimenti la denominazione di XSS locale. I DOM-based XSS vengono spesso utilizzati per rubare i cookie delle sessioni di navigazione.
Come capire se si è vulnerabili
Per valutare la vulnerabilità di un sito ad un cross-site scripting vengono solitamente utilizzati degli appositi tool. Si tratta di web scanner in grado di attivare una serie di azioni per capire se un sito o un’applicazione web sia o meno in grado di trasmettere ad un client un input non convalidato, potenzialmente nocivo.
La procedura di web scanning consiste in una simulazione di attacco: uno script injection nelle varie modalità in cui cercherebbe di farlo l’attaccante: variabili GET / POST, cookie, URL e qualsiasi codice possa essere oggetto di un attacco cross-site scripting.
Si tratta di una procedura di vulnerability assessment, pertanto si procede secondo vari obiettivi. Da un lato si cerca di capire se e quali siano le vulnerabilità presenti nel sito o nell’applicazione web. Si cerca quindi di violarle per valutare i possibili effetti dannosi che l’attaccante potrebbe generare. A valle del tutto, si realizza una sintesi delle vulnerabilità, dello script utilizzato per simulare l’attacco e degli effetti generati dallo stesso.
Oltre all’impiego dei web scanner si può procedere attraverso procedure manuali più o meno complesse, a cui si ricorre nel caso in cui si voglia effettuare una valutazione molto specifica sulle possibili vulnerabilità individuate. L’obiettivo di questo sforzo risiede nel comprendere in maniera dettagliata gli effetti sulla sicurezza delle applicazioni, per individuare le misure di mitigazione più appropriate.
Proteggersi da un attacco dicross-site scripting (XSS)
La protezione da un attacco cross-site scripting coinvolge sia i provider dei siti web che gli utenti finali, con procedure e livelli di responsabilità ovviamente molto differenti.
Il gestore di un sito web è responsabile dei dati in esso contenuti. Un contenuto dannoso può provocare al visitatore un danno evidente, con effetti negativi su ampia scala, che vanno dalla penalizzazione sui motori di ricerca, alla perdita di utenti e al danno di immagine in caso di incidenti reiterati o particolarmente rilevanti. Tale condizione può risultare oltremodo gravosa da gestire per i brand e i marketplace attivi in ambito e-commerce, la cui credibilità si riflette automaticamente sulla qualità degli strumenti coinvolti nel customer journey.
Quando si sviluppano siti e applicazioni web è pertanto fondamentale adottare le consuete best practice relative all’escaping, alla sanitizzazione e alla validazione del codice. Tali procedure, se eseguite in maniera efficace, consentono di limitare in maniera sensibile l’insorgenza e gli effetti di vulnerabilità agli attacchi cross-site scripting.
A titolo di best practice, le applicazioni web andrebbero considerate insicure per quanto riguarda qualsiasi valore di input, per cui è importante prevedere sistematicamente dei procedimenti analitici. Una volta che si è ragionevolmente certi che le fonti siano attendibili, è possibile inserirle in una whitelist. Il discorso relativo agli input vale ovviamente anche per i valori di output, ossia i dati in uscita.
Per ovviare a buona parte dei problemi, sarebbe opportuno limitare l’impiego dei metacaratteri HTML, spesso problematici, al punto che certi linguaggi, come Perl, PHP o lo stesso Javascript sono dotati di funzioni predefinite per la sostituzione e il mascheramento di tali contenuti. Per il resto, quando si tratta di monitorare il flusso di dati in ingresso e in uscita è logicamente possibile affidarsi ad un firewall, a patto di saperlo configurare in maniera opportuna, onde evitare un’illusione di falsa sicurezza o di “chiudere troppo”, penalizzando l’esperienza della navigazione.
Lato utente le responsabilità sono ovviamente più limitate e molto spesso un antivirus aggiornato costituisce una misura più che sufficiente per identificare la presenza di script dannosi all’interno dei siti e delle applicazioni web. I browser utilizzati durante la navigazione su Internet sono dotati di tecnologie per evitare l’esecuzione di script dannosi, come le estensioni no-script, progressivamente affinati anche in funzione dell’evoluzione degli attacchi.
È inoltre possibile, agendo sulle impostazioni del browser, disattivare il supporto JavaScript, evitando sul nascere soprattutto l’insorgenza dei DOM-based XSS, dal momento che lo script dannoso non può essere in alcun modo eseguito dal client, vanificando lo sforzo dell’attaccante. Gli utenti più accorti entrano inoltre nello specifico di analizzare le pagine che visitano e, una volta verificata la loro attendibilità, inserirle in apposite whitelist. Per il resto, valgono le consuete best practice di igiene informatica, basate sulla naturale diffidenza nei confronti di dati esterni, come i link contenuti nelle mail di phishing.
