Tecnica

Cos’è XSS? Spiegazione degli attacchi di scripting tra siti

Cos’è XSS? Spiegazione degli attacchi di scripting tra siti

 

Nel caso di un attacco XSS, gli aggressori iniettano codice dannoso in un modulo Web o nell’URL di un’applicazione Web per costringerlo a fare qualcosa che non dovrebbe fare.


 
 

Cross-Site Scripting (XSS) è un attacco informatico in cui un hacker inserisce codice dannoso in un modulo Web o nell’URL di un’applicazione Web. Questo codice dannoso, scritto in un linguaggio di scripting come JavaScript o PHP, può fare qualsiasi cosa, dal distruggere la pagina che stai tentando di caricare per rubare le tue password o altre credenziali di accesso.

XSS utilizza un aspetto importante della moderna Internet, ovvero il fatto che la maggior parte delle pagine Web viene creata durante il caricamento delle pagine, a volte eseguendo il codice nel browser stesso. Ciò può rendere difficile prevenire tali attacchi.

Controlla anche:

Come funziona un attacco XSS?

Chiunque può creare un sito Web che contiene codice dannoso. Nel caso di un attacco di cross-site scripting, l’attaccante organizza tutto in modo che il suo codice raggiunga il computer della vittima quando visita il sito Web di qualcun altro. Da qui deriva la “croce” nel nome. Gli attacchi XSS raggiungono questo obiettivo senza richiedere l’accesso privilegiato a un server Web per inserire di nascosto il codice. Invece, gli aggressori sfruttano il modo in cui funzionano i siti Web moderni.

Se qualcuno ti chiedesse una spiegazione semplice e basilare di come funziona il web, probabilmente potresti dirgli qualcosa del genere: la persona che vuole creare una pagina web scrive un documento HTML e lo inserisce su un web server; Quando l’utente vuole accedere a questa pagina, indirizza il suo browser all’indirizzo del server, il browser scarica e interpreta il codice HTML e costruisce una copia della pagina web dell’utente.

Questa descrizione non è sbagliata, ma alcuni aspetti sono obsoleti (e sono in circolazione da oltre dieci anni). Innanzitutto, molte, se non tutte, le pagine Web oggi sono dinamiche, ovvero non mostrano lo stesso HTML statico a tutti i visitatori, ma vengono generate istantaneamente dalle informazioni nel database del server quando il browser richiede l’accesso. La pagina che il browser riceve dal server dipende spesso dalle informazioni inviate con la richiesta, informazioni che a volte assumono la forma di parametri nell’URL utilizzato per accedere al sito. I siti Web non sono solo costituiti da HTML e Cascading Style Sheets (CSS) che descrivono come visualizzare testo e grafica, ma contengono anche codice eseguibile scritto in linguaggi di scripting, solitamente JavaScript.

In un attacco XSS, l’hacker utilizza questa interazione tra l’utente e il sito Web per eseguire codice dannoso sul computer dell’utente. ma come? Considera il seguente URL:

https://www.google.com/search?q=CSO+online

Inseriscilo nella barra degli indirizzi del tuo browser e vedrai i risultati di ricerca di Google per “CSO Online”. In effetti, la pagina che vedrai è esattamente la stessa di se avessi inserito “CSO Online” nella barra di ricerca del tuo browser o nella home page di Google. Noterai, tra l’altro, che questa frase compare in più punti della pagina, inclusa la barra di ricerca in montagna:

Cos'è XSS?  Chiarire gli attacchi di scripting tra siti

E se, invece della frase innocente e di successo “CSO online”, questo URL contenesse codice JavaScript dannoso come questo?

https://www.google.com/search?<script>doEvil()</script>

doEvil() fa davvero un pessimo lavoro qui. Potresti essere preoccupato che Google, invece di visualizzare “CSO Online” sulla pagina che stai tornando da questo URL, integrerà invece dinamicamente il javascript errato nella pagina che stai visualizzando e che questo script venga eseguito nel tuo browser , provocando un pasticcio. Le tue preoccupazioni saranno infondate, perché Google ha un gran numero di professionisti della sicurezza IT di talento tra i suoi dipendenti e ha implementato misure correttive di cui parleremo tra poco. Tuttavia, non tutti i siti sono molto attenti e questo ti dà un’idea di come funzionano tali attacchi.

Ataki XSS

Gli attacchi XSS rientrano in diverse categorie: attacchi riflessi, attacchi basati su DOM e attacchi archiviati. Ecco come differiscono:

  • Attacchi riflessi: noti anche come attacchi deboli, il codice JavaScript dannoso viene inviato dal browser della vittima a Google, quindi riflesso in un formato eseguibile, mai archiviato sui server di Google. Questi attacchi fanno spesso parte di una truffa di phishing, in cui il collegamento dannoso è camuffato da qualcosa di più divertente e inviato alla vittima tramite e-mail o SMS.
  • Attacchi basati su DOM: questo è un tipo di attacco riflesso chiamato Document Object Model, che è un’API standard che definisce come i browser creano una pagina Web da codice HTML o JavaScript di base. La maggior parte degli attacchi DOM sono simili agli attacchi reflex descritti in precedenza, con la differenza che il codice dannoso non viene mai inviato al server: viene invece passato come parametro ad alcune funzioni JavaScript che vengono eseguite nel browser stesso, il che significa che i meccanismi di protezione lato server non sono in grado di proteggere l’utente. Se sei interessato ai dettagli, PortSwigger ha una descrizione più dettagliata di come funzionano gli attacchi DOM.
  • Attacchi memorizzati: altrimenti persistenti; L’attaccante utilizza le funzionalità interattive del sito Web per salvare codice dannoso sul server Web. In un tipico esempio, l’attaccante lascia un commento su un post del blog che contiene JavaScript dannoso. La prossima volta che qualcuno caricherà questa pagina, il codice verrà eseguito.
  • Vulnerabilità all’attacco XSS

Cosa rende un sito Web vulnerabile a un attacco XSS? Si spera che la nostra discussione finora abbia fornito alcune indicazioni. Se l’applicazione Web accetta ingenuamente l’input dell’utente, non lo controlla per codice eseguibile dannoso e utilizza tali dati per eseguire il rendering di una pagina o eseguire altre operazioni, è vulnerabile a questo tipo di attacco.

E i rischi sono grandi. L’aspetto principale della sicurezza del browser è la cosiddetta politica della stessa origine, che afferma che uno script in esecuzione su una pagina può accedere ai dati sull’altra pagina solo se entrambi i lati hanno la stessa origine (definita come una combinazione di URI, nome host, e porta numerica). Tuttavia, se è possibile eseguire JavaScript dannoso nel browser mentre la vittima accede al sito Web, il browser consentirà a JavaScript di accedere ai dati di altri siti Web che condividono una risorsa con il sito Web vulnerabile. JavaScript può accedere ai cookie e ad altre informazioni di sessione proprietarie, che è una buona ricetta per hackerare gli account Internet delle vittime.

Carichi utili XSS

Nel gergo del malware, un payload è un codice eseguibile che esegue le azioni richieste dall’attaccante. Nel caso di un attacco XSS, il payload è un codice script che l’attaccante esegue per ingannare l’esecuzione del browser della vittima.

C’è un enorme elenco di modelli di payload XSS nel repository Payloadbox su GitHub. Se hai familiarità con JavaScript, esaminarlo potrebbe darti un’idea di come gli aggressori XSS fanno il loro lavoro sporco. Tuttavia, un attacco XSS va oltre il tagliare e incollare il payload nell’URL: l’attaccante deve comprendere le funzioni e le vulnerabilità specifiche dell’applicazione web che vuole sfruttare per pianificare l’attacco. Se vuoi approfondire e vedere alcuni esempi di attacchi XSS, controlla il sito Web OWASP XSS per uno sguardo approfondito al codice dello script che dimostra un attacco XSS.

Protezione e prevenzione XSS

Se stai creando o mantenendo un’applicazione Web o un sito Web interattivo, ci sono tre tecniche principali che dovresti considerare nella tua progettazione per evitare potenziali attacchi di scripting tra siti.

  • Sterilizzazione dei dati in ingresso. La risposta ovvia per impedire che codice dannoso venga passato come input e restituito all’utente è semplicemente non accettare codice script come input. Dovresti assolutamente filtrare il tuo input tenendo presente questo, ma è più facile a dirsi che a farsi; Piccole porzioni di codice eseguibile possono passare attraverso i filtri. Un modo per affrontare questo problema è utilizzare una whitelist invece di un approccio blacklist – ad esempio, invece di provare a scrivere un filtro che bloccherà tutto il codice dannoso inserito in un modulo web, devi scrivere la tua applicazione per accettare il dati in determinati orari Formati (numeri di telefono, indirizzi e-mail, ecc.) solo quando è quello che vuoi.
  • Fuga dall’output. Questa è la soluzione al problema d’altra parte. Se un’applicazione Web rimanda l’input dell’utente a una pagina Web, questi dati devono essere filtrati per garantire che non diventino eseguibili su quella pagina. Se l’utente inserisce tag HTML come input, l’applicazione deve utilizzare caratteri sovrascritti in modo che questi tag appaiano come testo nella pagina dei risultati anziché integrarsi con l’HTML della pagina stessa.
  • Politica di sicurezza dei contenuti standard (CSP). CSP adotta l’approccio “whitelisting” al di fuori dell’immissione di testo nel regno dello scripting: un’applicazione Web dovrebbe eseguire solo il codice che l’utente ha specificato per essere sicuro. Google ha alcune grandi risorse sull’implementazione di CSP.

Prova XSS

Il test di vulnerabilità per gli attacchi XSS è un aspetto importante per garantire la sicurezza di un’applicazione web. OWASP dispone di risorse che descrivono in dettaglio come testare le applicazioni per evitare attacchi DOM o invertire lo scripting cross-site. Se stai cercando un foglio XSS, OWASP ha anche un documento con codice di attacco XSS per te che può essere utilizzato per aggirare alcuni filtri di difesa XSS; Si rivelerà prezioso nei test di penetrazione che puoi eseguire sui tuoi sistemi.

XSS e CSRF

Potresti sentire che CSRF viene utilizzato nello stesso contesto di XSS. È l’abbreviazione di Cross-Site Request Forgery, un attacco, come XSS, che prende di mira il browser di un utente. La differenza principale è che CSRF utilizza una sessione autenticata per l’utente (forse ha effettuato l’accesso al proprio conto bancario) mentre XSS non ha bisogno di una sessione autenticata per essere efficace.

Diciamo che un utente ha effettuato l’accesso a Twitter e a una banca Internet contemporaneamente e fa clic su un collegamento Twitter simile al seguente:

http://www.yourbank.com/sendmoney,do?from=you&to=attacker&amount=5000

A seconda del modo in cui la tua banca gestisce i token di sessione e del browser che stai utilizzando, possono improvvisamente diventare molto più poveri. XSS è un vettore di attacco più pericoloso, ma è importante difendersi sia da XSS che da CSRF. OWASP ha preparato una scheda informativa sulle misure di protezione contro CSRF.

Attacchi XSS recenti e famigerati

Uno dei più antichi e famosi attacchi di cross-site scripting si è verificato nel 2005, quando l’intraprendente utente di MySpace Sammy Kamkar si è reso conto che poteva inserire codice JavaScript nel suo profilo che avrebbe autenticato automaticamente chiunque visitasse il sito – e anche copiare quel codice sui profili del tuo nuovi amici, grazie a ciò, tutti coloro che visiteranno queste pagine saranno anche suoi amici. (La sceneggiatura ha assicurato che ciascuno dei nuovi amici di Kamkar entrasse nella “top 8” – abbiamo paura di capirlo, dovresti esserci, ma credici, era importante.) In 24 ore, si è fatto più di un milione di amici e ha costretto MySpace a chiudere l’intero sito per un breve periodo.

Si scopre che il cosiddetto worm Sami è per lo più innocuo. Tuttavia, altri erano più fastidiosi:

• Ebay ha avuto per anni vulnerabilità XSS che hanno consentito agli hacker di rubare le credenziali di accesso degli utenti

• Gli attaccanti XSS sono stati in grado di rubare V-Bucks dai giocatori di Fortnite nel 2019.

• Il gruppo di hacker Magecart ha attaccato British Airways nel 2018 con un attacco XSS, rubando centinaia di migliaia di identità di utenti

E il cross-site scripting rimane una seria minaccia oggi. A partire dal 2021, sono state rilevate vulnerabilità XSS nella piattaforma di posta elettronica Zimbra, Wordpress e nella piattaforma di gestione IT open source Nagios. Tieni presente che gli hacker di solito non utilizzano tecniche di attacco isolatamente: lo scripting tra siti è un componente di una forma complessa di attacco con caratteri jolly TLS recentemente scoperta nota come ALPACA. Per evitare minacce pericolose, assicurati di chiudere le vulnerabilità XSS.

Fonte: OSC

.

Guarda anche

Elon Musk fornisce gratuitamente il servizio Starlink in Ucraina

Related Articles

Back to top button