Quando pensiamo agli attacchi informatici, pensiamo a violazioni dei dati, virus e malware, ma hai mai sentito parlare di cross-site scripting, alias attacchi XSS? Probabilmente no. Anche se è una delle minacce più famigerate e comuni nelle applicazioni web che usiamo oggi. Quindi, cos'è?
Cos'è il cross-site scripting (XSS)?
Il cross-site scripting, o un attacco XSS, è un tipo di attacco di iniezione. Gli aggressori inseriscono script dannosi, tipicamente scritti in JavaScript, in un sito web fidato. Quando altri utenti visitano la pagina web compromessa, a loro insaputa, i loro browser eseguono gli script iniettati, pensando che provengano da una fonte fidata, portando ad ulteriori pericolosi attacchi informatici.
Le applicazioni web spesso permettono agli utenti di interagire con le applicazioni web inviando dati tramite moduli o altri campi di input. Gli hacker possono sfruttare questa vulnerabilità per iniettare script dannosi se l'applicazione non convalida e sanitizza adeguatamente questo input utente.
Gli attacchi XSS comportano rischi significativi, tra cui perdite finanziarie, violazioni dei dati, sistemi compromessi, danni alla reputazione e conseguenze legali. Gli sviluppatori e i proprietari di siti web devono implementare misure di sicurezza robuste e configurare strumenti come firewall per applicazioni web e software di gestione delle minacce unificate per prevenire le vulnerabilità XSS.
Come funziona il cross-site scripting (XSS)?
Iniziamo imparando la politica dello stesso origine per capire come funzionano gli attacchi di cross-site scripting.
Politica dello stesso origine
La politica dello stesso origine è un meccanismo di sicurezza integrato nei browser web che previene il furto di dati. Ad esempio, il contenuto di un sito è autorizzato a utilizzare cookie e altre risorse sul browser web di un utente. Secondo la politica dello stesso origine, il contenuto di qualsiasi URL con lo stesso identificatore di risorsa uniforme (URI), nome host e numero di porta condivide anche queste autorizzazioni. Se questi tre attributi differiscono, il sito necessita di un'autorizzazione separata.
Quando la politica dello stesso origine non è rigorosamente applicata utilizzando misure di sicurezza web come la convalida e la sanitizzazione dell'input utente, crea vulnerabilità nelle applicazioni web.
Definizione di convalida e sanitizzazione nella sicurezza delle applicazioni web
-
Convalida è il processo di verifica e certificazione che l'input utente soddisfi i criteri attesi definiti dall'applicazione. Comporta la verifica del formato, della lunghezza, del tipo e dell'intervallo dei dati di input per prevenire valori dannosi o non intenzionali dall'essere accettati.
Ad esempio, se un'applicazione web si aspetta un input numerico per un campo specifico, la convalida assicura che l'input fornito sia un numero e che rientri nell'intervallo consentito. - Sanitizzazione o codifica dell'output è il processo di pulizia o modifica dell'input utente per rimuovere qualsiasi contenuto potenzialmente dannoso. Comporta l'applicazione di tecniche di filtraggio specifiche per garantire che il contenuto generato dall'utente sia trattato come testo semplice e non eseguito come codice dai browser.
Gli attacchi di cross-site scripting utilizzano tipicamente JavaScript, ma anche qualsiasi linguaggio di programmazione lato client, come PHP, hypertext markup language (HTML) e .NET, funziona.
L'anatomia di un attacco di cross-site scripting
Passiamo attraverso un esempio per capire come funziona un attacco XSS:
Supponiamo che ci sia un'applicazione web con una sezione commenti dove gli utenti possono pubblicare messaggi che vengono visualizzati sul sito web. Tuttavia, la sezione commenti dell'applicazione ha una vulnerabilità che non convalida o sanitizza correttamente l'input utente prima che venga visualizzato.
Un aggressore identifica questo e sfrutta la vulnerabilità iniettando codice JavaScript dannoso in una delle sezioni commenti delle pagine web. Pubblicano un commento con il seguente contenuto:
<script>
alert('Questo è un attacco di cross-site scripting (XSS) dannoso, attenzione!');
</script>
Ora, invece di trattare il codice iniettato come testo semplice, l'applicazione non protetta visualizza il commento sul sito web senza una corretta codifica o convalida. Quando altri utenti visitano la pagina web che ha questo commento, i loro browser interpretano il codice JavaScript iniettato come parte del contenuto del sito web e lo eseguono.
Di conseguenza, appare una finestra di avviso che visualizza il messaggio, "Questo è un attacco di cross-site scripting (XSS) dannoso, attenzione!"
Se ciò non fosse abbastanza grave, le conseguenze dell'attacco potrebbero essere molto più gravi, a seconda delle intenzioni del criminale informatico. Gli attori delle minacce possono sfruttare lo script eseguito per rubare informazioni sensibili, reindirizzare gli utenti a siti web di phishing, registrare i tasti premuti, catturare le sottomissioni dei moduli o compromettere il sistema scaricando ed eseguendo malware.
Le conseguenze degli attacchi di cross-site scripting (XSS)
Gli aggressori possono utilizzare gli attacchi XSS per
- Reindirizzare gli utenti a un sito web dannoso
- Ottenere i tasti premuti e accedere alla cronologia del browser e ai contenuti degli appunti
- Infectare il dispositivo dell'utente con altri malware o addirittura prendere il controllo del computer della vittima
- Rubare il token di sessione di accesso dell'utente, imitare l'utente legittimo e interagire con l'applicazione
- Forzare l'utente a inviare richieste controllate dall'aggressore al server web e lanciare attacchi di negazione del servizio
- Alterare il contenuto di un'applicazione web e usarlo per iniettare annunci dannosi
Vuoi saperne di più su Firewall per applicazioni web (WAF)? Esplora i prodotti Firewall per applicazioni web (WAF).
Attacco XSS vs. CSRF vs. SQL injection
È facile confondere XSS con SQL injection e cross-site request forgery (CSRF) perché tutti e tre sfruttano le vulnerabilità delle applicazioni web. Tuttavia, sono minacce alla sicurezza web distinte e variano nella loro natura e nel tipo di attacchi che generano.
- Gli attacchi XSS iniettano codici dannosi in un sito web fidato e causano l'esecuzione involontaria da parte del browser web dell'utente.
- Cross-site request forgery inganna un utente autorizzato utilizzando tecniche di ingegneria sociale come il phishing per effettuare richieste dannose per conto dell'utente.
- Gli attacchi SQL injection iniettano codice SQL dannoso nel livello del database di un'applicazione web per accedere a dati che non dovevano essere mostrati.
.png)
Storia degli attacchi XSS
Le vulnerabilità XSS risalgono ai primi giorni di internet. Man mano che le pagine web diventavano più interattive con il lancio di JavaScript nel 1995, gli sviluppatori hanno iniziato ad accettare input utente tramite moduli e altri elementi cooperativi sulle pagine web.
Tuttavia, gli sviluppatori non hanno convalidato e sanitizzato efficacemente l'input utente ed hanno esposto vulnerabilità che gli aggressori potevano - e hanno - sfruttato. Un team di ingegneri della sicurezza di Microsoft ha coniato per la prima volta il termine "cross-site scripting" per questi attacchi, e nel tempo, la sua definizione si è ampliata per includere altri tipi di attacchi di iniezione di codice.
Prima del 2005, la maggior parte dei ricercatori di sicurezza si concentrava su altre minacce alla sicurezza web come attacchi di overflow del buffer, worm, botnet o virus. Questo fino a quando il famigerato worm Samy su MySpace ha infettato oltre un milione di utenti in 24 ore utilizzando un attacco XSS, dimostrando la sua potenziale scala e impatto.
Dopo il colpo devastante, la comunità della sicurezza informatica ha fatto sforzi encomiabili per affrontare le vulnerabilità XSS. Ma anche allora, continua a essere una minaccia persistente per la sicurezza delle applicazioni web. Grandi siti web come Orkut, Youtube, Yahoo Mail, eBay, Amazon, Twitter e Facebook hanno affrontato attacchi XSS nel corso degli anni.
3 principali tipi di attacchi XSS con esempi
Gli attacchi XSS sono generalmente classificati in tre principali categorie:
- Attacchi di cross-site scripting memorizzati (persistenti)
- Attacchi di cross-site scripting riflessi (non persistenti)
- Attacchi XSS basati su document object model (DOM)
.png)
1. Attacchi XSS memorizzati (persistenti)
Il cross-site scripting memorizzato o persistente si verifica quando uno script dannoso è memorizzato permanentemente sul server dell'applicazione web mirata e presentato agli utenti che accedono a una pagina specifica. Di solito accade quando l'input utente non è correttamente convalidato e sanitizzato prima della memorizzazione.
Lo script dannoso viene eseguito automaticamente quando altri utenti caricano la pagina iniettata. Poiché il payload è memorizzato dal server web e poi incorporato in una pagina HTML fornita all'utente, questo è chiamato attacco XSS memorizzato.
L'esempio più comune di attacco XSS memorizzato è il codice HTML non sanitizzato che viene pubblicato come messaggi su forum online, registri dei visitatori o campi di commento. Qualsiasi utente che clicca sulla pagina dove appare il commento è colpito dall'attacco, senza scorrere fino alla sezione dei commenti o addirittura cliccarci sopra.
Esempio recente di attacco XSS memorizzato
Nel febbraio 2023, il team di sicurezza di WordPress ha scoperto che gli aggressori avevano sfruttato una vulnerabilità XSS memorizzata in uno dei plugin di WordPress chiamato "Beautiful Cookie Consent" che aveva oltre 40.000 installazioni. I ricercatori hanno scoperto che gli hacker potevano aggiungere JavaScript non sicuro a un sito web utilizzando il cookie per reindirizzare gli utenti.
2. Attacchi XSS riflessi (non persistenti)
Gli sviluppatori di app devono prestare attenzione a questi più spesso. In un attacco XSS riflesso, un utente fornisce un input a un'app, e poi, l'attacco non persistente fa sì che gli script lato server utilizzino immediatamente quei dati. Gli script utilizzano quelle informazioni per mostrare all'utente una pagina web, ma l'input non è stato correttamente sanitizzato.
È chiamato attacco di cross-site scripting riflesso perché il server risponde immediatamente con il payload dannoso come risposta a una richiesta HTTP della vittima ignara.
Ad esempio, un'applicazione web fidata chiamata mybank.com ha una funzione di ricerca. Visualizza la query di ricerca degli utenti sulla pagina dei risultati senza una corretta convalida e codifica dell'output. Un aggressore potrebbe costruire il seguente URL dannoso per sfruttare questa vulnerabilità:
https://mybank.com/search?q=<script>alert(‘/*script dannoso che ruba la sessione utente’);</script>
L'aggressore invierà quindi questo URL dall'aspetto legittimo agli utenti tramite email o altri siti web neutrali. Pensando che provenga dal loro sito web bancario, uno degli utenti clicca sul link creato, e lo script dell'hacker viene eseguito, e la vittima non ne è consapevole.
Esempio recente di attacco XSS riflesso
Nel maggio 2023, i ricercatori hanno trovato gravi vulnerabilità XSS riflessi in due dei plugin di WordPress più comuni utilizzati per creare campi personalizzati sui siti WordPress. Gli aggressori potrebbero potenzialmente sfruttare questa instabilità per effettuare un attacco di escalation dei privilegi ingannando gli utenti privilegiati a cliccare su un percorso URL ingannevole.
3. Attacchi XSS basati su DOM
Gli attacchi XSS basati su DOM sono stati definiti per la prima volta dal ricercatore di sicurezza delle applicazioni web Amit Klein nel 2005. Il document object model è la rappresentazione orientata agli oggetti di una pagina web che supporta contenuti dinamici. Gli attacchi XSS basati su DOM si verificano quando gli hacker sfruttano le vulnerabilità del DOM. La pagina web non cambia, ma il codice lato client con il payload corrotto sul DOM viene eseguito nel browser dell'utente.
Gli attacchi XSS basati su DOM si verificano interamente sul lato client, in contrasto con gli attacchi XSS memorizzati e riflessi, che si verificano a causa di punti deboli sul lato server.
Esempio recente di attacco XSS basato su DOM
Nel novembre 2022, il ricercatore di sicurezza Justin Steven, ha trovato una vulnerabilità in un widget di marketing fornito da Gartner che potrebbe portare ad attacchi XSS basati su DOM. Qualsiasi sito web che utilizza il widget potrebbe essere utilizzato per eseguire codice JavaScript arbitrario nel browser di un utente utilizzando questa vulnerabilità da parte di criminali informatici.
Altri tipi di attacchi XSS
Oltre alle tre principali categorie di attacchi XSS menzionate sopra, ci sono diverse altre varianti di attacchi XSS che sfruttano vulnerabilità specifiche.
Self-XSS
Il self-cross-site scripting è più un attacco di ingegneria sociale in cui l'intruso inganna l'utente facendogli incollare un JavaScript dannoso nel proprio browser da solo. Tipicamente attirano le vittime pubblicando un messaggio che dice che l'utente sarà in grado di ricevere una ricompensa copiando ed eseguendo un certo codice. In realtà, il codice consente all'aggressore di dirottare l'account della vittima.
Mutation XSS
Il mutation XSS o mXSS è reso possibile a causa di una vulnerabilità nella proprietà DOM chiamata innerHTML e nel modo in cui il codice HTML viene analizzato quando si forniscono contenuti dinamici. Gli hacker iniettano codici dannosi appositamente creati che sembrano sicuri, ma mutano e diventano vettori di attacco XSS nel browser.
Blind XSS
Una variante degli attacchi XSS persistenti, gli attacchi di cross-site scripting ciechi risultano in payload dannosi memorizzati in un server di applicazioni web solo per essere eseguiti dall'utente del backend o dall'amministratore dell'applicazione.
7 misure preventive contro gli attacchi XSS
Le vulnerabilità continuano a esistere in molte delle nostre app web, ma i ricercatori hanno proposto molteplici soluzioni XSS, da semplici analisi statiche a meccanismi di protezione complessi in tempo reale. Alcune di esse sono discusse qui.
1. Framework web e librerie di codifica sicure
I moderni framework web e le librerie di codifica sicure forniscono un modo standard per sviluppare e distribuire applicazioni web su internet senza difetti di progettazione e implementazione legati alla sicurezza. Uno sviluppatore potrebbe non avere tutte le risorse per implementare correttamente le funzionalità di sicurezza quando costruisce un'app da zero. Lavorare con librerie di codifica sicure e strumenti di framework web aiuta a evitare eventuali lacune di sicurezza o errori nel codice.
2. Convalida dell'input e codifica dell'output
La convalida dell'input e la codifica dell'output sono tecniche di difesa chiave contro gli attacchi XSS. La convalida dell'input assicura che il contenuto generato dall'utente sia nel formato previsto e rifiuta o neutralizza qualsiasi dato che non corrisponde ai criteri.
La codifica dell'output sanitizza qualsiasi carattere speciale nell'input generato dall'utente sconosciuto in modo che venga interpretato come testo semplice. Questo conferma che il browser web non registra l'input utente come markup o codice JavaScript in nessuna circostanza. Entrambe queste tecniche prevengono vulnerabilità di sicurezza che XSS può sfruttare.
3. Sanitizzazione HTML
Un certo numero di sviluppatori di applicazioni web utilizza editor what you see is what you get (WYSIWYG) per creare contenuti testuali e video per le loro pagine web in linguaggio HTML. In questi casi, diventa importante sanitizzare i codici HTML per proteggersi dagli attacchi XSS.
La sanitizzazione HTML permette tag HTML di base come <b>, <i>, <u>, <em>, e <strong>. Allo stesso tempo, rimuove tag più avanzati come <script>, <object>, <embed>, e <link> che possono essere utilizzati per iniettare codici dannosi.
L'Open Source Foundation for Application Security (OWASP), una comunità di sicurezza leader, raccomanda l'uso di DOMPurify per la sanitizzazione HTML.
4. Sicurezza dei cookie
Poiché XSS e altri attacchi informatici prendono di mira i cookie web, è importante implementare una corretta sicurezza dei cookie. Puoi farlo utilizzando attributi dei cookie come il flag "secure" e "HttpOnly" per affermare che i cookie sono trasmessi solo tramite una connessione sicura.
5. Politica di sicurezza dei contenuti (CSP)
La CSP è un ulteriore livello di difesa per i proprietari di siti web contro XSS e altre minacce informatiche come il clickjacking e gli attacchi di iniezione di codice. Definisce e limita le fonti da cui i browser web possono caricare contenuti, come script, fogli di stile o immagini, e gli URL da cui possono essere caricati. La CSP impedisce l'esecuzione di codici dannosi specificando fonti fidate e bloccando o limitando i contenuti.
6. Test di sicurezza
I test di sicurezza regolari, inclusi la scansione delle vulnerabilità e i test di penetrazione, classificano e affrontano le vulnerabilità XSS. Revisioni manuali del codice, scanner di vulnerabilità, e strumenti di test del software con automazione possono far parte della tua routine per rilevare potenziali debolezze e misurare l'efficacia delle tecniche preventive contro XSS.
Esplora i 5 migliori strumenti di test di penetrazione e vedi quali si adattano meglio alle tue esigenze!
7. Firewall per applicazioni web (WAF)
I WAF sono il software di cybersecurity più comune per proteggere le app web contro XSS e SQL injection. Monitorano e filtrano il traffico in entrata e impiegano analisi per bloccare qualsiasi richiesta anomala all'applicazione e negare l'iniezione di script dannosi.
I 5 migliori strumenti di firewall per applicazioni web (WAF):
- Azure Web Application Firewall
- AWS WAF
- Imperva Web Application Firewall (WAF)
- Cloudflare Spectrum
- Symantec Web Application Firewall and Reverse Proxy
*Sopra ci sono le cinque soluzioni WAF leader dal Grid® Report di G2 dell'estate 2023.
Il software di sicurezza come le piattaforme di gestione delle minacce unificate (UTM) protegge efficacemente anche contro gli attacchi XSS integrando più funzionalità di sicurezza.
Cross-site scripting: Domande frequenti (FAQ)
1. Cos'è il cross-site scripting?
Gli attacchi di cross-site scripting (XSS) sono vulnerabilità di sicurezza delle applicazioni web che permettono agli hacker di iniettare script dannosi nelle pagine web. Questi script rubano informazioni sensibili, manipolano le interazioni degli utenti o distribuiscono malware.
2. Quale linguaggio viene utilizzato negli attacchi di cross-site scripting?
Qualsiasi linguaggio di programmazione lato client come Javascript, HTML, VBScript o Flash può essere utilizzato per scrivere codici dannosi negli attacchi di cross-site scripting. Ma Javascript e HTML sono i più comunemente usati per gli attacchi XSS.
3. Quali sono i tre tipi di attacchi di cross-site scripting?
I tre principali tipi di XSS sono XSS memorizzato, XSS riflesso e XSS basato su DOM.
4. Qual è la differenza tra XSS e CSRF?
XSS inietta ed esegue script dannosi sul browser di un utente, mentre CSRF si concentra sullo sfruttamento della fiducia riposta in una sessione autenticata di un utente per eseguire azioni non autorizzate per suo conto.
5. Qual è la differenza tra XSS e SQL injection?
Gli attacchi XSS prendono di mira gli utenti del sito web. L'SQL injection si concentra sui meccanismi di archiviazione e recupero dei dati del sito web.
Difendere il regno digitale
Oggi, il mondo funziona con le app. Il cross-site scripting rimane una pericolosa vulnerabilità di sicurezza. Espone gli utenti web all'accesso remoto, al furto di dati e alle perdite monetarie. Ma con una corretta consapevolezza e misure preventive, il suo impatto può essere mitigato se puoi aiutare a scrivere un web più sicuro se implementi le misure preventive condivise qui.
Vuoi scrivere codici più sicuri? Scopri il software di formazione per codici sicuri e come aiuta sviluppatori e programmatori.

Soundarya Jayaraman
Soundarya Jayaraman is a Content Marketing Specialist at G2, focusing on cybersecurity. Formerly a reporter, Soundarya now covers the evolving cybersecurity landscape, how it affects businesses and individuals, and how technology can help. You can find her extensive writings on cloud security and zero-day attacks. When not writing, you can find her painting or reading.
