Cross-Site Scripting (XSS) e CSRF

Cross-Site Scripting (XSS) è una vulnerabilità di injection lato client in cui un attaccante inserisce script dannosi nelle pagine web visualizzate da altri utenti. A differenza della SQL injection, che prende di mira il server, l'XSS prende di mira il browser della vittima. Quando il browser esegue il rendering dello script dell'attaccante, questo viene eseguito con gli stessi privilegi degli script legittimi della pagina, consentendo il dirottamento della sessione, il furto delle credenziali e la distribuzione di malware.

Si verifica un XSS riflesso quando uno script dannoso è incorporato in un URL e il server lo «riflette» immediatamente nella risposta HTTP senza una codifica adeguata. La vittima viene indotta (spesso tramite un link di phishing) a fare clic sull'URL predisposto, causando l'esecuzione dello script dell'attaccante nel suo browser. L'XSS riflesso non è persistente: viene eseguito solo quando la vittima fa clic sul link dannoso.

L'XSS memorizzato (persistente) incorpora lo script dannoso nel database dell'applicazione, ad esempio in un commento o in un post del forum. Ogni utente che visualizza quel contenuto esegue lo script nel proprio browser, rendendo l'XSS memorizzato molto più pericoloso di quello riflesso. L'XSS basato sul DOM si verifica interamente nel browser, quando JavaScript lato client legge dati controllati dall'attaccante dal DOM (ad esempio il frammento dell'URL) e li riscrive nella pagina in modo non sicuro.

La difesa principale contro l'XSS è la codifica dell'output: convertire i caratteri speciali nei corrispondenti riferimenti a entità HTML (<, >, &) prima di eseguirne il rendering nel browser. Un'intestazione Content Security Policy (CSP) limita gli script che possono essere eseguiti, fornendo un'importante difesa secondaria. È inoltre necessario applicare la convalida degli input (allowlist) lato server.

Il Cross-Site Request Forgery (CSRF) sfrutta la fiducia che un sito web ripone nel browser di un utente autenticato. Un attaccante induce il browser della vittima a inviare una richiesta autenticata indesiderata a un sito in cui la vittima ha effettuato l'accesso. Poiché il browser allega automaticamente i cookie di sessione, il server destinatario considera la richiesta legittima. Gli attacchi CSRF comuni trasferiscono fondi, modificano indirizzi email o alterano le impostazioni dell'account.

Immaginate che un utente abbia effettuato l'accesso al proprio conto bancario all'indirizzo bank.com. Un attaccante gli invia un'email contenente un tag immagine nascosto: <img src='https://bank.com/transfer?to=attacker&amount=1000'>. Quando l'email viene aperta, il browser carica automaticamente l'URL dell'immagine, inviando la richiesta di trasferimento con il cookie di sessione bancaria della vittima allegato. La banca la elabora come una richiesta legittima.

La difesa più efficace contro il CSRF è un token CSRF: un valore univoco e imprevedibile incorporato in ogni modulo e verificato lato server. Poiché l'attaccante non può leggere il token da un'origine diversa (per via della same-origin policy), le richieste contraffatte non contengono un token valido e vengono rifiutate. Anche l'attributo cookie SameSite (SameSite=Strict o Lax) impedisce ai browser di inviare cookie nelle richieste cross-site.

XSS e CSRF vengono spesso confusi, ma prendono di mira elementi diversi. XSS inserisce uno script dannoso che viene eseguito nel browser della vittima, sfruttando la fiducia dell'utente nel sito web. Il CSRF contraffà le richieste dal browser della vittima verso un sito attendibile, sfruttando la fiducia del sito nel browser dell'utente. L'XSS può essere utilizzato per sottrarre i token CSRF, concatenando di fatto le due vulnerabilità.

I flag dei cookie forniscono importanti misure di mitigazione contro l'XSS. Il flag HttpOnly impedisce a JavaScript di accedere al cookie tramite document.cookie, rendendo più difficile il furto del token di sessione anche in presenza di XSS. Il flag Secure garantisce che i cookie vengano trasmessi solo tramite HTTPS, impedendone l'intercettazione su canali non cifrati. Entrambi i flag dovrebbero essere impostati su tutti i cookie di sessione come misura di difesa in profondità.

I tester di sicurezza identificano l'XSS inserendo payload di verifica in ogni campo di input, parametro URL, intestazione HTTP e campo JSON. Un semplice test è <script>alert(1)</script>: se viene visualizzata una finestra di avviso, l'XSS è confermato. Strumenti come Burp Suite automatizzano la scansione XSS, mentre OWASP ZAP offre la scansione attiva gratuita. L'XSS basato sul DOM richiede l'analisi di JavaScript lato browser anziché l'ispezione della risposta del server.

Gli attacchi XSS hanno causato danni significativi nel mondo reale. Il Samy worm (2005) si è diffuso su MySpace in 20 ore sfruttando un XSS memorizzato per propagarsi automaticamente a oltre un milione di profili. Gli attacchi XSS possono sottrarre token di sessione per dirottare completamente gli account, reindirizzare gli utenti verso siti di phishing, distribuire exploit per browser (download drive-by) e modificare il contenuto delle pagine per mostrare informazioni false agli utenti presi di mira.

Verificate la vostra comprensione dei concetti di CompTIA Security+ (SY0-701) trattati in questa lezione.

In questa lezione avete appreso che: l'XSS inserisce script nelle pagine visualizzate da altri utenti, il CSRF induce i browser autenticati a inviare richieste contraffatte e la codifica dell'output, la CSP, i token CSRF e l'attributo cookie SameSite sono le principali difese. Ora esamineremo l'autenticazione compromessa e la deserializzazione non sicura.