Migliora la sicurezza e la privacy aggiornando la cache HTTP

Se dimentichi o utilizzi in modo improprio l'intestazione Cache-Control, la sicurezza del tuo sito web e la privacy dei tuoi utenti potrebbero risentirne.

Arthur Sonzogni

Per impostazione predefinita, è sempre consentito memorizzare nella cache le risorse da qualsiasi tipo di cache. Il mancato utilizzo o l'uso improprio dell'intestazione Cache-Control potrebbe influire negativamente sulla sicurezza del tuo sito web e sulla privacy dei tuoi utenti.

Per le risposte personalizzate che vuoi mantenere private, ti consigliamo di:

• Impedire agli intermediari di memorizzare nella cache la risorsa. Imposta Cache-Control: private.
• Imposta una chiave della cache secondaria appropriata. Se la risposta varia a causa dei cookie, il che può accadere quando il cookie memorizza le credenziali, imposta Vary: Cookie.

Continua a leggere per scoprire perché è importante e per scoprire:

1. Problemi di sicurezza e privacy di cui potresti non essere a conoscenza
2. Diversi tipi di cache HTTP e idee sbagliate comuni
3. Azioni consigliate per i siti web di alto valore

Rischi per la sicurezza e la privacy correlati alla cache

Risorse con perdite dovute alle vulnerabilità Spectre

La vulnerabilità Spectre consente a una pagina di leggere la memoria di un processo del sistema operativo. Ciò significa che un malintenzionato può ottenere accesso non autorizzato ai dati cross-origin. Di conseguenza, i browser web moderni hanno limitato l'utilizzo di alcune delle loro funzionalità, come SharedArrayBuffer o il timer ad alta risoluzione, alle pagine con isolamento di origine diversa.

I browser web moderni applicano le norme sull'incorporamento multiorigine (COEP). In questo modo, le risorse cross-origin sono:

• Risorse pubbliche richieste senza cookie
• Risorse consentite esplicitamente per la condivisione tra origini tramite CORS o l'intestazione CORP

La configurazione COEP non impedisce a un malintenzionato di sfruttare Spectre. Tuttavia, garantisce che le risorse cross-origin non siano utili all'attaccante (se caricate dal browser come risorse pubbliche) o che non possano essere condivise con l'attaccante (se condivise con CORP: cross-origin).

In che modo la memorizzazione nella cache HTTP influisce su Spectre?

Se l'intestazione Cache-Control non è impostata correttamente, un malintenzionato potrebbe eseguire un attacco. Ad esempio:

1. La risorsa con credenziali è memorizzata nella cache.
2. L'utente malintenzionato carica una pagina con isolamento multiorigine.
3. L'utente malintenzionato richiede di nuovo la risorsa.
4. COEP:credentialless viene impostato dal browser, quindi la risorsa viene recuperata senza cookie. Tuttavia, una cache potrebbe restituire la risposta con le credenziali.
5. L'hacker può quindi leggere la risorsa personalizzata utilizzando un attacco Spectre.

Sebbene la cache HTTP di un browser web non consenta che questo tipo di attacco si verifichi in pratica, esistono cache aggiuntive al di fuori del controllo immediato del browser. Ciò potrebbe portare al successo di questo attacco.

Convinzioni errate comuni sulle cache HTTP

1. Le risorse vengono memorizzate nella cache solo dal browser

Spesso sono presenti più livelli di cache. Alcune cache sono dedicate a un singolo utente, altre a più utenti. Alcune sono controllate dal server, altre dall'utente e altre da intermediari.

• Cache del browser. Queste cache sono di proprietà di un singolo utente e dedicate a questo, implementate nel suo browser web. Migliorano le prestazioni evitando di recuperare la stessa risposta più volte.
• Proxy locale. Potrebbe essere stata installata dall'utente, ma può anche essere gestita da intermediari: la sua azienda, la sua organizzazione o il suo fornitore di servizi internet. I proxy locali memorizzano spesso nella cache una singola risposta per più utenti, il che costituisce una cache "pubblica". I proxy locali hanno più ruoli.
• Cache del server di origine / CDN. Questo aspetto è controllato dal server. Lo scopo della cache del server di origine è ridurre il carico sul server di origine memorizzando nella cache la stessa risposta per più utenti. Gli obiettivi di una CDN sono simili, ma distribuiti in tutto il mondo e assegnati al gruppo di utenti più vicino per ridurre la latenza.

Potrebbero esserci vari livelli di cache tra il browser e il server. Ad esempio, potresti trovare una cache del server, seguita da una CDN e dalla cache del browser. Potrebbe anche essere configurato un proxy locale tra la CDN e la cache del browser.

2. SSL impedisce agli intermediari di memorizzare nella cache le risorse HTTPS

Molti utenti utilizzano regolarmente proxy configurati localmente, a scopo di accesso (ad esempio per condividere una connessione con misuratore), per l'ispezione di virus o per la Prevenzione della perdita di dati (DLP). La cache intermedia esegue l'intercettazione TLS.

Spesso viene installata una cache intermedia sulle workstation dei dipendenti di un'azienda. I browser web sono configurati per considerare attendibili i certificati del proxy locale.

Di conseguenza, alcune risorse HTTPS potrebbero essere memorizzate nella cache da questi proxy locali.

Come funziona la cache HTTP

• Per impostazione predefinita, la memorizzazione nella cache delle risorse è consentita implicitamente.
• La chiave della cache principale è composta dall'URL e dal metodo. (URL, metodo)
• La chiave della cache secondaria è costituita dalle intestazioni incluse nell'intestazione Vary. Vary: Cookie indica che la risposta dipende da Cookie.
• L'intestazione Cache-Control offre un controllo più granulare.

Sfrutta queste azioni consigliate per il tuo sito web

Gli sviluppatori di siti web di alto valore, inclusi i siti web con traffico elevato e i siti web che interagiscono con informazioni di identificazione personale, devono intervenire subito per migliorare la sicurezza.

Il rischio maggiore si verifica quando l'accesso a una risorsa varia a seconda dei cookie. Se non viene intrapresa alcuna azione preventiva, una cache intermedia potrebbe restituire una risposta richiesta con i cookie per una richiesta che non li ha utilizzati.

Ti consigliamo di seguire uno dei seguenti passaggi:

• Impedire agli intermediari di memorizzare nella cache la risorsa. Imposta Cache-Control: private.
• Imposta una chiave della cache secondaria appropriata. Se la risposta varia a causa dei cookie, il che può accadere quando il cookie memorizza le credenziali, imposta Vary: Cookie.

In particolare, modifica il comportamento predefinito: definisci sempre Cache-Control o Vary.

Considerazioni aggiuntive

Esistono altri tipi di attacchi simili che utilizzano la cache HTTP, ma si basano su un meccanismo diverso dall'isolamento delle origini diverse. Ad esempio, Jake Archibald descrive alcuni attacchi in How to win at CORS.

Questi attacchi vengono mitigati da alcuni browser web che suddividono la cache HTTP in base al fatto che la risposta della risorsa sia stata richiesta con le credenziali o meno. A partire dal 2022, Firefox suddivide la cache, mentre Chrome e Safari no. In futuro, Chrome potrebbe suddividere la cache. Tieni presente che questi attacchi sono diversi e complementari alla suddivisione in base all'origine di primo livello.

Anche se questo problema può essere mitigato per i browser web, rimarrà nelle cache dei proxy locali. Pertanto, ti consigliamo comunque di seguire i consigli riportati sopra.

---

Foto di intestazione di Ben Pattinson su Unsplash.