Das Ende von HTTP/1.1: Request Smuggling unter der Lupe
Pentest Factory verfolgt aktiv die neuesten Entwicklungen im Bereich Cybersecurity. Hierbei ist vor allem der Unterbereich „Web Security“ ein Schwerpunkt, da ein Großteil an Unternehmen darauf setzt, ihre Produkte als Webanwendungen zu verkaufen.
Hierbei wurde am 6. August auf der Black Hat USA 2025 Hacker Konferenz ein Präsentation von James Kettle gehalten, die die Sicherheit des HTTP/1.1 Protokolls maßgeblich in Frage stellt. Dieses Protokoll bildet die Grundlage der gesamten Kommunikation zwischen Webbrowsern und Webseiten – und ist, wie wir im Verlauf dieses Artikels diskutieren, bereits im Design fehlerhaft. Eine neue Klasse an Schwachstellen, bedroht die Sicherheit von Millionen von Nutzern und zeitnahes Handeln ist erforderlich.
Request Smuggling - Eine vergessene Technik aus dem Jahr 2004
Bereits 2004 stellte die „Watchfire Corporation“ in einem Forschungsartikel eine neue Angriffstechnik „HTTP Request Smuggling“ vor. Hierbei wurde beschrieben, dass es Mehrdeutigkeiten in der Verarbeitung der Längenangaben eines HTTP-Requests geben kann, wenn dieser Request von mehr als nur einem Server verarbeitet wird. Letzteres ist genau dann der Fall, wenn ein Load Balancer die Anfrage eines Clients entgegennimmt und diese anschließend an ein Backend weiterleitet („Reverse Proxying“). Auf Seite 10 des Papers wird erläutert, dass eine solche Mehrdeutigkeit u.a. auftreten kann, wenn ein Angreifer anstelle eines einzelnen Content-Length Headers, zwei solche Header mit verschiedenen Längenangaben absendet. Load Balancer und Backend nehmen unterschiedliche Header als korrekte Header an – was dazu führt, dass die beiden Server unterschiedliche Versionen der initialen Anfrage verarbeiten. Hierbei stellt der Angriff mit zwei Content-Length Headern eine von vielen Techniken dar, mit der sich die Längenbegrenzung eines Requests manipulieren lässt.
Die Folgen einer solchen Diskrepanz zwischen Frontend und Backend Server sind vielfältig:
• Es können Anfragen im Request Body „versteckt“ werden – die dann vom Backend-Server separat interpretiert werden. Dies hat zur Folge, dass der Backend-Server eine zusätzliche Antwort zurückliefert. Diese Antwort stört die sonst eindeutige 1:1 Zuordnung von Anfrage und Antwort – was zu einem „Desync“ führen kann: Die Clients einer Webseite erhalten die Antworten von anderen Nutzern.
• Falls der Frontend Server Caching betreibt, ist es möglich, dass für eine statische Ressource eine fremde Antwort des Backends gecached wird. Dies können Angreifer ausnutzen, um im schlimmsten Fall bösartiges JavaScript (-> XSS) in den Cache zu speichern.
• Das Request Smuggling ermöglich das Umgehen von Zugangsbeschränkungen die im Frontend implementiert sind
Request Smuggling als gegenwärtiges Problem
Während die Forschung aus dem Jahr 2004 in Vergessenheit geraten ist, hat James Kettle erkannt, dass diese Schwachstellen nicht nur mit alten Sun Webservern ausnutzbar sind, sondern auch heutige Webanwendungen mit modernen Frameworks und Servern hierfür anfällig sind. Dabei hat er von 2019 bis 2025 eine Reihe an Techniken herausgearbeitet, mit denen Diskrepanzen in der Längenverarbeitung von Webservern zu erfolgreichem Request-Smuggling führen.
Hinweis: Viele dieser Techniken sind kompliziert und erfordern ein tiefgehendes Verständnis der HTTP Protokollimplementierung verschiedener Hersteller, um sie im Detail zu verstehen. Wir sehen daher davon ab, in diesem Artikel alle Techniken ausführlich zu erklären. Die folgende Liste dient hauptsächlich dazu, zu veranschaulichen, dass HTTP Request Smuggling kein isolierter Einzelfall ist, sondern das Resultat eines kaputten, unsicheren Designs von HTTP/1.1.
- 2019 – CL.TE, TE.CL: Das Senden von Anfragen mit Content-Length und Transfer-Encoding Headern führt zu Unklarheiten in der Längenverarbeitung der Anfrage. Content-Length gibt hierbei die Länge des Requests als dezimale Ganzzahl an in Byte. Transfer-Encoding gibt die Länge von einzelnen Request Body „Chunks“ als hexadezimale Ganzzahl an.
- 2021 – H2.CL, H2.TE: James Kettle erkennt, dass HTTP/2 Anfragen zwischen Client und Frontend oft downgegraded werden müssen, da die Backends nur HTTP/1.1 sprechen. Beim Downgrade werden unterschiedliche Längenangaben gemacht (z.B. entweder mit Content-Length oder mit Transfer-Encoding) – es kommt zu Mehrdeutigkeiten aufgrund des Downgrade-Verhaltens.
- 2022 – CL.0, H2.0: Zwei serverseitige Varianten, bei denen der Content-Length Header oder die HTTP/2 Länge vom Back-End ignoriert werden, das Frontend diese jedoch parsed
- 2022 – Client-side-Desync:
James Kettle erkennt, dass es möglich ist, einen fremden Browser dazu zu bewegen, eine Anfrage zu versenden, die vom Server als zwei verschiedene Antworten interpretiert wird. Somit erfolgt das Request Smuggling nicht mehr zwischen Frontend und Backend, sondern zwischen Browser und Reverse Proxy. Der Browser erhält eine manipulierte Antwort als Resultat der geschmuggelten Anfrage.
- 2024 – TE.0: Eine Variante bei der das Frontend das Transfer-Encoding parsed, das Backend jedoch nicht
- 2025 – TE.TE: Zwei Varianten bei denen eine Diskrepanz in der Verarbeitung von TE Chunk Extensions zu Mehrdeutigkeit führt: Entweder wird ein Zeichen wie \n als Line Terminator interpretiert, oder es wird ignoriert
- 2025 – 0.CL: Zuvor als unmöglich geglaubte Technik (wegen Problemen mit serverseitigem Timeout) ist in Randfällen (Windows Server mit reservierten Verzeichnisnamen) doch möglich mittels doppeltem CL.0 Desync
Betrachtet man den zeitlichen Verlauf dieser Veröffentlichungen, so wird klar, dass die nächste Technik nur darauf wartet entdeckt zu werden. Zusammenfassend lässt sich sagen – überall dort wo HTTP/1.1 direkt oder indirekt zwischen Frontend und Backend (also „upstream“) zum Einsatz kommt, lassen sich mehrdeutige Längenangaben in HTTP machen, die ultimativ dazu führen, dass Webserver den eingehenden Request unsicher verarbeiten.
Upstream HTTP/2 als besserer Nachfolger
HTTP/2 definiert HTTP Streams über einen neuen Mechanismus, bei dem ein Stream aus mehreren einzelnen Frames besteht. Beim Senden des letzten übertragenen Frames wird ein „END_STREAM“ Flag übermittelt, dass den Stream terminiert. HTTP/2 besitzt als Binärprotokoll somit eine eigene, eindeutige Methode das Ende eines HTTP Streams zu signalisieren. Ein Angreifer kann das END_STREAM Flag nicht mit anderen Längenangaben überlagern und somit Request Smuggling erreichen.
Laut RFC 7540 (HTTP/2), Section 8.1.2.6:
„A request or response is also malformed if the value of a content-length header field does not equal the sum of the DATA frame payload lengths that form the body. […] Intermediaries that process HTTP requests or responses (i.e., any intermediary not acting as a tunnel) MUST NOT forward a malformed request or response.“
Wenn somit ausschließlich HTTP/2 auf dem Kommunikationsweg zwischen Frontend und Backend („upstream“) gesprochen wird, so lässt sich eine Verwirrung von Längenangaben weitestgehend verhindern und die Schwachstellenkategorie „Request Smuggling“ unterbinden.
Lösungen in der Praxis
Auf Seite der Reverse Proxies sehen wir, dass fast alle Produkte sehr ähnliche oder die gleichen Funktionen anbieten und ein Wechsel auf einen Reverse Proxy mit HTTP/2 Upstream Support keinen größeren Aufwand darstellen sollten. Zur Zeit der Veröffentlichung dieses Fachartikels konnten wir folgenden Support für größere Produkte feststellen:
- Caddy: Vollständiger Upstream HTTP/2 Support, mittels „transport“ Direktive, Support von H2 und H2C
- HAProxy: Vollständiger Upstream Support über „proto“ Direktive
- Traefik: Vollständiger Support (siehe https://github.com/traefik/traefik/issues/11985#issuecomment-3182524614)
- Apache als Reverse Proxy: Via mod_proxy_http2 Jedoch wird das Modul als „experimental“ betitelt und sollte mit Vorsicht verwendet werden.
- Nginx: Aktuell kein HTTP/2 Support für Upstream Direktiven (z.B. proxy_pass) (siehe ngx_http_proxy_module.html#proxy_http_version)
- Squid: Aktuell kein HTTP/2 Support – Features sind in Entwicklung – kein ETA (https://wiki.squid-cache.org/Features/HTTP2)
- Varnish: Aktuell kein HTTP/2 für Upstream Direktiven, ausschließlich das Hitch Frontend kann HTTP/2 via ALPN anbieten
Auf der Seite des Backends kommt es hier auf die eingesetzte Technologie und den Backend Server an:
- Apache Tomcat (Spring Boot, JSP, Java) – Support via Upgrade Protocol component (UpgradeProtocol className=“org.apache.coyote.http2.Http2Protocol“)
- Nginx – Nginx stellt als Anwendungsserver HTTP/2 Support bereit (somit Support für diverse Module – z.B. PHP)
- Apache – Support via mod_http2 Modul
- .NET via IIS – Ab IIS 10.0 wird HTTP/2 unterstützt
- Node.JS Express Framework – Aktuell kein Support (aber aktive Diskussion https://github.com/expressjs/express/issues/5462) – Möglichkeit andere Middleware für HTTP/2 zu verwenden, verschiedene experimentelle Pakete existieren
- Django via uWSGI: Aktuell kein HTTP/2 Support bekannt oder dokumentiert (https://uwsgi-docs.readthedocs.io/en/latest/Options.html)
- Django via gUnicorn: Aktuell kein HTTP/2 Support bekannt – Github Issues sind closed (https://github.com/benoitc/gunicorn/issues/3304)
- Ruby on Rails via Puma / Unicorn / Thin Server: Trotz diverser Diskussionen ist die Antwort aktuell, dass RoR mittels den genannten Servern ausschließlich HTTP/1.1 nutzt. Hieran gibt es kein aktives Development (https://github.com/puma/puma/issues/454)
Fazit
Aktuell ist es nicht ganz einfach eine Kombination aus Load Balancer und Backend zu finden, die HTTP/2 zu 100% unterstützt. Gleichzeitig ist die Schwachstellenkategorie „Request Smuggling“ aufgrund ihrer Komplexität noch nicht im „Mainstream“ angekommen und nur wenige Angreifer kennen sich mit der Technik aus. Auf technischer Ebene sind die Angriffe aufwändig und erfordern Detailwissen. Wir empfehlen in den nächsten Monaten eine Strategie zu entwickeln, wie das Upgrade auf Upstream HTTP/2 durchgeführt werden kann. Wir gehen davon aus, dass in den nächsten Jahren weitere Angriffstechniken veröffentlicht werden und mit verbesserten Tools auch die Ausführung solcher Angriffe einfacher und zugänglicher wird.
Fragen Sie bei den Maintainern von Softwareprojekten an, wie eine Kompatibilität zu HTTP/2 ermöglicht werden kann. Jede Konversation die diese Problematik aufgreift ist sinnvoll und trägt zu einer Härtung dieser Anwendungen bei. Wir gehen davon aus, dass der Druck auf größere Softwarehersteller kontinuierlich ansteigen wird, was das Thema Request Smuggling angeht. Im besten Fall führt dies dazu, dass unsere zuvor aufgeführte Liste immer mehr „grüne“ Einträge erhalten wird.
Haben Sie Fragen?
Sind Sie sich unsicher, ob Ihre Anwendung anfällig ist für aktuelle Request Smuggling Schwachstellen? Im Rahmen eines Pentests prüfen wir Ihr System ausführlich auf diese Schwachstellen. Wir verwenden die neuesten Tools von James Kettle und PortSwigger, um Request Smuggling zu detektieren, sowie exemplarisch auszunutzen. Nutzen Sie hierfür gerne unser Kontaktformular und wir melden uns baldmöglichst bei Ihnen.