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

Si olvidas o usas el encabezado Cache-Control de forma inadecuada, se puede afectar de forma negativa la seguridad de tu sitio web y la privacidad de los usuarios.

Arthur Sonzogni
Arthur Sonzogni

De forma predeterminada, cualquier tipo de caché siempre permite almacenar en caché los recursos. No usar o usar de forma inadecuada el encabezado Cache-Control puede afectar negativamente la seguridad de tu sitio web y la privacidad de los usuarios.

Para las respuestas personalizadas que deseas mantener en privado, te recomendamos que sigas estas indicaciones:

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

Continúa leyendo para saber por qué esto es importante y descubre los siguientes:

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

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 datos de origen cruzado. En consecuencia, los navegadores web modernos han restringido el uso de algunas de sus funciones, como SharedArrayBuffer o temporizador de alta resolución, en 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 tengan las siguientes características:

  • Recursos públicos, solicitados sin cookies
  • Los recursos se pueden compartir de origen cruzado de forma explícita mediante CORS o el encabezado CORP.

La configuración de COEP no impide que un atacante explote 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 puedan 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 de forma correcta, 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 configura COEP:credentialless, por lo que se recupera el recurso sin cookies. Sin embargo, una caché puede mostrar la respuesta con credenciales en su lugar.
  5. Luego, el atacante puede leer el recurso personalizado mediante un ataque de Spectre.

Aunque 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 llevar al éxito de este ataque.

Conceptos erróneos comunes sobre las cachés HTTP

1. Solo el navegador almacena los recursos en caché

A menudo, hay varias capas de caché. Algunas cachés están dedicadas a un solo usuario; otras, a varios usuarios. Algunas son controladas por el servidor, otras, por el usuario y otras, por intermediarios.

  • Cachés del navegador. Estas cachés son propiedad de un solo usuario y se dedican a ellas, y se implementan en su navegador web. Mejoran el rendimiento, ya que evitan que se recupere la misma respuesta varias veces.
  • Proxy local. Es posible que el usuario lo haya instalado, pero también lo pueden administrar los intermediarios: la empresa, la organización o el proveedor de Internet. A menudo, los proxies locales almacenan en caché una sola respuesta para varios usuarios, lo que constituye una caché “pública”. Los proxies locales tienen varios roles.
  • Caché del servidor de origen / CDN. El servidor controla esto. El objetivo de la caché del servidor de origen es reducir la carga en el servidor de origen mediante el almacenamiento en caché de la misma respuesta para varios usuarios. Los objetivos de una CDN son similares, pero se distribuyen en todo el mundo y se asignan al conjunto de usuarios más cercano para reducir la latencia.
A menudo hay varias capas de caché entre el navegador y el servidor.
Es posible que haya varias capas de caché entre el navegador y el servidor. Por ejemplo, es posible que encuentres una caché de servidor, seguida de una CDN y la caché del navegador. También es posible que haya una configuración de proxy local entre la CDN y la caché del navegador.

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

Con frecuencia, muchos usuarios usan proxies configurados de forma local, ya sea para fines de acceso (como compartir una conexión de uso medido), inspección de virus o prevención de pérdida de datos (DLP). La caché intermediaria realiza la intercepción TLS.

A menudo, se instala una caché intermediaria 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, estos proxies locales pueden almacenar 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é primaria 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 brinda un control más detallado.

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

El mayor riesgo se produce cuando el acceso a un recurso varía según las cookies. Una caché intermediaria puede mostrar una respuesta que se solicitó con cookies para una solicitud que no lo fue si no se tomaron medidas preventivas.

Te recomendamos que sigas uno de estos pasos:

  • Evita que los intermediarios almacenen en caché el recurso. Establece Cache-Control: private.
  • Configura una clave de caché secundaria adecuada. Si la respuesta varía debido a las cookies, lo que puede suceder cuando la cookie almacena las 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 dependen de un mecanismo diferente del aislamiento de origen cruzado. Por ejemplo, Jake Archhibald describe algunos ataques en Cómo ganar en CORS.

Algunos navegadores web mitigan estos ataques que dividen su caché HTTP en función de 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. 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 en 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.