Was ist HTTP Request Smuggling?

HTTP Request Smuggling entsteht, wenn zwei Systeme derselben Verbindung uneinig darüber sind, wo eine Anfrage endet und die nächste beginnt. Ein Load Balancer oder Reverse Proxy liest die Nachricht anders als der Backend-Server. Vom Frontend als Teil der ersten Anfrage behandelte Bytes können beim Backend zur eingeschmuggelten nächsten Anfrage werden – oder umgekehrt.

Wie entsteht Request Smuggling?

HTTP/1.1 kann einen Body unter anderem über Content-Length oder Transfer-Encoding: chunked begrenzen. Mehrdeutige, doppelte oder ungewöhnlich formatierte Header treffen auf eine Kette aus CDN, WAF, Proxy, Gateway und Anwendungsserver. Wenn diese Komponenten unterschiedliche Regeln, Parser oder Normalisierung verwenden, bleibt ein Teil der Angreiferanfrage auf einer wiederverwendeten Backend-Verbindung übrig. Er wird dort mit der nächsten legitimen Anfrage zusammengesetzt.

Die Schwachstelle liegt damit in der Kombination der Systeme. Ein einzelner Server kann eine Anfrage scheinbar korrekt verarbeiten, während die Abweichung erst an der nächsten Komponente gefährlich wird.

Was bedeuten CL.TE, TE.CL und TE.TE?

Die Namen beschreiben Parserentscheidungen, nicht fertige Exploits. Moderne Varianten nutzen doppelte Header, ungültige Chunk-Größen, Whitespace, Zeilenumbrüche und andere Unterschiede. Blocklisten einzelner historischer Payloads sind deshalb kein dauerhafter Schutz.

Welche Rolle spielen HTTP/2 und HTTP/3?

HTTP/2 verwendet binäre Frames und besitzt nicht dieselbe Mehrdeutigkeit der HTTP/1-Textsyntax. Viele Frontends übersetzen Anfragen für ein HTTP/1.1-Backend. Entsteht beim Downgrade eine widersprüchliche Länge, ein ungeprüfter Header oder eine fehlerhafte neue Request-Zeile, kehrt die Desynchronisation an der Protokollgrenze zurück. HTTP/2-spezifische Varianten werden oft als H2.CL oder H2.TE bezeichnet. HTTP/3 beseitigt nicht automatisch Risiken, wenn Gateways anschließend in anfällige Protokolle übersetzen.

Welche Angriffe werden möglich?

• Sicherheitskontrollen umgehen: Das Frontend prüft eine harmlose äußere Anfrage, während das Backend die eingeschmuggelte Anfrage verarbeitet.
• Anfragen beeinflussen: Präfix oder Body der nächsten Benutzeranfrage wird verändert oder an einen Angreifer-Endpunkt geleitet.
• Antworten vertauschen: Nutzer erhalten eine Antwort, die zu einer anderen Anfrage gehört, was Daten offenlegen kann.
• Cache Poisoning: Eine eingeschmuggelte Antwort landet unter einem öffentlich abrufbaren Cache-Key.
• Interne Funktionen erreichen: Routing-, Host- oder Pfadprüfungen vorgeschalteter Systeme werden umgangen.

Auswirkungen sind oft instabil und betreffen zufällige andere Verbindungen. Genau das macht die Schwachstelle zugleich kritisch und schwer reproduzierbar.

Wie wird Request Smuggling verhindert?

1. Mehrdeutigkeit ablehnen: Widersprüchliche, doppelte oder ungültige Längen- und Transfer-Header mit Fehler beantworten und Verbindung schließen.
2. Einheitliche Protokolle: Wenn möglich HTTP/2 Ende-zu-Ende nutzen oder Downgrade streng und eindeutig normalisieren.
3. Ein Parserergebnis: Nachrichten am Frontend vollständig parsen und eine sauber neu erzeugte Anfrage weitergeben, nicht rohe problematische Bytes.
4. Komponenten aktuell halten: CDN, WAF, Proxy, Gateway, Server und Framework gemeinsam inventarisieren und patchen.
5. Backend schützen: Nur Verbindungen vertrauenswürdiger Frontends akzeptieren und unerwartete direkte Zugänge sperren.
6. Verbindungswiederverwendung begrenzen: Bei Parserfehlern und unklarer Begrenzung nicht versuchen, die Verbindung fortzusetzen.

Protokollbeispiel: Eine Anfrage mit widersprüchlicher Begrenzung

POST /example HTTP/1.1
Host: application.example
Content-Length: 6
Transfer-Encoding: chunked

0

X

Frontend und Backend dürfen hier nicht jeweils einen anderen Header priorisieren. Die sichere Reaktion ist, die Anfrage als ungültig abzulehnen, die Verbindung zu schließen und keine teilweise geparsten Bytes weiterzureichen.

if hasHeader('Content-Length') and hasHeader('Transfer-Encoding'):
    reject(400)
    closeConnection()

request = parseCompletelyWithOneStrictParser()
forward(serializeFreshRequest(request))

Das Pseudocode-Beispiel beschreibt eine Architekturregel, keine alleinstehende Reparatur. Entscheidend ist, dass jede reale Komponente der Kette dieselben gültigen Nachrichten akzeptiert und dieselben mehrdeutigen Nachrichten verwirft.

Wie wird sicher getestet und erkannt?

Produktive Tests sind sensibel, weil eine präparierte Anfrage die nächste Anfrage eines echten Nutzers beeinflussen kann. Autorisierte Tester beginnen mit zeitbasierten oder differenziellen Verfahren auf kontrollierten Endpunkten und eigenen Verbindungen. Destruktive Cache- oder Opfernachweise brauchen eine ausdrückliche Freigabe. Monitoring achtet auf abgelehnte mehrdeutige Requests, ungewöhnliche 400er-Antworten, Backend-Requests ohne passende Frontend-ID, Response-Mismatches und Verbindungsfehler. Frontend- und Backend-Logs müssen dafür über eine gemeinsame Request-ID korrelierbar sein.