mirror of
https://github.com/HackTricks-wiki/hacktricks.git
synced 2025-10-10 18:36:50 +00:00
Translated ['src/pentesting-web/http-connection-request-smuggling.md'] t
This commit is contained in:
Translator
parent
ce95a484fb
commit
a69e62856f
@ -2,33 +2,82 @@
|
||||
|
||||
{{#include ../banners/hacktricks-training.md}}
|
||||
|
||||
**Ceci est un résumé du post** [**https://portswigger.net/research/browser-powered-desync-attacks**](https://portswigger.net/research/browser-powered-desync-attacks)
|
||||
**Cette page résume, étend et met à jour** la recherche fondamentale de PortSwigger sur [Browser-Powered Desync Attacks](https://portswigger.net/research/browser-powered-desync-attacks) et les travaux ultérieurs sur l'abus de l'état de connexion HTTP/2. Elle se concentre sur les vulnérabilités où **une origine est déterminée uniquement une fois par connexion TCP/TLS**, permettant à un attaquant de « faire passer » des requêtes vers un autre hôte interne une fois le canal établi.
|
||||
|
||||
## Attaques d'état de connexion <a href="#state" id="state"></a>
|
||||
## Attaques sur l'état de connexion <a href="#state" id="state"></a>
|
||||
|
||||
### Validation de la première requête
|
||||
|
||||
Lors du routage des requêtes, les proxies inverses peuvent dépendre de l'**en-tête Host** pour déterminer le serveur back-end de destination, s'appuyant souvent sur une liste blanche d'hôtes autorisés. Cependant, une vulnérabilité existe dans certains proxies où la liste blanche n'est appliquée que sur la requête initiale d'une connexion. Par conséquent, les attaquants pourraient en profiter en effectuant d'abord une requête vers un hôte autorisé, puis en demandant un site interne via la même connexion :
|
||||
```
|
||||
Lors du routage des requêtes, les proxys inverses peuvent dépendre de l'en-tête **Host** (ou **:authority** dans HTTP/2) pour déterminer le serveur back-end de destination, s'appuyant souvent sur une liste blanche d'hôtes autorisés. Cependant, une vulnérabilité existe dans un certain nombre de proxys où la liste blanche est **uniquement appliquée à la toute première requête dans une connexion**. Par conséquent, les attaquants peuvent accéder à des hôtes virtuels internes en envoyant d'abord une requête autorisée, puis en réutilisant la même connexion sous-jacente :
|
||||
```http
|
||||
GET / HTTP/1.1
|
||||
Host: [allowed-external-host]
|
||||
Host: allowed-external-host.example
|
||||
|
||||
GET / HTTP/1.1
|
||||
Host: [internal-host]
|
||||
GET /admin HTTP/1.1
|
||||
Host: internal-only.example
|
||||
```
|
||||
### Routage de la première requête
|
||||
|
||||
Dans certaines configurations, un serveur frontal peut utiliser le **header Host de la première requête** pour déterminer le routage en arrière-plan pour cette requête, puis acheminer de manière persistante toutes les requêtes suivantes provenant de la même connexion client vers la même connexion en arrière-plan. Cela peut être démontré comme suit :
|
||||
```
|
||||
De nombreux proxies inverses HTTP/1.1 associent une connexion sortante à un pool de back-end **basé exclusivement sur la première requête qu'ils transmettent**. Toutes les requêtes suivantes envoyées via le même socket frontal sont silencieusement réutilisées, indépendamment de leur en-tête Host. Cela peut être combiné avec des attaques classiques sur l'[en-tête Host](https://portswigger.net/web-security/host-header) telles que le poisoning de réinitialisation de mot de passe ou le [poisoning de cache web](https://portswigger.net/web-security/web-cache-poisoning) pour obtenir un accès semblable à SSRF à d'autres hôtes virtuels :
|
||||
```http
|
||||
GET / HTTP/1.1
|
||||
Host: example.com
|
||||
Host: public.example
|
||||
|
||||
POST /pwreset HTTP/1.1
|
||||
Host: psres.net
|
||||
Host: private.internal
|
||||
```
|
||||
Ce problème peut potentiellement être combiné avec [Host header attacks](https://portswigger.net/web-security/host-header), comme le poisoning de réinitialisation de mot de passe ou [web cache poisoning](https://portswigger.net/web-security/web-cache-poisoning), pour exploiter d'autres vulnérabilités ou obtenir un accès non autorisé à d'autres hôtes virtuels.
|
||||
> [!TIP]
|
||||
> Dans Burp Suite Professional ≥2022.10, vous pouvez activer **HTTP Request Smuggler → Connection-state probe** pour détecter automatiquement ces faiblesses.
|
||||
|
||||
> [!NOTE]
|
||||
> Pour identifier ces vulnérabilités, la fonctionnalité 'connection-state probe' dans HTTP Request Smuggler peut être utilisée.
|
||||
---
|
||||
|
||||
## NOUVEAU en 2023-2025 – Abus de la coalescence de connexion HTTP/2/3
|
||||
|
||||
Les navigateurs modernes **coalescent** régulièrement les requêtes HTTP/2 et HTTP/3 sur une seule connexion TLS lorsque le certificat, le protocole ALPN et l'adresse IP correspondent. Si un front-end n'autorise que la première requête, chaque requête coalescée suivante hérite de cette autorisation – **même si le Host/:authority change**.
|
||||
|
||||
### Scénario d'exploitation
|
||||
1. L'attaquant contrôle `evil.com` qui résout le même nœud de bord CDN que la cible `internal.company`.
|
||||
2. Le navigateur de la victime a déjà une connexion HTTP/2 ouverte vers `evil.com`.
|
||||
3. L'attaquant intègre une `<img src="https://internal.company/…">` cachée dans sa page.
|
||||
4. Comme les paramètres de connexion correspondent, le navigateur réutilise la connexion TLS **existante** et multiplexe la requête pour `internal.company`.
|
||||
5. Si le CDN/le routeur a seulement validé la première requête, l'hôte interne est exposé.
|
||||
|
||||
Des PoCs pour Chrome/Edge/Firefox sont disponibles dans la présentation de James Kettle *“HTTP/2: The Sequel is Always Worse”* (Black Hat USA 2023).
|
||||
|
||||
### Outils
|
||||
* **Burp Suite 2023.12** a introduit un point d'insertion **HTTP/2 Smuggler** expérimental qui tente automatiquement la coalescence et les techniques TE/CL.
|
||||
* **smuggleFuzz** (https://github.com/microsoft/smugglefuzz) – Un framework Python publié en 2024 pour forcer les vecteurs de désynchronisation front-end/back-end sur HTTP/2 et HTTP/3, y compris les permutations d'état de connexion.
|
||||
|
||||
### Atténuations
|
||||
* Toujours **re-valider Host/:authority à chaque requête**, pas seulement lors de la création de la connexion.
|
||||
* Désactiver ou restreindre strictement la **coalescence d'origine** sur les couches CDN/équilibreur de charge (par exemple, `http2_origin_cn` désactivé dans NGINX).
|
||||
* Déployer des certificats ou des adresses IP séparés pour les noms d'hôtes internes et externes afin que le navigateur ne puisse pas les coalescer légalement.
|
||||
* Préférer **connection: close** ou `proxy_next_upstream` après chaque requête lorsque cela est pratique.
|
||||
|
||||
---
|
||||
|
||||
## Cas réels (2022-2025)
|
||||
|
||||
| Année | Composant | CVE | Remarques |
|
||||
|------|-----------|-----|-------|
|
||||
| 2022 | AWS Application Load Balancer | – | L'en-tête Host n'a été validé que sur la première requête ; corrigé par le patch du moteur de règles (divulgué par SecurityLabs). |
|
||||
| 2023 | Apache Traffic Server < 9.2.2 | CVE-2023-39852 | A permis le request smuggling via la réutilisation de connexion HTTP/2 lorsque `CONFIG proxy.config.http.parent_proxy_routing_enable` était activé. |
|
||||
| 2024 | Envoy Proxy < 1.29.0 | CVE-2024-2470 | Validation incorrecte de :authority après le premier flux a permis le request smuggling inter-locataires dans des mailles partagées. |
|
||||
|
||||
---
|
||||
|
||||
## Feuille de triche de détection
|
||||
|
||||
1. Envoyer deux requêtes dans la **même** connexion TCP/TLS avec des en-têtes Host ou :authority différents.
|
||||
2. Observer si la deuxième réponse provient du premier hôte (sûr) ou du deuxième hôte (vulnérable).
|
||||
3. Dans Burp : `Repeat → keep-alive → Send → Follow`.
|
||||
4. Lors de tests HTTP/2, ouvrir un flux **dédié** (ID 1) pour un hôte bénin, puis multiplexe un deuxième flux (ID 3) vers un hôte interne et rechercher une réponse.
|
||||
|
||||
---
|
||||
|
||||
## Références
|
||||
|
||||
* PortSwigger Research – *HTTP/2: The Sequel is Always Worse* (Black Hat USA 2023)
|
||||
* Avis de sécurité Envoy CVE-2024-2470 – Validation incorrecte de l'autorité
|
||||
|
||||
{{#include ../banners/hacktricks-training.md}}
|
||||
|
||||
Loading…
x
Reference in New Issue
Block a user