<summary><strong>Aprende hacking en AWS de cero a héroe con</strong><ahref="https://training.hacktricks.xyz/courses/arte"><strong>htARTE (HackTricks AWS Red Team Expert)</strong></a><strong>!</strong></summary>
* Si quieres ver a tu **empresa anunciada en HackTricks** o **descargar HackTricks en PDF**, consulta los [**PLANES DE SUSCRIPCIÓN**](https://github.com/sponsors/carlospolop)!
* Consigue el [**merchandising oficial de PEASS & HackTricks**](https://peass.creator-spring.com)
* Descubre [**La Familia PEASS**](https://opensea.io/collection/the-peass-family), nuestra colección de [**NFTs**](https://opensea.io/collection/the-peass-family) exclusivos
* **Únete al** 💬 [**grupo de Discord**](https://discord.gg/hRep4RUj7f) o al [**grupo de telegram**](https://t.me/peass) o **sígueme** en **Twitter** 🐦 [**@carlospolopm**](https://twitter.com/carlospolopm)**.**
* **Comparte tus trucos de hacking enviando PRs a los repositorios de github de** [**HackTricks**](https://github.com/carlospolop/hacktricks) y [**HackTricks Cloud**](https://github.com/carlospolop/hacktricks-cloud).
Utiliza [**Trickest**](https://trickest.com/?utm_campaign=hacktrics\&utm_medium=banner\&utm_source=hacktricks) para construir y **automatizar flujos de trabajo** con las herramientas comunitarias **más avanzadas** del mundo.\
> * En el **envenenamiento de caché web**, el atacante provoca 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 el **engaño de caché web**, el atacante provoca que la aplicación almacene contenido sensible perteneciente a otro usuario en la caché, y luego el atacante recupera este contenido de la caché.
La respuesta envenenada solo se servirá a los usuarios que visiten la página afectada mientras la caché esté envenenada. Como resultado, el impacto puede variar de inexistente a masivo dependiendo de si la página es popular o no.
Para realizar un ataque de envenenamiento de caché, primero necesitas **identificar entradas no claveadas** (parámetros que no necesitan aparecer en la solicitud caché pero que cambian la página devuelta), ver **cómo abusar** de este parámetro y **conseguir que la respuesta se almacene en la caché**.
Normalmente, cuando una respuesta fue **almacenada en la caché** habrá una **cabecera indicándolo**, puedes verificar qué cabeceras deberías prestar atención en este post: [**Cabeceras de Caché HTTP**](../network-services-pentesting/pentesting-web/special-http-headers.md#cache-headers).
Si piensas que la respuesta está siendo almacenada en una caché, podrías intentar **enviar solicitudes con una mala cabecera**, que debería ser respondida 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).\
Podrías usar [**Param Miner**](https://portswigger.net/bappstore/17d2949a985c4b7ca092728dba871943) para **fuerza bruta de parámetros y cabeceras** que puedan estar **cambiando la respuesta de la página**. Por ejemplo, una página puede estar utilizando la cabecera `X-Forwarded-For` para indicar al cliente que cargue el script desde allí:
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 él de alguna manera (realizar un XSS o cargar un código JS controlado por ti? ¿realizar un DoS?...)
Una vez que has **identificado** la **página** que puede ser abusada, qué **parámetro**/**cabecera** usar y **cómo****abusar** de ella, necesitas conseguir que la página se almacene en caché. Dependiendo del recurso que estés intentando almacenar en caché, esto podría llevar algún tiempo, es posible que necesites intentarlo durante varios segundos.\
La cabecera **`X-Cache`** en la respuesta puede ser muy útil ya que puede tener el valor **`miss`** cuando la solicitud no fue almacenada en caché y el valor **`hit`** cuando sí lo está.\
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 se almacene de nuevo: `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 lo son. Por lo tanto, si el usuario conoce el `User-Agent` de la víctima a la que está apuntando, puede envenenar la caché para los usuarios que utilicen 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 una solicitud en caché, ten **cuidado con las cabeceras que usas** porque algunas de ellas podrían ser **utilizadas inesperadamente** como **claveadas** y la **víctima necesitará usar esa misma cabecera**. Siempre **prueba** un envenenamiento de caché con **diferentes navegadores** para verificar si está funcionando.
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 maliciosa de la caché.
Tenga en cuenta que si la cookie vulnerable es muy utilizada por los usuarios, las solicitudes regulares estarán limpiando la caché.
### Utilizando múltiples encabezados para explotar vulnerabilidades de envenenamiento de caché web <a href="#using-multiple-headers-to-exploit-web-cache-poisoning-vulnerabilities" id="using-multiple-headers-to-exploit-web-cache-poisoning-vulnerabilities"></a>
A veces necesitarás **explotar varias entradas no claveadas** para poder abusar de una caché. Por ejemplo, puedes encontrar un **Open redirect** si configuras `X-Forwarded-Host` a un dominio controlado por ti y `X-Forwarded-Scheme` a `http`. **Si** el **servidor** está **redirigiendo** todas las solicitudes **HTTP** a **HTTPS** y utilizando el encabezado `X-Forwarded-Scheme` como el nombre de dominio para la redirección. Puedes controlar hacia dónde apunta la página por la redirección.
Si descubres que la cabecera **`X-Host`** se utiliza como **nombre de dominio para cargar un recurso JS** pero la cabecera **`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:
Aprende aquí cómo realizar [ataques de envenenamiento de caché abusando del contrabando de solicitudes HTTP](http-request-smuggling/#using-http-request-smuggling-to-perform-web-cache-poisoning).
El [Escáner de Vulnerabilidades de Caché Web](https://github.com/Hackmanit/Web-Cache-Vulnerability-Scanner) se puede utilizar para probar automáticamente el envenenamiento de caché web. Soporta muchas técnicas diferentes y es altamente personalizable.
Utiliza [**Trickest**](https://trickest.com/?utm\_campaign=hacktrics\&utm\_medium=banner\&utm\_source=hacktricks) para construir y **automatizar flujos de trabajo** con las herramientas comunitarias **más avanzadas** del mundo.\
ATS reenviaba el fragmento dentro de la URL sin eliminarlo y generaba la clave de caché solo usando el host, la ruta y la consulta (ignorando el fragmento). Por lo tanto, la solicitud `/#/../?r=javascript:alert(1)` se enviaba al backend como `/#/../?r=javascript:alert(1)` y la clave de caché no tenía el payload dentro de ella, solo host, ruta y consulta.
Enviar un valor incorrecto en el encabezado content-type provocaba una respuesta 405 almacenada en caché. La clave de caché contenía la cookie, por lo que solo era posible atacar a usuarios no autenticados.
GitLab utiliza buckets de GCP para almacenar contenido estático. **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 devuelva un cuerpo de respuesta vacío. También podría soportar el método `PURGE`.
La aplicación Ruby on Rails a menudo se implementa junto con el middleware Rack. El código de Rack a continuación toma el valor del **`x-forwarded-scheme` y lo usa como el esquema de la solicitud**.
Enviar el encabezado `x-forwarded-scheme: http` resultaría en una redirección 301 a la misma ubicación, lo que causaría un DoS sobre ese recurso como en este ejemplo:
La aplicación también podría soportar el encabezado `X-forwarded-host` y redirigir al usuario a ese host, lo que permitiría cargar archivos javascript desde el servidor del atacante:
Anteriormente, **Cloudflare** solía **almacenar en caché** las respuestas **403**, por lo tanto, enviar encabezados de **Autorización incorrectos** al intentar acceder a **S3** o **Azure Storage Blobs** expuestos devolverá un 403 que se almacenará en caché. Cloudflare ya no almacena en caché las respuestas 403, pero esto podría funcionar con otros proxies.
Por ejemplo, Fastly usando Varnish **almacenaba en caché el parámetro `size`** en la solicitud, pero si enviabas **también** el parámetro **`siz%65`** con un valor incorrecto, la **clave de caché** se construía con el parámetro size **bien escrito**, pero el **backend** usaba el **valor dentro del parámetro codificado en la URL**.
Codificar en URL el segundo parámetro `size` provocaba que la caché lo ignorara, pero el backend lo utilizaba. Darle al parámetro un valor de 0 resultaría en un 400 Bad Request almacenable en caché.
Debido a la gran cantidad de tráfico que generan herramientas como FFUF o Nuclei, algunos desarrolladores decidieron bloquear solicitudes que coincidan con sus user-agents. Irónicamente, estos ajustes pueden introducir oportunidades no deseadas de envenenamiento de caché y DoS.
En teoría, si un nombre de encabezado contiene caracteres distintos a los listados en **tchar** debería ser rechazado con un 400 Bad request. Sin embargo, en la práctica, los servidores no siempre respetan el RFC. La forma más fácil de explotar esta sutileza fue apuntando a Akamai, que no rechaza encabezados inválidos, pero los reenvía y almacena cualquier error 400 siempre que el encabezado cache-control no esté presente.
Enviar un encabezado que contenga un carácter ilegal, `\` provocaría un error 400 Bad Request almacenable en caché. Este fue uno de los patrones más comúnmente identificados a lo largo de mis pruebas.
Primero, ten en cuenta que las **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á **respondiendo** con los contenidos **sensibles** del usuario almacenados en _www.example.com/profile.php_, puedes **robar** esos contenidos de otros usuarios.
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 basado en el content-type. En el ejemplo _http://www.example.com/home.php/non-existent.css_ tendrá un content-type `text/html` en lugar de un mime type `text/css` (que es lo esperado para un archivo _.css_).
Aprende aquí cómo realizar [ataques de Engaño de Caché abusando del contrabando de solicitudes HTTP](http-request-smuggling/#using-http-request-smuggling-to-perform-web-cache-deception).
Utiliza [**Trickest**](https://trickest.com/?utm\_campaign=hacktrics\&utm\_medium=banner\&utm\_source=hacktricks) para construir y **automatizar flujos de trabajo** con las herramientas comunitarias **más avanzadas** del mundo.\
<summary><strong>Aprende hacking en AWS de cero a héroe con</strong><ahref="https://training.hacktricks.xyz/courses/arte"><strong>htARTE (HackTricks AWS Red Team Expert)</strong></a><strong>!</strong></summary>
* Si quieres ver a tu **empresa anunciada en HackTricks** o **descargar HackTricks en PDF** consulta los [**PLANES DE SUSCRIPCIÓN**](https://github.com/sponsors/carlospolop)!
* Consigue el [**merchandising oficial de PEASS & HackTricks**](https://peass.creator-spring.com)
* Descubre [**La Familia PEASS**](https://opensea.io/collection/the-peass-family), nuestra colección de [**NFTs**](https://opensea.io/collection/the-peass-family) exclusivos
* **Únete al** 💬 [**grupo de Discord**](https://discord.gg/hRep4RUj7f) o al [**grupo de telegram**](https://t.me/peass) o **sígueme** en **Twitter** 🐦 [**@carlospolopm**](https://twitter.com/carlospolopm)**.**
* **Comparte tus trucos de hacking enviando PRs a los repositorios de GitHub** [**HackTricks**](https://github.com/carlospolop/hacktricks) y [**HackTricks Cloud**](https://github.com/carlospolop/hacktricks-cloud).
