e-tags en información sensible

Question

e-tags en información sensible

#1 de Anders (3 votos)

6

Supongamos que tenemos un gran documento JSON que solo ciertos usuarios pueden ver, pero que rara vez cambia, pero que si cambia, los usuarios esperan ver el cambio con bastante rapidez. Tiene sentido utilizar etags para esto: guarda el documento completo que se transfiere por el cable si no se modificó, pero envía el documento si lo ha hecho.

Un riesgo parece ser que si varias personas usan la misma ventana del navegador:

Alice inicia sesión en el sitio y el recurso se le envía con una etiqueta
Alice cierra la sesión y va a almorzar
Bob usa su navegador para iniciar sesión como él mismo, pero no puede ver el recurso
Bob busca en el caché del navegador, ve un etag que fue almacenado por el navegador, y configura su navegador para enviar ese mismo etag - ahora Bob puede ver los datos

Supongo que dado que Bob ya está usando la instancia del navegador de Alice, ya podía ver lo que hay en el caché y, por lo tanto, podría leer los datos de todos modos.

Parece que no hay una forma segura de utilizar etags (¿o el almacenamiento en caché del navegador en general?) para obtener información confidencial, y debemos almacenar los datos en la memoria con JavaScript. ¿O nos falta una forma específica en la que está destinada a ser utilizada?

web-browser http caching

pregunta Paul Stovell 12.04.2017 - 08:25

fuente

1 respuesta

Lea otras preguntas en las etiquetas web-browser http caching

Facebook permite la contraseña + cualquier carácter ¿Cómo asegurarnos de que nuestro proceso de implementación del entorno de producción sea compatible con PCI cuando necesitamos realizar actualizaciones de código en vivo?

score 3 · Answer 1

Usando el etag para obtener los datos

Saber solo el etag no le ayudará a obtener el recurso secreto, suponiendo que el servidor esté implementado correctamente. El navegador verificará con el servidor para ver si el etag es válido (usando el encabezado If-None-Match ).

Cuando Alice realice la solicitud, se autenticará para que el servidor responda con 304 Not Modified , lo que le pedirá al navegador que cargue el recurso desde la memoria caché.

Pero cuando Bob realiza la solicitud, no se autentica, por lo que el servidor debe responder con 403 Forbidden . El navegador no cargará nada del caché (y si Bob está usando un navegador diferente al de Alicia, de todos modos no habría nada que cargar).

Todo esto se basa en el supuesto de que Cache-Control se establece en no-cache (o está ausente). De lo contrario, el navegador cargaría el recurso directamente desde la memoria caché sin consultar con el servidor. Si Bob y Alice usan el mismo navegador, Bob obtendría la versión Alice de la página, aunque no esté autenticado.

Robando el recurso del caché del navegador

Como señala, en lugar de simplemente robar el etag, Bob podría simplemente robar el recurso real de la caché.

Los navegadores modernos protegen contra esto de varias maneras. A menos que Alice y Bob estén usando el mismo usuario del sistema operativo o Bob es root o admin (dependiendo del sistema operativo), esto no se podría hacer sin aprovechar algún exploit.

Aún así, si el recurso es realmente sensible y espera que sus usuarios accedan a él en computadoras que se comparten con personas que no son de confianza, debería considerar la posibilidad de configurar Cache-Control: no-store deshabilitando toda la caché.