Attacchi XSS: la minaccia invisibile nel browser

XSS in parole semplici

L'XSS nasce quando una pagina interpreta dati non affidabili come contenuto eseguibile. Lo script gira nell'origine di quella pagina: può interagire con il DOM e spesso inviare richieste al sito usando la sessione dell'utente. La politica della stessa origine continua a limitare l'accesso alle altre origini. Uno script non può leggere con document.cookie i cookie marcati HttpOnly, ma può comunque agire nella pagina in cui l'utente ha effettuato l'accesso.

L'attributo SameSite regola soprattutto quando il browser invia cookie nelle richieste tra siti diversi e può mitigare alcuni attacchi CSRF. Non elimina uno script che gira già nella pagina del sito stesso. La documentazione MDN su Set-Cookie distingue il ruolo di SameSite da quello di HttpOnly.

Pensa alla bacheca di un ufficio. Un visitatore dovrebbe poter appendere un biglietto, senza però cambiare le istruzioni o i comandi della bacheca. Nell'XSS, il sito tratta il biglietto di un visitatore come se fosse una parte attiva della bacheca. Il confine si rompe quando un dato finisce in un contesto eseguibile.

Tre tipi principali (più qualche caso limite)

Le tre categorie descrivono da dove entra il dato non affidabile e dove diventa eseguibile. Possono anche sovrapporsi: il server può fornire un valore che il codice sul client inserisce poi in un punto non sicuro del DOM.

XSS persistente. L'applicazione salva contenuto controllato dall'attaccante, per esempio in un commento, un profilo o un ticket, e lo mostra ad altri utenti. L'esposizione dipende da chi vede quel contenuto e da come viene visualizzato.

XSS riflesso. Il server inserisce nella risposta un dato ricevuto nella richiesta, spesso un parametro dell'URL, senza codificarlo correttamente per quel contesto. Un link preparato ad hoc può condurre l'utente a quella risposta.

XSS basato sul DOM. Il codice sul client legge un dato non affidabile e lo passa a un'operazione DOM rischiosa, come innerHTML. Il dato può arrivare da un URL, dalla risposta del server o da un'altra fonte: il tratto distintivo è la trasformazione non sicura nel browser. Consulta la guida OWASP all'XSS basato sul DOM.

Il self-XSS è diverso: qualcuno convince l'utente a eseguire codice di persona, per esempio incollandolo negli strumenti per sviluppatori. Gli XS-Leaks deducono informazioni tra origini tramite effetti osservabili e costituiscono un'altra categoria. Il problema centrale dell'XSS resta lo stesso: un dato non affidabile diventa contenuto attivo in una pagina fidata.

Come funziona un attacco XSS, passo dopo passo

Una sequenza tipica mostra dove i controlli dell'applicazione possono interrompere l'attacco.

1. 1

   Trovare un punto d'ingresso

   L'attaccante cerca un commento, un parametro dell'URL, un messaggio o un altro valore che appare in una pagina.
2. 2

   Raggiungere un contesto non sicuro

   L'applicazione inserisce quel valore dove il browser potrebbe interpretarlo come HTML o script anziché testo.
3. 3

   Far arrivare il contenuto

   L'attaccante induce qualcuno ad aprire la pagina colpita, per esempio tramite un link o un contenuto condiviso.
4. 4

   Eseguire il codice nella pagina

   Se il browser lo esegue, il codice condivide l'origine della pagina e può interagire con contenuti e API disponibili, entro i limiti imposti dal sito e dal browser.
5. 5

   Sfruttare l'accesso disponibile

   Secondo l'applicazione, il codice può cambiare la pagina, leggere dati esposti o inviare richieste con la sessione corrente. L'esito dipende dai controlli del sito.

Cosa può fare il codice iniettato

L'XSS non si limita a modificare l'aspetto della pagina. L'impatto dipende dai dati e dalle azioni disponibili nel contesto colpito. Questi quattro esiti mostrano le possibilità, senza indicarne la frequenza.

Azioni sull'account. Il codice iniettato può inviare richieste da una pagina autenticata e leggere eventuali token esposti a JavaScript. HttpOnly impedisce di leggere direttamente i cookie, ma non blocca da solo le azioni nella stessa origine. Lo spiega la guida MDN ai cookie.

Acquisizione di credenziali. Un modulo alterato potrebbe raccogliere una password o altri dati mentre l'utente li digita. Perché accada, l'utente deve inserirli in quella pagina: l'XSS non rivela automaticamente password conservate altrove.

Manipolazione della pagina. Il codice può cambiare link, istruzioni o dettagli di un'operazione mostrati all'utente. Può anche caricare altre risorse web entro i limiti delle regole del sito. Per eseguire malware sul dispositivo servirebbe un passaggio distinto, come un exploit del browser o un download avviato dall'utente.

Esposizione di dati. Uno script può leggere informazioni già presenti nella pagina e inviarle altrove se i controlli di rete lo consentono. La politica della stessa origine continua a limitare l'accesso agli altri siti; il rischio riguarda soprattutto dati e permessi del sito vulnerabile.

Cinque scenari illustrativi

Sono esempi ipotetici, non resoconti di incidenti reali. Ciascuno mostra un punto in cui verificare il confine tra dati e codice.

Sito di comunità. L'anteprima di un commento rende attivo l'HTML inviato. Se un moderatore la apre dopo aver effettuato l'accesso, il codice iniettato potrebbe agire nell'interfaccia di moderazione. Occorrono una resa sicura e una verifica delle funzioni riservate ai moderatori.

Negozio online. Un termine di ricerca viene riprodotto nella risposta HTML senza una codifica adatta al contesto. Chi segue un URL preparato potrebbe vedere un link di pagamento alterato. Il dominio legittimo, da solo, non dimostra che quel link sia sicuro.

Portale sanitario. Un messaggio memorizzato appare nel browser di un medico. Anche con cookie HttpOnly, il codice iniettato potrebbe leggere dati già visibili nella pagina o inviare richieste consentite al medico. Contano sia i controlli di accesso sia la resa sicura dei messaggi.

Area clienti finanziaria. Il codice sul client legge un frammento dell'URL e lo scrive in innerHTML. Un link ostile potrebbe cambiare quello che il cliente vede. Controlli lato server e conferme potrebbero comunque bloccare un trasferimento non autorizzato; il difetto nel DOM va corretto a parte.

Sito di informazioni pubbliche. Un vecchio modello CMS considera affidabile l'HTML contenuto nel campo del titolo. Un redattore malevolo o un account compromesso potrebbero alterare le indicazioni pubblicate. Vanno controllati sia i vecchi modelli sia i permessi di chi può alimentarli.

Perché l'XSS continua a esistere

I framework moderni codificano automaticamente molti valori, ma HTML grezzo, API DOM non sicure, scorciatoie nei modelli e codice di terze parti possono aggirare queste protezioni. OWASP considera l'iniezione, incluso l'XSS, un rischio per le applicazioni web. La sua guida alla prevenzione dell'XSS spiega perché una sola misura non copre ogni contesto.

Le applicazioni grandi mescolano vecchi modelli, componenti moderni, testi formattati dagli utenti e script esterni. La soluzione cambia a seconda del punto in cui il dato entra e di quello in cui finisce: testo HTML, attributo, URL, blocco di script e operazione sul DOM richiedono regole diverse. Gli strumenti automatici aiutano, ma testare soltanto le risposte del server può lasciare fuori le trasformazioni sul client. Servono anche prove nel browser e revisione del codice che tratta dati non affidabili.

Accorgimenti pratici per chi naviga

Non puoi correggere un sito vulnerabile, ma puoi limitare ciò che gli esponi. Questi accorgimenti riducono alcuni rischi senza garantire una protezione totale dall'XSS.

Controlla l'indirizzo del sito prima di inserire credenziali o autorizzare operazioni importanti. Aggiorna il browser e rimuovi le estensioni inutili. Separa account o profili quando lavori con livelli di fiducia diversi. Se sospetti che un sito sia compromesso, esci e controlla l'attività dell'account da un dispositivo fidato: la revoca delle altre sessioni dipende dal servizio. Browser.lol esegue il codice del sito in un browser remoto, ma uno script XSS può comunque agire sull'account aperto in quella sessione e sui dati che inserisci o sulle azioni che approvi. Anche il visualizzatore, gli appunti e i download collegano la sessione al tuo dispositivo.

Checklist per sviluppatori e team di sicurezza

La prevenzione spetta all'applicazione. Parti da questi cinque controlli e provali nei contesti realmente usati.

Codifica l'output in base al contesto. Testo HTML, attributi, URL, JavaScript e CSS richiedono trattamenti diversi. Per il testo semplice usa API che inseriscono solo testo; se serve HTML formattato, usa una libreria di sanificazione mantenuta e adatta allo scopo.

Usa con criterio le protezioni del framework. React, Vue e Angular aiutano a codificare i valori mostrati, ma le funzioni per l'HTML grezzo e le modifiche dirette al DOM aggirano parte di questa protezione. Esamina con cura queste eccezioni.

Adotta una CSP restrittiva. Una Content Security Policy ben progettata, basata su nonce o hash, può limitare l'esecuzione di script dopo un'iniezione. È una difesa aggiuntiva, non sostituisce codifica e sanificazione. Consulta la guida OWASP alla CSP.

Controlla il flusso dei dati e le operazioni rischiose. L'analisi statica può segnalare assegnazioni non verificate a innerHTML e altri schemi pericolosi. Affiancale test sulle pagine renderizzate e sui percorsi dei dati nel client.

Esamina le funzioni con accessi elevati. Prova le pagine in cui il personale vede contenuti degli utenti, quelle che consentono testi formattati e quelle da cui partono azioni sensibili. Le prove in un browser remoto possono ridurre l'esposizione locale al codice web, ma non rendono innocua una dimostrazione dell'attacco: usa account di prova ed evita segreti reali.

Tieni i dati fuori dai contesti eseguibili

L'XSS nasce quando un'applicazione supera il confine tra dati e codice. Codifica adatta al contesto, API DOM sicure, trattamento attento dell'HTML formattato e una CSP restrittiva riducono la possibilità che dati non affidabili diventino codice. Attributi dei cookie e controlli lato server possono limitarne alcune conseguenze, ma nessuna misura è una cura universale.

Un browser remoto cambia il luogo in cui gira il codice del sito, ma non corregge il sito vulnerabile e non protegge l'account da azioni compiute nella sessione remota. Separa gli account sensibili, verifica le operazioni importanti e correggi il passaggio dai dati al codice alla fonte. Sono misure complementari perché intervengono su parti diverse del rischio.