Listino Supporto Partner Contatti 800 13.40.41

Articoli

Icona delle News


Ignorare SOP utilizzando la cache del browser

26/03/20 CoreTech Blog

×Non sei ancora nostro cliente Acunetix? Diventa Partner CoreTech e visita il nostro configuratore prezzi

La memorizzazione nella cache non configurata correttamente può causare varie vulnerabilità. Ad esempio, gli utenti malintenzionati potrebbero utilizzare server intermedi mal configurati (proxy inversi, servizi di bilanciamento del carico o proxy della cache) per ottenere l'accesso a i dati sensibili. Un altro modo per sfruttare la memorizzazione nella cache è attraverso attacchi di avvelenamento da Cache  Web.

La cache del browser può apparire come un posto molto sicuro per archiviare temporaneamente le informazioni private. Il rischio principale è che un utente malintenzionato possa accedervi tramite il file system, che di solito è considerato una vulnerabilità a basso rischio. Tuttavia, in alcuni casi, le intestazioni relative alla cache non configurate correttamente possono causare problemi di sicurezza più gravi.

Rischi di interazione tra domini

Alcuni siti web hanno diversi sottodomini e hanno la necessità di condividere i dati tra di loro. Ciò normalmente non è possibile a causa della politica sulla stessa origine (SOP). Esistono alcuni metodi che abilitano tale interazione tra domini, ad esempio, JSONP (JSON con Padding). Gli sviluppatori che utilizzano tali metodi devono implementare un qualche tipo di protezione contro la perdita di dati su altri siti.

Diciamo che un sito di esempio ha due sottodomini: blog.example.com e account.example.com. Il sito account.example.com dispone di un endpoint JSONP che restituisce dati sensibili dell’utente in base al cookie dell’utente. Per evitare perdite, questo endpoint verifica l'intestazione Referer in una whitelist che include blog.example.com.

Con questa configurazione, se l'utente è attirato a visitare un sito dannoso, l'attaccante non può rubare direttamente i dati sensibili. Tuttavia, se l'endpoint JSONP imposta le intestazioni relative alla cache, l'utente malintenzionato potrebbe essere in grado di accedere alle informazioni private dalla cache del browser.

Comportamento del browser

I browser hanno implementazioni della cache leggermente diverse, ma alcuni aspetti sono simili.  Innanzitutto, è possibile memorizzare nella cache solo le risposte GET. Quando il browser riceve la risposta alla richiesta GET, controlla le intestazioni di risposta per le informazioni sulla memorizzazione nella cache:

  • Se la risposta contiene un'intestazione pubblica Cache-Control: private o Cache-Control: public la risposta viene memorizzata nella cache per Cache-Control: max-age=<seconds>.
  • Se la risposta contiene un'intestazione Expires la risposta viene memorizzata nella cache in base al relativo valore (questa intestazione ha meno priorità rispetto a Cache-Control)
  • Se nessuna di queste intestazioni è presente, alcuni browser possono controllare l'intestazione Last-Modified e in genere memorizzare nella cache la risposta per il dieci percento della differenza tra la data corrente e la data Last-Modified
  • Se non sono presenti intestazioni relative alla cache, il browser può memorizzare nella cache la risposta, ma in genere la riconvalida prima di utilizzarla.

Potrebbero sorgere problemi a causa del fatto che esiste una sola cache del browser per tutti i siti Web e utilizza solo una chiave per identificare i dati: un URI assoluto normalizzato (scheme://host:port/path?query). Ciò significa che la cache del browser non dispone di informazioni aggiuntive sulla richiesta che ha avviato una particolare risposta (ad esempio, il sito/origine da cui proviene, la funzione JavaScript o il tag che l'ha avviata, i cookie o le intestazioni associate, ecc.). Qualsiasi sito ottiene la risposta memorizzata nella cache da account.example.com purché avvii una richiesta GET allo stesso URI.

Anatomia dell'attacco

Di seguito è riportata una spiegazione dettagliata dell'utilizzo di questa vulnerabilità per un attacco:

  1. L'utente visita blog.example.com.
  2. Uno script in blog.example.com richiede informazioni sull'account utente.
  3. Il browser dell'utente invia una richiesta all'endpoint JSONP in account.example.com.
  4. La risposta dall'endpoint JSONP in account.example.com contiene intestazioni correlate alla cache.
  5. Il browser dell'utente memorizza nella cache il contenuto della risposta.
  6. L'utente è attirato a un sito dannoso
  7. Il sito dannoso contiene uno script che punta all'endpoint JSONP in account.example.com.
  8. Il browser restituisce la risposta memorizzata nella cache allo script nel sito dannoso.

In questo caso, l'intestazione Referer non viene mai controllata perché la risposta proviene dalla cache. Pertanto, l'utente malintenzionato ottiene l'accesso alle informazioni private memorizzate nella cache.

Vulnerabilità simili

Lo stesso approccio può essere utilizzato per sfruttare altre varianti di Cross-Site Script Inclusion (XSSI) e altri attacchi SOP Bypass. Tali attacchi possono ignorare altri controlli sul lato server, ad esempio l'intestazione Origin l'attributo cookie SameSite o intestazioni personalizzate.

Supponiamo che account.example.com utilizza Cross-Origin Resource Sharing (CORS) anziché l'endpoint JSONP. Restituisce Access-Control-Allow-Origin: * ma utilizza un token speciale da un'intestazione personalizzata per autenticare l'utente e proteggere i dati sensibili.

Se le risposte vengono memorizzate nella cache, l'utente malintenzionato può rubare informazioni private effettuando una richiesta allo stesso URI. Non esiste alcuna protezione CORS (a causa di Access-Control-Allow-Origin: * e il browser dell'utente restituirà i dati memorizzati nella cache senza controllare il token di intestazione personalizzato.

È possibile vedere come funzionano queste vulnerabilità in pratica analizzando gli output della console del browser in un sito di test dedicato.

Come proteggersi dal bypass SOP

La vulnerabilità di bypass SOP descritta è causata da una configurazione errata. Nel caso di interazioni tra origini, è necessario disattivare la cache del browser. La maggior parte dei framework e degli script già pronti non imposta le intestazioni relative alla cache o le imposta correttamente per impostazione predefinita (Cache-Control: no-store). Tuttavia, dovresti sempre controllare queste intestazioni per essere sicuro.

I fornitori di browser stanno ora prendendo in considerazione o implementando un approccio più rigoroso alla memorizzazione nella cache. Speriamo che questo cambiamento prevenga tali perdite di origine incrociata.

Nota – I trucchi inventati ai fini di questo articolo sono stati ispirati dall'articolo HTTP Cache Cross-Site Leaks di Eduardo Vela.


Articoli su Acunetix e Hacking

Introduzione alle web shell - parte 1Iniezioni di NoSQL e come evitarleDebunking 5 miti sulla postura della sicurezza informaticaConfigurazione passo passo di Acunetix con JenkinsAnche il più forte cade: un'iniezione SQL in Sophos XG FirewallCosa sono i riferimenti a oggetti diretti non sicuriAcunetix rilascia Business Logic RecorderCome recuperare da un evento del sito Web compromessoCome difendersi dagli hacker Black Hat durante la pandemia COVID-19Che cos'è l'inclusione remota dei file (RFI)?Apache Security - 10 consigli per un'installazione sicuraUn nuovo sguardo sugli attacchi correlati al proxy inversoVulnerabilità delle entità esterne XML in Internet ExplorerVulnerabilità delle password comuni e come evitarleChe cosa sono le iniezioni HTMLTutto quello che devi sapere sugli attacchi Man-in-the-MiddleTesta le tue competenze XSS utilizzando siti vulnerabiliRed Teaming – 5 consigli su come farlo in modo sicuroPratiche di codifica sicura – I tre principi chiavePerché hacker malintenzionati hanno messo gli occhi sugli ospedaliMutation XSS nella ricerca GoogleLa maledizione delle vecchie librerie JavaIgnorare SOP utilizzando la cache del browserDirottamento di sessione e altri attacchi di sessioneCome e perché evitare reindirizzamenti e inoltri non convalidati?Come abbiamo trovato un altro XSS in Google con AcunetixChe cos'è un buffer overflowChe cos'è l'overflow di IntegerChe cos'è HSTS e perché dovrei usarlo?Che cosa è OS Command InjectionCoreTech assicura protezione dei siti Web con AcunetixCoreTech distributore Acunetix a fianco dei partner per la CyberSecurityCyberSecurity applicativa, nuova opportunità per voi!

Knowledge Base su Acunetix e Hacking

Il Pen Testing applicativo con Acunetix
Ripe Ncc Member
vmware
CloudLinux
Plesk
HP
Microsoft