# HTTP Connection Request Smuggling

{{#include ../banners/hacktricks-training.md}}

**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.

## Connection-State Attacks <a href="#state" id="state"></a>

### First-request Validation

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.example

GET /admin HTTP/1.1
Host: internal-only.example
```
### First-request Routing

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: public.example

POST /pwreset HTTP/1.1
Host: private.internal
```
> [!TIP]
> In Burp Suite Professional ≥2022.10 können Sie **HTTP Request Smuggler → Connection-state probe** aktivieren, um diese Schwächen automatisch zu erkennen.

---

## 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}}