Con la mia limitata esposizione alla sicurezza informatica e l'ampia gamma di argomenti che abbracciano questo campo, la mia curiosità è cresciuta solo nel corso degli anni. Mentre filtravo articoli e diverse fonti di ricerca, volevo condividere e documentare un po' di più il mio viaggio nella comprensione degli attacchi informatici. Oggi daremo una rapida occhiata insieme a uno degli attacchi informatici più comuni: il cross-site scripting (XSS).

Cos'è lo scripting tra siti (XSS)?

Il cross site scripting , anche popolarmente noto con il suo acronimo, XSS, è un attacco in cui un utente malintenzionato "inietta" script eseguibili dannosi nel codice di un'applicazione o di un sito Web attendibili.

Secondo i report statistici di Edge Scan, le applicazioni web sono quelle a più alto rischio per questo tipo di attacchi.

Come sono consentiti questi attacchi?

Qualcosa che mi sono sempre chiesto è stato: "Bene, come diamine sono consentiti questi attacchi in primo luogo?". Questi attacchi possono verificarsi manipolando le richieste e le risposte HTTP o il DOM. Se non ci sono protocolli di sicurezza per convalidare o controllare i dati trasmessi tramite richieste/risposte HTTP o persino al DOM, sei a rischio di questi attacchi XSS.

Come funziona XSS: una visualizzazione

• Gli hacker sono alla ricerca di vulnerabilità del sito Web, in cui possono curiosare nel tuo codice. Se il tuo sito Web non adotta misure preventive per proteggersi, gli hacker potrebbero sfruttare questi spazi non protetti per iniettare i loro script dannosi.
• Se gli script vengono posizionati correttamente, vengono attivati ​​gli script dell'aggressore.

• Le informazioni personali vengono inviate all'hacker.
• Le sequenze di tasti dell'utente vengono acquisite.
• Un utente viene reindirizzato a un sito Web dannoso.
• Le informazioni sui cookie vengono prelevate da un utente che ha effettuato l'accesso a un sito Web (compromettendo così l'account della vittima).

• Attacco XSS riflesso
• Attacco XSS memorizzato
• Attacco basato su DOM

Gli attacchi riflessi implicano che l'input di una richiesta HTTP venga immediatamente riflesso come risposta. Un semplice esempio può essere dimostrato se qualcuno dovesse iniettare questi attacchi di script all'interno del campo di ricerca di un modulo. Dopo che un utente ha "cliccato" su Invia, il browser riconosce questo input come HTML, non vede nulla di dannoso e continua comunque a eseguire questo script dannoso. Il codice inserito viaggia verso il sito Web a cui l'utente sta accedendo. L'attacco, quindi, compare sul browser dell'utente (OWASP).

Di seguito è riportato un esempio di ciò. Un utente malintenzionato inserisce uno script dannoso nel campo di ricerca del sito Web e, di conseguenza, viene visualizzata una finestra di dialogo di avviso con la scritta "xss". Esistono ovviamente più intenzioni dannose di un utente malintenzionato che desidera che una finestra di avviso appaia sulla tua pagina, ma questo esempio dimostra quanto sia facile eseguire questi script iniettati.

Nota: gli attacchi riflessi NON vengono salvati in modo permanente e NON sono persistenti. Non vivono in un'applicazione. Gli attacchi riflessi di solito si verificano quando un utente apre un collegamento sospetto o apre una determinata pagina web.

Segni di un collegamento XSS:

• Un utente malintenzionato attira emotivamente l'attenzione di un lettore, inventando scenari peggiori che rendono una persona molto curiosa di fare clic, come illustrato nell'immagine sopra.
• È presente un URL abbreviato che imita l'URL di un'azienda attendibile. Questo fa sentire un utente inesperto come se fosse autentico, aspettandosi che il collegamento reindirizzasse alla pagina di quella società.
• Tuttavia, quel collegamento non reindirizza al video di TikTok e invece le informazioni sui cookie dell'utente sono state rubate, consentendo a un utente malintenzionato di accedere al login dell'utente.

Gli attacchi memorizzati "archiviano" gli script iniettati in luoghi, come un database o un server, quindi utilizzano questi dati successivamente in una risposta HTTP. Questi script si inseriscono direttamente in un'applicazione web. Un esempio è quando un sito web ti permette di scrivere un commento. Dopo aver inviato il tuo commento, il sito Web memorizza i tuoi commenti nel proprio server/database. Pertanto, un utente malintenzionato può archiviare i propri script all'interno del database di un sito Web commentando. Pertanto, tutti gli altri utenti che navigano in queste pagine che visualizzano questi commenti eseguono inconsapevolmente questi script che vengono salvati e archiviati nel database.

Nota: gli attacchi memorizzati vengono salvati in modo permanente e sono persistenti . Sono anche noti come "XSS persistenti" e sono noti per essere più dannosi degli attacchi riflessi (Imperva.com). Vivono in un'applicazione e possono avere effetti di lunga durata.

Attacco XSS basato su DOM

Il DOM è un'API Web. In sostanza, è solo un modo di strutturare e una rappresentazione di come appare una pagina web. I linguaggi di scripting, come Javascript, utilizzano il DOM per manipolare gli elementi DOM che modificano la struttura, lo stile e l'aspetto di una pagina web. Questo è vitale per la modifica delle pagine web.

A causa della sua natura facilmente accessibile, presenta implicazioni che consentono un'altra forma di XSS: attacchi basati su DOM. È importante notare che gli attacchi XSS basati su DOM sono diversi dagli attacchi XSS riflessi e archiviati, poiché "non toccano il server Web", mentre gli attacchi XSS riflessi e archiviati lo fanno.

Tuttavia, gli attacchi basati su DOM possono essere visti come una sottoclasse di attacchi riflessi in quanto riflettono una risposta immediata, ma invece sul codice lato client. (Wikipedia).

Taint Flow e XSS basato su DOM

Taint-flow è un modo in cui possiamo visualizzare XSS basato su DOM. Taint-flow è il processo di dati contaminati che fluiscono nel tuo corpo di codice, per mezzo di due termini chiave: fonti e pozzi .

Le fonti consentono l'ingresso di dati contaminati. Mi piace usare le analogie, quindi mi piace immaginare le fonti come un portale o un'entrata. Alcuni esempi ben noti includono: document.cookie, document.URL, localStorage, sessionStorage.
" In definitiva, qualsiasi proprietà che può essere controllata dall'attaccante è una potenziale fonte" (Portswigger.net).

I sink eseguono i dati, forniti dall'origine. Alcuni esempi ben noti includono: document.write , document.body.innerHTML, setTimeOut. Un sink comune per l'iniezione di JavaScript è: eval . I dati immessi dall'origine vengono utilizzati come input per un sink e il sink viene eseguito da solo .

Conclusione

Complessivamente, XSS è il processo di iniezione di script con intenti dannosi. Le richieste e le risposte HTTP sono importanti per comprendere come si verificano gli attacchi riflessi e archiviati, mentre la manipolazione del DOM e il flusso di contaminazione sono processi chiave per comprendere come si verifica l'XSS basato su DOM.

La principale differenza tra ogni attacco è che gli attacchi XSS riflessi implicano che l'input di una richiesta HTTP venga immediatamente riflesso come risposta sul tuo browser, mentre gli attacchi XSS memorizzati "memorizzano" questo input in qualcosa come un database esterno, quindi utilizzano questi dati successivamente in un Risposta HTTP. Gli attacchi basati sul DOM comportano l'inserimento di script dannosi nel DOM e sono una sottoclasse degli attacchi riflessi.

Gli attacchi riflessi sono più comuni, ma gli attacchi memorizzati sono più dannosi.

È importante considerare di proteggere le tue applicazioni per evitare questi tipi di attacchi che possono salvare la ginnastica mentale e alleviare la tua mente.

Fonti

https://portswigger.net/web-security/dom-based#:~:text=The%20Document%20Object%20Model%20(DOM,of%20how%20modern%20websites%20work

https://www.imperva.com/learn/application-security/cross-site-scripting-xss-attacks/#:~:text=Stored%20XSS%2C%20also%20known%20as,application%2C%20onto%20a%20user's%20browser.