<summary><strong>Aprende hacking en AWS desde cero hasta experto con</strong><ahref="https://training.hacktricks.xyz/courses/arte"><strong>htARTE (HackTricks AWS Red Team Expert)</strong></a><strong>!</strong></summary>
* Si deseas ver tu **empresa anunciada en HackTricks** o **descargar HackTricks en PDF** ¡Consulta los [**PLANES DE SUSCRIPCIÓN**](https://github.com/sponsors/carlospolop)!
* Obtén el [**swag oficial de PEASS & HackTricks**](https://peass.creator-spring.com)
* Descubre [**The PEASS Family**](https://opensea.io/collection/the-peass-family), nuestra colección exclusiva de [**NFTs**](https://opensea.io/collection/the-peass-family)
* **Únete al** 💬 [**grupo de Discord**](https://discord.gg/hRep4RUj7f) o al [**grupo de telegram**](https://t.me/peass) o **síguenos** en **Twitter** 🐦 [**@carlospolopm**](https://twitter.com/hacktricks\_live)**.**
* **Comparte tus trucos de hacking enviando PRs a los repositorios 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** fácilmente con las herramientas comunitarias **más avanzadas** del mundo.\
> * En el **envenenamiento de caché web**, el atacante hace que la aplicación almacene algún 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 hace que la aplicación almacene algún contenido sensible perteneciente a otro usuario en la caché, y luego el atacante recupera este contenido de la caché.
El envenenamiento de caché tiene como objetivo manipular la caché del lado del cliente para forzar a los clientes a cargar recursos que son inesperados, parciales o están bajo el control de 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é.
1.**Identificación de Entradas sin Clave**: Estos son parámetros que, aunque no son necesarios para que se almacene una solicitud en la caché, pueden alterar la respuesta devuelta por el servidor. Identificar estas entradas es crucial, ya que pueden ser explotadas para manipular la caché.
2.**Explotación de las Entradas sin Clave**: Después de identificar las entradas sin clave, el siguiente paso implica descubrir cómo abusar de estos parámetros para modificar la respuesta del servidor de una manera que beneficie al atacante.
3.**Asegurar que la Respuesta Envenenada se Almacene en la Caché**: El paso final es asegurar que la respuesta manipulada se almacene en la caché. De esta manera, cualquier usuario que acceda a la página afectada mientras la caché esté envenenada recibirá la respuesta contaminada.
Por lo general, cuando una respuesta fue **almacenada en la caché** habrá un **encabezado que lo indique**, puedes verificar a qué encabezados debes prestar atención en este post: [**Encabezados de Caché HTTP**](../network-services-pentesting/pentesting-web/special-http-headers.md#cache-headers).
### Descubrimiento: Almacenamiento de código 400 en caché
Si piensas que la respuesta se está almacenando en una caché, podrías intentar **enviar solicitudes con un encabezado incorrecto**, que debería recibir una **código de estado 400** como respuesta. Luego intenta acceder a la solicitud de forma normal y si la **respuesta es un código de estado 400**, sabrás que es vulnerable (e incluso podrías realizar un DoS).\
Un encabezado mal configurado podría ser simplemente `\:` como encabezado.\
_Ten en cuenta que a veces este tipo de códigos de estado no se almacenan en caché, por lo que esta prueba será inútil._
### Descubrimiento: Identificar y evaluar entradas sin clave
Podrías utilizar [**Param Miner**](https://portswigger.net/bappstore/17d2949a985c4b7ca092728dba871943) para **bruteforcear parámetros y encabezados** que podrían estar **cambiando la respuesta de la página**. Por ejemplo, una página podría estar usando el encabezado `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 desde la cabecera. ¿Puedes abusar de alguna manera (realizar un XSS o cargar un código JS controlado por ti? ¿realizar un DoS?...)
Una vez que hayas **identificado** la **página** que puede ser abusada, qué **parámetro**/**cabecera** usar y **cómo** abusar de ella, necesitas que la página se almacene en caché. Dependiendo del recurso que estés intentando almacenar en caché, esto podría llevar algo de 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 estaba en caché y el valor **`hit`** cuando está en caché.\
La cabecera **`Cache-Control`** también es interesante para saber si un recurso está en caché y cuándo será la próxima vez que se almacene en caché nuevamente: `Cache-Control: public, max-age=1800`\
Otra cabecera interesante es **`Vary`**. Esta cabecera se usa a menudo para **indicar cabeceras adicionales** que se tratan como **parte de la clave de caché** incluso si normalmente no tienen clave. Por lo tanto, si el usuario conoce el `User-Agent` de la víctima a la que apunta, puede envenenar la caché para los usuarios que utilizan ese `User-Agent` específico.\
Al almacenar en caché una solicitud, ten **cuidado con las cabeceras que uses** porque algunas de ellas podrían ser **utilizadas inesperadamente** como **clave** 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 carguen la respuesta de caché maliciosa.
### Envenenamiento de caché con traversal de ruta para robar clave de API <a href="#using-multiple-headers-to-exploit-web-cache-poisoning-vulnerabilities" id="using-multiple-headers-to-exploit-web-cache-poisoning-vulnerabilities"></a>
[**Este informe explica**](https://nokline.github.io/bugbounty/2024/02/04/ChatGPT-ATO.html) 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/*` se almacenará en caché sin que Cloudflare normalice la URL, lo cual se hizo cuando la solicitud llegó al servidor web.
### Uso de 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 varios inputs sin clave** para poder abusar de una caché. Por ejemplo, puedes encontrar una **redirección abierta** 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 con la redirección.
Si descubres que el encabezado **`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 forma de extraer 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. Admite 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** fácilmente 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 contenía la carga útil en su interior, solo el host, la ruta y la consulta.
Enviar un valor incorrecto en el encabezado de tipo de contenido desencadenaba una respuesta en caché 405. 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. Los **buckets de GCP** admiten el encabezado `x-http-method-override`. Por lo tanto, era posible enviar el encabezado `x-http-method-override: HEAD` y envenenar la caché para devolver un cuerpo de respuesta vacío. También podría admitir el método `PURGE`.
En las aplicaciones de Ruby on Rails, a menudo se utiliza el middleware de Rack. El propósito del código de 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`, se produce una redirección 301 a la misma ubicación, lo que potencialmente 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.
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 almacenaba en caché. Aunque Cloudflare ha dejado de almacenar en caché respuestas 403, este comportamiento aún podría estar presente en otros servicios de proxy.
Las cachés a menudo incluyen parámetros GET específicos en la clave de caché. Por ejemplo, Varnish de Fastly almacenaba en caché el parámetro `size` en las solicitudes. Sin embargo, si se enviaba también 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 utilizando 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` llevaba a su omisión por la caché pero su utilización por el backend. Asignar un valor de 0 a este parámetro resultaba en un error 400 Bad Request en caché.
Algunos desarrolladores bloquean solicitudes con agentes de usuario 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 el envenenamiento de caché y DoS.
El [RFC7230](https://datatracker.ietf.mrg/doc/html/rfc7230) especifica los caracteres aceptables en los nombres de encabezado. Los encabezados que contienen caracteres fuera del rango especificado de **tchar** deberían idealmente desencadenar 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 cualquier error 400, siempre que el encabezado `cache-control` no esté presente. Se identificó un patrón explotable donde el envío de un encabezado con un carácter no válido, como `\`, resultaría en un error 400 Bad Request en caché.
En primer lugar, 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`, es probable que la caché almacene la respuesta porque ve la extensión `.js`. Sin embargo, si la **aplicación** está **reproduciendo** con el **contenido sensible** del usuario almacenado en _www.example.com/profile.php_, puedes **robar** ese contenido de otros usuarios.
Un ejemplo muy claro se puede encontrar en este informe: [https://hackerone.com/reports/593712](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 **cachear** archivos **basados** en la **extensión** del archivo (_.css_) y no 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 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** fácilmente 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 (Experto en Red Team de HackTricks AWS)</strong></a><strong>!</strong></summary>
* Si deseas ver tu **empresa anunciada en HackTricks** o **descargar HackTricks en PDF** Consulta los [**PLANES DE SUSCRIPCIÓN**](https://github.com/sponsors/carlospolop)!
* Obtén el [**swag 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íguenos** en **Twitter** 🐦 [**@carlospolopm**](https://twitter.com/hacktricks\_live)**.**
* **Comparte tus trucos de hacking enviando PRs a los** [**HackTricks**](https://github.com/carlospolop/hacktricks) y [**HackTricks Cloud**](https://github.com/carlospolop/hacktricks-cloud) repositorios de github.
