Teil 1 – Was ist HTTP Request Smuggling?

Sep. 12, 2025

—

von

in Cyber Security, HTTP Request Smuggling, Websecurity

Wenn zwei Poststellen durcheinanderkommen

Stell dir vor, du schickst einen Brief über eine Zwischenstelle an die eigentliche Post.

Die Zwischenstelle trennt die Briefe nach „drei Leerzeilen“.
Die Hauptpost trennt die Briefe aber nach „zwei Leerzeilen“.

Wenn du einen Brief mit genau zwei Leerzeilen schreibst, denkt die Zwischenstelle: Alles gut, ein Brief. Die Hauptpost aber liest: Moment, da sind zwei Briefe! – und verarbeitet den zweiten Brief als eigenständige Sendung.

Das ist im Kern, was bei HTTP Request Smuggling (HRS) passiert: zwei Systeme interpretieren denselben HTTP-Request unterschiedlich – und Angreifer nutzen das, um versteckte Anfragen „durchzuschmuggeln“.

HTTP – ein kurzer Rückblick

HTTP ist das Protokoll, über das Browser mit Webservern sprechen.
Ein Request sieht grob so aus:

POST /login HTTP/1.1
Host: example.com
Content-Length: 27

username=alice&password=123

Request-Line: POST /login HTTP/1.1
Header: zusätzliche Infos, z. B. Content-Length (wie viele Bytes folgen).
Body: die eigentlichen Daten (hier ein Login-Formular).

Normalerweise sind sich Proxy, CDN und Backend einig, wie dieser Request aussieht. Aber manchmal eben nicht.

Was ist HTTP Request Smuggling?

HTTP Request Smuggling bezeichnet Angriffe, bei denen ein Angreifer durch widersprüchliche Header (meist Content-Length und Transfer-Encoding) einen Request so formt, dass Proxy und Backend ihn unterschiedlich interpretieren.

Der Proxy denkt: Das ist ein vollständiger Request.
Das Backend denkt: Da kommt noch einer dran.

So „schmuggelt“ der Angreifer einen zweiten, versteckten Request hinter den ersten.

Das typische Setting

HRS tritt fast nie bei einem einzelnen Server auf, sondern in einer Kette:

Client (Angreifer/Browser) sendet einen Request.
Proxy/Load Balancer/CDN empfängt den Request zuerst.
Backend-Server verarbeitet den Request letztlich.

Wenn Proxy und Backend nicht denselben Parsing-Algorithmus haben, öffnet das die Tür für Smuggling.

Die kritischen Header: Content-Length & Transfer-Encoding

Content-Length (CL): sagt, wie viele Bytes der Body hat.
Transfer-Encoding: chunked (TE): sagt, dass der Body in einzelnen „Chunks“ übertragen wird, bis ein „0\r\n\r\n“ kommt.

Das Problem: Manche Proxies vertrauen auf Content-Length, andere auf Transfer-Encoding.

Wenn ein Request beide Header enthält, entsteht Verwirrung:

Proxy: „Ah, Body = 13 Bytes (laut CL).“
Backend: „Nein, Body ist chunked, und da kommt noch was.“

Ein einfaches Beispiel (gedanklich, nicht live testen)

POST / HTTP/1.1
Host: victim.com
Content-Length: 13
Transfer-Encoding: chunked

0

GET /admin HTTP/1.1
Host: victim.com

Proxy liest: „Content-Length = 13 Bytes → das ist der ganze Request.“
Backend liest: „Transfer-Encoding = chunked → nach dem 0 ist der Request zu Ende, und danach kommt ein zweiter Request (GET /admin).“

Ergebnis: Der Angreifer hat es geschafft, einen zweiten Request einzuschleusen, den der Proxy gar nicht wahrnimmt.

Warum das so gefährlich ist

HTTP Request Smuggling ist nicht nur ein kleiner Parsing-Bug, sondern hat gravierende Folgen:

Sicherheitskontrollen umgehen
Proxies oder WAFs (Web Application Firewalls) sehen nur den ersten Teil des Requests – der zweite Teil passiert unsichtbar direkt beim Backend.
Session Hijacking
Ein Angreifer kann Requests von legitimen Nutzern beeinflussen oder sich in deren Sessions einschleusen.
Cache Poisoning
Durch geschmuggelte Requests kann der Cache mit manipulierten Antworten gefüllt werden. Nutzer bekommen dann falsche Inhalte.
Privilegierte Aktionen
Angreifer können Requests wie GET /admin einschleusen, die sonst blockiert wären.

Analogie: Warteschlange beim Konzert

Stell dir eine Warteschlange mit Ticketkontrolle vor:

Der erste Sicherheitsmann (Proxy) zählt, wie viele Leute reinkommen dürfen.
Der zweite Sicherheitsmann (Backend) zählt aber nach einer anderen Regel.

Ein Angreifer drängt sich zwischen zwei Gruppen und flüstert dem ersten: „Bin noch Teil der Gruppe.“
Der zweite denkt aber: „Das ist schon eine neue Gruppe.“

So schummelt er sich unbemerkt rein.

Warum taucht das heute noch auf?

Man könnte meinen: So ein alter Bug, den hat man doch längst gefixt.
Aber in der Realität gibt es Gründe, warum HTTP Request Smuggling immer noch aktuell ist:

Komplexe Infrastrukturen: Zwischen Browser und Backend liegen oft CDNs, Proxies, Load Balancer.
Unterschiedliche Implementierungen: Apache, Nginx, HAProxy, Node.js – alle verarbeiten Header ein bisschen anders.
Legacy-Systeme: Manche Server akzeptieren alte Header-Syntax, die längst unsicher ist.
Neue Angriffsarten: Forscher wie James Kettle (PortSwigger) entdecken immer neue Varianten – auch gegen HTTP/2 und HTTP/3.

Was du bis hier mitnehmen solltest

HTTP Request Smuggling = Angreifer schmuggelt Requests durch unterschiedliche Interpretationen von Proxy und Backend.
Schlüsselrolle spielen die Header Content-Length und Transfer-Encoding.
Folgen: Sicherheitsmechanismen umgehen, Sessions übernehmen, Caches vergiften.
Es ist kein veralteter Angriff – durch komplexe Web-Infrastrukturen ist er aktueller denn je.