e-tags su informazioni sensibili

Question

e-tags su informazioni sensibili

#1 da (3 voti)

6

Supponiamo di avere un grande documento JSON che solo alcuni utenti possono vedere, ma che raramente cambia, ma che, se cambia, gli utenti si aspettano di vedere la modifica abbastanza rapidamente. Ha senso usare gli etags per questo - salva l'intero documento che viene trasferito sul filo se non è cambiato, ma invia il documento se lo ha.

Un rischio sembra essere che se più persone usano la stessa finestra del browser:

Alice accede al sito e la risorsa viene inviata a lei con un tag
Alice si disconnette e va a pranzo
Bob usa il proprio browser per accedere come se stesso, ma non può visualizzare la risorsa
Bob guarda nella cache del browser, vede un etag che è stato memorizzato dal browser e configura il suo browser per inviare lo stesso etag - ora Bob può vedere i dati

Suppongo che dal momento che Bob sta già utilizzando l'istanza del browser di Alice, potrebbe già vedere cosa c'è nella cache e quindi potrebbe comunque leggere i dati.

Sembra che non ci sia un modo sicuro di utilizzare gli etags (o il caching del browser in generale?) per le informazioni sensibili, e dovremmo semplicemente archiviare i dati in memoria con JavaScript. O ci manca un modo specifico che è destinato a essere utilizzato?

http caching web-browser

posta Paul Stovell 12.04.2017 - 08:25

fonte

1 risposta

Leggi altre domande sui tag http caching web-browser

Quali sono i vantaggi o i rischi per la sicurezza di HTTP / 2? IOMMU impedisce gli attacchi DMA?

score 3 · Answer 1

Uso di etag per ottenere i dati

Sapere che l'etag da solo non ti aiuterà a ottenere la risrourzione segreta, supponendo che il server sia implementato correttamente. Il browser controllerà con il server per vedere se l'etag è valido (usando l'intestazione If-None-Match ).

Quando Alice effettua la richiesta, verrà autenticata in modo che il server risponda con 304 Not Modified , inducendo il browser a caricare la risorsa dalla cache.

Ma quando Bob effettua la richiesta non è autenticato, quindi il server dovrebbe rispondere con 403 Forbidden . Il browser non caricherà quindi nulla dalla cache (e se Bob sta utilizzando un browser diverso da quello di Alice, non ci sarebbe comunque nulla da caricare).

Tutto ciò si basa sul presupposto che Cache-Control sia impostato su no-cache (o assente). In caso contrario, il browser caricherà la risorsa direttamente dalla cache senza verificare con il server. Se Bob e Alice utilizzano lo stesso browser, Bob otterrebbe la versione di Alice della pagina, anche se non è autenticato.

Rubare la risorsa dalla cache del browser

Come fai notare, invece di rubare semplicemente l'etag, Bob potrebbe semplicemente rubare la risorsa reale dalla cache.

I moderni browser proteggono da questo in vari modi. A meno che Alice e Bob non stiano utilizzando lo stesso utente del sistema operativo o Bob sia root o admin (a seconda del sistema operativo), ciò non può essere fatto senza sfruttare alcuni exploit.

Tuttavia, se la risorsa è veramente sensibile e ti aspetti che i tuoi utenti possano accedervi su computer condivisi con persone non affidabili, dovresti prendere in considerazione l'impostazione di Cache-Control: no-store di disabilitare tutta la cache.