Attacchi XSS: la minaccia invisibile nel browser

XSS in parole semplici

Si parla di cross-site scripting quando un attaccante riesce a far includere a un sito uno script malevolo in una pagina che altri utenti andranno a vedere. Il browser si fida dello script perché arriva da un dominio legittimo. Da lì lo script gira con i permessi della vittima e mette le mani su cookie, token di sessione, contenuto della pagina o elementi del DOM.

Un'analogia per chi non scrive codice tutti i giorni. Immagina un post-it attaccato alla bacheca di un'azienda. Se nessuno controlla quella bacheca, chiunque può appenderci istruzioni false che i colleghi finiscono per seguire. L'XSS è la versione digitale di tutto questo: contenuto inaffidabile infilato in un contesto che invece ispira fiducia.

Tre tipi principali (più qualche caso limite)

Conoscere le varianti dell'XSS aiuta a inquadrare in fretta una vulnerabilità. Sono tre quelle principali, più una manciata di casi limite che continuano a comparire in campagne reali.

Stored XSS. Lo script malevolo viene salvato sul server (in un database, un CMS o simili) e servito a ogni visitatore. Sezioni commenti e sistemi di ticket di supporto sono i terreni classici. L'impatto tende a essere ampio, perché ogni lettore fa scattare la payload.

Reflected XSS. Lo script malevolo torna indietro dal server nella stessa risposta, di solito tramite parametri di URL. La vittima clicca un link preparato, il server ribalta l'input dentro la pagina e la payload parte.

DOM-based XSS. La payload non tocca mai il server. Viene eseguita interamente nel browser, manipolando il DOM. Il server può non accorgersi di nulla, e questo rende la rilevazione più difficile, oltre a spiegare perché questo tipo torni così spesso nei report di incidente.

Il self-XSS (convincere l'utente a incollare uno script in console) e l'XS-Search (sfruttare i form di ricerca per dedurre uno stato) restano presenti negli attacchi di oggi. Le contromisure si sovrappongono in larga parte a quelle classiche dell'XSS.

Come funziona un attacco XSS, passo dopo passo

Ricostruire una tipica catena di exploit fa capire bene dove conviene inserire dei controlli per spezzarla.

1. 1

   Trovare un punto d'ingresso

   L'attaccante individua un form, un parametro di URL o un campo memorizzato che restituisce contenuto senza una vera sanificazione.
2. 2

   Costruire la payload

   Scrive un JavaScript che ruba cookie, modifica elementi del DOM, carica malware o dirotta il traffico.
3. 3

   Recapitare la payload

   Tramite un link preparato, un account compromesso o contenuto già salvato sulla piattaforma.
4. 4

   Far eseguire nel browser della vittima

   Il browser si fida della payload perché viene servita dal dominio legittimo.
5. 5

   Esfiltrare i dati o rimbalzare oltre

   Gli script spediscono il bottino agli endpoint dell'attaccante, oppure iniettano altro malware.

Cosa ottengono gli attaccanti

L'XSS non si ferma più al defacement. Le campagne di oggi lo usano per attacchi ad alto impatto, e quattro esiti sono i più ricorrenti.

Furto di sessione. Rubano i token di autenticazione per impersonare gli utenti su portali bancari, dashboard di amministrazione e piattaforme SaaS. L'utente del furto non si accorge mai.

Raccolta di credenziali. Iniettano form di login fasulli, oppure ne modificano di esistenti, per pescare username e password direttamente nel browser, prima ancora che il form legittimo venga inviato.

Distribuzione di malware. Caricano script remoti che scaricano ransomware o miner di cripto. Sono particolarmente efficaci negli attacchi alla supply chain, quando uno script di terze parti ritenuto sicuro finisce compromesso.

Manipolazione sociale. Riscrivono contenuti o infilano messaggi in chat per spingere l'utente verso azioni rischiose o bonifici. Quando è il sito di cui ti fidi a chiederti di muovere dei soldi, i soldi si muovono.

Cinque casi reali in settori diversi

Questi incidenti (presi da divulgazioni pubbliche e report di settore) danno un'idea di quanto possa essere ampio l'impatto di un XSS.

Piattaforma media (2024). Un XSS nella moderazione dei commenti ha permesso agli attaccanti di far mettere like automatici a canali truffa. Il danno reputazionale è stato concreto: un calo del 7 % nelle metriche di fiducia degli abbonati e una settimana di lavoro per ripulire tutto.

Marketplace e-commerce (2023). Un reflected XSS nei codici coupon dirottava gli acquirenti verso pagine di checkout di phishing. Impatto: 4,1 milioni di dollari di addebiti fraudolenti prima che il team si accorgesse del pattern.

Portale sanitario (2022). Uno stored XSS nella messaggistica con i pazienti rubava i cookie di sessione ed esponeva risultati di laboratorio. Conseguenze: una notifica HIPAA e un accordo da 1,2 milioni di dollari.

App bancaria (2021). Un DOM-based XSS tramite widget iniettava richieste di bonifico non autorizzate. La risposta rapida del SOC ha evitato le perdite, ma l'incidente ha fatto partire un audit regolatorio durato mesi.

CMS governativo (2020). Una vecchia vulnerabilità XSS in un CMS legacy ha reso possibile il defacement di comunicazioni comunali sul COVID-19. Il danno si è misurato nella fiducia pubblica perduta in piena emergenza, non in dollari.

Perché l'XSS funziona ancora nel 2025

Nonostante i framework moderni, l'XSS resta anno dopo anno nella OWASP Top 10. Le ragioni sono strutturali, non tecniche.

Codebase enormi continuano ad appoggiarsi alla concatenazione di stringhe e a sistemi di templating datati. I widget di terze parti (pixel di marketing, chatbot, analytics) portano con sé una superficie di attacco che il team di sicurezza non controlla. I nuovi team di engineering ereditano pattern insicuri senza conoscere gli incidenti del passato che hanno plasmato quel codice. Gli scanner automatici si lasciano sfuggire le payload DOM-based, perché analizzano l'output renderizzato lato server e non il DOM vivo, e i pentest manuali spesso guardano da un'altra parte.

Come difendersi nella vita di tutti i giorni

Internet non lo puoi patchare, ma puoi contenere i danni. Quattro abitudini coprono la parte più grossa del rischio reale.

Apri i link sospetti dentro Browser.lol, così sulla tua macchina non parte nessuno script. Disattiva le estensioni del browser che non usi, perché molte allargano la superficie d'attacco XSS. Tieni il browser aggiornato: una CSP (Content Security Policy) moderna blocca gli script inline e molte tecniche XSS classiche. Esci dai siti sensibili quando non li stai usando, perché i cookie rubati perdono in fretta valore se le sessioni scadono presto.

Checklist per sviluppatori e team di sicurezza

Se sviluppi o mantieni applicazioni web, ci sono cinque controlli che danno il ritorno più alto.

Fare escape dell'output in base al contesto. I contesti HTML, JavaScript, URL e CSS richiedono regole di escaping diverse. Un'unica funzione "sanitize" generica si lascia quasi sempre sfuggire qualche categoria.

Affidarsi a framework con sanificazione integrata. React, Vue e Angular riducono la manipolazione diretta del DOM e trasformano la strada sicura nella strada di default.

Implementare una Content Security Policy. Limita le sorgenti degli script e proibisci gli script inline dove puoi. La CSP è una delle difese dal miglior rapporto costi-benefici mai entrate in un browser.

Usare linter e tool SAST orientati alla sicurezza. I plugin di sicurezza di ESLint, Semgrep e SonarQube individuano presto i pattern più comuni, quando correggerli costa ancora poco.

Pianificare review di sicurezza periodiche. Inserisci dei laboratori di payload XSS nella QA e nello scope del bug bounty. Integrando Browser.lol nella QA, puoi eseguire payload di proof of concept non fidati in sicurezza, senza mettere a rischio le macchine degli sviluppatori.

Contenere lo script, tenere il rischio sotto controllo

L'XSS non sparirà. La superficie d'attacco cresce ogni volta che si aggiunge un widget, un pixel di marketing o un'integrazione di terze parti. Ma non sei senza armi. Codice scritto con disciplina previene le vulnerabilità, una buona igiene dell'utente limita l'esposizione, e i browser virtuali fanno in modo che, anche quando uno script malevolo viene eseguito, non arrivi mai a toccare il tuo hardware.

Tratta ogni sito che non conosci come un potenziale vettore XSS. Naviga da un ambiente isolato, tieni credenziali e cookie ben separati, e spingi i team a intervenire sulle cause alla radice. È così che eviti che uno script invisibile si trasformi in un incidente da milioni di dollari.