Attacchi XSS: come proteggere te stesso, i tuoi clienti e la tua azienda

Tobias Schüring Ultimo aggiornamento 23.01.2020
5 Min.
In questo modo, gli operatori dei siti web e gli utenti possono proteggersi dagli attacchi cross-site scripting.
Ultimo aggiornamento 23.01.2020

Gli attacchi XSS sono particolarmente subdoli. E particolarmente popolare tra gli hacker. Mostriamo come puoi proteggerti dall'hijacking del tuo sito - come operatore di siti web e come utente.

1599 WordPress -Plugins sono stati analizzati dal fornitore di sicurezza Wordfence durante un periodo di 14 mesi, e le vulnerabilità più frequenti di tutte erano le cosiddette vulnerabilità XSS. Quasi il 47% delle lacune trovate avevano a che fare con il cross-site scripting - XSS in breve. Motivo sufficiente per dare un'occhiata più da vicino a questo tipo di attacco, in cui gli hacker iniettano codice maligno nel tuo sito e virtualmente lo dirottano. In questo modo, gli aggressori usano il tuo blog, il tuo negozio o il tuo sito web aziendale come un veicolo per le loro attività illegali.

Questo grafico mostra che XSS è la vulnerabilità più comune trovata in Plugins , secondo wordfence .
XSS è la vulnerabilità più comunemente trovata in Plugins , secondo wordfence .

Le vulnerabilità XSS sono sempre pericolose quando l'input dell'utente viene inoltrato al server web senza essere controllato, per esempio nei moduli di contatto o nei campi di commento. Una volta sfruttati, gli hacker possono rubare dati, integrare il tuo sito in una botnet o infettare i computer dei tuoi visitatori. Fortunatamente, ci sono alcune misure di protezione molto semplici contro gli attacchi XSS.

XSS è rilevante sia per i visitatori che per gli operatori del sito

È importante comprendere che le vulnerabilità XSS sulle WordPress pagine sono ugualmente rilevanti per gli operatori del sito e per i visitatori. Gli operatori del sito vengono sfruttati per soddisfare gli obiettivi di basso livello degli hacker e i visitatori del sito sono spesso le vittime, ad esempio rubando dati o diffondendo codice dannoso.

In linea di principio, gli attacchi XSS iniziano quando gli utenti inviano dati al server web del gestore del sito. In questi punti nevralgici viene iniettato del codice, che - se l'input dell'utente non è controllato criticamente, per esempio da un firewall - può infettare la pagina. I diversi tipi di attacchi XSS sono riassunti nel nostro articolo di fondo sull'argomento.

La cosa più importante: aggiornamenti regolari di WordPress

Le vulnerabilità che gli hacker usano per iniettare codice dannoso si trovano nel core di WordPress , in Plugins o in Themes. Questo è esattamente il motivo per cui gli aggiornamenti regolari di tutti questi componenti sono così importanti. Le vulnerabilità che sono state trovate fino ad oggi sono risolte in questi aggiornamenti.

Ha anche senso leggere regolarmente i dettagli degli aggiornamenti dei rispettivi produttori per avere un'idea di quali lacune di sicurezza vengono regolarmente chiuse tramite gli aggiornamenti. Per la manutenzione e gli aggiornamenti di sicurezza del nucleo di WordPress , queste informazioni sono documentate nel blog WordPress , per esempio. Il miglior esempio di questo è l'ultimo aggiornamento di sicurezza, WordPress 4.7.5.

Firewall e whitelist contro semplici attacchi XSS

Un'altra semplice misura di protezione contro gli attacchi XSS sono i cosiddetti web application firewall, o WAF. Questi firewall sono il cuore della grande sicurezzaPlugins e sono alimentati con le ultime vulnerabilità dal rispettivo team di ricerca del produttore. Un WAF è generalmente una procedura che proteggeleapplicazioni web dagli attacchi attraverso l'Hypertext Transfer Protocol (HTTP).

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 il codice dannoso è uno dei meccanismi di sicurezza centrali nella lotta contro gli attacchi XSS. Per esempio, il contenuto dei commenti viene scansionato alla ricerca di stringhe di caratteri sospetti e, se necessario, viene smistato.

Anche l'uscita dei dati dovrebbe 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 Seite 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 (z. B. <, > und &) durch harmlose Zeichenreferenzen ersetzt werden. So wird verhindert, dass der Schadcode aktiv werden kann. Auch sollte der Code mithilfe von sog. sanitization libraries bereinigt werden. Hierfür wird ein Plugin auf dem Server installiert und zusätzlicher Code in deinen Seitenquellcode eingebunden. Der folgende Code-Schnipsel sorgt dann zum Beispiel dafür, dass <class> zu den erlaubten Attributen hinzugefügt wird:

Ecco come potrebbe apparire il codice di configurazione necessario per eseguire la sanificazione del codice.
Questo è quello che può sembrare il codice necessario per eseguire la sanificazione del codice.

Sono richieste competenze di programmazione per implementare questo. Questa protezione dell'uscita dei dati può essere facilmente implementata da uno sviluppatore o da un CTO, per esempio.

Una sana dose di scetticismo: come gli utenti si proteggono

Ma non solo i gestori delle pagine, anche i visitatori delle pagine sono colpiti da attacchi XSS. Molti attacchi XSS possono già essere prevenuti da una gestione critica e attenta in relazione ai link "stranieri". Per esempio, gli utenti hanno la possibilità di utilizzare i componenti aggiuntivi NoScript .Questi impediscono l'esecuzione di script, cioè le dannose linee di codice che rubano i dati, per esempio.

Se volete andare sul sicuro, potete anche evitare il cross-site scripting lato client semplicemente spegnendo il supporto JavaScript nel browser. Perché se questo cosiddetto scripting attivo è disattivato, certi tipi di attacchi XSS non hanno più possibilità, poiché le applicazioni maligne non vengono nemmeno avviate. Tuttavia, la maggior parte dei siti web moderni poi non "funzionano" più correttamente - o nel peggiore dei casi, non funzionano più affatto. Qui è quindi necessario soppesare gli aspetti di sicurezza e di usabilità.

Come disabilitare JavaScript con un clic nelle impostazioni del browser Chrome.
Come disabilitare JavaScript con un clic nelle impostazioni del browser Chrome.

Conclusione: gli attacchi XSS sono talvolta molto complessi, ma la protezione è talvolta abbastanza semplice.

XSS è un pericolo per te come operatore di un sito web, così come per i tuoi visitatori e clienti. Sempre più spesso si scoprono vulnerabilità in Plugins o Themes . Per esempio, il Plugin WP Statistics, con più di 400.000 installazioni attive, o WooCommerce e Jetpack, ciascuno con più di tre milioni di installazioni attive.

Se mantenete il vostro Plugins e Themes aggiornati e usate un WAF, avete già fatto un grande passo nella giusta direzione. Se usate anche delle whitelist per il codice in entrata e in uscita, avete già protetto il vostro sito in modo eccellente. Tuttavia, le ultime due misure in particolare non sono facili da implementare senza conoscenze di programmazione.

Rispetto agli attacchBrute Force i abbastanza primitivi di gli attacchi XSS più complessi hanno purtroppo ancora relativamente spesso successo. Tuttavia, ci sono significativamente meno di questi cosiddetti attacchi complessi rispetto agli attacchiBrute Force sulle pagine WordPress .. Tuttavia, si dovrebbe rendere il più difficile possibile per gli attaccanti. Un hacking riuscito non solo costa tempo e denaro per la rimozione degli script, ma può anche mettere in pericolo la vostra posizione nei motori di ricerca.

Forse hai già avuto esperienze con attacchi XSS? Cosa fai per proteggerti da loro?

Articoli correlati

Commenti su questo articolo

Scrivi un commento

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