C’è un’antica convinzione, quanto il primo form di login mai scritto in HTML, che dice:
“Se io non ho cattive intenzioni, nessuno le avrà contro di me.”
Un po’ come lasciare la porta di casa aperta perché “tanto non ho niente di importante dentro”.
Benvenuti nel mondo del Cross‑Site Scripting, o come lo chiamano gli amici: XSS.
Un nome tanto tecnico quanto subdolo, perché come ogni maestro dell’inganno, l’XSS non si presenta mai per quello che è. Non bussa e non chiede permesso, si infila, silenzioso come un ladro notturno.
🤖 Cos’è, davvero, l’XSS?
Il Cross‑Site Scripting è l’arte (sì, l’arte) di convincere un sito a eseguire codice che non gli appartiene, sfruttando la sua ingenuità: fidarsi dei dati che riceve dagli utenti.
Prendiamo un tipico modulo contatti:
“Ciao, volevo solo dire che la tua azienda è fantastica!
<script>alert('boom')</script>“
Lo inviamo al server, che lo riceve, lo archivia o lo riflette nella pagina web… e lo pubblica. Senza saperlo, spalanca una porta per gli script malintenzionati.
🧪 Prima di cliccare: HackThisSite & la gioia dell’apprendimento legale
Prima di impazzire all’idea di attaccare siti veri (umanamente comprensibile, ma pericoloso), ricorda:
💡 Fare test di sicurezza su siti altrui senza autorizzazione è reato.
Per fortuna esistono templi digitali protetti, dove l’hacking è incoraggiato e legale. Uno di questi è:
🧱 HackThisSite.org – “Hack the planet, ma con buone maniere”
Attivo da quando i modem facevano “brrrr”, HackThisSite propone sfide etiche per imparare facendo:
- Livello 5 (XSS reflected): metti su payload, scatenalo, comprendi la logica, esplori la vulnerabilità.
- Monitori la risposta passo a passo, impari perché il server ha usato quello
<script>, e come proteggersi.
Se vuoi qualcosa di più moderno, c’è Hack Yourself First di Troy Hunt (il creatore di Have I Been Pwned?). È il campo di addestramento per sviluppatori curiosi: test XSS, buffer overflow, SQL injection, tutto in un ambiente controllato dove il massimo rischio è diventare troppo fiero di sé.
🥷 Tre volti della stessa maschera: i tipi di XSS
🪞 1. Reflected XSS
È istintivo, impulsivo.
Il server “riflette” immediatamente il payload nella risposta: basta un click su un link malevolo inoltrato via email o chat.
(es: ?name=<script>…)
il contenuto nel HTML della risposta
il link malevolo
lo script come parte del co
💾 2. Stored XSS
È strategico, paziente.
Il payload sopravvive sotto forma di messaggio, commento o profilo. Quando lo visita il prossimo, voilà: script attivato. È contagioso come un meme virale… che ruba cookie anziché sorrisi.
un commento, messaggio o post con:
<script>codice malevolo</script>il contenuto nel database
alla pagina con quel contenuto
il commento come HTML attivo
per ogni visitatore
🧩 3. DOM‑based XSS
È silenzioso ma moderno.
Il codice manipola il DOM all’interno del browser senza passare per il server. È come installare un congegno esplosivo direttamente dentro la casa, senza nemmeno bisogno di forzare la porta.
carica uno script come:
document.write(location.hash);https://site.com/page.html#<script>…
il codice nel DOM → nessun server coinvolto
nel browser
📊 Tabella Comparativa – Tipi di XSS
| Tipo di XSS | Modalità di attacco | Dove si verifica | Rischio principale | Esempio comune |
|---|---|---|---|---|
| Reflected | Payload nella URL | Risposta immediata | Furto cookie / redirect | Link con ?q=<script> inviato via email |
| Stored | Payload salvato | Server / DB | Auto-esecuzione ogni visita | Commento contenente JavaScript |
| DOM-based | JavaScript locale | Browser (DOM) | Script eseguito solo sul client | Modifica di location.hash o innerHTML |
🍪 Perché dovremmo preoccuparcene?
Perché ormai non sono solo ragazzini con felpe e tastiere rumorose a cercare falle.
Esistono bot che scandagliano il web cercando opportunità XSS. Le conseguenze:
- Furto di cookie di sessione → accesso non autorizzato ai conti.
- Attivazione di azioni indesiderate (es. compere automatiche, cambi password).
- Reindirizzamento su pagine phishing o malware.
Il colpo fatale? Il server pubblica innocenti commenti, ignaro di aver installato la trappola.
🧘 L’illusione dell’input innocente
La domanda filosofica è più antica di Socrate: possiamo fidarci dell’input dell’utente?
Risposta breve: no.
Risposta lunga: mai, mai e ancora mai.
Considera ogni dato esterno come un donatore di sangue potenzialmente infetto. Anche se sembra pulito, potrebbe nascondere un <script> pronto a esplodere.
🧰 Gli strumenti del mestiere
Per chi sceglie la via dell’etica informatica:
- Burp Suite – Swiss Army Knife del pentesting.
- Wireshark – sniffare pacchetti come un segugio digitale.
- BeEF – sfrutta browser compromessi (nome buffo, ma utile).
- Fiddler – manipola richieste HTTP come fossero LEGO.
🛡️ Come ci difendiamo?
Difendersi dall’XSS è come recitare una tragedia greca con i guanti da cucina. Difficile, ma non impossibile.
- Validazione e sanitizzazione
- Validate: accetta solo ciò che serve (es: solo lettere, numeri, @, punto).
- Sanitize: applica escaping (es:
htmlspecialchars()in PHP o DOMPurify in JS).
- Framework moderni
React, Vue, Angular: fanno escaping automatico e segnalano potenziali rischi. - Content Security Policy (CSP)
Come un lucchetto ai script esterni: solo quelli approvati entrano in azione. - Evita
innerHTMLcome il sushi del giorno dopo
UsatextContent; non interpreta codice HTML. - Paranoia costruttiva
Tratta ogni input come un potenziale traditore. Questo è il prezzo della sicurezza.
🛡️ Difese a confronto – Tabella
| Tecnica di difesa | Protegge da | Pro | Contro |
|---|---|---|---|
| Escaping/Output encoding | Tutti | Semplice, efficace | Deve essere fatto ovunque |
| Sanitizzazione | Tutti | Pulisce input, versatile | Può essere aggirata se mal configurata |
| CSP (Content Security Policy) | DOM & script injection | Limita fonti script | Complesso da configurare |
| Framework moderni (React, Vue) | DOM, Reflected | Escaping automatico | Necessita apprendimento |
| Whitelist input | Reflected, Stored | Più sicuro | Rigidità per l’utente |
Evita innerHTML | DOM-based | Elimina rischio diretto | Richiede refactoring |
💥 Il caso Samy: quando XSS diventò virale
Nel 2005, il giovane Samy Kamkar lanciò un worm XSS su MySpace con una frase:
“but most of all, Samy is my hero”
Un complimento travestito da virus. In meno di 24 ore, trasformò oltre un milione di profili in suoi propagandisti involontari. MySpace collassò, Samy finì sotto processo, internet scoprì quanto fosse potente (e pericolosa) una riga di JavaScript.
📌 Conclusione: tra fiducia e paranoia
L’XSS è un paradosso che ci insegna quanto sia fragile la nostra fiducia sul web.
Basta una riga di codice, una sola, per far crollare il castello di sabbia.
Il web è un’enorme città affollata di finestre: alcune guardano su strade trafficate, altre… dentro casa tua.
Difendersi significa imparare a chiudere le finestre sospette, non a vivere al buio.
Imparare le regole dell’XSS è un passo verso il controllo consapevole del nostro regno digitale.
📖 Glossario Tecnico Interattivo
🔐 XSS (Cross-Site Scripting)
Una vulnerabilità che consente a un attaccante di inserire ed eseguire codice malevolo (di solito JavaScript) in pagine web visualizzate da altri utenti.
🔗 OWASP – Cross Site Scripting (XSS)
🧬 Payload
È il contenuto “maligno” iniettato in una vulnerabilità. In XSS, un payload può essere uno script JavaScript che ruba cookie o manipola la pagina.
🔗 Wikipedia – Payload (computer)
🧾 Sanitizzazione
Processo di “pulizia” dei dati in input per rimuovere o neutralizzare contenuti potenzialmente pericolosi, come tag HTML o script.
🔗 Mozilla – Sanitizing user input
🧪 Escaping
Tecnica che sostituisce i caratteri speciali con entità sicure, impedendo che vengano interpretati come codice.
Esempio: < diventa <
🔗 OWASP – Output Encoding and Escaping
🏗️ DOM (Document Object Model)
È la rappresentazione ad albero della struttura di una pagina web nel browser. Gli attacchi DOM-based XSS manipolano direttamente questa struttura tramite JavaScript.
🔗 MDN Web Docs – DOM
🔒 CSP (Content Security Policy)
Un meccanismo di sicurezza che specifica quali fonti di contenuti (script, immagini, ecc.) un browser è autorizzato a caricare, limitando il rischio XSS.
🔗 MDN Web Docs – Content Security Policy (CSP)
📦 Reflected XSS
Tipo di attacco in cui il codice viene “riflesso” subito nella risposta HTTP del server (es. messaggi d’errore o parametri URL).
🔗 PortSwigger – Reflected XSS
💾 Stored XSS
Tipo di attacco in cui il payload viene salvato in un database o file server e poi rilasciato a ogni visitatore (es. commenti, messaggi).
🔗 PortSwigger – Stored XSS
🧩 DOM-based XSS
Attacco che manipola il DOM direttamente nel browser dell’utente, senza passare per il server.
🔗 PortSwigger – DOM-based XSS
🧰 Burp Suite
Strumento professionale per test di penetrazione (pentesting) che consente di intercettare, modificare e analizzare le richieste HTTP.
🔗 Burp Suite – Official Website
🐍 BeEF (Browser Exploitation Framework)
Framework per testare la sicurezza dei browser, usato in ambito etico per simulare attacchi contro client compromessi.
🔗 BeEF Project
🧲 Wireshark
Strumento di analisi del traffico di rete (packet sniffer), utile per ispezionare le comunicazioni HTTP e trovare vulnerabilità.
🔗 Wireshark – Official Site
🔧 Fiddler
Proxy HTTP gratuito che consente di monitorare, manipolare e testare il traffico web da e verso un’applicazione.
🔗 Fiddler – Telerik