In questa sezione, spiegheremo le differenze tra XSS e CSRF, e discuteremo se i token CSRF possono aiutare a prevenire gli attacchi XSS.

Qual è la differenza tra XSS e CSRF?

Il Cross-site scripting (o XSS) permette ad un attaccante di eseguire JavaScript arbitrario all’interno del browser di un utente vittima.

Cross-site request forgery (o CSRF) permette ad un attaccante di indurre un utente vittima ad eseguire azioni che non intende eseguire.

Le conseguenze delle vulnerabilità XSS sono generalmente più gravi delle vulnerabilità CSRF:

• CSRF spesso si applica solo ad un sottoinsieme di azioni che un utente è in grado di eseguire. Molte applicazioni implementano difese CSRF in generale, ma trascurano una o due azioni che rimangono esposte. Al contrario, un exploit XSS di successo può normalmente indurre un utente ad eseguire qualsiasi azione che l’utente è in grado di eseguire, indipendentemente dalla funzionalità in cui la vulnerabilità si presenta.
• CSRF può essere descritto come una vulnerabilità “a senso unico”, nel senso che mentre un attaccante può indurre la vittima ad emettere una richiesta HTTP, non può recuperare la risposta da tale richiesta. Al contrario, XSS è “a due vie”, in quanto lo script iniettato dall’attaccante può emettere richieste arbitrarie, leggere le risposte ed esfiltrare dati a un dominio esterno a scelta dell’attaccante.

I token CSRF possono prevenire gli attacchi XSS?

Alcuni attacchi XSS possono effettivamente essere prevenuti attraverso un uso efficace dei token CSRF. Consideriamo una semplice vulnerabilità XSS riflessa che può essere banalmente sfruttata in questo modo:

https://insecure-website.com/status?message=<script>/*+Bad+stuff+here...+*/</script>

Ora, supponiamo che la funzione vulnerabile includa un token CSRF:

https://insecure-website.com/status?csrf-token=CIwNZNlR4XbisJF39I8yWnWX9wX4WFoz&message=<script>/*+Bad+stuff+here...+*/</script>

Supponendo che il server convalidi correttamente il token CSRF, e rifiuti le richieste senza un token valido, allora il token impedisce lo sfruttamento della vulnerabilità XSS. L’indizio qui è nel nome: “cross-site scripting”, almeno nella sua forma riflessa, comporta una richiesta cross-site. Impedendo ad un attaccante di falsificare una richiesta cross-site, l’applicazione impedisce un banale sfruttamento della vulnerabilità XSS.

Qui sorgono alcune importanti avvertenze:

• Se una vulnerabilità XSS riflessa esiste altrove sul sito all’interno di una funzione che non è protetta da un token CSRF, allora quell’XSS può essere sfruttato nel modo normale.
• Se una vulnerabilità XSS sfruttabile esiste ovunque su un sito, allora la vulnerabilità può essere sfruttata per far eseguire azioni all’utente vittima anche se queste azioni sono protette da token CSRF. In questa situazione, lo script dell’attaccante può richiedere la pagina interessata per ottenere un token CSRF valido, e quindi utilizzare il token per eseguire l’azione protetta.
• I token CSRF non proteggono dalle vulnerabilità XSS memorizzate. Se una pagina che è protetta da un token CSRF è anche il punto di uscita per una vulnerabilità XSS memorizzata, allora quella vulnerabilità XSS può essere sfruttata nel solito modo, e il payload XSS verrà eseguito quando un utente visita la pagina.