Cross site scripting esempi e prevenzione: guida pratica
Cross site scripting esempi e prevenzione: ecco la risposta in breve. Il cross site scripting (XSS) è una vulnerabilità delle applicazioni web che permette a un attaccante di far eseguire codice JavaScript malevolo nel browser di altri utenti. Si previene trattando ogni dato in ingresso come non affidabile: codifica dell'output, validazione dell'input, Content Security Policy e cookie protetti.
In questa guida vediamo come funziona XSS, quali sono i tre tipi principali, alcuni esempi concreti e le misure pratiche per ridurre il rischio. Il taglio è pensato per le aziende, in particolare per chi gestisce e-commerce, portali clienti e applicazioni web a Milano.
Cos'è il cross site scripting e perché è pericoloso
XSS nasce quando un'applicazione inserisce in una pagina web dei dati forniti dall'utente senza controllarli o codificarli correttamente. Il browser della vittima non distingue tra lo script legittimo del sito e quello iniettato dall'attaccante: esegue entrambi con gli stessi privilegi.
Il bersaglio quindi non è direttamente il server, ma gli utenti del sito: clienti, dipendenti, amministratori. Uno script eseguito nel loro browser può leggere informazioni visibili nella pagina, modificare ciò che l'utente vede o compiere azioni a suo nome.
È una categoria ben distinta dalla SQL injection, che colpisce invece il database lato server. Entrambe derivano dallo stesso errore di fondo: mescolare dati e istruzioni senza separarli. Per il quadro generale su come queste falle diventano attacchi, puoi leggere la guida sulle vulnerabilità informatiche e su come vengono sfruttate.
Cross site scripting esempi e prevenzione: i tre tipi di XSS
Capire il tipo di XSS aiuta a scegliere la difesa giusta. Ecco il confronto sintetico.
| Tipo | Dove vive il codice malevolo | Come colpisce |
|---|---|---|
| Reflected | Nell'URL o nella richiesta | La vittima clicca un link costruito ad hoc |
| Stored | Nel database o nei contenuti del sito | Colpisce chiunque visualizzi la pagina |
| DOM-based | Nel JavaScript lato client | La pagina stessa manipola male i dati nel browser |
XSS reflected: l'esempio del campo di ricerca
Immagina un sito che mostra "Hai cercato: ..." riportando nella pagina il testo digitato. Se il testo non viene codificato, un attaccante può costruire un link con uno script al posto del termine di ricerca e inviarlo alla vittima via email o messaggio.
Esempio illustrativo: un link che contiene nel parametro di ricerca la sequenza <script> ... </script>. Se la pagina la riporta senza codifica, il browser la esegue.
L'attacco richiede che la vittima clicchi, quindi spesso si accompagna a tecniche di phishing. Il link può sembrare del tutto legittimo perché il dominio è quello reale dell'azienda.
XSS stored: l'esempio del commento o del ticket
Nel caso stored, lo script viene salvato dall'applicazione: in un commento, nel profilo utente, in una recensione o nel messaggio di un ticket di assistenza. Ogni persona che apre quel contenuto esegue il codice, senza nemmeno cliccare su un link sospetto.
È la variante più insidiosa quando il contenuto viene letto da personale con privilegi elevati, ad esempio un operatore del supporto che apre un ticket dal pannello di amministrazione.
XSS DOM-based: l'esempio del JavaScript lato client
Qui il problema non è il server, ma il codice JavaScript della pagina. Se uno script legge un dato dall'URL e lo inserisce nella pagina con funzioni come innerHTML, senza controlli, l'attaccante può far eseguire codice senza che il server veda mai il payload nelle risposte.
Per questo motivo i test automatici lato server non sempre lo individuano: serve analizzare anche il comportamento del front-end.
Come si sviluppa un attacco XSS: dalle fasi alle conseguenze
Nelle fasi di un attacco informatico (la cosiddetta kill chain), XSS è spesso un punto d'ingresso o un anello intermedio. Un percorso tipico è questo:
- Ricognizione: l'attaccante cerca form, parametri URL e campi che riportano input nelle pagine.
- Verifica: prova input di test per capire se vengono codificati o restituiti così come sono.
- Sfruttamento: costruisce un payload adatto al contesto (HTML, attributo, JavaScript).
- Consegna: invia il link alla vittima o inserisce il contenuto malevolo in una pagina visibile ad altri.
- Azione: lo script ruba dati di sessione, altera la pagina o compie operazioni a nome dell'utente.
Le conseguenze dipendono da chi viene colpito. Se la vittima è un amministratore, l'XSS può diventare un trampolino per ottenere accessi più ampi, in una logica simile a quella della privilege escalation. Per questo non va mai considerata una falla "minore" a priori.
Quali danni può causare una vulnerabilità XSS
I rischi concreti per un'azienda sono diversi e vanno valutati caso per caso:
- Furto di sessione: se i cookie non sono protetti, lo script può sottrarli e permettere di impersonare l'utente.
- Phishing dall'interno del sito: finti moduli di login mostrati su un dominio autentico, molto più credibili.
- Azioni non autorizzate: modifica di dati, invio di richieste o cambi di impostazioni a nome della vittima.
- Danno reputazionale: contenuti alterati o reindirizzamenti verso siti malevoli.
- Possibili profili di responsabilità: se vengono esposti dati personali di clienti, possono entrare in gioco gli obblighi in materia di protezione dei dati.
Come prevenire il cross site scripting: le misure che funzionano
La prevenzione efficace combina più livelli. Nessuna singola misura basta da sola, ma l'insieme riduce drasticamente la probabilità e l'impatto.
Codifica dell'output in base al contesto
È la difesa principale. Ogni dato inserito in una pagina va codificato in modo adatto al punto in cui compare: corpo HTML, attributo, JavaScript o URL. Il contesto conta, perché una codifica corretta per l'HTML può non bastare dentro uno script.
Validazione e sanificazione dell'input
Accetta solo ciò che ti aspetti: formato, lunghezza e caratteri consentiti. Se devi permettere HTML (ad esempio in un editor di testo), usa librerie di sanificazione consolidate invece di scrivere filtri artigianali, che si aggirano con facilità.
Content Security Policy e cookie protetti
Una Content Security Policy ben configurata limita da dove il browser può caricare ed eseguire script, riducendo l'effetto di un'eventuale iniezione. Sui cookie di sessione conviene attivare gli attributi HttpOnly, Secure e SameSite.
Buone pratiche di sviluppo
- Usa framework e template che applicano la codifica automatica e non disattivarla senza motivo.
- Evita funzioni che inseriscono contenuto grezzo nella pagina, come innerHTML, quando non servono.
- Mantieni aggiornati librerie, plugin e CMS: molte XSS arrivano da componenti di terze parti.
- Inserisci controlli di sicurezza nel processo di revisione del codice.
- Considera un Web Application Firewall come protezione aggiuntiva, non sostitutiva.
Come verificare se la tua applicazione è vulnerabile
Dopo aver messo in atto le difese, bisogna verificarle. Un buon punto di partenza è un vulnerability assessment, che individua in modo sistematico le debolezze note. Per capire se una falla è davvero sfruttabile nel tuo contesto, serve invece un pentest, in cui un tecnico prova a sfruttarla come farebbe un attaccante.
Quando una vulnerabilità in un componente di terze parti riceve un identificativo CVE, trovi la descrizione e un punteggio CVSS nelle banche dati pubbliche. Il CVSS indica la gravità tecnica in una scala numerica, ma non sostituisce l'analisi del tuo caso: una XSS su una pagina pubblica e una su un pannello interno hanno impatti diversi. Controlla sempre la fonte ufficiale per i dettagli aggiornati.
Infine, i risultati vanno inseriti in un processo continuo: priorità, correzione, nuovo test. Se vuoi strutturarlo, la guida alla gestione delle vulnerabilità spiega come organizzare queste attività.
Conclusione
Il cross site scripting resta una delle falle più comuni nelle applicazioni web perché basta un campo non codificato. Conoscere i tre tipi, applicare codifica dell'output, validazione, CSP e cookie protetti, e verificare tutto con test periodici è il modo più concreto per ridurre il rischio.
Se gestisci un sito o un'applicazione web e vuoi capire quanto sei esposto, puoi approfondire i servizi di Fred for Security e valutare con un professionista quale verifica sia più adatta alla tua realtà.
Domande frequenti
Il cross site scripting può colpire anche un sito WordPress?
Sì. WordPress, come qualsiasi CMS, può essere esposto a XSS tramite plugin, temi o codice personalizzato non aggiornati. Il rischio dipende dalla qualità del codice che gestisce l'input degli utenti. Aggiornare regolarmente il core e i componenti, e rimuovere quelli inutilizzati, riduce molto la superficie d'attacco.
Un firewall o un WAF bastano a fermare gli attacchi XSS?
No, da soli non bastano. Un Web Application Firewall può bloccare molti payload noti e dare un livello di protezione in più, ma può essere aggirato. La difesa solida resta correggere il codice con output encoding, validazione e Content Security Policy, usando il WAF come misura complementare.
Quanto è grave una vulnerabilità XSS rispetto a una SQL injection?
Dipende dal contesto. La SQL injection colpisce il database lato server, mentre XSS colpisce gli utenti e le loro sessioni nel browser. Una XSS su un'area amministrativa può però portare a conseguenze molto serie. Per valutarla conviene usare il punteggio CVSS e considerare i dati realmente esposti.
Ogni quanto conviene testare un'applicazione web contro XSS?
Conviene testarla a ogni rilascio rilevante e almeno periodicamente, ad esempio una volta l'anno tramite penetration test. Servono controlli anche dopo modifiche importanti a form, ricerca o area utenti. La frequenza ideale dipende dalla criticità dell'applicazione e dai dati che gestisce.