Actualiza la caché HTTP para mejorar la seguridad y la privacidad

Si olvidas el encabezado Cache-Control o lo usas de forma inadecuada, es posible que se vea afectada de forma negativa la seguridad de tu sitio web y la privacidad de tus usuarios.

De forma predeterminada, los recursos siempre pueden almacenarse en caché con cualquier tipo de caché. No usar o usar de forma inadecuada el encabezado Cache-Control podría afectar de forma negativa la seguridad de tu sitio web y la privacidad de tus usuarios.

Para las respuestas personalizadas que quieras mantener en privado, te recomendamos que hagas lo siguiente:

• Evita que los intermediarios almacenen en caché el recurso. Establece Cache-Control: private.
• Establece una clave de caché secundaria adecuada. Si la respuesta varía debido a las cookies, lo que puede suceder cuando la cookie almacena credenciales, configura Vary: Cookie.

Sigue leyendo para descubrir por qué es importante y conocer lo siguiente:

1. Problemas de seguridad y privacidad que quizás no conozcas
2. Diferentes tipos de cachés de HTTP y conceptos erróneos comunes
3. Acciones recomendadas para sitios web de alto valor

Riesgos de seguridad y privacidad relacionados con la caché

Recursos con fugas de vulnerabilidades de Spectre

La vulnerabilidad Spectre permite que una página lea la memoria de un proceso del SO. Esto significa que un atacante puede obtener acceso no autorizado a los datos de varios orígenes. Como consecuencia, los navegadores web modernos restringieron el uso de algunas de sus funciones, como SharedArrayBuffer o el cronómetro de alta resolución, a las páginas con aislamiento de origen cruzado.

Los navegadores web modernos aplican la política de incorporaciones de origen cruzado (COEP). Esto garantiza que los recursos de origen cruzado sean lo siguiente:

• Recursos públicos solicitados sin cookies
• Recursos que se permiten compartir de forma explícita entre dominios, a través de CORS o el encabezado CORP

La configuración de COEP no impide que un atacante aproveche Spectre. Sin embargo, garantiza que los recursos de origen cruzado no sean valiosos para el atacante (cuando el navegador los carga como recursos públicos) ni se permitan compartir con el atacante (cuando se comparten con CORP: cross-origin).

¿Cómo afecta el almacenamiento en caché HTTP a Spectre?

Si el encabezado Cache-Control no está configurado correctamente, un atacante podría ejecutar un ataque. Por ejemplo:

1. El recurso con credenciales se almacena en caché.
2. El atacante carga una página aislada de origen cruzado.
3. El atacante vuelve a solicitar el recurso.
4. El navegador establece COEP:credentialless, por lo que el recurso se recupera sin cookies. Sin embargo, una caché puede mostrar la respuesta con credenciales.
5. Luego, el atacante puede leer el recurso personalizado con un ataque Spectre.

Si bien la caché HTTP de un navegador web no permite que este tipo de ataque ocurra en la práctica, existen cachés adicionales fuera del control inmediato del navegador. Esto puede hacer que el ataque se lleve a cabo con éxito.

Conceptos erróneos comunes sobre las cachés HTTP

1. Solo el navegador almacena en caché los recursos.

A menudo, hay varias capas de caché. Algunas cachés están dedicadas a un solo usuario y otras a varios. Algunas las controla el servidor, otras el usuario y otras los intermediarios.

• Cachés del navegador: Estas cachés son propiedad de un solo usuario y están dedicadas a él, y se implementan en su navegador web. Mejoran el rendimiento, ya que evitan recuperar la misma respuesta varias veces.
• Proxy local. Es posible que el usuario lo haya instalado, pero también pueden gestionarlo intermediarios, como su empresa, su organización o su proveedor de Internet. Los proxies locales suelen almacenar en caché una sola respuesta para varios usuarios, lo que constituye una caché “pública”. Los proxies locales tienen varios roles.
• Caché o CDN del servidor de origen: El servidor controla esto. El objetivo de la caché del servidor de origen es reducir la carga en el servidor de origen almacenando en caché la misma respuesta para varios usuarios. Los objetivos de una CDN son similares, pero se distribuyen por todo el mundo y se asignan al conjunto de usuarios más cercano para reducir la latencia.

2. SSL evita que los intermediarios almacenen en caché recursos HTTPS.

Muchos usuarios usan proxies configurados de forma local con frecuencia, ya sea para fines de acceso (como compartir una conexión medida), inspección de virus o prevención de pérdida de datos (DLP). La caché intermedia realiza una interceptación de TLS.

A menudo, se instala una caché intermedia en las estaciones de trabajo de los empleados de una empresa. Los navegadores web están configurados para confiar en los certificados del proxy local.

En última instancia, es posible que estos proxies locales almacenen en caché algunos recursos HTTPS.

Cómo funciona la caché HTTP

• Los recursos se pueden almacenar en caché de forma implícita de forma predeterminada.
• La clave de caché principal consta de la URL y el método. (URL, método)
• La clave de caché secundaria son los encabezados incluidos en el encabezado Vary. Vary: Cookie indica que la respuesta depende de Cookie.
• El encabezado Cache-Control proporciona un control más detallado.

Realiza estas acciones recomendadas para tu sitio web

Los desarrolladores de sitios web de alto valor, incluidos los sitios web con mucho tráfico y los que interactúan con información de identificación personal, deben actuar ahora para mejorar la seguridad.

El mayor riesgo ocurre cuando el acceso a un recurso varía según las cookies. Una caché intermedia puede mostrar una respuesta que se solicitó con cookies para una solicitud que no se solicitó si no se tomó ninguna medida preventiva.

Te recomendamos que sigas uno de estos pasos:

• Evita que los intermediarios almacenen en caché el recurso. Establece Cache-Control: private.
• Establece una clave de caché secundaria adecuada. Si la respuesta varía debido a las cookies, lo que puede suceder cuando la cookie almacena credenciales, configura Vary: Cookie.

En particular, cambia el comportamiento predeterminado: siempre define Cache-Control o Vary.

Consideraciones adicionales

Existen otros tipos de ataques similares que usan la caché HTTP, pero que dependen de un mecanismo diferente al aislamiento de origen cruzado. Por ejemplo, Jake Archibald describe algunos ataques en Cómo ganar en CORS.

Algunos navegadores web mitigan estos ataques, ya que dividen su caché HTTP según si la respuesta del recurso se solicitó con credenciales o no. A partir de 2022, Firefox divide la caché, mientras que Chrome y Safari no lo hacen. Es posible que Chrome divida la caché en el futuro. Ten en cuenta que estos ataques son diferentes y complementarios a la división por el origen de nivel superior.

Incluso si este problema se puede mitigar para los navegadores web, el problema permanecerá en las cachés de proxy locales. Por lo tanto, te sugerimos que sigas las recomendaciones anteriores.

---

Foto del encabezado de Ben Pattinson en Unsplash.