# HTTP Response Smuggling / Desync

{% hint style="success" %}
Apprenez et pratiquez le hacking AWS :<img src="/.gitbook/assets/arte.png" alt="" data-size="line">[**HackTricks Training AWS Red Team Expert (ARTE)**](https://training.hacktricks.xyz/courses/arte)<img src="/.gitbook/assets/arte.png" alt="" data-size="line">\
Apprenez et pratiquez le hacking GCP : <img src="/.gitbook/assets/grte.png" alt="" data-size="line">[**HackTricks Training GCP Red Team Expert (GRTE)**<img src="/.gitbook/assets/grte.png" alt="" data-size="line">](https://training.hacktricks.xyz/courses/grte)

<details>

<summary>Support HackTricks</summary>

* Consultez les [**plans d'abonnement**](https://github.com/sponsors/carlospolop) !
* **Rejoignez le** 💬 [**groupe Discord**](https://discord.gg/hRep4RUj7f) ou le [**groupe telegram**](https://t.me/peass) ou **suivez-nous sur** **Twitter** 🐦 [**@hacktricks\_live**](https://twitter.com/hacktricks\_live)**.**
* **Partagez des astuces de hacking en soumettant des PR aux** [**HackTricks**](https://github.com/carlospolop/hacktricks) et [**HackTricks Cloud**](https://github.com/carlospolop/hacktricks-cloud) dépôts github.

</details>
{% endhint %}

**La technique de ce post a été tirée de la vidéo :** [**https://www.youtube.com/watch?v=suxDcYViwao\&t=1343s**](https://www.youtube.com/watch?v=suxDcYViwao\&t=1343s)

## Désynchronisation de la file d'attente des requêtes HTTP

Tout d'abord, cette technique **abuse d'une vulnérabilité de HTTP Request Smuggling**, donc vous devez savoir ce que c'est :

La **principale** **différence** entre cette technique et un smuggling HTTP Request commun est que **au lieu** de **cibler** la **requête** de la **victime** **en ajoutant un préfixe**, nous allons **fuiter ou modifier la réponse que la victime reçoit**. Cela se fait en, au lieu d'envoyer 1 requête et demie pour abuser du HTTP Request smuggling, **envoyer 2 requêtes complètes pour désynchroniser la file d'attente des réponses des proxies**.

C'est parce que nous allons pouvoir **désynchroniser la file d'attente des réponses** afin que la **réponse** de la **requête** **légitime** de la **victime soit envoyée à l'attaquant**, ou en **injectant du contenu contrôlé par l'attaquant dans la réponse à la victime**.

### Désynchronisation du pipeline HTTP

HTTP/1.1 permet de demander des **ressources différentes sans avoir besoin d'attendre les précédentes**. Par conséquent, s'il y a un **proxy** au **milieu**, c'est la tâche des proxies de **maintenir une correspondance synchronisée des requêtes envoyées au backend et des réponses provenant de celui-ci**.

Cependant, il y a un problème de désynchronisation de la file d'attente des réponses. Si un attaquant envoie une attaque de HTTP Response smuggling et que les réponses à la **requête initiale et à celle smuggled sont répondues immédiatement**, la réponse smuggled ne sera pas insérée dans la file d'attente de la réponse de la victime mais sera **juste rejetée comme une erreur**.

![](<../.gitbook/assets/image (633).png>)

Par conséquent, il est nécessaire que la **requête smuggled** **prenne plus de temps à être traitée** à l'intérieur du serveur backend. Ainsi, au moment où la requête smuggled est traitée, la communication avec l'attaquant sera terminée.

Si dans cette situation spécifique une **victime a envoyé une requête** et que la **requête smuggled est répondue avant** la requête légitime, la **réponse smuggled sera envoyée à la victime**. Par conséquent, l'attaquant va **contrôler la requête "effectuée" par la victime**.

De plus, si l'**attaquant effectue ensuite une requête** et que la **réponse légitime** à la **requête** de la **victime** est **répondue** **avant** la requête de l'attaquant. La **réponse à la victime va être envoyée à l'attaquant**, **volant** la réponse à la victime (qui peut contenir par exemple l'en-tête **Set-Cookie**).

![](<../.gitbook/assets/image (1020).png>)

![](<../.gitbook/assets/image (719).png>)

### Injections imbriquées multiples

Une autre **différence intéressante** avec le **HTTP Request Smuggling** commun est que, dans une attaque de smuggling commune, le **but** est de **modifier le début de la requête de la victime** afin qu'elle effectue une action inattendue. Dans une **attaque de HTTP Response smuggling**, comme vous **envoyez des requêtes complètes**, vous pouvez **injecter dans une charge utile des dizaines de réponses** qui vont **désynchroniser des dizaines d'utilisateurs** qui vont **recevoir** les **réponses injectées**.

En plus de pouvoir **distribuer plus facilement des dizaines d'exploits** parmi des utilisateurs légitimes, cela pourrait également être utilisé pour provoquer un **DoS** sur le serveur.

### Organisation de l'exploit

Comme expliqué précédemment, pour abuser de cette technique, il est nécessaire que le **premier message smuggled** dans le serveur **prenne beaucoup de temps à être traité**.

Cette **requête consommatrice de temps est suffisante** si nous voulons juste **essayer de voler la réponse de la victime.** Mais si vous voulez effectuer un exploit plus complexe, cela sera une structure commune pour l'exploit.

Tout d'abord la **requête initiale** abusant du **HTTP** **Request** **smuggling**, puis la **requête consommatrice de temps** et ensuite **1 ou plusieurs requêtes de charge utile** dont les réponses seront envoyées aux victimes.

## Abus de la désynchronisation de la file d'attente des réponses HTTP

### Capturer les requêtes d'autres utilisateurs <a href="#capturing-other-users-requests" id="capturing-other-users-requests"></a>

Comme avec les charges utiles connues de HTTP Request Smuggling, vous pouvez **voler la requête de la victime** avec une différence importante : Dans ce cas, vous avez juste besoin que le **contenu envoyé soit reflété dans la réponse**, **aucun stockage persistant** n'est nécessaire.

Tout d'abord, l'attaquant envoie une charge utile contenant une **requête POST finale avec le paramètre réfléchi** à la fin et une grande Content-Length.

![](<../.gitbook/assets/image (1053).png>)

Ensuite, une fois que la **requête initiale** (bleue) a été **traitée** et **pendant** que la **requête lente** est en cours de traitement (jaune), la **prochaine requête qui arrive d'une victime** va être **ajoutée dans la file d'attente juste après le paramètre réfléchi** :

![](<../.gitbook/assets/image (794).png>)

Ensuite, la **victime** va **recevoir** la **réponse à la requête lente** et si entre-temps l'**attaquant** **envoie** **une autre** **requête**, la **réponse de la requête de contenu réfléchi sera envoyée à lui**.

## Désynchronisation de la réponse

Jusqu'à présent, nous avons appris comment abuser des attaques de HTTP Request Smuggling pour **contrôler** la **requête** **dont** la **réponse** un **client** va **recevoir** et comment vous pouvez ensuite **voler la réponse qui était destinée à la victime**.

Mais il est encore possible de **désynchroniser encore** plus les réponses.

Il existe des requêtes intéressantes comme la requête **HEAD** qui sont spécifiées pour ne pas avoir **de contenu à l'intérieur du corps des réponses** et qui devraient (doivent) **contenir la Content-Length** de la requête comme **si c'était une requête GET**.

Par conséquent, si un attaquant **injecte** une **requête HEAD**, comme dans ces images :

![](<../.gitbook/assets/image (1107).png>)

Alors, **une fois que la bleue est répondue à l'attaquant**, la prochaine requête de la victime va être introduite dans la file d'attente :

![](<../.gitbook/assets/image (999).png>)

Ensuite, la **victime** va **recevoir** la **réponse** de la **requête HEAD**, qui va **contenir une Content-Length mais aucun contenu du tout**. Par conséquent, le proxy **ne va pas envoyer cette réponse** à la victime, mais va **attendre** un **contenu**, qui en réalité va être la **réponse à la requête jaune** (également injectée par l'attaquant) :

![](<../.gitbook/assets/image (735).png>)

### Confusion de contenu

En suivant l'exemple précédent, sachant que vous pouvez **contrôler le corps** de la requête dont la réponse va être reçue par la victime et qu'une **réponse HEAD** **contient généralement dans ses en-têtes le **Content-Type et le Content-Length**, vous pouvez **envoyer une requête comme la suivante** pour **provoquer un XSS** chez la victime sans que la page soit vulnérable au XSS :

![](<../.gitbook/assets/image (688).png>)

### Poisoning de cache

En abusant de l'attaque de désynchronisation de réponse commentée précédemment, **si le cache stocke la réponse à la requête effectuée par la victime et que cette réponse est une réponse injectée provoquant un XSS, alors le cache est empoisonné**.

Requête malveillante contenant la charge utile XSS :

![](<../.gitbook/assets/image (614).png>)

Réponse malveillante à la victime qui contient l'en-tête indiquant au cache de stocker la réponse :

![](<../.gitbook/assets/image (566).png>)

{% hint style="warning" %}
Notez que dans ce cas, si la **"victime" est l'attaquant**, il peut maintenant effectuer **un empoisonnement de cache sur des URL arbitraires** car il peut **contrôler l'URL qui va être mise en cache** avec la réponse malveillante.
{% endhint %}

### Tromperie de cache web

Cette attaque est similaire à la précédente, mais **au lieu d'injecter une charge utile dans le cache, l'attaquant va mettre en cache des informations de la victime à l'intérieur du cache :**

![](<../.gitbook/assets/image (991).png>)

### Division de réponse

Le **but** de cette attaque est d'abuser à nouveau de la **désynchronisation** de la **réponse** afin de **faire en sorte que le proxy envoie une réponse générée à 100 % par l'attaquant**.

Pour y parvenir, l'attaquant doit trouver un point de terminaison de l'application web qui **reflète certaines valeurs à l'intérieur de la réponse** et **connaître la longueur de contenu de la réponse HEAD**.

Il enverra un **exploit** comme :

![](<../.gitbook/assets/image (911).png>)

Après que la première requête soit résolue et renvoyée à l'attaquant, la **requête de la victime est ajoutée dans la file d'attente** :

![](<../.gitbook/assets/image (737).png>)

La victime recevra comme réponse la **réponse HEAD + le contenu de la réponse de la deuxième requête (contenant une partie des données réfléchies) :**

![](<../.gitbook/assets/image (356).png>)

Cependant, notez comment les **données réfléchies avaient une taille selon la Content-Length** de la **réponse HEAD** qui **a généré une réponse HTTP valide dans la file d'attente des réponses**.

Par conséquent, la **prochaine requête de la deuxième victime** va **recevoir** comme **réponse quelque chose complètement fabriqué par l'attaquant**. Comme la réponse est complètement fabriquée par l'attaquant, il peut également **faire en sorte que le proxy mette en cache la réponse**.

{% hint style="success" %}
Apprenez et pratiquez le hacking AWS :<img src="/.gitbook/assets/arte.png" alt="" data-size="line">[**HackTricks Training AWS Red Team Expert (ARTE)**](https://training.hacktricks.xyz/courses/arte)<img src="/.gitbook/assets/arte.png" alt="" data-size="line">\
Apprenez et pratiquez le hacking GCP : <img src="/.gitbook/assets/grte.png" alt="" data-size="line">[**HackTricks Training GCP Red Team Expert (GRTE)**<img src="/.gitbook/assets/grte.png" alt="" data-size="line">](https://training.hacktricks.xyz/courses/grte)

<details>

<summary>Support HackTricks</summary>

* Consultez les [**plans d'abonnement**](https://github.com/sponsors/carlospolop) !
* **Rejoignez le** 💬 [**groupe Discord**](https://discord.gg/hRep4RUj7f) ou le [**groupe telegram**](https://t.me/peass) ou **suivez-nous sur** **Twitter** 🐦 [**@hacktricks\_live**](https://twitter.com/hacktricks\_live)**.**
* **Partagez des astuces de hacking en soumettant des PR aux** [**HackTricks**](https://github.com/carlospolop/hacktricks) et [**HackTricks Cloud**](https://github.com/carlospolop/hacktricks-cloud) dépôts github.

</details>
{% endhint %}