Cache Poisoning and Cache Deception
Aprende y practica Hacking en AWS:HackTricks Training AWS Red Team Expert (ARTE)
Aprende y practica Hacking en GCP:
HackTricks Training GCP Red Team Expert (GRTE)
![](https://book.hacktricks.xyz/~gitbook/image?url=https%3A%2F%2F2730383215-files.gitbook.io%2F%7E%2Ffiles%2Fv0%2Fb%2Fgitbook-x-prod.appspot.com%2Fo%2Fspaces%252FOGiU7XValBchYYDg6h1H%252Fuploads%252Fgit-blob-78abb7891633b1e8147b4e743e4f00af375d3cd6%252Fimage%2520%2848%29.png%3Falt%3Dmedia&width=768&dpr=4&quality=100&sign=cef6a567&sv=1)
Usa Trickest para construir y automatizar flujos de trabajo fácilmente con las herramientas comunitarias más avanzadas del mundo. Obtén acceso hoy:
La diferencia
¿Cuál es la diferencia entre el envenenamiento de caché web y la decepción de caché web?
En el envenenamiento de caché web, el atacante hace que la aplicación almacene contenido malicioso en la caché, y este contenido se sirve desde la caché a otros usuarios de la aplicación.
En la decepción de caché web, el atacante hace que la aplicación almacene contenido sensible perteneciente a otro usuario en la caché, y luego el atacante recupera este contenido de la caché.
Envenenamiento de Caché
El envenenamiento de caché tiene como objetivo manipular la caché del lado del cliente para obligar a los clientes a cargar recursos que son inesperados, parciales o controlados por un atacante. La magnitud del impacto depende de la popularidad de la página afectada, ya que la respuesta contaminada se sirve exclusivamente a los usuarios que visitan la página durante el período de contaminación de la caché.
La ejecución de un ataque de envenenamiento de caché implica varios pasos:
Identificación de Entradas Sin Clave: Estos son parámetros que, aunque no son necesarios para que una solicitud sea almacenada en caché, pueden alterar la respuesta devuelta por el servidor. Identificar estas entradas es crucial, ya que pueden ser explotadas para manipular la caché.
Explotación de las Entradas Sin Clave: Después de identificar las entradas sin clave, el siguiente paso implica averiguar cómo abusar de estos parámetros para modificar la respuesta del servidor de una manera que beneficie al atacante.
Asegurar que la Respuesta Envenenada esté Almacenada en Caché: El paso final es asegurarse de que la respuesta manipulada esté almacenada en la caché. De esta manera, cualquier usuario que acceda a la página afectada mientras la caché esté envenenada recibirá la respuesta contaminada.
Descubrimiento: Verificar encabezados HTTP
Por lo general, cuando una respuesta fue almacenada en la caché, habrá un encabezado que lo indique, puedes verificar qué encabezados debes tener en cuenta en esta publicación: Encabezados de caché HTTP.
Descubrimiento: Códigos de error de caché
Si estás pensando que la respuesta se está almacenando en una caché, podrías intentar enviar solicitudes con un encabezado incorrecto, que debería ser respondido con un código de estado 400. Luego intenta acceder a la solicitud normalmente y si la respuesta es un código de estado 400, sabes que es vulnerable (y podrías incluso realizar un DoS).
Puedes encontrar más opciones en:
Cache Poisoning to DoSSin embargo, ten en cuenta que a veces estos tipos de códigos de estado no se almacenan en caché, por lo que esta prueba podría no ser confiable.
Descubrimiento: Identificar y evaluar entradas sin clave
Podrías usar Param Miner para fuerza bruta de parámetros y encabezados que pueden estar cambiando la respuesta de la página. Por ejemplo, una página puede estar usando el encabezado X-Forwarded-For
para indicar al cliente que cargue el script desde allí:
Elicit a harmful response from the back-end server
Con el parámetro/cabecera identificado, verifica cómo está siendo sanitizado y dónde se está reflejando o afectando la respuesta de la cabecera. ¿Puedes abusar de ello de alguna manera (realizar un XSS o cargar un código JS controlado por ti? ¿realizar un DoS?...)
Get the response cached
Una vez que hayas identificado la página que puede ser abusada, qué parámetro/cabecera usar y cómo abusar de ello, necesitas hacer que la página se almacene en caché. Dependiendo del recurso que estés tratando de almacenar en caché, esto podría tomar algún tiempo, podrías necesitar intentarlo durante varios segundos.
La cabecera X-Cache
en la respuesta podría ser muy útil ya que puede tener el valor miss
cuando la solicitud no fue almacenada en caché y el valor hit
cuando está en caché.
La cabecera Cache-Control
también es interesante para saber si un recurso está siendo almacenado en caché y cuándo será la próxima vez que el recurso será almacenado en caché nuevamente: Cache-Control: public, max-age=1800
Otra cabecera interesante es Vary
. Esta cabecera se utiliza a menudo para indicar cabeceras adicionales que se tratan como parte de la clave de caché incluso si normalmente no están indexadas. Por lo tanto, si el usuario conoce el User-Agent
de la víctima que está atacando, puede envenenar la caché para los usuarios que utilizan ese User-Agent
específico.
Una cabecera más relacionada con la caché es Age
. Define el tiempo en segundos que el objeto ha estado en la caché del proxy.
Al almacenar en caché una solicitud, ten cuidado con las cabeceras que usas porque algunas de ellas podrían ser usadas inesperadamente como indexadas y la víctima necesitará usar esa misma cabecera. Siempre prueba un Cache Poisoning con diferentes navegadores para verificar si está funcionando.
Exploiting Examples
Easiest example
Una cabecera como X-Forwarded-For
se está reflejando en la respuesta sin sanitizar.
Puedes enviar una carga útil básica de XSS y envenenar la caché para que todos los que accedan a la página sean XSSed:
Note que esto envenenará una solicitud a /en?region=uk
no a /en
Envenenamiento de caché para DoS
Cache Poisoning to DoSUsando el envenenamiento de caché web para explotar vulnerabilidades en el manejo de cookies
Las cookies también podrían reflejarse en la respuesta de una página. Si puedes abusar de esto para causar un XSS, por ejemplo, podrías ser capaz de explotar XSS en varios clientes que cargan la respuesta de caché maliciosa.
Note que si la cookie vulnerable es muy utilizada por los usuarios, las solicitudes regulares estarán limpiando la caché.
Generando discrepancias con delimitadores, normalización y puntos
Verifique:
Cache Poisoning via URL discrepanciesEnvenenamiento de caché con recorrido de ruta para robar la clave de API
Este informe explica cómo fue posible robar una clave de API de OpenAI con una URL como https://chat.openai.com/share/%2F..%2Fapi/auth/session?cachebuster=123
porque cualquier cosa que coincida con /share/*
será almacenada en caché sin que Cloudflare normalice la URL, lo cual se hizo cuando la solicitud llegó al servidor web.
Esto también se explica mejor en:
Cache Poisoning via URL discrepanciesUsando múltiples encabezados para explotar vulnerabilidades de envenenamiento de caché web
A veces necesitarás explotar varias entradas sin clave para poder abusar de una caché. Por ejemplo, puedes encontrar un redireccionamiento abierto si configuras X-Forwarded-Host
a un dominio controlado por ti y X-Forwarded-Scheme
a http
. Si el servidor está reenviando todas las solicitudes HTTP a HTTPS y usando el encabezado X-Forwarded-Scheme
como el nombre de dominio para el redireccionamiento. Puedes controlar hacia dónde apunta la página por el redireccionamiento.
Explotando con un encabezado Vary
limitado
Vary
limitadoSi descubres que el X-Host
se está utilizando como nombre de dominio para cargar un recurso JS pero el encabezado Vary
en la respuesta indica User-Agent
. Entonces, necesitas encontrar una manera de exfiltrar el User-Agent de la víctima y envenenar la caché utilizando ese user agent:
Fat Get
Envía una solicitud GET con la solicitud en la URL y en el cuerpo. Si el servidor web utiliza la del cuerpo pero el servidor de caché almacena en caché la de la URL, cualquier persona que acceda a esa URL utilizará en realidad el parámetro del cuerpo. Como la vulnerabilidad que James Kettle encontró en el sitio web de Github:
There it a portswigger lab about this: https://portswigger.net/web-security/web-cache-poisoning/exploiting-implementation-flaws/lab-web-cache-poisoning-fat-get
Parameter Cloacking
Por ejemplo, es posible separar parámetros en servidores ruby usando el carácter ;
en lugar de &
. Esto podría usarse para poner valores de parámetros no clave dentro de los clave y abusar de ellos.
Portswigger lab: https://portswigger.net/web-security/web-cache-poisoning/exploiting-implementation-flaws/lab-web-cache-poisoning-param-cloaking
Exploiting HTTP Cache Poisoning by abusing HTTP Request Smuggling
Aprende aquí cómo realizar ataques de Cache Poisoning abusando de HTTP Request Smuggling.
Automated testing for Web Cache Poisoning
El Escáner de Vulnerabilidades de Cache Web se puede usar para probar automáticamente la intoxicación de caché web. Soporta muchas técnicas diferentes y es altamente personalizable.
Ejemplo de uso: wcvs -u example.com
Vulnerable Examples
Apache Traffic Server (CVE-2021-27577)
ATS reenvió el fragmento dentro de la URL sin eliminarlo y generó la clave de caché solo usando el host, la ruta y la consulta (ignorando el fragmento). Así que la solicitud /#/../?r=javascript:alert(1)
se envió al backend como /#/../?r=javascript:alert(1)
y la clave de caché no tenía la carga útil dentro de ella, solo host, ruta y consulta.
GitHub CP-DoS
Enviar un valor incorrecto en el encabezado content-type activó una respuesta 405 en caché. La clave de caché contenía la cookie, por lo que solo era posible atacar a usuarios no autenticados.
GitLab + GCP CP-DoS
GitLab utiliza buckets de GCP para almacenar contenido estático. Los Buckets de GCP soportan el encabezado x-http-method-override
. Por lo tanto, era posible enviar el encabezado x-http-method-override: HEAD
y envenenar la caché para que devolviera un cuerpo de respuesta vacío. También podría soportar el método PURGE
.
Rack Middleware (Ruby on Rails)
En aplicaciones Ruby on Rails, a menudo se utiliza middleware Rack. El propósito del código Rack es tomar el valor del encabezado x-forwarded-scheme
y establecerlo como el esquema de la solicitud. Cuando se envía el encabezado x-forwarded-scheme: http
, ocurre una redirección 301 a la misma ubicación, lo que puede causar una Denegación de Servicio (DoS) a ese recurso. Además, la aplicación podría reconocer el encabezado X-forwarded-host
y redirigir a los usuarios al host especificado. Este comportamiento puede llevar a la carga de archivos JavaScript desde el servidor de un atacante, lo que representa un riesgo de seguridad.
403 and Storage Buckets
Cloudflare anteriormente almacenaba en caché respuestas 403. Intentar acceder a S3 o Azure Storage Blobs con encabezados de autorización incorrectos resultaría en una respuesta 403 que se almacenó en caché. Aunque Cloudflare ha dejado de almacenar en caché respuestas 403, este comportamiento podría seguir presente en otros servicios de proxy.
Injecting Keyed Parameters
Las cachés a menudo incluyen parámetros GET específicos en la clave de caché. Por ejemplo, el Varnish de Fastly almacenaba en caché el parámetro size
en las solicitudes. Sin embargo, si se enviaba una versión codificada en URL del parámetro (por ejemplo, siz%65
) con un valor erróneo, la clave de caché se construiría usando el parámetro size
correcto. Sin embargo, el backend procesaría el valor en el parámetro codificado en URL. Codificar en URL el segundo parámetro size
llevó a su omisión por parte de la caché, pero su utilización por parte del backend. Asignar un valor de 0 a este parámetro resultó en un error 400 Bad Request que se podía almacenar en caché.
User Agent Rules
Algunos desarrolladores bloquean solicitudes con user-agents que coinciden con los de herramientas de alto tráfico como FFUF o Nuclei para gestionar la carga del servidor. Irónicamente, este enfoque puede introducir vulnerabilidades como la intoxicación de caché y DoS.
Illegal Header Fields
El RFC7230 especifica los caracteres aceptables en los nombres de encabezados. Los encabezados que contienen caracteres fuera del rango tchar especificado deberían idealmente activar una respuesta 400 Bad Request. En la práctica, los servidores no siempre se adhieren a este estándar. Un ejemplo notable es Akamai, que reenvía encabezados con caracteres no válidos y almacena en caché cualquier error 400, siempre que el encabezado cache-control
no esté presente. Se identificó un patrón explotable donde enviar un encabezado con un carácter ilegal, como \
, resultaría en un error 400 Bad Request que se podía almacenar en caché.
Finding new headers
https://gist.github.com/iustin24/92a5ba76ee436c85716f003dda8eecc6
Cache Deception
El objetivo de la Decepción de Caché es hacer que los clientes carguen recursos que van a ser guardados por la caché con su información sensible.
Primero, ten en cuenta que extensiones como .css
, .js
, .png
, etc., suelen estar configuradas para ser guardadas en la caché. Por lo tanto, si accedes a www.example.com/profile.php/nonexistent.js
, la caché probablemente almacenará la respuesta porque ve la extensión .js
. Pero, si la aplicación está reproduciendo con los contenidos sensibles del usuario almacenados en www.example.com/profile.php, puedes robar esos contenidos de otros usuarios.
Otras cosas para probar:
www.example.com/profile.php/.js
www.example.com/profile.php/.css
www.example.com/profile.php/test.js
www.example.com/profile.php/../test.js
www.example.com/profile.php/%2e%2e/test.js
Usa extensiones menos conocidas como
.avif
Otro ejemplo muy claro se puede encontrar en este informe: https://hackerone.com/reports/593712. En el ejemplo, se explica que si cargas una página inexistente como http://www.example.com/home.php/non-existent.css, el contenido de http://www.example.com/home.php (con la información sensible del usuario) se devolverá y el servidor de caché guardará el resultado. Luego, el atacante puede acceder a http://www.example.com/home.php/non-existent.css en su propio navegador y observar la información confidencial de los usuarios que accedieron antes.
Ten en cuenta que el proxy de caché debe estar configurado para almacenar en caché archivos basados en la extensión del archivo (.css) y no basarse en el tipo de contenido. En el ejemplo http://www.example.com/home.php/non-existent.css tendrá un tipo de contenido text/html
en lugar de un tipo MIME text/css
(que es el esperado para un archivo .css).
Aprende aquí cómo realizar ataques de Decepción de Caché abusando de HTTP Request Smuggling.
Automatic Tools
toxicache: Escáner de Golang para encontrar vulnerabilidades de intoxicación de caché web en una lista de URLs y probar múltiples técnicas de inyección.
References
![](https://book.hacktricks.xyz/~gitbook/image?url=https%3A%2F%2F2730383215-files.gitbook.io%2F%7E%2Ffiles%2Fv0%2Fb%2Fgitbook-x-prod.appspot.com%2Fo%2Fspaces%252FOGiU7XValBchYYDg6h1H%252Fuploads%252Fgit-blob-78abb7891633b1e8147b4e743e4f00af375d3cd6%252Fimage%2520%2848%29.png%3Falt%3Dmedia&width=768&dpr=4&quality=100&sign=cef6a567&sv=1)
Usa Trickest para construir y automatizar flujos de trabajo fácilmente impulsados por las herramientas más avanzadas de la comunidad. Obtén acceso hoy:
Aprende y practica Hacking en AWS:HackTricks Training AWS Red Team Expert (ARTE)
Aprende y practica Hacking en GCP:
HackTricks Training GCP Red Team Expert (GRTE)
Last updated