HTTP/2 Desync: Die nächste Generation des Request Smuggling

Entdecken Sie, wie das binäre Framing von HTTP/2 neue Smuggling-Vektoren einführt, die herkömmliche Abwehrmechanismen umgehen. Von H2C-Smuggling bis Header-Name-Ausnutzung – diese Angriffe funktionieren, wenn HTTP/1.1-Schutzmaßnahmen versagen.

Einführung: Das falsche Versprechen der HTTP/2-Sicherheit

HTTP Request Smuggling besteht seit 2005 und nutzt Inkonsistenzen in der Interpretation von Request-Grenzen durch Server aus. Mit dem Aufkommen von HTTP/2 und seinem binären Framing-Protokoll glaubten viele, diese Schwachstellen vollständig beseitigt zu haben. Schließlich verwendet HTTP/2 explizite Längenfelder für jeden Datenrahmen, was die Mehrdeutigkeit bei Content-Length- und Transfer-Encoding-Headern eliminiert.

Leider erwies sich diese Annahme als voreilig. Das Downgrade von HTTP/2 – bei dem ein Front-End-Server mit Clients HTTP/2 spricht, Requests aber vor Weiterleitung in HTTP/1.1 umschreibt – ermöglicht eine Reihe von Angriffen, inklusive Request Smuggling. Diese Protokollübersetzung schafft eine gefährliche Lücke, in der die Sicherheitsgarantien von HTTP/2 schwinden und raffinierte Angreifer die Übergänge zwischen den Protokollen ausnutzen können.

Dieser Artikel verfolgt die Entwicklung des Request Smuggling in die HTTP/2-Ära und zeigt, wie Angreifer H2C-Smuggling, CRLF-Injection und Header-Manipulation nutzen, um moderne Sicherheitskontrollen zu umgehen.

Grundlagen des HTTP/2 Request Smuggling verstehen

Warum HTTP/2 eigentlich immun sein sollte

HTTP/2-Anfragen werden nicht als Klartextnachrichten gesendet, sondern in binärem Format umgewandelt. Die Anfrage wird als “Frames” dargestellt, wobei jeder Frame ein explizites Längenfeld hat, das den Server angibt, wie viele Bytes gelesen werden sollen. Diese Architektur beseitigt die Mehrdeutigkeit zwischen Content-Length und Transfer-Encoding, die HTTP/1.1 anfällig machte.

HTTP Request Smuggling ist kein echtes Protokoll-Schwachstelle in HTTP/1.1, sondern entsteht durch die Existenz zweier verschiedener Möglichkeiten, das Ende einer Anfrage zu kennzeichnen (Content-Length und Transfer-Encoding). Das einheitliche, unmissverständliche Längenmechanismus von HTTP/2 sollte diese Angriffe theoretisch verhindern.

Das Downgrade-Problem

In der Realität sind reine HTTP/2-Umgebungen noch relativ selten. Obwohl HTTP/2 weit verbreitet ist, gibt es noch Legacy-Back-End-Server, die ausschließlich HTTP/1.1 verwenden, da das neuere Protokoll in Unternehmen noch relativ neu ist. Das führt zu Mischumgebungen, in denen HTTP/2-Frontends mit HTTP/1.1-Backends kommunizieren.

Die HTTP/2-Spezifikation empfiehlt, dass Anfragen mit Transfer-Encoding-Header entweder entfernt oder vom Front-End-Server blockiert werden. Wenn der Front-End-Server diese Vorgabe ignoriert und die Anfrage mit Header durchlässt, wird die Anfrage auf HTTP/1.1 zurückgestuft und an einen Back-End-Server weitergeleitet, der Chunked-Encoding unterstützt. Hier entstehen wieder Schwachstellen beim Request Smuggling.

Angriffsvektoren: H2.CL und H2.TE Desync

HTTP/2 zu Content-Length (H2.CL) Angriffe

Bei H2.CL-Angriffen leitet der Front-End-HTTP/2-Server einen Content-Length-Header weiter, der im HTTP/2-Kontext eigentlich nicht existieren sollte. Beim Downgrade auf HTTP/1.1 nutzt der Back-End-Server diesen Header, um Request-Grenzen zu bestimmen, was Smuggling-Möglichkeiten schafft.

Durch das Umleiten von JavaScript-Includes könnten Angreifer bösartigen JavaScript-Code ausführen, um Nutzerkonten zu kompromittieren und Passwörter sowie Kreditkartendaten zu stehlen. Bei wiederholtem Angriff könnten sie schrittweise alle aktiven Nutzer der Seite kompromittieren, ohne dass Nutzerinteraktion erforderlich ist. Netflix war von genau dieser Schwachstelle betroffen, was in CVE-2021-21295 und einer maximalen Belohnung von 20.000 US-Dollar resultierte.

HTTP/2 zu Transfer-Encoding (H2.TE) Angriffe

Die RFC besagt, dass Nachrichten mit verbindungsspezifischen Header-Feldern als fehlerhaft behandelt werden müssen. Eines dieser Felder ist Transfer-Encoding. Der Application Load Balancer von Amazon Web Services ignorierte diese Vorgabe und akzeptierte Requests mit Transfer-Encoding, was die Ausnutzung bei fast jeder Website ermöglichte via H2.TE-Desync.

Diese Angriffe zeigen, wie selbst große Cloud-Anbieter HTTP/2 falsch implementieren können, wodurch Millionen von Websites verwundbar bleiben.

H2C-Smuggling: Der Angriff auf das klare Text-Verbindungs-Upgrade

Was ist H2C-Smuggling?

H2C-Smuggling ist eine der innovativsten Angriffstechniken auf HTTP/2, die in den letzten Jahren entdeckt wurde. Im September 2020 von Bishop Fox-Forschern vorgestellt, nutzt H2C-Smuggling Front-Ends aus, die H2C-unaware sind, um einen Tunnel zu Back-End-Systemen zu erstellen. Damit können Angreifer Front-End-Regeln umgehen und interne HTTP-Header ausnutzen.

Das Upgrade von HTTP/1.1 auf HTTP/2 (h2c) ermöglicht es, eine Umgehung der Edge-Proxy-Zugriffskontrollen zu erreichen. Diese Technik wurde 2020 von PortSwigger als die Top-Web-Hacking-Technik gewählt.

Funktionsweise des Angriffs

Der Angriff nutzt die Möglichkeit, HTTP-Verbindungen von HTTP/1.1 auf HTTP/2 zu upgraden. Das h2c-Smuggling erlaubt es Angreifern, Proxy-Kontrollen zu umgehen, indem sie HTTP/1.1-Upgrade-Anfragen via TLS an Back-End-Server senden. Diese Upgrades, die über TLS erfolgen, verletzen oft die Spezifikation, werden aber von vielen Servern akzeptiert.

h2cSmuggler schleust HTTP-Verkehr an unsichere Edge-Server-Proxy-Konfigurationen vorbei, indem er HTTP/2-Klartext-Kommunikation mit h2c-kompatiblen Back-End-Servern herstellt und so Proxy-Regeln umgeht.

Auswirkungen in der Praxis

Untersuchungen zu H2C-Smuggling bei Bug-Bounty-Zielen zeigten, dass sich Authentifizierungs-, Routing- und WAF-Umgehungen bei verschiedenen Cloud-Anbietern realisieren lassen. Selbst Anbieter, die anfänglich immun schienen, waren anfällig, wenn die Technik gründlich angewandt wurde.

Mit dieser Art von Request Smuggling können beliebig viele Requests via HTTP/2-Multiplexing gesendet werden. Das ermöglicht Angriffe wie das Fälschen interner Header, Zugriff auf eingeschränkte Admin-Endpunkte und manchmal Host-Header-SSRF, was weitere Bewegungen im Netzwerk erlaubt.

CRLF-Injection in HTTP/2-Headern

Das binäre Protokoll-Problem

Das binäre Design von HTTP/2 sollte CRLF (Carriage Return Line Feed)-Injection-Angriffe, die bei HTTP/1.1 häufig sind, verhindern. Aufgrund der binären Natur gibt es jedoch mehrere Wege, Schutzmaßnahmen zu umgehen. CRLF-Injection, die Header-Smuggling ermöglicht, ist ein primärer Vektor.

Die HTTP/2-Spezifikation für Header-Werte schreibt vor, dass ein Feldwert keine Nullzeichen (ASCII NUL, 0x00), Zeilenfeed (ASCII LF, 0x0a) oder Wagenrücklauf (ASCII CR, 0x0d) enthalten darf. Werden diese Zeichen in einem Wert verwendet, sollte die Anfrage als fehlerhaft behandelt werden. Viele Server setzen diese Vorgabe nicht konsequent um.

Exploitation-Technik

Das Transfer-Encoding muss in den Wert eines beliebigen Headers mit CRLF-Sequenz injiziert werden, z.B. Foo: bar\r\nTransfer-Encoding: chunked. Es muss ein doppelter Header vorhanden sein.

Beim Downgrade auf HTTP/1.1 interpretiert der Server die CRLF-Zeichen wörtlich und erstellt neue Header-Linien, die im ursprünglichen HTTP/2-Request nicht existierten. Der Back-End-Server sieht dann einen Transfer-Encoding-Header, der alle Front-End-Sicherheitskontrollen umgeht.

Bei Angriffen auf Request Smuggling in HTTP/2 zu HTTP/1.1 ist CRLF-Injection oft notwendig. Da HTTP/2 binär ist, interpretiert der Front-End-Server bestimmte Binärzeichen als Zeilenumbrüche, was Angreifern erlaubt, zusätzliche Header zu injizieren und die umgeschriebene Anfrage zu manipulieren.

Response-Queue-Poisoning und Session-Hijacking

Verständnis von Response Desynchronization

Eine der schwerwiegendsten Folgen von Desync-Angriffen ist Response Queue Poisoning. Dabei werden sensible Daten, Sitzungsinformationen anderer Nutzer oder dauerhafte Kompromittierungen durch das Smuggling verursacht.

Beim Response Queue Poisoning wird eine zusätzliche Anfrage nach der ersten eingeschleust. Diese löst die Response-Queue-Desynchronisierung aus, sodass Nutzer Antworten erhalten, die eigentlich zu anderen gehören.

Session-Diebstahl in der Praxis

Mit Response Queue Desynchronization und klassischen Request Smuggling-Techniken können Angreifer Anfragen legitimer Nutzer abfangen, was zu Kontenübernahmen und Zugriff auf sensible Daten führt.

Der Ablauf: Angreifer senden eine gezielt präparierte Anfrage, die die Desynchronisierung auslöst. Danach werden legitime Nutzeranfragen an vom Angreifer kontrollierte Prefixe angehängt. So können Session-Cookies, Authentifizierungstoken und andere sensible Daten abgegriffen werden.

Client-seitige Desynchronisierung: Ein neues Forschungsfeld

Über die Server-zu-Server-Angriffe hinaus

Eine der neuesten Entwicklungen in der Desync-Forschung ist die Entdeckung client-seitiger Desynchronisierung (CSD). Dabei wird der Browser des Opfers dazu gebracht, seine Verbindung zur verwundbaren Website zu desynchronisieren. Das unterscheidet sich vom klassischen Request Smuggling, bei dem die Verbindung zwischen Front-End- und Back-End-Server betroffen ist.

Diese Entwicklung zeigt, dass sogar Architekturen, die Nutzerverbindungen isolieren sollen, verwundbar sind, da der Angriff die Verbindung des Clients selbst betrifft.

Erweiterte Techniken: Header-Name-Ausnutzung und Encoding-Tricks

Schwache Header-Validierung ausnutzen

Cloudflare setzte nach dem 100. Header eine schwächere Validierung ein, bevor Anfragen an Upstream-Server weitergeleitet werden. Wenn ein HTTP-Server Tabulatoren oder Leerzeichen in Headern akzeptiert, kann dies zu Request/Response-Desynchronisierung führen.

Obwohl Doppelpunkte, Zeilenumbrüche und A-Z-Zeichen weiterhin verboten sind, reichen Leerzeichen und Tabs in manchen Fällen aus, um die Attacke auszuführen. Um HTTP-Desynchronisierung bei Keep-Alive-Verbindungen zu triggern, kann man z.B. “transfer-encoding : chunked” (mit Leerzeichen vor dem Doppelpunkt) verwenden.

Neue Angriffsvarianten

Forschung entdeckt ständig neue Desync-Techniken: 0.CL-Angriffe mit Content-Length-Headern, Expect-Header-Manipulation mit 100-Continue, sowie Protokoll-Ketten aus HTTP/2, HTTP/1.1 und WebSocket-Upgrades. Das Thema ist noch wenig erforscht, und Sicherheitsforscher entdecken laufend neue Exploitation-Methoden.

Aktuelle Schwachstellen und Praxisbeispiele

Bedeutende CVEs

Mehrere kritische Schwachstellen zeigen die anhaltende Bedrohung:

CVE-2023-25690 betrifft Apache HTTP Server, bei dem mod_proxy Rewrite-Regeln für Request-Splitting und Smuggling ausgenutzt werden konnten, behoben in Version 2.4.56. CVE-2023-25950 betrifft HAProxy 2.⁷⁄₂.6, bei dem der HTX-Parser pipelined Requests falsch handhabte. CVE-2022-41721 betrifft Go’s MaxBytesHandler, bei dem Rest-Body-Bytes als HTTP/2-Frames interpretiert wurden, was Cross-Protokoll-Smuggling ermöglichte.

Apache HTTP Server bis Version 2.4.63 enthielt Schwachstellen, die Man-in-the-Middle-Angreifern erlaubten, HTTP-Desynchronisationsangriffe durchzuführen und HTTP-Sitzungen während TLS-Upgrades zu kapern. CVE-2025-49812 zeigte, dass sogar verschlüsselte Verbindungen verwundbar sind.

Auswirkungen auf Bug Bounty

Im Jahr 2024 wurde die Resilienz gegen TE.0- und funky chunks-Schwachstellen kritisch. 2025 wurde die Immunität gegen Expect- und 0.CL-Angriffe bestätigt, mit Belohnungen über 350.000 US-Dollar. Diese hohen Summen spiegeln die Schwere der HTTP/2-Desync-Schwachstellen wider.

Erkennungs- und Testwerkzeuge

Professionelle Testansätze

TRACE-Anfragen sind sehr hilfreich bei der Analyse von Smuggling-Schwachstellen. Die Antwort zeigt genau, was vom Back-End empfangen wird, inklusive modifizierter oder hinzugefügter Header sowie Protokoll-Änderungen wie das Downgrade von HTTP/2 auf HTTP/1.1.

Mehrere Tools unterstützen Sicherheitsexperten bei der Identifikation:

Burp Request Smuggler seit v1.26 testet automatisch H2.TE/H2.CL und versteckte ALPN-Unterstützung – aktivieren Sie “HTTP/2 probing” in den Extension-Optionen. h2cSmuggler ist ein Python-Proof-of-Concept von Bishop Fox, um den Cleartext-Upgrade-Angriff zu automatisieren.

Das Open-Source-Tool http2smugl ermöglicht es Teams, Load Balancer auf HTTP/2 Request Smuggling-Schwachstellen zu prüfen – kostenlos und nützlich für Bug-Bounty-Recherchen.

Prävention und Gegenmaßnahmen

Hauptschutz: End-to-End HTTP/2

Um Request Smuggling zu verhindern, verwenden Sie HTTP/2 durchgängig und deaktivieren Sie Downgrades, wo möglich. HTTP/2 verfügt über einen robusten Mechanismus zur Bestimmung der Request-Länge und schützt bei durchgängiger Nutzung vor Smuggling.

Stellen Sie sicher, dass Verbindungen end-to-end mit HTTP/2 laufen und keine Downgrades erfolgen. Bei Servern, die Downgrades unterstützen, sollten Anfragen mit übertriebenen Headern, die die Request-Größe angeben, abgelehnt werden.

Wenn Downgrades unvermeidbar sind

Wenn Downgrades notwendig sind, validieren Sie die umgeschriebene Anfrage strikt nach HTTP/1.1. Zusätzliche Maßnahmen:

Ablehnen Sie mehrdeutige Requests mit sowohl Content-Length als auch Transfer-Encoding, sowohl im Front-End als auch im Back-End. Vermeiden Sie die gemeinsame Nutzung von Verbindungen zwischen Front- und Back-End, um Out-of-Sync-Anfragen zu verhindern. Setzen Sie eine WAF ein, die Exploits erkennt und blockiert. Verwenden Sie auf beiden Seiten denselben Server, um Unterschiede bei der Interpretation zu vermeiden.

Spezifische Maßnahmen gegen H2C

Schutz gegen H2C-Smuggling ist einfach: Entfernen oder hartkodieren Sie den Upgrade-Header am Rand, außer bei WebSockets.

Pflegen Sie eine Defense-in-Depth-Strategie, reduzieren Sie die Bedeutung smuggled-Headers in Ihrer Architektur, und bereiten Sie sich vor, verdächtige Requests zu erkennen und abzulehnen.

Verhinderung von CRLF-Injection

Blockieren Sie Header, die bestimmte Sequenzen enthalten, z.B. CRLF. Server sollten die Spezifikation strikt umsetzen und CRLF-Zeichen in Header-Werten verbieten.

Zukunftsausblick und aufkommende Trends

Die Persistenz von HTTP/1.1

HTTP/1.1 ist besonders anfällig für Request Smuggling, weil seine Nachrichten-Grenzen auf verschiedene Weisen ausgedrückt werden können. Viele Server wurden unterschiedlich programmiert, um diese Regeln zu interpretieren. Um Kompatibilität zu gewährleisten, akzeptieren viele Implementierungen auch leicht fehlerhafte Requests.

Request Smuggling bleibt relevant, weil viele Anwendungen noch auf legacy HTTP/1.1 setzen. Patchen ist schwierig, da die Unterstützung für HTTP in verschiedenen Serverumgebungen uneinheitlich ist.

Laufende Forschung

Smuggling-Angriffe, inklusive Desync, sind große Bedrohungen für das moderne Web. Forscher untersuchen weiterhin die Interaktion zwischen Protokollen, und neue Angriffsmethoden werden wahrscheinlich auftauchen.

Fazit

HTTP/2 Desync-Angriffe sind eine raffinierte Weiterentwicklung des Request Smuggling, die die Lücke zwischen Protokollversionen ausnutzt. Obwohl das binäre Framing von HTTP/2 die Mehrdeutigkeit beseitigen sollte, führt das häufige Downgrade auf HTTP/1.1 die Schwachstellen wieder ein.

Organisationen müssen erkennen, dass die reine Nutzung von HTTP/2 am Rand keinen vollständigen Schutz bietet. Wirkliche Sicherheit erfordert eine durchgängige HTTP/2-Implementierung, strikte Header-Validierung, sorgfältigen Umgang mit Protokoll-Upgrades und ständige Wachsamkeit gegenüber neuen Angriffstechniken.

Da die Web-Infrastruktur sich weiterentwickelt, bleibt die Interaktion zwischen verschiedenen Protokollversionen ein attraktives Ziel für Angreifer. Sicherheitsmaßnahmen sollten das Downgrade so weit wie möglich vermeiden, robuste Header-Validierung implementieren und mit aktuellen Forschungsergebnissen Schritt halten.

Wichtige Erkenntnisse:

HTTP/2-Downgrades führen zu Schwachstellen im Request Smuggling, die bei reinem HTTP/2 nicht bestehen
H2C-Smuggling umgeht Edge-Proxy-Kontrollen durch Ausnutzung von Klartext-Upgrade-Mechanismen
CRLF-Injection in HTTP/2-Headern kann zusätzliche Header an Front-End-Validierungen vorbeischmuggeln
End-to-End HTTP/2 ist der effektivste Schutz gegen diese Angriffe
Laufende Forschung entdeckt ständig neue Exploit-Techniken bei Protokoll-Interaktionen