Cross-Site Scripting (XSS)

Cross-site scripting-preferito come XSS-è una vulnerabilità dell’applicazione che ha il potenziale di devastare applicazioni e siti web. XSS è così dilagante e potenzialmente dannoso che continua ad essere incluso nella lista delle 10 principali vulnerabilità dell’Open Web Application Security Project (OWASP).

In effetti il Cross-Site Scripting è la vulnerabilità più comune scoperta dal 2014 e nel 2019 continua ad apparire nella Top 3 delle vulnerabilità segnalate.

In alcuni casi, anche gli script lato browser possono introdurre questa vulnerabilità permettendo ad un attaccante di sfruttarla senza che l’utente target faccia una richiesta all’applicazione web.

Gli attaccanti sfruttano l’XSS creando codice maligno che può essere indirizzato ad un altro utente, viene poi eseguito dal browser ignaro. Poiché lo script è il più delle volte incluso nel contenuto della risposta dell’applicazione web, viene eseguito e ha lo stesso accesso come se lo script fosse legittimo. L’accesso può essere consentito ai token di sessione, ai cookie e anche alle informazioni riservate o sensibili a cui il browser ha accesso su quel sito, anche riscrivendo il contenuto della pagina HTML.

Attacchi XSS riflessi

Negli attacchi XSS riflessi, lo script dannoso viene iniettato in una richiesta HTTP (di solito tramite un link appositamente creato fornito all’utente). Come varietà più semplice, utilizza parametri di input nella richiesta HTTP che possono essere facilmente manipolati per includere il contenuto dello script dannoso. Lo script dannoso viene poi riflesso dal server in una risposta HTTP e viene eseguito nel browser della vittima.

In questo caso, agisce come un XSS memorizzato senza effettivamente memorizzare dati dannosi sul server.

Ecco un esempio di attacco XSS riflesso:

Diciamo che example.com/profile contiene un parametro name. L’URL per la richiesta sarebbe come questo: https://example.com/profile?user=Tammy. Sulla base di questo input, l’applicazione web risponderebbe così con “Hi Tammy” all’inizio della pagina. Se i parametri non vengono convalidati per garantire che contengano solo i dati attesi, un attaccante potrebbe far visitare all’utente una versione dannosa dell’URL come questa: https://example.com/profile?user<script>some_malicious_code</script>.

Quando la risposta viene inviata al browser, include lo script dannoso, che viene poi eseguito nel browser, probabilmente senza che l’utente lo sappia. Questo è un esempio di attacco XSS riflesso, in quanto il codice dannoso viene immediatamente “riflesso” all’utente che effettua la richiesta.

Attacchi XSS memorizzati

In quello che è conosciuto come un attacco XSS memorizzato o persistente, il contenuto dannoso viene consegnato direttamente, insieme alla risposta del server quando l’utente carica una pagina web. Così il contenuto è già memorizzato nel database del sito web (da qui il nome di tali attacchi). Gli utenti entrano semplicemente nella pagina web violata e cadono vittime di tali attacchi.

Ogni singolo utente che apre un sito web compromesso è quindi a rischio di furto dei propri dati personali, e quindi questo potrebbe essere considerato il tipo più pericoloso di attacco XSS.

Ma come fa il contenuto dannoso ad entrare nel database per cominciare? Nella maggior parte dei casi, viene introdotto attraverso moduli di pagine web non protette in cui l’input dell’utente non è adeguatamente convalidato e sanificato. Se i dati inseriti da un hacker non vengono convalidati sia dal lato client che dal lato server, verranno salvati nel database. Per esempio, tale input potrebbe includere un’area di testo per i commenti, un editor di testo per i post, un editor di dati personali o altri moduli.

Una volta che un attaccante riesce a inviare contenuti dannosi al server e tali contenuti appaiono non filtrati su una pagina web, tutti gli utenti diventano potenziali vittime.Il rimedio comune agli attacchi XSS memorizzati è di sanitizzare l’input sia sul front end che sul back end dell’applicazione. La sanitizzazione implica una combinazione di validazione dei dati e l’escaping dei caratteri speciali o il loro completo filtraggio ed è una best practice comune per la sicurezza web e JavaScript.

Attacchi XSS basati sul DOM

Document Object Model (DOM) è un’interfaccia che permette alle applicazioni di leggere e manipolare la struttura di una pagina web, il suo contenuto e lo stile. In un attacco XSS basato su DOM, la vulnerabilità risiede nel codice script lato browser e può essere sfruttata senza alcuna interazione con il server, modificando l’ambiente nel browser della vittima ignara.

A volte, gli attacchi XSS basati su DOM sono simili agli attacchi riflessi. L’esempio precedente di un attacco XSS riflesso può essere applicato in questo caso con un solo presupposto: L’applicazione web legge i dati direttamente da una stringa di query.

Supponiamo che l’applicazione utilizzi il parametro di query “name” per visualizzare istantaneamente il nome dell’utente sullo schermo mentre si aspetta il caricamento del resto della pagina. Senza un’adeguata convalida, questo può produrre lo stesso risultato di un attacco riflesso, se l’hacker riesce a far aprire alla vittima un link sospetto.

Come per lo stored XSS, per prevenire gli attacchi riflessi e basati sul DOM, gli sviluppatori dovrebbero implementare la convalida dei dati ed evitare di visualizzare l’input grezzo dell’utente, nonostante la presenza o l’assenza di comunicazione con il server.

Quali sono i vettori di attacco Cross-site Scripting?

Ci sono diversi vettori comunemente utilizzati negli attacchi XSS:

• < tag script>: Un tag script può essere usato per fare riferimento a codice JavaScript esterno, rendendo questo il punto XSS più diretto. Gli attaccanti possono anche incorporare il codice dannoso all’interno del tag script.
• Eventi JavaScript: Un altro popolare vettore XSS usato dagli attaccanti, gli attributi degli eventi, possono essere applicati in una varietà di tag. Tali attributi come “onerror” e “onload” sono esempi.
• <body> tag: Gli attributi degli eventi possono anche essere la fonte dello script quando vengono forniti attraverso il tag “body”.
• <img> tag: A seconda del browser in uso, questo attributo può essere utile agli attaccanti per eseguire il codice JavaScript.
• <iframe> tag: Particolarmente efficace per gli attacchi di phishing, questo vettore permette all’attacco XSS di incorporare un’altra pagina HTML nella pagina corrente.
• < taginput>: Alcuni browser permettono la manipolazione attraverso questo vettore, che può essere usato per incorporare uno script.
• <link> tag: Questo tag può contenere uno script, invece del normale uso di collegamento a fogli di stile esterni.
• <table> tag: Dove l’attributo di sfondo normalmente si riferisce a un’immagine, questo potrebbe essere compromesso per riferirsi allo script incriminato.
• <div> tag: Anche questo tag contiene un riferimento allo sfondo e può essere usato allo stesso modo di <table> per riferirsi a uno script.
• <object> tag: Gli script di un sito esterno possono essere inclusi usando questo tag.

Mentre ci sono altri vettori che gli attaccanti XSS usano nei loro sforzi per rubare informazioni e compromettere i siti web, questi sono alcuni dei metodi più comunemente usati. Gli sviluppatori devono aderire a pratiche corrette di escape e sanitizzazione per difendersi da tali attacchi.

A seconda dell’attaccante e del suo intento malevolo, gli attacchi XSS possono provocare diversi impatti, tra cui:

• dirottare la sessione di un utente, utilizzando le credenziali per accedere ad altri siti o reindirizzare l’utente a siti web non desiderati,
• alterare le pagine del sito o inserire sezioni in una pagina web,
• eseguire script per estrarre informazioni sensibili da cookie o database,
• se la vittima ha diritti amministrativi, l’attacco potrebbe estendersi al lato server, causando ulteriori danni o recuperando ulteriori informazioni sensibili.

Passi chiave nei test per le vulnerabilità XSS per le applicazioni web critiche includono:

• utilizzare uno strumento di scansione del codice per rilevare le vulnerabilità che consentono correzioni del codice durante il processo di sviluppo,
• implementare funzionalità di test automatizzate che riveleranno le potenziali vulnerabilità in modo completo e veloce.

Diciamo che exmple.com/profile contiene un parametro nome. L’URL per la richiesta sarebbe come https://example.com/profile?user=Tammy. L’applicazione web risponde con “Hi Tammy” all’inizio della pagina sulla base di questo input.

Se il parametro utente non viene convalidato per garantire che contenga solo i dati attesi, un aggressore potrebbe far visitare all’utente una versione dannosa dell’URL che assomiglia a questa:
https://example.com/profile?user<script>some_malicious_code</script>.
Quando la risposta viene inviata al browser, include lo script dannoso che viene poi eseguito nel browser, probabilmente senza che l’utente lo sappia. Questo è un esempio di attacco XSS riflesso. Il codice dannoso viene immediatamente “riflesso” all’utente che ha fatto la richiesta.

• Educazione e consapevolezza: Assicuratevi che tutti gli sviluppatori, i progettisti di siti web e i team di QA siano consapevoli dei metodi che gli hacker utilizzano per sfruttare le vulnerabilità e fornire linee guida e best practice per la codifica. Questo include tecniche di escape/codifica adeguate per l’ambiente dell’applicazione (JavaScript, HTML, ecc.).
• Sanitizzare l’input: Che si tratti di pagine web interne o di siti pubblici, non fidatevi mai della validità dei dati inseriti dall’utente. Vagliare e convalidare qualsiasi campo di dati, specialmente se sarà incluso nell’output HTML.
• Scansionare il codice: Implementare un software che analizza il codice per le vulnerabilità, compreso il cross-site scripting, per garantire che le migliori pratiche siano seguite e minimizzare l’esposizione da XSS e altre vulnerabilità elencate da OWASP.
• Content Security Policy: Utilizzare la Content Security Policy (CSP) per definire ciò che un sito web può fare, e con questo ridurre il rischio di un attacco XSS. Usando la CSP, gli XSS possono essere bloccati completamente (bloccando tutti gli script in linea) o essere ridotti a un rischio molto più basso.

OWASP fornisce ulteriori indicazioni su come prevenire le vulnerabilità XSS con un foglio di istruzioni completo.