Translated ['src/pentesting-web/http-connection-request-smuggling.md'] t

This commit is contained in:
Translator 2025-07-12 22:07:52 +00:00
parent 8d50742aaf
commit 713f875380

View File

@ -1,34 +1,83 @@
# HTTP-Verbindungsanfrage-Smuggling
# HTTP Connection Request Smuggling
{{#include ../banners/hacktricks-training.md}}
**Dies ist eine Zusammenfassung des Beitrags** [**https://portswigger.net/research/browser-powered-desync-attacks**](https://portswigger.net/research/browser-powered-desync-attacks)
**Diese Seite fasst zusammen, erweitert und aktualisiert** die wegweisende PortSwigger-Forschung zu [Browser-Powered Desync Attacks](https://portswigger.net/research/browser-powered-desync-attacks) und die anschließende Arbeit zum Missbrauch des HTTP/2-Verbindungsstatus. Sie konzentriert sich auf Schwachstellen, bei denen **ein Ursprung nur einmal pro TCP/TLS-Verbindung bestimmt wird**, was es einem Angreifer ermöglicht, Anfragen an einen anderen internen Host zu „schmuggeln“, sobald der Kanal eingerichtet ist.
## Verbindungsstatusangriffe <a href="#state" id="state"></a>
## Connection-State Attacks <a href="#state" id="state"></a>
### Validierung der ersten Anfrage
### First-request Validation
Bei der Weiterleitung von Anfragen könnten Reverse-Proxys von der **Host-Header** abhängen, um den Ziel-Backend-Server zu bestimmen, wobei oft auf eine Whitelist von Hosts zurückgegriffen wird, die den Zugriff erlauben. Es besteht jedoch eine Schwachstelle in einigen Proxys, bei der die Whitelist nur bei der ersten Anfrage in einer Verbindung durchgesetzt wird. Folglich könnten Angreifer dies ausnutzen, indem sie zunächst eine Anfrage an einen erlaubten Host stellen und dann über dieselbe Verbindung eine interne Seite anfordern:
```
Beim Routing von Anfragen könnten Reverse-Proxys von dem **Host** (oder **:authority** in HTTP/2) Header abhängen, um den Ziel-Backend-Server zu bestimmen, wobei oft auf eine Whitelist von Hosts zurückgegriffen wird, die den Zugriff erlauben. Es besteht jedoch eine Schwachstelle in einer Reihe von Proxys, bei der die Whitelist **nur bei der allerersten Anfrage in einer Verbindung durchgesetzt wird**. Folglich können Angreifer auf interne virtuelle Hosts zugreifen, indem sie zunächst eine erlaubte Anfrage senden und dann die gleiche zugrunde liegende Verbindung wiederverwenden:
```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
```
### First-request Routing
In einigen Konfigurationen kann ein Front-End-Server den **Host-Header der ersten Anfrage** verwenden, um das Back-End-Routing für diese Anfrage zu bestimmen, und dann alle nachfolgenden Anfragen von derselben Client-Verbindung dauerhaft an dieselbe Back-End-Verbindung weiterleiten. Dies kann wie folgt demonstriert werden:
```
Viele HTTP/1.1 Reverse Proxies ordnen eine ausgehende Verbindung zu einem Back-End-Pool **ausschließlich basierend auf der ersten Anfrage, die sie weiterleiten**. Alle nachfolgenden Anfragen, die über denselben Front-End-Socket gesendet werden, werden stillschweigend wiederverwendet, unabhängig von ihrem Host-Header. Dies kann mit klassischen [Host header attacks](https://portswigger.net/web-security/host-header) wie Passwortzurücksetzungsvergiftung oder [web cache poisoning](https://portswigger.net/web-security/web-cache-poisoning) kombiniert werden, um SSRF-ähnlichen Zugriff auf andere virtuelle Hosts zu erhalten:
```http
GET / HTTP/1.1
Host: example.com
Host: public.example
POST /pwreset HTTP/1.1
Host: psres.net
Host: private.internal
```
Dieses Problem kann potenziell mit [Host-Header-Angriffen](https://portswigger.net/web-security/host-header) kombiniert werden, wie z.B. Passwortzurücksetzungsvergiftung oder [Web-Cache-Vergiftung](https://portswigger.net/web-security/web-cache-poisoning), um andere Schwachstellen auszunutzen oder unbefugten Zugriff auf zusätzliche virtuelle Hosts zu erlangen.
> [!TIP]
> In Burp Suite Professional ≥2022.10 können Sie **HTTP Request Smuggler → Connection-state probe** aktivieren, um diese Schwächen automatisch zu erkennen.
> [!HINWEIS]
> Um diese Schwachstellen zu identifizieren, kann die Funktion 'connection-state probe' im HTTP Request Smuggler genutzt werden.
---
## NEU in 2023-2025 Missbrauch der HTTP/2/3-Verbindungskohäsion
Moderne Browser **kohäsieren** routinemäßig HTTP/2- und HTTP/3-Anfragen auf einer einzigen TLS-Verbindung, wenn das Zertifikat, das ALPN-Protokoll und die IP-Adresse übereinstimmen. Wenn ein Frontend nur die erste Anfrage autorisiert, erbt jede nachfolgende kohäsierte Anfrage diese Autorisierung **selbst wenn der Host/:authority wechselt**.
### Ausnutzungsszenario
1. Der Angreifer kontrolliert `evil.com`, das auf denselben CDN-Edge-Knoten wie das Ziel `internal.company` aufgelöst wird.
2. Der Browser des Opfers hat bereits eine offene HTTP/2-Verbindung zu `evil.com`.
3. Der Angreifer bettet ein verstecktes `<img src="https://internal.company/…">` in seine Seite ein.
4. Da die Verbindungsparameter übereinstimmen, verwendet der Browser die **bestehende** TLS-Verbindung erneut und multiplexiert die Anfrage für `internal.company`.
5. Wenn das CDN/der Router nur die erste Anfrage validiert hat, wird der interne Host offengelegt.
PoCs für Chrome/Edge/Firefox sind in James Kettles Vortrag *“HTTP/2: The Sequel is Always Worse”* (Black Hat USA 2023) verfügbar.
### Werkzeuge
* **Burp Suite 2023.12** führte einen experimentellen **HTTP/2 Smuggler**-Einsprungspunkt ein, der automatisch versucht, Kohäsion und TE/CL-Techniken anzuwenden.
* **smuggleFuzz** (https://github.com/microsoft/smugglefuzz) Ein Python-Framework, das 2024 veröffentlicht wurde, um Frontend-/Backend-Desynchronisationsvektoren über HTTP/2 und HTTP/3 zu brute-forcen, einschließlich Verbindungsstatus-Permutationen.
### Minderung
* Immer **Host/:authority bei jeder Anfrage erneut validieren**, nicht nur bei der Verbindungsherstellung.
* Deaktivieren oder streng einschränken **der Ursprungs-Kohäsion** auf CDN-/Lastenausgleichsschichten (z. B. `http2_origin_cn` in NGINX ausschalten).
* Separate Zertifikate oder IP-Adressen für interne und externe Hostnamen bereitstellen, damit der Browser sie nicht rechtlich kohäsieren kann.
* Bevorzugen Sie **connection: close** oder `proxy_next_upstream` nach jeder Anfrage, wo es praktikabel ist.
---
## Anwendungsfälle aus der Praxis (2022-2025)
| Jahr | Komponente | CVE | Anmerkungen |
|------|-----------|-----|-------------|
| 2022 | AWS Application Load Balancer | | Host-Header nur bei der ersten Anfrage validiert; durch Patchen der Regel-Engine behoben (offengelegt von SecurityLabs). |
| 2023 | Apache Traffic Server < 9.2.2 | CVE-2023-39852 | Ermöglichte Request Smuggling über HTTP/2-Verbindungswiederverwendung, wenn `CONFIG proxy.config.http.parent_proxy_routing_enable` gesetzt war. |
| 2024 | Envoy Proxy < 1.29.0 | CVE-2024-2470 | Unzureichende Validierung von :authority nach dem ersten Stream ermöglichte cross-tenant Request Smuggling in gemeinsamen Meshes. |
---
## Erkennungs-Checkliste
1. Senden Sie zwei Anfragen in derselben TCP/TLS-Verbindung mit unterschiedlichen Host- oder :authority-Headern.
2. Beobachten Sie, ob die zweite Antwort vom ersten Host (sicher) oder vom zweiten Host (anfällig) stammt.
3. In Burp: `Repeat → keep-alive → Send → Follow`.
4. Beim Testen von HTTP/2 öffnen Sie einen **dedizierten** Stream (ID 1) für einen harmlosen Host, multiplexieren dann einen zweiten Stream (ID 3) zu einem internen Host und suchen nach einer Antwort.
---
## Referenzen
* PortSwigger Research *HTTP/2: The Sequel is Always Worse* (Black Hat USA 2023)
* Envoy Security Advisory CVE-2024-2470 Unzureichende Autoritätsvalidierung
{{#include ../banners/hacktricks-training.md}}