<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)!
* 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 no Claveadas**: 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 no Claveadas**: Después de identificar las entradas no claveadas, 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).
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**. 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).\
Podrías utilizar [**Param Miner**](https://portswigger.net/bappstore/17d2949a985c4b7ca092728dba871943) para **bruteforcear parámetros y encabezados** que puedan 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 travesía 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 exfiltrar el User-Agent de la víctima y envenenar la caché utilizando ese user agent:
Aprende aquí cómo realizar [ataques de Manipulación de Caché al abusar 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) puede utilizarse para probar automáticamente la manipulación 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 utilizando 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 que devolviera un cuerpo de respuesta vacío. También podía admitir el método `PURGE`.
En las aplicaciones de Ruby on Rails, se utiliza frecuentemente 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 causa 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 podría seguir 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 la manipulación 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.
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 Decepción de Caché abusando del Contrabando de Solicitudes HTTP](http-request-smuggling/#using-http-request-smuggling-to-perform-web-cache-deception).
* [**toxicache**](https://github.com/xhzeem/toxicache): Escáner en Golang para encontrar vulnerabilidades de manipulación de caché web en una lista de URLs y probar múltiples técnicas de inyección.
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 AWS de HackTricks)</strong></a><strong>!</strong></summary>
* Si quieres ver tu **empresa anunciada en HackTricks** o **descargar HackTricks en PDF** Consulta los [**PLANES DE SUSCRIPCIÓN**](https://github.com/sponsors/carlospolop)!
* Descubre [**La Familia PEASS**](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** [**HackTricks**](https://github.com/carlospolop/hacktricks) y [**HackTricks Cloud**](https://github.com/carlospolop/hacktricks-cloud) repositorios de github.
