Cross-Site Scripting - Come gli hacker dirottano il tuo sito

Tobias Schüring Ultimo aggiornamento 15.01.2020
6 Min.
Cross-Site Scripting_XSS

XSS, SQL injection, XMLrpc - quando viene rilasciato un aggiornamento di sicurezza WordPress , i rapporti di aggiornamento contengono soprattutto acronimi criptici. Anche se è chiaro che questi aggiornamenti sono necessari e il plus di sicurezza è molto piacevole, è importante capire cosa c'è dietro queste vulnerabilità di sicurezza. Perché solo se si capisce quali lacune chiudono gli aggiornamenti, si può anche prendere una decisione informata. Ecco perché oggi daremo un'occhiata al cross-site scripting, o XSS, che è di gran lunga il più comune attacco complesso sulle pagine WordPress .

Gli attacchi degli hacker possono essere paragonati ai ladri. Brute Force Gli attacchi sono più simili al metodo del piede di porco. Il criminale resiste all'attrezzo finché la porta o la finestra non si apre. Gli attacchi alle vulnerabilità XSS, d'altra parte, sono sofisticati: Il ladro sa esattamente da dove cominciare e ottiene un accesso mirato a una pagina.

Nel corso del cross-site scripting, le lacune di sicurezza nei siti web sono deliberatamente sfruttate. Gli hacker iniettano script malevoli in un contesto di fiducia (le tue pagine!). Simile a un clandestino su una nave, questo codice maligno utilizza il tuo sito come un veicolo per perseguire i propri obiettivi.

Nel caso peggiore, gli aggressori ottengono così informazioni riservate o l'accesso al computer dell'utente vittima. Tali attacchi non sono esattamente rari: Una buona metà delle vulnerabilità trovate dal fornitore di sicurezza Wordfence nel 2015 e 2016 erano vulnerabilità di cross-site scripting in Plugins .. Spesso, un attacco XSS forma poi la "base" per ulteriori attacchi, come spam, phishing o attacchi DDoS. Ecco perché oggi vi mostrerò come funziona esattamente il cross-site scripting, quali tipi di attacchi ci sono e quanto sono pericolosi gli attacchi.

Il Cross-site scripting funziona sempre in modo simile: il codice maligno entra nel tuo sito attraverso una falla.

Il cross-site scripting è un pericolo quando un'applicazione web inoltra i dati inseriti dall'utente al browser web senza controllare alcun codice script. Un buon esempio di tale applicazione web è una chat di supporto.

Attraverso l'applicazione web stessa gli script maligni possono raggiungere il server. Da lì, il codice maligno prima o poi finisce sui client colpiti. Un buon esempio di tale vulnerabilità XSS è il bug scoperto nel luglio 2016 nel meta-infos delle immagini in WooCommerce 2.6.2. Un bug ha reso possibile agli aggressori di iniettare codice HTML nelle meta descrizioni delle immagini dall'esterno. Ogni cliente che avrebbe guardato più da vicino l'immagine in questione (per esempio cliccando sull'immagine) avrebbe corso il rischio di essere attaccato. Per esempio, un hacker potrebbe aver infettato i computer dei vostri clienti con un virus.

Trucco popolare per il cross-site scripting: moduli manipolati

Gli XSS possono anche permettere agli hacker di sostituire moduli innocui con altri manipolati. Questi moduli raccolgono poi i dati delle vittime (i visitatori del tuo sito!). DA proposito, nemmeno la crittografia SSL può proteggerti da questo. HTTPS "solo" significa che la connessione tra server e client è criptata. Tuttavia, se il modulo stesso è stato manipolato, anche una connessione criptata è inutile.

Come per altri tipi di attacchi, l'obiettivo degli hacker è più spesso quello di monetizzare le loro macchinazioni. In termini concreti, questo significa che gli aggressori o rubano dati che poi vendono o vogliono infettare i siti per integrarli in una cosiddetta botnet che viene poi affittata.

3 tipi di XSS: XSS riflesso, persistente e locale

Gli attacchi di cross-site scripting possono essere approssimativamente divisi in tre tipi:

Approssimativamente, gli attacchi XSS funzionano come segue: Il codice maligno viene iniettato dove ci si aspetta l'input dell'utente (ad esempio in una ricerca interna alla pagina). Come parte della risposta del server, il codice maligno viene poi eseguito sul client, cioè nel browser dell'utente. Ed è proprio qui che viene fatto il danno, ad esempio vengono rubati i dati degli utenti.

Cross-site scripting riflessivo

Alcuni input, come le query di ricerca, sono riflessi dal server. Questo significa che, per esempio, dopo aver inserito "test" nella casella di ricerca, la pagina restituirà "hai cercato test". Quindi ciò che l'utente inserisce diventa parte della risposta del server.

Questo è esattamente ciò che gli aggressori sfruttano abilmente: Se uno script maligno viene inviato al server web al posto di un termine di ricerca, la pagina può essere manipolata per eseguirlo. Questo tipo di attacco è anche conosciuto come non persistente indicato come non persistente. Il codice maligno è quindi solo temporaneamente iniettato nella rispettiva pagina, ma non memorizzato.

A luglio, una tale vulnerabilità è stata trovata in Plugin WP Statistics (e corretta lo stesso giorno!). Un valore di input nella pagina 'wps_visitors_page' è stato inoltrato senza controllo, il che ha portato ad una vulnerabilità attraverso XSS riflesso. In questo modo, una pagina potrebbe essere violata se un amministratore avesse precedentemente cliccato su un link opportunamente manipolato

Per esempio, un attacco cross-site scripting riflesso potrebbe essere come questo.
Per esempio, un attacco cross-site scripting riflesso potrebbe essere come questo.

Funziona cosìL'attaccante distribuisce link con parametri manipolati alle sue potenziali vittime. Senza saperlo, l'utente invia una richiesta "manipolata" al server cliccando sul link, e il codice maligno viene eseguito insieme alla risposta del server. Poiché il codice - a differenza degli XSS persistenti - non è memorizzato da nessuna parte, l'hacker deve distribuirlo in massa alle potenziali vittime. Questo può accadere, per esempio, attraverso le mail o i social network.

cross-site scripting persistente

Con gli XSS persistenti, gli script maligni sono memorizzati sul server web e consegnati ogni volta che vengono chiamati da un client. Predestinate a questo sono le applicazioni web che memorizzano i dati degli utenti sul server e poi li emettono senza verifica o codifica (ad esempio i forum). Questo tipo di scripting può essere particolarmente pericoloso per blog e forum molto frequentati, poiché il malware può diffondersi rapidamente qui a causa del gran numero di utenti.

Questo grafico mostra una possibile sequenza di un attacco cross-site scripting persistente.
Flusso di un attacco cross-site scripting persistente. Fonte: Blog SAP

Esempio: In un forum, i contributi inviati sono memorizzati in un database. Non è raro che questi vengano memorizzati senza controllo e senza cifratura. Gli attaccanti approfittano di questa opportunità e aggiungono uno script maligno (ad esempio con l'aiuto di un commento) a un normale post di un forum. un normale post di un forum con uno script maligno (ad esempio con l'aiuto di un commento). Gli utenti ricevono il relativo link al post via e-mail o arrivano alla voce corrispondente per caso ed eseguono lo script quando richiamano il post. Il vantaggio per l'hacker è che ora può "spiare" i clienti colpiti o aggiungerli alla sua botnet per ulteriori attacchi.

Cross-site scripting basato su DOM o locale

A differenza degli XSS persistenti e riflessi, il cross-site scripting basato su DOM (Document Object Model) funziona eseguendo script lato client. Questo significa che il server non è a conoscenza di un tale attacco e le misure di sicurezza lato server non aiutano.

Un esempio ben noto di tale vulnerabilità è il caso del pacchetto genericon. Il pacchetto genericon è un set di icone che è usato da molti Plugins, incluso Jetpack. Era possibile iniettare codice maligno attraverso un file HTML in questo set di icone.

Dopo aver inserito questo URL, è apparso un avviso javascript. Questa è la prova che il codice javascript inserito potrebbe essere usato per manipolare la pagina in questione.
Dopo aver inserito questo URL, è apparso un avviso JavaScript. Questa è la prova che il codice JavaScript inserito potrebbe essere usato per manipolare la pagina in questione. Fonte: securityaffairs.co

Tuttavia, un prerequisito per un attacco XSS basato su DOM è che l'utente clicchi su un URL manipolato. Chiamando questo URL, il codice maligno può essere eseguito attraverso una lacuna in uno script lato client. Tra le altre cose, il fatto che un link deve prima essere cliccato rende l'XSS basato su DOM un tipo di attacco un po' più difficile e quindi meno probabile.

Il grafico mostra una possibile sequenza di un attacco locale di cross-site scripting.
Esempio di un attacco locale di cross-site scripting. Fonte: heise.de

Esempio: L'utente clicca sull'URL manipolato e invia una richiesta all'applicazione web. L'applicazione web risponde passando il codice dello script (che è errato ma non manipolato) al browser per avviare l'esecuzione dello script. I parametri manipolati dall'URL sono ora interpretati ed eseguiti nel browser dell'utente come parte dello script. La pagina web visualizzata nel browser viene così cambiata e l'utente ora vede - senza accorgersene - la pagina manipolata.

Conclusione: abbastanza frequente e non senza pericolo, quindi è importante una protezione adeguata.

Le vulnerabilità XSS sono tra i gateway più comuni per il codice maligno. E spesso un attacco corrispondente costituisce la base per ulteriori attacchi, come spam, phishing o attacchi DDoS. Gli aggressori dirottano il tuo sito e ne abusano per raggiungere i loro obiettivi.

Gli XSS riflessi e persistenti sono particolarmente comuni, poiché il cross-site scripting locale è più elaborato e difficile da implementare. Pagine che inoltrare i dati dell'utente al browser web senza verificare la presenza di possibile codice dannoso sono particolarmente a rischio. Trovare tali lacune, tuttavia, non è così facile. In linea di principio, questo è proprio il compito dei fornitori di sicurezza come sucuri and Co, che sviluppano costantemente le loro misure di sicurezza.

Ma naturalmente c'è anche un modo per i normali utenti di WordPress di proteggersi da questi attacchi. Gli aggiornamenti di tutti i componenti di WordPress , per esempio, sono una misura semplice ma molto efficace. Come voi come gestore di un sito, ma anche come utente di Internet, potete prevenire il cross-site scripting, ve lo spieghiamo nel nostro prossimo articolo sull'argomento.

Hai ancora commenti o domande? Allora basta lasciare un commento!

Articoli correlati

Commenti su questo articolo

Scrivi un commento

Il tuo indirizzo e-mail non sarà pubblicato. I campi obbligatori sono contrassegnati con *.