Home Articoli tecnici Attacchi XSS (Cross-Site Scripting) nel quarto trimestre del 2020: Tendenze e BEST practice
Applications

Attacchi XSS (Cross-Site Scripting) nel quarto trimestre del 2020: Tendenze e BEST practice

About The Author

Outline

Fonte originale: Edgecast

La sicurezza delle applicazioni Web rimane un vettore di minacce principale per le organizzazioni di piccole e grandi dimensioni. Secondo il rapporto DBIR (Data Breach Investigations Report) di Verizon 2020, il 43% di tutte le violazioni dei dati riguardava un’applicazione web,¹ e il 80% di tutti i vettori di hacking si rivolgono ad applicazioni web.²

Nel quarto trimestre del 2020, Verizon Media ha registrato un netto aumento del traffico XSS (Cross-Site Scripting) sulla nostra CDN (rete per la distribuzione dei contenuti) rispetto ai trimestri precedenti. Questo blog esplora alcuni punti dati sul traffico e analizza uno dei payload XSS più tentati. Condividiamo anche come utilizzare questi dati per applicare misure di protezione.

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 tenere una conversazione sulla sicurezza necessaria con il vostro team di leadership e le vostre controparti operative/aziendali.

‍We avere i dati – esploriamo

‍The Verizon Media WAF ha mitigato 1,5 miliardi di richieste nel quarto trimestre del 2020. “Definiamo “mitigate” qualsiasi evento WAF che ha attivato un blocco, una risposta personalizzata o un reindirizzamento URL.” Questi 1,5 miliardi di blocchi rappresentano richieste HTTP che altrimenti avrebbero raggiunto i server di origine dei nostri clienti. Questi dati ci dicono:

  1. La quantità di analisi delle vulnerabilità in background è enorme. Ti sbagli 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, in questo caso non c’è modo di stravolgere l’orso, perché gli orsi sono tutti stampati in 3D in massa e automatizzati per darvi la caccia.”³
  2. Se le applicazioni Web sono protette, tale scansione potrebbe sembrare non più dannosa di una manopole antieffrazione e consentire a tale traffico di raggiungere i server è innocuo se non incorrere in un carico aggiuntivo sul server. Ma nella guerra asimmetrica della cibersicurezza, l’attaccante deve avere ragione solo una volta, rendendo così più facile per loro avere ragione in futuro. Allora perché lasciare che il ladro faccia oscillare il pomello della porta se si riesce a evitarlo?

Per guidare questa 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 secondo trimestre del 2020 al quarto posto nel quarto trimestre del 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 per conoscere il traffico XSS

Nell’Open Web Application Security Project (OWASP), i difetti di XSS si verificano quando un’applicazione include dati non attendibili in una nuova pagina Web senza convalida o fuga adeguata 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 ‍According. XSS consente agli autori degli attacchi di eseguire script nel browser della vittima, il che può dirottare le sessioni degli utenti, danneggiare i siti Web o reindirizzare l’utente a siti dannosi.

Questa esposizione minaccia l’infrastruttura, la riservatezza e l’integrità dei dati e la disponibilità dei dati trasmessi su Internet. Questi attacchi possono comportare l’accesso non autorizzato ai contenuti, la perdita di informazioni personali identificabili (PII) e la diffusione di informazioni private/protette da copyright.

Si tratta di un problema in quanto non viene nascosto nulla dopo la connessione e l’esposizione a Internet: Se lo si alza, verrà scansionato. Una volta che una nuova applicazione Web è 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 colpo di scena, di cui discuteremo a breve.

In primo luogo, continuiamo a 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 per 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 per MITER CWE Top 25 anche per il 2020:⁴

Figura 2. Un breve elenco delle debolezze nella Top 25 CWE 2020, compreso il punteggio complessivo di ciascuna di esse.

Così come abbiamo visto un aumento del traffico XSS bloccato, anche il numero di vulnerabilità effettive 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 le vulnerabilità XSS sono sempre documentate

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 curioso cattivo attore scansiona con successo un sistema, potrebbe tentare un exploit XSS, tutto nello spirito di eseguire la ricognizione. Peggio ancora, l’attività di ricostruzione, e i risultati ottenuti, potrebbero essere utilizzati per eliminare un payload compromettente o distruttivo tramite XSS o come trampolino di lancio verso qualcosa di più nefasto, come un SSRF (Server-Side Request Forgery).

‍Is che è un “eccellente trampolino di lancio”, vedo?

‍Remember lo scenario di doorknob-jiggling che abbiamo menzionato prima? È ora di riportare quella metafora.

La maggior parte del traffico e degli eventi XSS potrebbe non essere critica per se stessi, ma potrebbero portare a sfide e problemi significativi lungo la strada, un trampolino di lancio per un compromesso di successo, se volete.

Gli attacchi XSS riusciti potrebbero consentire agli autori degli attacchi di eseguire HTML e JavaScript arbitrari nel browser della vittima. In genere, l’utente deve interagire con alcuni collegamenti dannosi che puntano a una pagina controllata da un utente malintenzionato, ad esempio siti Web o annunci pubblicitari.

Esaminiamo la violazione della regola principale per il quarto trimestre 2020, designata internamente come regola ID 941100, che è stata mappata a uno dei payload più importanti, dimostrando la capacità di utilizzare XSS come attacco di lancio:

“><Avviso script >(String.fromCharCode(88,83,83))</script>”

“Si tratta di una stringa di test XSS molto comune in molti archivi di codice, come 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 al XSS riflesso.”

“Quando un utente malintenzionato verifica l’esistenza di un XSS riflesso, gli attacchi riflessi vengono consegnati tramite un altro percorso, ad esempio in un messaggio di posta elettronica o in un altro sito Web.” “Quando un utente viene ingannato a fare clic su un collegamento dannoso, a inviare un modulo appositamente predisposto o anche solo a navigare in un sito dannoso, il codice inserito viene inviato al sito Web vulnerabile, che riflette l’attacco nel browser dell’utente.”⁶.

Figura 3. In che modo gli autori degli attacchi informatici sfruttano le vulnerabilità XSS.

“Questo attacco può eseguire qualsiasi cosa sul sito Web che l’utente attaccato può eseguire, inclusa la “divulgazione del cookie di sessione dell’utente, che consente 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 suo conto può determinare il rilevamento di un account.

Ci sono altri esempi di scalini su cui attingere. In un altro caso pubblicamente documentato, un attacco SSRF è stato originariamente avviato tramite un exploit XSS e il ricercatore della sicurezza “è stato in grado di passare da XSS all’interno di un’immagine fino a ottenere una lettura arbitraria di file locali sul server”⁸

Non tutti i ricercatori (né cybercriminali) 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 premio più importante nei loro programmi bug Bounty.

‍Mitigation e defense‍

In assenza di dati, è difficile prendere una decisione. Tuttavia, diventa più facile identificare un percorso che ti conduca al risultato desiderato una volta che hai visibilità su una situazione. Ecco una raccolta di suggerimenti e risorse per ridurre i rischi che il traffico XSS comporta per la rete e l’azienda.

  1. Assicurarsi di essere a conoscenza di tutti i dispositivi collegati a Internet e che sia i sistemi legacy che quelli di test siano considerati per l’irrigidimento o non in linea. Questo aspetto è particolarmente importante nell’era dell’infrastruttura cloud, in cui i team di sviluppo possono avviare i computer con pochi clic o inviando un modulo.
  2. 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 server. Configurare correttamente le configurazioni TLS per proteggerle dagli attacchi MITM.
  3. Applicare regolarmente patch a tutti i server collegati a Internet. A volte, i framework comunemente usati 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.
  4. Verificare periodicamente l’efficacia del rafforzamento della sicurezza. Utilizzare gli stessi strumenti DAST (Dynamic Application Security Testing) utilizzati dagli autori degli attacchi, come OWASP ZAP o strumenti di scansione delle vulnerabilità simili in Kali Linux. In alternativa, utilizzare un servizio DAST o di test di penetrazione per rilevare ed eseguire la scansione di server vulnerabili collegati a Internet.
  5. Abilitare un WAF (Web Application Firewall) per bloccare gli attacchi più comuni.
  6. Mantenere aggiornato il WAF per bloccare immediatamente eventuali vulnerabilità rilevate, consentendo al team dell’applicazione di distribuire una correzione. Aggiornare il WAF quando sono disponibili nuove regole per proteggersi dalle vulnerabilità rilevate di recente.
  7. Abilitare la registrazione e ispezionare tali registri.
  8. 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 CDN.

Iniziate con il vostro data‍

Le applicazioni potrebbero essere ottimizzate per la distribuzione di contenuti e un solido set di controlli di sicurezza per ridurre i rischi e, forse, bloccare gli attacchi interni. Tuttavia, perché lasciare che il traffico potenzialmente dannoso entri nella rete in primo luogo? Perché correre il rischio che una policy venga persa o che un controllo venga ignorato?

I clienti di Verizon Media Security hanno a portata di mano due funzionalità che possono proteggerli dalle minacce:

  1. Vediamo traffico di rete potenzialmente dannoso (o almeno non utile) che colpisce il tuo sito.
  2. Il Verizon Media WAF integrato 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

  1. Verizon, “2020 Data Breach Investigations Report “,Verizon.com/business.com, enterprise.verizon.com/resources/reports/dbir/. Pagina 7.
  2. Ibid, pagina 88.
  3. Ibid, pagina 23.
  4. CWE, “2020 CWE Top 25 Most Dangerous software Wealth“, CWE.mitre.org, cwe.mitre.org/top25/archive/2020/2020_cwe_top25.html.
  5. HTMLpurifier, “HTML purifier XSS Attacks Smoketest,” HTMLpurifier.org, htmlpurifier.org/live/smoketests/xssAttacks.php.
  6. “OWASP, “Cross Site Scripting (XSS)“, owasp.org, owasp.org/www-community/attacks/xss/.
  7. Ibid
  8. Buerhaus, Brett, “escalating XSS in PhantomJS image rendering to SSRF/local-file read, buer.haus. 29 giugno 2020.