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

6 Min.
Scripting cross-site_XSS

XSS, SQL injection, XMLrpc - quando viene rilasciato un WordPress aggiornamento di sicurezza, l'opzione Aggiornamento dei rapporti abbreviazioni particolarmente criptiche. Anche se è chiaro che questi aggiornamenti sono necessari e la sicurezza aggiunta è molto gradita, è importante capire cosa c'è dietro queste vulnerabilità. Perché solo se si capisce quali sono le lacune che gli aggiornamenti colmano, si può prendere una decisione informata. Ecco perché oggi ci stiamo concentrando sul Cross-Site Scripting, o XSS, di gran lunga il più comune attacco complesso ai WordPress siti.

Gli attacchi degli hacker possono essere facilmente paragonati ai ladri. Brute Force Attacchi sono più simili al metodo del piede di porco. Il criminale spinge contro l'utensile fino a quando la porta o la finestra non si apre. Gli attacchi alle vulnerabilità XSS, invece, sono più sofisticati: Il ladro sa esattamente da dove cominciare e accede a una pagina specifica.

Nel corso del cross-site scripting, le falle di sicurezza nei siti web vengono così sfruttate in modo mirato. Gli hacker contrabbandano script dannosi in un contesto affidabile (le tue pagine!). Simile a un clandestino su una nave, questo codice maligno utilizza il vostro sito come veicolo per perseguire i propri obiettivi.

Nel peggiore dei casi gli aggressori possono così ottenere informazioni riservate o accedere al computer dell'utente danneggiato. Tali attacchi non sono esattamente rari: Una buona metà delle vulnerabilità riscontrate dal fornitore Wordfence di sicurezza nel 2015 e nel 2016 Plugins era costituita da vulnerabilità di scripting cross-site. Spesso un attacco XSS costituisce poi la "base" per ulteriori attacchi, come ad esempio spam, phishing o anche attacchi DDoS. Ecco perché oggi vi mostrerò da un lato come funziona esattamente il cross-site scriptingche Tipi di attacchi ci sono e quanto siano pericolosi gli attacchi.

Lo scripting cross-site funziona sempre in modo simile: il codice dannoso entra nel tuo sito attraverso una lacuna

Il cross-site scripting è sempre un pericolo quando un'applicazione web inoltra i dati utente inseriti al browser web senza verificare l'eventuale presenza di un codice script esistente. Un buon esempio di tale applicazione web è una chat di supporto.

Informazioni sull'applicazione web stessa gli script maligni possono entrare nel server. Da lì il codice maligno prima o poi finisce ai clienti interessati. Un buon esempio di tale vulnerabilità XSS è la Cimice nell'immagine meta info in 2WooCommerce.6.2. Per un difetto, gli aggressori hanno potuto infiltrarsi nelle metadescrizioni delle immagini dall'esterno. Qualsiasi cliente che ora avrebbe guardato l'immagine in questione più da vicino (ad es. cliccando sull'immagine) correrebbe il rischio di essere attaccato. Un hacker potrebbe aver infettato i computer dei vostri clienti con un virus, ad esempio.

Trucco popolare nello scripting cross-site: forme manipolate

XSS può anche permettere agli hacker di sostituire le forme innocue con quelle manipolate. Questi moduli raccolgono poi i dati delle vittime (i visitatori del vostro sito!). DA proposito, avor non può proteggere nemmeno la crittografia SSL. Perché HTTPS significa "solo" che la connessione tra server e client è criptata. Tuttavia, se il modulo stesso viene manipolato, anche una connessione criptata non serve a nulla.

Come per altri tipi di attacchi, il bersaglio degli hacker nella maggior parte dei casi è il Monetizzare le loro macchinazioni. Concretamente ciò significa che gli aggressori o rubano dati che poi vendono, oppure vogliono infettare i siti per integrarli in una cosiddetta botnet che viene poi affittata.

3 tipi di XSS: XSS riflessi, persistenti e locali

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

In linea di massima, gli attacchi XSS procedono come segue: Il codice maligno viene introdotto laddove è previsto l'input dell'utente (ad es. durante una ricerca interna della pagina). Come parte della risposta del server, il codice dannoso viene poi eseguito sul client, cioè nel browser dell'utente. Ed è proprio qui che si verificano i rispettivi danni, ad esempio il furto dei dati utente.

Sceneggiatura riflessa in cross-site

Alcuni input, come le query di ricerca, sono riflessi dal server. Ad esempio, se si digita "Test" nella casella di ricerca, nella pagina viene visualizzato "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 dannoso viene inviato al server web al posto di un termine di ricerca, la pagina può essere manipolata per poterla infine eseguire. Questo tipo di attacco è noto anche come non persistente si chiama. Il codice maligno viene quindi infiltrato solo temporaneamente nella rispettiva pagina, ma non viene salvato.

A luglio, a Plugin Statistiche WP una tale vulnerabilità è stata trovata (e risolta lo stesso giorno!). Un valore di input nella pagina 'wps_visitors_page' è stato inoltrato senza controllo, con conseguente vulnerabilità XSS riflessa. Una pagina potrebbe essere violata se un amministratore avesse cliccato su un link manipolato

Ad esempio, un attacco di cross-site scripting riflesso può avere questo aspetto.
Ad esempio, un attacco di cross-site scripting riflesso può avere questo aspetto.

Funziona cosìL'aggressore distribuisce alle sue potenziali vittime collegamenti con parametri manipolati. Senza saperlo, cliccando sul link, l'utente invia una richiesta "manipolata" al server e il codice maligno viene eseguito insieme alla risposta del server. Poiché il codice - a differenza di quanto avviene con gli XSS persistenti - non viene memorizzato da nessuna parte, l'hacker deve distribuirlo in massa alle potenziali vittime. Ciò può avvenire, ad esempio, tramite e-mail o social network.

Sceneggiatura persistente tra i siti

Con XSS persistente, o persistent, gli script dannosi vengono memorizzati sul server web e vengono consegnati ogni volta che un client li chiama. Sono predestinate a questo scopo le applicazioni web che memorizzano i dati degli utenti sul server e poi li emettono senza verifica o codifica (ad es. forum). Questo tipo di scripting può essere particolarmente pericoloso per i blog e i forum molto frequentati, poiché il malware può diffondersi rapidamente a causa del gran numero di utenti.

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

Esempio: In un forum, i contributi inviati vengono memorizzati in un database. Questi sono spesso immagazzinati senza controllo e non criptati. Gli aggressori approfittano di questa opportunità e aggiungono un normale forum postano uno script maligno (per esempio, usando un commento). Gli utenti riceveranno il rispettivo link al post via e-mail o andranno a caso alla voce corrispondente ed eseguiranno lo script chiamando il post. Vantaggio per l'hacker: ora può "spiare" i clienti interessati o aggiungerli alla sua rete bot per ulteriori attacchi.

DOM-based o cross-site scripting locale

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

Un esempio ben noto di tale lacuna è il caso del pacchetto genericon. Il pacchetto genericon è un set di icone usato da moltiPlugins, incluso Jetpack. Utilizzando un file HTML in questo set di icone, è stato possibile infiltrarsi nel codice maligno.

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

Un presupposto per un attacco XSS basato su DOM è tuttavia che l'utente clicchi su un URL manipolato. Richiamando questo URL, il codice dannoso può essere eseguito attraverso una lacuna in uno script lato client. Tra l'altro, il fatto che si debba prima cliccare su un link rende l'XSS basato sul DOM un tipo di attacco un po' più difficile e quindi meno probabile.

Il grafico mostra una possibile sequenza di un attacco locale di scripting cross-site.
Esempio di attacco locale di scripting cross-site. 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 è difettoso ma non manipolato) al browser per avviare l'esecuzione dello script. I parametri manipolati dall'URL vengono ora interpretati ed eseguiti nel browser dell'utente come parte dello script. La pagina web visualizzata nel browser viene così modificata e l'utente vede ora la pagina manipolata - senza accorgersene.

Conclusione: molto spesso e non senza pericolo, quindi è importante una protezione adeguata

Le vulnerabilità XSS sono uno dei punti di ingresso più comuni per il codice dannoso. E spesso un attacco corrispondente costituisce la base per ulteriori attacchi, come lo spam, il phishing o anche gli attacchi DDoS. Gli aggressori dirottano il tuo sito e ne abusano per raggiungere i loro obiettivi.

Gli XSS riflettenti e persistenti sono particolarmente comuni, in quanto lo scripting locale cross-site è più complesso e difficile da implementare. Pagine che I dati dell'utente inseriti nel browser web senza verificare la presenza di eventuali codici dannosi sono particolarmente a rischio. Trovare tali lacune, tuttavia, non è così facile. In linea di principio, questo è proprio il compito di fornitori di sicurezza come sucuri e Co, che migliorano costantemente le loro misure di sicurezza.

Ma naturalmente c'è anche la possibilità per gli utenti normali WordPress di proteggersi da questi attacchi. Gli aggiornamenti di tutti i WordPress componenti sono una misura semplice ma molto efficace. Nel nostro prossimo articolo vi spiegheremo come, come operatore del sito, ma anche come utente internet, potete evitare il cross-site scripting.

Avete commenti o domande? Allora lasciate un commento!

Articoli correlati

Commenti su questo articolo

Scrivi un commento

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