Cross Site Scripting

Cross Site Scripting: come viene violato il tuo sito web

XSS, SQL Injection, XMLrpc: quando viene rilasciato un aggiornamento di sicurezza di WordPress, i rapporti di aggiornamento contengono per lo più acronimi criptici. Anche se è chiaro che questi aggiornamenti sono necessari e che l'aumento della sicurezza è molto piacevole, è importante capire cosa c'è dietro queste vulnerabilità di sicurezza. Perché solo se capisci quali lacune colmano gli aggiornamenti puoi prendere una decisione consapevole. Ecco perché oggi ci occuperemo del Cross Site Scripting, o XSS, che è di gran lunga l'attacco complesso più comune ai siti web WordPress.

Gli attacchi degli hacker possono essere paragonati a un furto con scasso. Gli attacchi di forza bruta sono più simili al metodo del piede di porco. I criminali resistono allo strumento finché la porta o la finestra non si apre. Gli attacchi alle vulnerabilità XSS, invece, sono sofisticati: I criminali sanno esattamente da dove iniziare e riescono ad accedere a un sito web in modo molto mirato.

Nel corso del cross-site scripting, le falle di sicurezza dei siti web vengono deliberatamente sfruttate. Gli script dannosi vengono iniettati in un contesto affidabile (il tuo sito web!). Come un clandestino su una nave, questo codice maligno utilizza il tuo sito web come veicolo per perseguire i propri obiettivi.

Nel peggiore dei casi, si ottengono così informazioni riservate o addirittura l'accesso al computer dell'utente vittima. Tali attacchi non sono proprio rari: Una buona metà delle vulnerabilità nei plugin riscontrate dal fornitore di sicurezza Wordfence nel 2015 e nel 2016 erano vulnerabilità cross-site scripting. Un attacco XSS spesso costituisce la "base" per ulteriori attacchi, come spam, phishing o attacchi DDoS. Ecco perché oggi ti mostrerò come funziona esattamente il Cross Site Scripting, quali sono i tipi di attacchi e quanto sono pericolosi.

Il Cross Site Scripting ha un principio di base

Il cross-site scripting funziona secondo il principio di base di sfruttare una falla e iniettare codice dannoso nel tuo sito web. È sempre un pericolo quando un'applicazione web inoltra i dati inseriti al browser web senza verificare la presenza di eventuali codici script. Un buon esempio di applicazione web di questo tipo è una chat di assistenza.

Gli script dannosi possono raggiungere il server attraverso l'applicazione web stessa. Da lì, il codice maligno finisce prima o poi sui client colpiti. Un buon esempio di vulnerabilità XSS di questo tipo è il bug scoperto nel luglio 2016 nei meta-info delle immagini in WooCommerce 2 .6.2. A causa di un errore, era possibile inserire codice HTML nelle meta-descrizioni delle immagini dall'esterno. Qualsiasi dispositivo su cui l'immagine interessata veniva visualizzata più da vicino (ad esempio cliccando sull'immagine) correva il rischio di essere attaccato. In questo modo, tra l'altro, i computer su cui veniva visualizzata l'immagine potevano essere infettati da un virus.

"*" indica i campi obbligatori

Desidero iscrivermi alla newsletter per essere informato sui nuovi articoli del blog, sugli ebook, sulle funzionalità e sulle novità di WordPress. Posso ritirare il mio consenso in qualsiasi momento. Si prega di prendere nota della nostra Politica sulla Privacy.
Questo campo è per la convalida e non deve essere modificato.

Trucchi popolari per il cross-site scripting: moduli manipolati

Gli XSS possono anche consentire di sostituire moduli innocui con moduli manipolati. Questi moduli raccolgono poi i dati delle vittime (sul tuo sito web!). A proposito, nemmeno la crittografia SSL è in grado di proteggere da questo fenomeno. HTTPS significa "solo" che la connessione tra server e client è criptata. Tuttavia, se il modulo stesso è stato manipolato, anche una connessione crittografata è inutile.

Come per altri tipi di attacchi, nella maggior parte dei casi l'obiettivo è la monetizzazione. In concreto, ciò significa che i dati vengono rubati e successivamente venduti, oppure che i siti web infetti vengono integrati in una cosiddetta botnet, che viene poi affittata.

3 tipi di XSS

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

  • Cross Site Scripting riflesso
  • cross site scripting persistente
  • Cross site scripting locale o basato sul DOM

A grandi linee, gli attacchi XSS funzionano come segue: Il codice dannoso viene iniettato nel punto in cui ci si aspetta un input da parte del cliente (ad esempio, durante una ricerca interna alla pagina). Come parte della risposta del server, il codice dannoso viene poi eseguito sul client, cioè nel browser. Ed è proprio lì che si verificano i rispettivi danni, ad esempio il furto di dati.

Cross Site Scripting riflessivo

Alcuni input, come le query di ricerca, vengono riflessi dal server. Ciò significa che, ad esempio, dopo aver inserito "test" nel campo di ricerca, il sito web visualizza "Hai cercato test". Il testo inserito diventa quindi parte della risposta del server.

Questo è proprio ciò che viene abilmente sfruttato: Se al posto di un termine di ricerca viene inviato al server web uno script dannoso, il sito web può essere manipolato in modo che alla fine lo esegua. Questo tipo di attacco è anche detto non persistente. Ciò significa che il codice dannoso viene iniettato solo temporaneamente nel sito web in questione, ma non viene memorizzato.

Nel luglio 2017 è stata riscontrata una vulnerabilità di questo tipo nel plugin WP Statistics (e già risolta lo stesso giorno!). Un valore di input nella pagina 'wps_visitors_page' veniva inoltrato in modo non controllato, portando a una vulnerabilità tramite XSS riflesso. In questo modo, se un amministratore aveva precedentemente cliccato su un link manipolato, un sito web poteva essere violato.

Cross Site Scripting XSS riflesso
Ecco come può apparire un attacco cross-site scripting riflesso.

Funziona così: i link con parametri manipolati vengono diffusi alle potenziali vittime. Senza saperlo, la vittima 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 viene memorizzato da nessuna parte, deve essere distribuito in massa alle potenziali vittime. Ciò può avvenire, ad esempio, tramite e-mail o social network.

Cross Site Scripting persistente

Con gli XSS persistenti, gli script dannosi vengono memorizzati sul server web e consegnati ogni volta che vengono richiamati da un client. Le applicazioni web che memorizzano i dati dell'utente sul server e poi li trasmettono senza controllo o codifica (compresi i forum) sono le più adatte a questo scopo. Questo tipo di scripting può essere particolarmente pericoloso per i blog e i forum molto frequentati, in quanto il malware può diffondersi rapidamente grazie all'elevato numero di utenti.

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

Esempio: In un forum, i contributi inviati vengono memorizzati in un database. Non è raro che questi vengano memorizzati in modo non controllato e non criptato. Questa opportunità viene facilmente sfruttata e consente di aggiungere uno script dannoso a un normalissimo post del forum (in modo semplice con l'aiuto di un commento). Gli utenti ricevono il rispettivo link al post via e-mail o arrivano per caso alla voce corrispondente ed eseguono lo script quando richiamano il post. Ora, ad esempio, i clienti colpiti potrebbero essere "spiati" o aggiunti a una botnet per ulteriori attacchi.

Cross-site scripting locale o basato sul DOM

A differenza degli XSS persistenti e riflessi, il cross site scripting basato sul DOM (Document Object Model) funziona eseguendo gli script sul lato client. Ciò significa che il server non è a conoscenza di un attacco di questo tipo e nemmeno le misure di sicurezza sul lato server sono d'aiuto.

Un esempio molto noto di questa scappatoia è il caso del pacchetto genericon. Il pacchetto genericon è un set di icone utilizzato da molti plugin. Era possibile iniettare codice maligno tramite 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 utilizzato per manipolare la pagina in questione.
Dopo aver inserito questo URL, è apparso un avviso JavaScript. Questa è la prova che il codice JavaScript inserito poteva essere utilizzato per manipolare il sito web in questione. Fonte: securityaffairs.co

Un prerequisito per un attacco XSS basato sul DOM, tuttavia, è che gli utenti clicchino su un URL manipolato. Richiamando questo URL, il codice maligno 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.

Cross Site Scripting locale XSS
Esempio di attacco cross-site scripting locale.

Esempio: l'URL manipolato viene cliccato 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 dell'URL vengono ora interpretati dal browser del cliente come parte dello script ed eseguiti. Il sito web visualizzato nel browser viene quindi modificato e gli utenti vedono il sito web manipolato senza accorgersene.

Misure contro il Cross Site Scripting

Le migliori misure contro gli attacchi cross-site scripting sono semplici da implementare. È meglio affidarsi ad aggiornamenti regolari, firewall e whitelist. In secondo luogo, è possibile proteggere anche l'output del server.

Aggiornamenti regolari

Le vulnerabilità attraverso le quali si infiltra il codice maligno si trovano nel nucleo di WordPress, nei plugin o nei temi. È proprio per questo che gli aggiornamenti regolari di tutti questi componenti sono così importanti. Perché le vulnerabilità che sono state trovate finora vengono risolte in questi aggiornamenti.

È inoltre opportuno leggere regolarmente i dettagli degli aggiornamenti per capire quali vulnerabilità di sicurezza vengono regolarmente chiuse tramite gli aggiornamenti. Per gli aggiornamenti di manutenzione e sicurezza del nucleo di WordPress, ad esempio, queste informazioni sono documentate nel blog di WordPress.

Firewall e whitelist contro i semplici attacchi XSS

Un'altra semplice misura di protezione contro gli attacchi XSS sono i cosiddetti firewall per applicazioni web, o WAF. Questi firewall sono il cuore di grandi plugin di sicurezza e vengono alimentati con le ultime vulnerabilità dal rispettivo team di ricerca del produttore. Un WAF è in genere una procedura che protegge le applicazioni web dagli attacchi tramite il protocollo HTTP (Hypertext Transfer Protocol).

Tuttavia, anche questi meccanismi di protezione hanno i loro limiti. Per alcuni attacchi XSS, l'attacco avviene attraverso il database. Pertanto, il controllo dell'input dell'utente per verificare la presenza di codice maligno è uno dei meccanismi di sicurezza principali nella lotta contro gli attacchi XSS. Ad esempio, il contenuto dei commenti viene analizzato alla ricerca di stringhe di caratteri sospetti e, se necessario, viene eliminato.

Anche l'uscita dei dati deve essere protetta

Regelmäßige Updates schließen vorhandene XSS Sicherheitslücken und Firewalls sowie Whitelists versuchen Schadcode auszufiltern, bevor dieser den Webserver erreicht und die Website infizieren kann. Doch sollte auch die Datenausgabe entsprechend gesichert werden. Die meisten Programmier- und Skriptsprachen, wie PHP, Perl oder JavaScript, besitzen hierfür bereits vordefinierte Funktionen zur Zeichenersetzung bzw. -maskierung. Diese sorgen dafür, dass „problematische“ HTML Metazeichen wie <> und & durch harmlose Zeichenreferenzen ersetzt werden. So wird verhindert, dass der Schadcode aktiv werden kann. Auch sollte der Code mithilfe von sogenannten sanitization libraries bereinigt werden. Hierfür wird ein Plugin auf dem Server installiert und zusätzlicher Code in den Quellcode deiner Website eingebunden. Der folgende Codeschnipsel sorgt dann zum Beispiel dafür, dass <class> zu den erlaubten Attributen hinzugefügt wird:

var sanitizer = new HtmlSanitizer();
sanitizer.AllowedAttributes.Add("class");
var sanitized = sanitizer.Sanitize(html);

Per implementare questo sistema sono necessarie competenze di programmazione. Questa protezione dell'uscita dei dati è facile da implementare per chi ha queste conoscenze.

Una sana dose di scetticismo: come gli utenti si proteggono

Ma non solo il sito web, anche i client (cioè il tuo browser web) sono colpiti dagli attacchi XSS. Molti attacchi XSS possono essere evitati grazie a una gestione critica e attenta dei link "estranei". Tra le altre cose, esiste la possibilità di utilizzare i componenti aggiuntivi NoScript. Questi impediscono l'esecuzione di script, ossia di linee di codice dannose che rubano i dati, tra le altre cose.

Chi vuole andare sul sicuro può anche evitare il cross-site scripting lato client semplicemente disattivando il supporto JavaScript nel browser. Infatti, se il cosiddetto scripting attivo viene disattivato, alcuni tipi di attacchi XSS non hanno più alcuna possibilità, poiché le applicazioni dannose non vengono nemmeno avviate. Tuttavia, la maggior parte dei siti web moderni non "funzionano" più correttamente o, nel peggiore dei casi, non funzionano affatto. È quindi necessario soppesare gli aspetti della sicurezza e dell'usabilità. Se sei interessato a questa opzione, puoi trovarla nelle impostazioni del tuo browser.

Conclusione

Le vulnerabilità XSS sono tra le porte d'accesso più frequenti per il codice maligno. E un attacco corrispondente spesso costituisce la base per ulteriori attacchi, come spam, phishing o attacchi DDoS. Il tuo sito web viene dirottato e utilizzato per altri scopi. Gli XSS non sono quindi privi di pericoli, per questo è importante una protezione adeguata.

Gli XSS riflessi e persistenti sono particolarmente comuni, poiché il cross-site scripting locale è più complesso e difficile da implementare. I siti web che inoltrano i dati inseriti dall'utente al browser web senza verificare la presenza di eventuale codice maligno sono particolarmente a rischio. Trovare queste falle, tuttavia, non è così facile. In linea di massima, questo è proprio il compito di fornitori di sicurezza come sucuri e altri, che sviluppano costantemente le loro misure di sicurezza.

Ma ovviamente esiste anche un modo per proteggere WordPress da questi attacchi. Gli aggiornamenti di tutti i componenti di WordPress sono, tra l'altro, una misura semplice ma molto efficace. Se mantieni aggiornati i tuoi plugin e temi e utilizzi un WAF, hai già fatto un grande passo nella giusta direzione. Se utilizzi anche delle whitelist per il codice in entrata e in uscita, hai già messo in sicurezza il tuo sito web in modo eccellente. Tuttavia, le ultime due misure in particolare non sono facili da implementare senza conoscenze di programmazione.

Rispetto agli attacchi brute force, piuttosto primitivi, gli attacchi XSS più complessi hanno purtroppo ancora relativamente spesso successo. Tuttavia, gli attacchi cosiddetti complessi sono molto meno numerosi di quelli a forza bruta sui siti web WordPress. Tuttavia, dovresti rendere il più difficile possibile questi attacchi. Un attacco riuscito non solo costa tempo e denaro per la rimozione degli script, ma può anche compromettere la tua posizione nei motori di ricerca.

Ti è piaciuto l'articolo?

Con la tua valutazione ci aiuti a migliorare ancora di più i nostri contenuti. Grazie!

Scrivi un commento

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