<summary><strong>Aprende a hackear AWS desde cero hasta convertirte en un experto con</strong><ahref="https://training.hacktricks.xyz/courses/arte"><strong>htARTE (Experto en Equipos Rojos de AWS de HackTricks)</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 la [**merchandising oficial de PEASS & HackTricks**](https://peass.creator-spring.com)
* 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ígueme** en **Twitter** 🐦 [**@carlospolopm**](https://twitter.com/carlospolopm)**.**
* **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).
**La técnica de este post fue tomada del video: [https://www.youtube.com/watch?v=suxDcYViwao\&t=1343s](https://www.youtube.com/watch?v=suxDcYViwao\&t=1343s)**
La **principal****diferencia** entre esta técnica y una Desincronización de Solicitudes HTTP común es que **en lugar de atacar la solicitud de la víctima agregando un prefijo a la misma**, vamos a **filtrar o modificar la respuesta que recibe la víctima**. Esto se logra enviando 2 solicitudes completas para desincronizar la cola de respuestas de los proxies, en lugar de enviar 1 solicitud y media para abusar de la Desincronización de Solicitudes HTTP.
Esto se debe a que vamos a poder **desincronizar la cola de respuestas** para que la **respuesta** de la **solicitud legítima de la víctima se envíe al atacante**, o **inyectando contenido controlado por el atacante en la respuesta a la víctima**.
HTTP/1.1 permite solicitar **diferentes recursos sin necesidad de esperar los anteriores**. Por lo tanto, si hay un **proxy** en el **medio**, es tarea de los proxies **mantener una coincidencia sincronizada de las solicitudes enviadas al backend y las respuestas que provienen de él**.
Sin embargo, hay un problema al desincronizar la cola de respuestas. Si un atacante envía un ataque de Desincronización de Respuestas HTTP y las respuestas a la **solicitud inicial y la solicitada se responden inmediatamente**, la respuesta solicitada no se insertará en la cola de respuestas de la víctima, sino que **se descartará como un error**.
Por lo tanto, es necesario que la **solicitud filtrada****tome más tiempo en procesarse** dentro del servidor backend. Por lo tanto, cuando la solicitud filtrada se procese, la comunicación con el atacante habrá terminado.
Si en esta situación específica un **atacante envía una solicitud** y la **solicitud filtrada se responde antes** que la solicitud legítima, la **respuesta filtrada se enviará a la víctima**. Por lo tanto, el atacante estará **controlando la solicitud "realizada" por la víctima**.
Además, si el **atacante luego realiza una solicitud** y la **respuesta legítima** a la **solicitud de la víctima se responde****antes** que la solicitud del atacante. La **respuesta a la víctima se enviará al atacante**, **robando** la respuesta a la víctima (que puede contener, por ejemplo, el encabezado **Set-Cookie**).
Otra **diferencia interesante** con la Desincronización de Solicitudes HTTP común es que, en un ataque de desincronización común, el **objetivo** es **modificar el inicio de la solicitud de la víctima** para que realice una acción inesperada. En un **ataque de desincronización de respuestas HTTP**, al **enviar solicitudes completas**, puedes **inyectar en una carga útil decenas de respuestas** que **desincronizarán a decenas de usuarios** que estarán **recibiendo** las **respuestas****inyectadas**.
Además de poder **distribuir más fácilmente decenas de exploits** entre usuarios legítimos, esto también podría usarse para causar una **denegación de servicio** en el servidor.
Como se explicó anteriormente, para abusar de esta técnica, es necesario que el **primer mensaje filtrado** en el servidor **requiera mucho tiempo para procesarse**.
Esta **solicitud que consume tiempo es suficiente** si solo queremos **intentar robar la respuesta de las víctimas**. Pero si deseas realizar un exploit más complejo, esta será una estructura común para el exploit.
Primero la **solicitud inicial** abusando de la **Desincronización de Solicitudes HTTP**, luego la **solicitud que consume tiempo** y luego **1 o más solicitudes de carga útil** cuyas respuestas se enviarán a las víctimas.
Al igual que con las cargas útiles conocidas de Desincronización de Solicitudes HTTP, puedes **robar la solicitud de las víctimas** con una diferencia importante: En este caso, solo necesitas que el **contenido enviado se refleje en la respuesta**, **no se necesita almacenamiento persistente**.
Luego, una vez que la **solicitud inicial** (azul) fue **procesada** y **mientras** la **solicitud lenta** se está procesando (amarilla), la **próxima solicitud que llega de una víctima** se va a **agregar en la cola justo después del parámetro reflejado**:
Entonces, la **víctima****recibirá** la **respuesta a la solicitud lenta** y si en ese momento el **atacante****envía****otra****solicitud**, la **respuesta de la solicitud de contenido reflejado se le enviará**.
Hasta este punto, hemos aprendido cómo abusar de los ataques de Desincronización de Solicitudes HTTP para **controlar** la **solicitud****cuya****respuesta** un **cliente** va a **recibir** y cómo luego puedes **robar la respuesta que estaba destinada a la víctima**.
Existen solicitudes interesantes como la solicitud **HEAD** que se especifican para no tener **ningún contenido dentro del cuerpo de las respuestas** y que deben (deben) **contener el Content-Length** de la solicitud como **si fuera una solicitud GET**.
Entonces, la **víctima****recibirá** la **respuesta** de la **solicitud HEAD**, que **va a contener un Content-Length pero sin contenido alguno**. Por lo tanto, el proxy **no enviará esta respuesta** a la víctima, sino que **esperará** algún **contenido**, que en realidad será **la respuesta a la solicitud amarilla** (también inyectada por el atacante):
Siguiendo el ejemplo anterior, sabiendo que puedes **controlar el cuerpo** de la solicitud cuya respuesta va a recibir la víctima y que una **respuesta HEAD****generalmente contiene en sus encabezados el Content-Type y el Content-Length**, puedes **enviar una solicitud como la siguiente** para **causar XSS** en la víctima sin que la página sea vulnerable a XSS:
Abusando del ataque de Confusión de Contenido de desincronización de respuestas comentado anteriormente, **si la caché almacena la respuesta a la solicitud realizada por la víctima y esta respuesta es una inyectada que causa un XSS, entonces la caché está envenenada**.
Ten en cuenta que en este caso, si el **"víctima" es el atacante**, ahora puede realizar **envenenamiento de caché en URLs arbitrarias** ya que puede **controlar la URL que se va a cachear** con la respuesta maliciosa.
Este ataque es similar al anterior, pero **en lugar de inyectar una carga útil dentro de la caché, el atacante almacenará información de la víctima dentro de la caché:**
El **objetivo** de este ataque es abusar nuevamente de la **desincronización de respuestas** para **hacer que el proxy envíe una respuesta 100% generada por el atacante**.
Para lograr esto, el atacante necesita encontrar un punto final de la aplicación web que **refleje algunos valores dentro de la respuesta** y **conocer la longitud del contenido de la respuesta HEAD**.
La víctima recibirá como respuesta la **respuesta HEAD + el contenido de la respuesta de la segunda solicitud (que contiene parte de los datos reflejados):**
Sin embargo, observa cómo los **datos reflejados tenían un tamaño de acuerdo con el Content-Length** de la **respuesta HEAD** que **generó una respuesta HTTP válida en la cola de respuestas**.
Por lo tanto, la **próxima solicitud del segundo usuario** recibirá como **respuesta algo completamente creado por el atacante**. Como la respuesta está completamente creada por el atacante, también puede **hacer que el proxy almacene en caché la respuesta**.
