Best practice per memorizzare dati sensibili nella cache

Question

Best practice per memorizzare dati sensibili nella cache

#1 da (4 voti)
#2 da (3 voti)

3

Il mio server restituisce dati privati nel corpo di una risposta HTTPS. Non sono password o carte di credito, ma sono testi e immagini generati dagli utenti, che non dovrebbero essere accessibili ad altri.

I dati per un particolare URL non cambiano mai e potrebbero essere memorizzati nella cache per tutto il tempo che volevo. Il vantaggio prestazionale della memorizzazione nella cache è significativo.

Ci sono molte direttive di Cache-Control: max-age, private, no-store, ecc., ma non sono sicuro di cosa dovrei usare.

Ho impostato cookie di sessione (la durata è limitata a una singola sessione del browser). C'è un modo per avere una "cache di sessione" che si comporta in modo simile?

Che cosa è la migliore pratica?

http web-browser

posta Paul Draper 29.04.2015 - 17:15

fonte

2 risposte

Leggi altre domande sui tag http web-browser

Come proteggere la chiave API nell'applicazione Android Spam da .stream TLD - cosa posso fare?

score 4 · Answer 1

Se la maggior parte del tuo traffico è dati personalizzati, devi utilizzare HTTPS e fare affidamento principalmente sulle cache del browser. Utilizza questa cache impostando Expire header e ETag.

Inoltre, Cache-Control: no-store consiglia ai browser di non memorizzare nella cache i dati su una memoria persistente, i dati possono essere memorizzati solo nella RAM. In effetti, è come la cache di sessione.

score 3 · Answer 2

Dovresti usare la direttiva private . Tieni presente che il contenuto rimarrà disponibile nel browser dell'utente, anche se l'intestazione Expires è impostata poiché questa intestazione non obbliga necessariamente il browser a eliminarla dopo la data e l'ora impostate in modo da non soddisfare i requisiti di timeout della sessione. Tuttavia, se questo rischio è accettabile, potrebbe essere adatto.

Potresti assicurarti che l'intestazione Last-Modified sia impostata in modo che il browser sappia se aggiornare il contenuto.

Cache-Control: private

Indicates that all or part of the response message is intended for a single user and MUST NOT be cached by a shared cache, such as a proxy server.

Da RFC2616 sezione 14.9.1

_{Tratto da questo post .}

Tieni presente che no-store non è adatto se vuoi sicuramente la memorizzazione nella cache nel browser (emme me), anche da RFC:

The purpose of the no-store directive is to prevent the inadvertent release or retention of sensitive information (for example, on backup tapes). The no-store directive applies to the entire message, and MAY be sent either in a response or in a request. If sent in a request, a cache MUST NOT store any part of either this request or any response to it. If sent in a response, a cache MUST NOT store any part of either this response or the request that elicited it. This directive applies to both non- shared and shared caches. "MUST NOT store" in this context means that the cache MUST NOT intentionally store the information in non-volatile storage, and MUST make a best-effort attempt to remove the information from volatile storage as promptly as possible after forwarding it.

Tuttavia, dice anche

History buffers MAY store such responses as part of their normal operation

quindi navigare indietro al contenuto sarà ancora possibile dalla cache, supponendo che non sia stato ancora rimosso per scopi di gestione della memoria.

Anche alcuni browser potrebbero ancora chiedere di nuovo l'intero file , che è un'altra ragione per cui questo potrebbe non essere adatto:

we also do not send an if-modified-since request when validating 'no-store' content in the cache because we are not supposed to have a copy of it from a HTTP point-of-view.