Request Support  | Contact Sales

Diventa Autore per CoreTech | Scopri di più





Ignorare SOP utilizzando la cache del browser

26/03/20 CoreTech Blog

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.

Banner

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

Trovare le vulnerabilità dei siti web prima degli HackerL'importanza della convalida delle correzioni: lezioni da GoogleSDLC agile e sicuro - Best practiceIn che misura le aziende gestiscono la sicurezza delle applicazioni Web?Cross-Origin Resource Sharing (CORS) e intestazione Access-Control-Allow-OriginCosa sono i reindirizzamenti aperti?DevSecOps: come arrivarci da DevOpsIl bigino su SQL Injection per sviluppatoriSfruttare SSTI in ThymeleafSicurezza nginx: come proteggere la configurazione del serverRafforzamento del sistema Web in 5 semplici passaggiCos'è la sicurezza del sito Web - Come proteggere il tuo sito Web dall'hackingRapporto sulle vulnerabilità delle applicazioni Web Acunetix 2020Perché l'elenco delle directory è pericoloso?Cosa sono gli hack di Google?Cosa è l'attacco BEASTWeb Shells in Action - Rilevazione e prevenzione - parte 5Web Shells in Action - parte 4Mantenere le Web Shells sotto copertura - parte 3Introduzione alle web shell - parte 2: 101 Uso di PHPIntroduzione alle web shell - parte 1Debunking 5 miti sulla postura della sicurezza informaticaIniezioni di NoSQL e come evitarleConfigurazione passo passo di Acunetix con JenkinsCosa sono i riferimenti a oggetti diretti non sicuriAnche il più forte cade: un'iniezione SQL in Sophos XG FirewallAcunetix rilascia Business Logic RecorderCome recuperare un 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 password comuni e come evitarleTutto quello che devi sapere sugli attacchi Man-in-the-MiddleChe cosa sono le iniezioni HTMLRed Teaming – 5 consigli su come farlo in modo sicuroTesta le tue competenze XSS utilizzando siti vulnerabiliPerché hacker malintenzionati hanno messo gli occhi sugli ospedaliPratiche di codifica sicura – I tre principi chiaveLa maledizione delle vecchie librerie JavaMutation XSS nella ricerca GoogleIgnorare SOP utilizzando la cache del browserCome e perché evitare reindirizzamenti e inoltri non convalidati?Dirottamento di sessione e altri attacchi di sessioneCome 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 InjectionVulnerabilità delle entità esterne XML in Internet ExplorerCoreTech assicura protezione dei siti Web con AcunetixCoreTech distributore Acunetix a fianco dei partner per la CyberSecurityCyberSecurity applicativa, nuova opportunità per voi!