Migliora la sicurezza e la privacy aggiornando la cache HTTP

Eliminare o usare impropriamente l'intestazione Cache-Control può influire negativamente sulla sicurezza del tuo sito web e sulla privacy degli utenti.

Per impostazione predefinita, qualsiasi tipo di cache può sempre essere memorizzata nella cache. Il mancato utilizzo o l'uso improprio dell'intestazione Cache-Control potrebbe influire negativamente sulla sicurezza del tuo sito web e sulla privacy degli utenti.

Per mantenere private le risposte personalizzate, consigliamo di:

• Impedisci agli intermediari di memorizzare nella cache la risorsa. Imposta Cache-Control: private.
• Imposta una chiave cache secondaria appropriata. Se la risposta varia a causa dei cookie (che possono verificarsi quando il cookie memorizza le credenziali), imposta Vary: Cookie.

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

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

Rischi di sicurezza e privacy relativi alla cache

Risorse con perdita di dati dalle vulnerabilità di Spectre

La vulnerabilità Spectre consente a una pagina di leggere la memoria di un processo del sistema operativo. Ciò significa che un utente malintenzionato può ottenere l'accesso non autorizzato ai dati multiorigine. Di conseguenza, i browser web moderni hanno limitato l'utilizzo di alcune funzionalità, ad esempio SharedArrayBuffer o timer ad alta risoluzione, per le pagine con isolamento multiorigine.

I browser web moderni applicano il criterio COEP (Cross-Origin Embedder Policy). Ciò garantisce che le risorse multiorigine siano:

• Risorse pubbliche, richieste senza cookie
• Le risorse possono essere condivise esplicitamente tra origini, tramite CORS o l'intestazione CORP

La configurazione COEP non impedisce a un aggressore di sfruttare Spectre. Tuttavia, garantisce che le risorse multiorigine non siano preziose per l'utente malintenzionato (se caricate dal browser come risorsa pubblica) o che possano essere condivise con l'utente malintenzionato (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 utente malintenzionato potrebbe eseguire un attacco. Ad esempio:

1. La risorsa con credenziali viene memorizzata nella cache.
2. L’autore dell'attacco carica una pagina isolata 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 credenziali.
5. L'utente malintenzionato può quindi leggere la risorsa personalizzata usando un attacco Spectre.

Sebbene la cache HTTP di un browser web non consenta nella pratica questo tipo di attacco, esistono cache aggiuntive al di fuori del controllo immediato del browser. Questo potrebbe portare al successo dell'attacco.

Fraintendimenti 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à e dedicate a un singolo utente, implementate nel suo browser web. Migliorano le prestazioni evitando di recuperare la stessa risposta più volte.
• Proxy locale. Questo file potrebbe essere stato installato dall'utente, ma può anche essere gestito da intermediari come l'azienda, la sua organizzazione o il suo provider internet. I proxy locali spesso memorizzano 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. Ciò è controllato dal server. L'obiettivo 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 rete CDN sono simili, ma sono distribuiti in tutto il mondo e sono assegnati all'insieme di utenti più vicino per ridurre la latenza.

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

Molti utenti utilizzano regolarmente proxy configurati in locale per scopi di accesso (come la condivisione di una connessione a consumo), l'ispezione di virus o la prevenzione della perdita di dati (DLP). La cache intermedia sta eseguendo l'intercettazione TLS.

Una cache intermedia è spesso installata sulle workstation di un dipendente di un'azienda. I browser web sono configurati per considerare attendibili i certificati del proxy locale.

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

Funzionamento della cache HTTP

• Le risorse sono implicitamente consentite di essere memorizzate nella cache per impostazione predefinita.
• La chiave cache principale è composta dall'URL e dal metodo. (URL, metodo)
• La chiave cache secondaria è le intestazioni incluse nell'intestazione Vary. Vary: Cookie indica che la risposta dipende dal Cookie.
• L'intestazione Cache-Control offre un controllo più granulare.

Esegui queste azioni consigliate per il tuo sito web

Gli sviluppatori di siti web ad alto valore, che includono siti web ad alto traffico e siti web che interagiscono con informazioni che consentono l'identificazione personale, dovrebbero intervenire subito per migliorare la sicurezza.

Il rischio maggiore si verifica quando l'accesso a una risorsa varia in base ai cookie. Una cache intermedia potrebbe restituire una risposta richiesta con i cookie per una richiesta che non è stata eseguita se non è stata intrapresa alcuna azione preventiva.

Ti consigliamo di procedere in uno dei seguenti modi:

• Impedisci agli intermediari di memorizzare nella cache la risorsa. Imposta Cache-Control: private.
• Imposta una chiave cache secondaria appropriata. Se la risposta varia a causa dei cookie (che possono verificarsi 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 multiorigine. Ad esempio, Jake Archibald descrive alcuni attacchi in Come vincere su CORS.

Questi attacchi sono mitigati da alcuni browser web che dividono la cache HTTP a seconda che la risposta della risorsa sia stata richiesta o meno con credenziali. A partire dal 2022, Firefox e Chrome hanno diviso la cache, no. In futuro Chrome potrebbe suddividere la cache. Tieni presente che questi attacchi sono diversi e complementari per suddividerli per origine di primo livello.

Anche se questo problema può essere attenuato per i browser web, rimarrà nelle cache del proxy locali. Pertanto, ti suggeriamo di seguire i consigli precedenti.

---

Foto dell'intestazione di Ben Pattinson su Unsplash.