HTTP Connection Request Smuggling

Reading time: 5 minutes

tip

Lernen & üben Sie AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
Lernen & üben Sie GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE) Lernen & üben Sie Azure Hacking: HackTricks Training Azure Red Team Expert (AzRTE)

Unterstützen Sie HackTricks

Diese Seite fasst zusammen, erweitert und aktualisiert die wegweisende PortSwigger-Forschung zu 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

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 wie Passwortzurücksetzungsvergiftung oder 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)

JahrKomponenteCVEAnmerkungen
2022AWS Application Load Balancer–Host-Header nur bei der ersten Anfrage validiert; durch Patchen der Regel-Engine behoben (offengelegt von SecurityLabs).
2023Apache Traffic Server < 9.2.2CVE-2023-39852Ermöglichte Request Smuggling über HTTP/2-Verbindungswiederverwendung, wenn CONFIG proxy.config.http.parent_proxy_routing_enable gesetzt war.
2024Envoy Proxy < 1.29.0CVE-2024-2470Unzureichende 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

tip

Lernen & üben Sie AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
Lernen & üben Sie GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE) Lernen & üben Sie Azure Hacking: HackTricks Training Azure Red Team Expert (AzRTE)

Unterstützen Sie HackTricks