Una técnica de envenenamiento de caché web denominada inyección de claves de caché podría permitir que los atacantes accedan a datos restringidos, interrumpan sitios web o contaminen páginas almacenadas con contenido malicioso. La investigación de Alex Brumen demuestra que los atacantes no siempre necesitan explotar valores de solicitud HTTP no indexados, sino que pueden abusar de valores que ya están incluidos en el sistema.

Una técnica de envenenamiento de caché web llamada inyección de claves de caché podría permitir que los atacantes accedan a datos restringidos, interrumpan sitios web o envenenen páginas almacenadas en caché con contenido malicioso.

La investigación de Alex Brumen muestra que los atacantes no siempre necesitan explotar valores de solicitud HTTP no indexados (unkeyed), que suelen ser el foco habitual de los ataques de envenenamiento de caché.

En su lugar, pueden abusar de valores que ya están incluidos en una clave de caché cuando un servidor web los combina sin separadores claros. Las cachés web mejoran el rendimiento almacenando respuestas y sirviéndolas de nuevo cuando solicitudes posteriores generan la misma clave de caché.

En Nginx, una clave de caché puede construirse a partir de partes de una solicitud HTTP, incluyendo el esquema del protocolo, el nombre del host, la URI, la cadena de consulta, las cookies o los encabezados.

Una configuración común de Nginx puede parecerse a: proxy_cache_key "$scheme$host$request_uri$http_accept";.

El problema aparece cuando los componentes variables de la solicitud se unen directamente. Si no hay separadores entre ellos, dos solicitudes diferentes pueden crear la misma clave de caché final.

Claves de caché web para acceder a datos y envenenar sitios

Por ejemplo, una solicitud legítima para /home con un encabezado Accept: / podría producir la misma clave que una solicitud de un atacante para /h con Accept: ome*/*.

Aunque las rutas solicitadas son diferentes, Nginx puede tratar ambas solicitudes como el mismo objeto de caché después de concatenar los valores. Esta colisión permite que un atacante almacene una respuesta bajo una clave que luego coincida con una solicitud legítima diferente.

Un impacto demostrado involucra puntos finales con control de acceso como /admin. En la prueba de concepto, Nginx permitía que solo localhost accediera al panel de administración. Al mismo tiempo, su caché utilizaba una clave personalizada que contenía la URI de la solicitud y el encabezado Accept.

Un administrador podría almacenar en caché la página /admin desde localhost. Un atacante externo, que no podría solicitar /admin directamente, podría entonces solicitar una ruta diferente como /ad mientras coloca el fragmento "min" restante en un valor de encabezado controlado.

Si la solicitud manipulada crea la misma clave de caché que /admin, el servidor puede devolver la respuesta administrativa previamente almacenada sin evaluar la regla de acceso original para la ruta protegida. Esto crea una forma de engaño de caché web que no requiere que las víctimas hagan clic en un enlace manipulado.

La técnica también puede causar una denegación de servicio por envenenamiento de caché, o CPDoS. Un atacante podría solicitar un recurso inexistente como /h mientras manipula un encabezado para que su clave de caché colisione con /home.

Debido a que la solicitud del atacante devuelve una respuesta 404 Not Found almacenada en caché, los visitantes posteriores que soliciten la página /home real podrían recibir la respuesta de error envenenada hasta que la caché expire o se limpie.

Brumen también demostró un escenario más grave que involucra la confusión de esquemas HTTP y HTTPS. Si una clave de Nginx comienza con $scheme$host$request_uri, un atacante puede desplazar la "s" final de https hacia un valor de encabezado Host malicioso enviado a través de HTTP.

Por ejemplo, una solicitud HTTP que utilice el host sdummywebsite.localhost puede producir la misma clave que una solicitud HTTPS normal a dummywebsite.localhost.

Si el backend refleja el valor del Host dentro de una fuente de script, la página envenenada almacenada en caché podría cargar JavaScript desde un dominio controlado por el atacante. Esto puede resultar en un cross-site scripting (XSS) persistente.

La investigación también examinó entornos que utilizan Cloudflare delante de una caché de origen Nginx. Los atacantes pueden usar un encabezado de Autorización para hacer que Cloudflare ignore su caché de borde mientras reenvía la solicitud a Nginx.

Si Nginx sigue almacenando esa respuesta, el atacante puede dirigirse directamente a la caché de origen interna. Una solicitud posterior podría entonces recuperar la entrada envenenada de Nginx, especialmente después de que la entrada de borde de Cloudflare expire o no exista.

La mitigación principal es evitar la concatenación de fragmentos de claves de caché sin límites. Realizar un hash de una clave ambigua no soluciona el problema porque dos combinaciones de solicitudes diferentes aún pueden producir la misma cadena subyacente.

En lugar de esta configuración: proxy_cache_key "$scheme$host$request_uri$http_accept";, tú como administrador deberías usar delimitadores claros o una codificación estructurada: proxy_cache_key "$scheme|$host|$request_uri|$http_accept";.

Las organizaciones también deben evitar almacenar respuestas autenticadas o con control de acceso en cachés compartidas, validar estrictamente los encabezados Host, redireccionar el tráfico HTTP a HTTPS y asegurarse de que el comportamiento de la caché sea consistente en las capas de CDN y de origen.

Los hallazgos muestran que las claves de caché no deben considerarse seguras simplemente porque los valores de la solicitud estén incluidos en ellas. Sin límites claros, los valores controlados por el atacante pueden colisionar con solicitudes legítimas y convertir una función de rendimiento en un riesgo de exposición de datos, desfiguración de sitios web o denegación de servicio.