Fonte originale: Edgecast
La sicurezza delle applicazioni Web rimane un importante vettore di minacce per le organizzazioni di piccole e grandi dimensioni. Secondo il rapporto Verizon 2020 Data Breach Investigations Report (DBIR), il 43% di tutte le violazioni di dati riguardava un’applicazione web,¹ e il 80% di tutti i vettori di hacking puntavano ad applicazioni web.²
Nel quarto trimestre del 2020, Verizon Media ha registrato un netto aumento del traffico XSS (Cross-Site Scripting) sulla nostra rete per la distribuzione dei contenuti (CDN) rispetto ai trimestri precedenti. Questo blog esplora alcuni punti di dati sul traffico e individua uno dei principali payload XSS tentati. Condividiamo anche come utilizzare questi dati per applicare misure protettive.
Utilizzate questo contenuto come guida basata sulle azioni per gestire il traffico XSS potenzialmente dannoso che colpisce la porta principale della vostra organizzazione. Può anche aiutarvi a condurre una conversazione di sicurezza necessaria con il vostro team di leadership e le vostre controparti aziendali/operative.
We avere i dati – andiamo a esplorarli
The Verizon Media WAF ha mitigato 1,5 miliardi di richieste nel quarto trimestre del 2020. “Per “mitigazione” si intende qualsiasi evento WAF che ha attivato un blocco, una risposta personalizzata o un reindirizzamento URL.” Questi blocchi da 1,5 miliardi rappresentano richieste HTTP che altrimenti avrebbero raggiunto i server di origine dei nostri clienti. Questi dati ci dicono:
- La quantità di scansioni delle vulnerabilità in background è enorme. Ti stai sbagliando se pensi di essere al sicuro perché il tuo obiettivo non vale la pena attaccare o perché non sei ben noto. Secondo il Verizon DBIR, “se ci permettete una metafora mista, non vi è alcun superamento dell’orso in questo caso, perché gli orsi vengono tutti stampati in 3D in massa e automatizzati per darvi la caccia”.³
- Se le applicazioni Web sono protette, tale scansione potrebbe non sembrare più dannosa di un ladro jiggling delle maniglie, e consentire a tale traffico di raggiungere i server è innocuo se non incorrere in un carico aggiuntivo sul server. Ma nella guerra asimmetrica per la sicurezza informatica, l’aggressore deve avere ragione solo una volta, rendendo così più facile per loro avere ragione in futuro. Allora perché lasciare che il ladro agiti la maniglia della porta se puoi evitarla?
Per portare questo a casa un po ‘più lontano, diamo un’occhiata più da vicino ad alcuni del traffico bloccato dal Q4 2020.
Il traffico XSS (Cross-Site Scripting) bloccato negli ultimi tre trimestri è passato dal primo posto nel Q2 2020 al quarto posto nel Q4 2020, quasi raddoppiando il volume durante questo periodo di tempo, rappresentando il 10% del traffico bloccato.
Figura 1. In soli sei mesi, abbiamo visto il traffico XSS più del doppio.
Getting conoscere il traffico XSS
According in Open Web Application Security Project (OWASP), si verificano dei difetti XSS quando un’applicazione include dati non attendibili in una nuova pagina Web senza convalida o fuga o quando un’applicazione aggiorna una pagina Web esistente con dati forniti dall’utente utilizzando un’API del browser in grado di creare HTML o JavaScript. XSS consente agli autori degli attacchi di eseguire script nel browser della vittima, che può dirottare le sessioni degli utenti, danneggiare i siti Web o reindirizzare l’utente verso siti dannosi.
Questa esposizione mette a repentaglio l’infrastruttura, la riservatezza e l’integrità dei dati e la disponibilità dei dati trasmessi tramite Internet. Questi attacchi possono comportare l’accesso non autorizzato ai contenuti, la perdita di informazioni personali identificabili (PII) e la diffusione di informazioni private o protette da copyright.
Si tratta di un problema in quanto nulla viene nascosto dalla vista una volta connesso ed esposto a Internet: Se si solleva, verrà eseguita la scansione. Una volta che una nuova applicazione Web viene online e viene esposta a Internet, verrà testata per vedere come reagisce alle diverse azioni o richieste. I risultati di questi risultati possono creare un’interessante svolta della trama, di cui parleremo a breve.
Per prima cosa, continuiamo ad esplorare la portata della potenziale esposizione. Molti siti web, applicazioni web e server ricevono ed elaborano richieste al di fuori della rete interna protetta di un’azienda. Di conseguenza, sono vulnerabili a varie minacce dannose raggruppate da OWASP, tra cui attacchi SQL injection, XSS e DDoS (Distributed Denial-of-Service) a livello di applicazione.
Considerando l’aumento degli attacchi XSS rilevati dal WAF Verizon, non sorprende che XSS sia in cima alla lista anche per la Top 25 di MITER CWE per il 2020:⁴
Figura 2. Un breve elenco delle debolezze nella Top 25 CWE 2020, incluso il punteggio complessivo di ciascuna di esse.
Proprio come abbiamo visto un aumento del traffico XSS bloccato, anche il numero di vulnerabilità reali documentate nel National Vulnerability database (NVD) che sono anche collegate agli exploit XSS:
- 513 vulnerabilità XSS documentate negli ultimi tre mesi (171 al mese)
- 5,507 vulnerabilità XSS documentate negli ultimi tre anni (153 al mese)
- 16,936 vulnerabilità XSS documentate in ogni momento
Sì, i difensori utilizzano gli stessi strumenti degli autori degli attacchi per individuare le vulnerabilità. Pertanto, è importante riconoscere il potenziale che l’esistenza di traffico dall’aspetto malevolo non significa necessariamente che ci sia un intento malvagio dietro il traffico. Ma potrebbe esserci.
Come minimo, se un cattivo attore curioso scansiona con successo un sistema, potrebbe tentare un exploit XSS, il tutto nello spirito di eseguire una ricognizione. Peggio ancora, l’attività di ricostruzione e i risultati ottenuti potrebbero essere utilizzati per ridurre un payload compromettente o distruttivo tramite XSS o utilizzati come trampolino di lancio verso qualcosa di più nefario, come un SSRF (Server-Side Request Forgery).
Is questo è un “eccellente trampolino di lancio”, vedo?
Remember lo scenario del jiggling della porta di cui abbiamo parlato prima? È tempo di riportare indietro quella metafora.
La maggior parte del traffico e degli eventi XSS non sono critici per se stessi, ma potrebbero portare a sfide e problemi significativi lungo la strada, un passo avanti verso un compromesso di successo, se volete.
Gli attacchi XSS di successo potrebbero consentire agli autori degli attacchi di eseguire HTML e JavaScript arbitrari nel browser di una vittima. In genere, l’utente deve interagire con un collegamento dannoso che punta a una pagina controllata dall’utente malintenzionato, come siti Web o annunci pubblicitari.
Esaminiamo la principale violazione delle regole per il quarto trimestre 2020, definita internamente come regola ID 941100, che è stata mappata a uno dei payload principali, dimostrando la capacità di utilizzare XSS come attacco di primo piano:
“><>Avviso script(String.fromCharCode(88,83,83))</script>”
Si tratta di una stringa di test XSS molto comune in molti repository di codice, ad esempio htmlpurifier.org.⁵, mentre si cerca di verificare se questo particolare payload funzionerà, viene visualizzata una finestra di avviso popup con la stringa “XSS”, che verifica immediatamente all’utente malintenzionato che un sito Web specifico è vulnerabile a XSS riflesso.
“Una volta che un utente malintenzionato verifica l’esistenza di un XSS riflesso, gli attacchi riflessi vengono inviati tramite un altro percorso, ad esempio un messaggio di posta elettronica o un altro sito Web. Quando un utente viene ingannato a fare clic su un collegamento dannoso, inviare un modulo appositamente predisposto o anche semplicemente navigare in un sito dannoso, il codice iniettato viene indirizzato al sito Web vulnerabile, che riflette l’attacco al browser dell’utente.”⁶.
Figura 3. In che modo gli autori di attacchi informatici sfruttano le vulnerabilità XSS.
Questo attacco può eseguire qualsiasi operazione sul sito web che l’utente che viene attaccato può eseguire, tra cui la “divulgazione del cookie di sessione dell’utente, consentendo a un utente malintenzionato di dirottare la sessione dell’utente e assumere il controllo dell’account”.⁷ ad esempio, uno script che modifica la password di un utente inviata per conto dell’utente può portare a un controllo dell’account.
Ci sono altri esempi da cui trarre ispirazione. In un altro caso pubblicamente documentato, un attacco SSRF è stato originariamente avviato tramite un exploit XSS e il ricercatore di sicurezza “è stato in grado di passare da XSS all’interno di un’immagine fino a file locali arbitrari letti sul server”.⁸
Non tutti i ricercatori (né criminali informatici) saranno abbastanza pazienti da collegare il loro exploit XSS a qualcosa di più significativo. Tuttavia, tenere un XSS per cose più grandi e migliori sembra essere un metodo comune per alcuni ricercatori che cercano di ottenere il grande premio nei loro programmi di bug Bounty.
Mitigation e defense
In assenza di dati, è difficile prendere una decisione. Tuttavia, diventa più facile identificare un percorso che porta al risultato desiderato una volta che si ha visibilità su una situazione. Ecco una raccolta di suggerimenti e risorse per ridurre i rischi che il traffico XSS comporta per la vostra rete e la vostra azienda.
- Assicurarsi di essere a conoscenza di tutti i dispositivi presenti in Internet e che sia i sistemi legacy che i sistemi di test siano considerati per la protezione avanzata o non in linea. Questo aspetto è particolarmente importante nell’era dell’infrastruttura cloud, in cui i team di sviluppo possono avviare le macchine con pochi clic o inviando un modulo.
- Configurare e rafforzare correttamente i server Web. Prendi in considerazione l’utilizzo di strumenti come i benchmark Center for Internet Securities per capire come configurare i controlli del tuo server. Configurate correttamente le vostre configurazioni TLS per proteggervi dagli attacchi MITM.
- Applicare regolarmente patch a tutti i server presenti in Internet. A volte, i framework comunemente utilizzati sono vulnerabili a XSS. A partire da febbraio 2021, il database ATT&CK di MITER elenca quasi 17.000 vulnerabilità e punti deboli con qualche connessione a XSS.
- Verificare periodicamente l’efficacia della protezione rafforzata. Utilizzare gli stessi strumenti DAST (Dynamic Application Security Testing) utilizzati dagli autori degli attacchi, come OWASP ZAP o strumenti simili di scansione delle vulnerabilità in Kali Linux. In alternativa, utilizzare un DAST o un servizio di test di penetrazione per rilevare ed eseguire la scansione dei server vulnerabili presenti in Internet.
- Abilitare un WAF (Web Application Firewall) per bloccare gli attacchi più comuni.
- Mantenere aggiornato il WAF per bloccare immediatamente eventuali vulnerabilità rilevate, consentendo al team dell’applicazione di distribuire una correzione. Aggiornare il WAF man mano che sono disponibili nuove regole per la protezione contro le nuove vulnerabilità rilevate.
- Abilitare la registrazione e ispezionare tali registri.
- Proteggete i vostri siti web e l’infrastruttura di rete critica dagli attacchi volumetrici utilizzando un servizio DNS autoritativo altamente ridondante e servizi di protezione DDoS e accelerazione web altamente distribuiti, ad esempio la CDN.
Iniziate con il vostro data
Potreste avere le vostre app perfettamente sintonizzate per distribuire contenuti e un solido set di controlli di sicurezza che aiutano a mitigare i rischi e magari anche a bloccare gli attacchi che lo fanno entrare. Tuttavia, perché lasciare che il traffico potenzialmente dannoso entri nella vostra rete in primo luogo? Perché correre il rischio che una policy venga persa o che un controllo venga ignorato?
I clienti Verizon Media Security hanno a portata di mano due funzionalità che possono proteggerli dalle minacce:
- Vediamo traffico di rete potenzialmente dannoso (o almeno inutile) che colpisce il tuo sito.
- Il WAF integrato Verizon Media può essere abilitato per bloccare il traffico dannoso prima che diventi automaticamente un problema.
Fate un passo importante per migliorare la sicurezza delle vostre applicazioni Web. Contattateci oggi stesso per saperne di più.
Riferimenti
- Verizon, “2020 Data Breach Investigations Report“, Verizon.com/business.com, enterprise.verizon.com/resources/reports/dbir/. Pagina 7.
- Ibid, pagina 88.
- Ibid, pagina 23.
- CWE, “2020 CWE Top 25 Most Dangerous software Weapies”, CWE.mitre.org, cwe.mitre.org/top25/archive/2020/2020_cwe_top25.html.
- HTMLpurifier, “HTML purifier XSS Attacks Smoketest“, HTMLpurifier.org, htmlpurifier.org/live/smoketests/xssAttacks.php.
- “OWASP, ” Cross site scripting (XSS) “, owasp.org, owasp.org/www-community/attacks/xss/.
- Ibid
- Buerhaus, Brett, “escalating XSS in PhantomJS image rendering to SSRF/local-file read, buer.haus. 29 giugno 2020.
