Un attacco di cross-site scripting inganna un browser Web inducendolo a eseguire codice dannoso.
Dopo aver letto questo articolo sarai in grado di:
Argomenti correlati
Sicurezza delle applicazioni Web
Cross-Site Request Forgery (CSRF, richiesta intersito falsa)
Attacco brute-force
Attacco di buffer overflow
Cos'è l'SQL injection?
Abbonati a theNET, il riepilogo mensile di Cloudflare sulle tematiche più discusse in Internet.
Copia link dell'articolo
Il cross-site scripting (XSS) è un exploit in cui un malintenzionato collega un codice a un sito Web legittimo che verrà eseguito quando la vittima carica il sito Web. Tale codice dannoso può essere inserito in diversi modi. Più comunemente, viene aggiunto alla fine di un URL o pubblicato direttamente su una pagina che visualizza contenuti generati dagli utenti. In termini più tecnici, il cross-site scripting è un attacco di code injection lato client.
Il codice lato client è un codice JavaScript che viene eseguito sulla macchina di un utente. In termini di siti Web, il codice lato client è in genere un codice che viene eseguito dal browser Web dopo che il browser ha caricato una pagina Web. Ciò è in contrasto con il codice lato server, che viene eseguito sul server Web dell'host. Il codice lato client è molto utile con le pagine Web interattive; il contenuto interattivo viene infatti eseguito più velocemente e in modo più affidabile poiché il computer dell'utente non deve comunicare con il server Web ogni volta che si verifica un'interazione. I giochi basati su browser sono una piattaforma popolare per il codice lato client, poiché questo può garantire che il gioco funzioni senza problemi indipendentemente dai problemi di connettività.
Il codice che viene eseguito sul lato client è molto popolare nello sviluppo Web moderno ed è utilizzato nella maggior parte dei siti Web moderni. Poiché il codice cross-site è un punto fermo del Web moderno, il cross-site scripting è diventato una delle vulnerabilità della sicurezza informatica segnalate più frequentemente e gli attacchi di cross-site scripting hanno colpito siti importanti come YouTube, Facebook e Twitter.
Un esempio utile di attacchi cross-site scripting è quello che si riscontra comunemente nei siti Web che hanno forum di commenti non convalidati. In questo caso, un utente malintenzionato pubblicherà un commento costituito da codice eseguibile racchiuso nei tag '<script></script>'. Questi tag indicano a un browser Web di interpretare tutto ciò che si trova tra i tag come codice JavaScript. Una volta che quel commento è sulla pagina, quando un altro utente carica quel sito Web, il codice dannoso tra i tag dello script verrà eseguito dal suo browser Web e diventerà una vittima dell'attacco.
Gli attacchi di cross-site scripting JavaScript sono popolari perché JavaScript ha accesso ad alcuni dati sensibili che possono essere utilizzati per il furto di identità e altri scopi dannosi. Ad esempio, JavaScript ha accesso ai cookie* e un malintenzionato potrebbe utilizzare un attacco XSS per rubare i cookie di un utente e impersonarlo online. JavaScript può anche creare richieste HTTP che possono essere utilizzate per inviare dati (come i cookie rubati) al malintenzionato. Inoltre, JavaScript lato client può anche aiutare un malintenzionato ad accedere alle API che contengono coordinate di geolocalizzazione, dati della webcam e altre informazioni sensibili.
Un tipico flusso di attacco di cross-site scripting è il seguente:
*I cookie sono credenziali di accesso temporanee salvate sul computer di un utente. Ad esempio, quando un utente accede a un sito come Facebook, il sito gli invia un cookie in modo che se chiude la finestra del browser e torna su Facebook più tardi nello stesso giorno, verrà automaticamente autenticato dal cookie e non dovrà effettuare nuovamente l'accesso.
I due tipi più comuni di attacchi cross-site scripting sono cross-site scripting riflesso e cross-site scripting persistente.
Questo è l'attacco cross-site scripting più comune. Con un attacco riflesso, il codice dannoso viene aggiunto alla fine dell'URL di un sito Web, spesso legittimo e affidabile. Quando la vittima carica questo collegamento nel proprio browser Web, il browser eseguirà il codice inserito nell'URL. Il malintenzionato di solito utilizza una qualche forma di social engineering per indurre la vittima a fare clic sul collegamento.
Ad esempio, un utente potrebbe ricevere un'e-mail dall'aspetto legittimo che afferma di provenire dalla sua banca. L'e-mail gli chiederà di intraprendere qualche azione sul sito Web della banca e fornirà un collegamento. Il link potrebbe avere un aspetto simile a questo:
http://legitamite-bank.com/index.php?user=<script>ecco del codice errato!</script>
Sebbene la prima parte dell'URL appaia sicura e contenga il dominio di un sito Web attendibile, il codice inserito all'estremità dell'URL può essere dannoso.
Ciò accade nei siti che consentono agli utenti di pubblicare contenuti visibili ad altri utenti, come ad esempio un forum di commenti o un sito di social media. Se il sito non convalida correttamente gli input per i contenuti generati dagli utenti, un malintenzionato può inserire codice che i browser di altri utenti eseguiranno al caricamento della pagina. Ad esempio, un malintenzionato potrebbe andare su un sito di incontri online e inserire qualcosa del genere nel proprio profilo:
"Ciao! Mi chiamo Dave, mi piacciono le lunghe passeggiate sulla spiaggia e <script>codice dannoso qui</script>"
Qualsiasi utente che provi ad accedere al profilo di Dave diventerà una vittima dell'attacco di cross-site scripting persistente di Dave.
Non esiste un'unica strategia per mitigare il cross-site scripting e diversi tipi di applicazioni Web richiedono diversi livelli di protezione. È possibile adottare una serie di misure di protezione, di seguito ne indicheremo alcune.
Se possibile, evitare l'HTML negli input: un modo molto efficace per evitare attacchi di cross-site scripting persistenti è impedire agli utenti di pubblicare HTML negli input dei moduli. Esistono altre opzioni che consentono agli utenti di creare contenuti multimediali senza l'uso di HTML, come gli editor markdown e WYSIWYG.
Convalida degli input: la convalida consiste nell'implementare regole che impediscano a un utente di pubblicare dati in un modulo che non soddisfa determinati criteri. Ad esempio, un input che richiede il "Cognome" dell'utente dovrebbe avere regole di convalida che consentano all'utente di inviare solo dati costituiti da caratteri alfanumerici. Le regole di convalida possono anche essere impostate per rifiutare qualsiasi tag o carattere comunemente utilizzato nel cross-site scripting, come i tag "<script>".
Sanificazione dei dati: la sanificazione dei dati è simile alla convalida, ma avviene dopo che i dati sono già stati pubblicati sul server Web, prima però che vengano visualizzati da un altro utente. Esistono diversi strumenti online in grado di disinfettare l'HTML e filtrare eventuali iniezioni di codice dannoso.
Adottare misure di sicurezza per i cookie: le applicazioni Web possono anche impostare regole speciali per la gestione dei cookie in grado di mitigare il furto di cookie tramite attacchi di cross-site scripting. I cookie possono essere legati a determinati indirizzi IP in modo che gli autori di attacchi di cross-site scripting non possano accedervi. Inoltre, è possibile creare regole per impedire del tutto a JavaScript di accedere ai cookie.
Impostazione delle regole WAF: un WAF può essere configurato anche per applicare regole che impediscano il cross-site scripting riflesso. Queste regole WAF impiegano strategie che bloccano le richieste anomale al server, compresi gli attacchi cross-site scripting. Cloudflare WAF offre un'installazione chiavi in mano e protegge le applicazioni Web da cross-site scripting, attacchi DDoS, SQL injection e altre minacce comuni.