Teil 4 – Schutzmaßnahmen und Best Practices gegen HTTP Request Smuggling

Sep. 12, 2025

—

von

in Cyber Security, HTTP Request Smuggling, Websecurity

Warum Prävention so schwierig ist

HTTP Request Smuggling (HRS) entsteht durch uneinheitliche Interpretationen von HTTP-Requests zwischen Proxy/Load Balancer/CDN und Backend.
Das bedeutet: Ein Patch im Backend allein reicht nicht. Ein Proxy allein kann auch nicht alles verhindern. Alle Glieder der Kette müssen dieselben Regeln haben.

Wir gehen Schritt für Schritt durch, wie man HRS in den Griff bekommt.

1. Konsistente HTTP-Parsing-Regeln

Das Kernproblem

Proxy denkt: Request endet bei Content-Length.
Backend denkt: Request endet bei Transfer-Encoding.

→ Lösung: Beide Systeme müssen dieselben Regeln verwenden.

Maßnahmen

Konfiguriere Proxies so, dass sie entweder Content-Length oder Transfer-Encoding akzeptieren, niemals beide.
Stelle sicher, dass Backend-Server genauso konfiguriert sind.

2. Sichere Konfiguration gängiger Server

Apache

Aktiviere HttpProtocolOptions Strict: HttpProtocolOptions Strict → lehnt doppelte oder widersprüchliche Header ab.
Blockiere Requests mit sowohl CL als auch TE: RequestHeader unset Transfer-Encoding early

Nginx

Neuere Versionen von Nginx ignorieren Requests mit widersprüchlichen Headern.
Stelle sicher: proxy_request_buffering on; proxy_http_version 1.1; → sorgt dafür, dass Requests klar vom Proxy aufgelöst werden, bevor sie ans Backend gehen.

HAProxy

Nutze option http-buffer-request, damit Requests vollständig gelesen werden, bevor sie ans Backend gehen.
Verwende strikte Mode-Einstellungen: option http-use-htx h1-case-adjust-bogus off → verhindert Parsing-Unterschiede.

Node.js

Alte Node-Versionen hatten HRS-Probleme (vor v10.23.1 / v12.19.1).
Immer auf die neueste LTS-Version upgraden.

3. Request-Normalisierung

Eine gute Praxis ist es, dass der Proxy alle Requests normalisiert, bevor sie ans Backend gehen.

Entferne doppelte Header.
Wandle unterschiedliche Zeilenendungen (\r\n, \n) in ein einheitliches Format.
Entferne Header, die CL und TE gleichzeitig setzen.

Beispiel mit Nginx:

proxy_set_header Transfer-Encoding "";

So wird TE entfernt und nur CL genutzt.

4. HTTP/2 & HTTP/3 Migration

Viele HRS-Angriffe basieren auf HTTP/1.1.
Wenn möglich:

Frontend (Browser ↔ CDN) auf HTTP/2 oder HTTP/3 setzen.
Proxy konvertiert Requests zu einem sauberen HTTP/1.1 für das Backend.

Aber Achtung: Auch hier gibt es HTTP/2 Desync Attacks. Deshalb gilt: Nicht blind migrieren, sondern sauber konfigurieren.

5. Strikte Security-Policies

WAF-Regeln

Auch wenn eine WAF nicht die einzige Lösung ist, können Regeln helfen, verdächtige Requests zu blockieren:

Blockiere Requests mit doppelten Content-Length-Headern.
Blockiere Requests mit gleichzeitig CL und TE.
Logge alle verdächtigen Header-Kombinationen.

Proxy-Policies

Setze Limits:

Maximale Header-Länge.
Maximale Request-Größe.
Maximale Anzahl an Headern.

Damit erschwerst du das Basteln von Smuggling-Payloads.

6. Monitoring & Detection

HRS-Angriffe hinterlassen nicht immer sofort Spuren – aber man kann auffällige Muster überwachen:

Verdächtige Header-Kombinationen
- CL + TE gleichzeitig
- doppelte CL
- ungewöhnliche Transfer-Encoding-Werte
Ungewöhnliche Caching-Muster
- plötzliche Änderungen an Cache-Keys
- Responses mit fremden Host– oder X-Forwarded-Host-Headern
Log-Differenzen
- Proxy-Logs und Backend-Logs vergleichen.
- Wenn Requests in Backend-Logs auftauchen, die im Proxy-Log fehlen → Warnsignal.

7. Updates & Patch-Management

Die meisten HRS-Schwachstellen entstehen durch veraltete Versionen von Proxies oder Backends.

Halte Apache, Nginx, HAProxy, Node.js, Tomcat & Co. immer aktuell.
Verfolge Security Advisories von Anbietern.
Automatisiere Updates, wenn möglich.

8. Developer-Best Practices

Auch in der App selbst sollte man vorsorgen:

Nicht blind auf Header vertrauen.
App-Logik sollte nicht zwischen „Chunked“ und „Content-Length“ unterscheiden – das soll der Proxy klären.
Logging erweitern: Immer Header-Kombinationen mitloggen, wenn sie ungewöhnlich sind.

9. Testen wie ein Angreifer

Um sicherzugehen, dass deine Konfiguration nicht anfällig ist, solltest du testen:

Burp Suite

Verwende die Extension HTTP Request Smuggler.
Sie probiert automatisch Payloads für CL.TE, TE.CL und TE.TE.

Manuelle Tests

Sende Requests mit CL und TE gleichzeitig und beobachte, ob Proxy und Backend unterschiedliche Antworten liefern.

CI/CD Security-Tests

Binde HRS-Tests in deine Pipeline ein, z. B. mit OWASP ZAP oder speziellen Plugins.

10. Fallstricke vermeiden

„Unsere WAF schützt uns schon.“ → Nein. Eine WAF vor dem Proxy sieht denselben Request wie der Proxy – nicht wie das Backend.
„Wir nutzen nur Content-Length.“ → Sicherer, aber du musst garantieren, dass TE nie durchrutscht.
„HTTP/2 schützt uns.“ → Nur teilweise. Es gibt auch Smuggling-Varianten gegen HTTP/2.

Analogie: Eine gemeinsame Sprache finden

Stell dir vor, Proxy und Backend sind zwei Übersetzer, die Nachrichten weiterreichen.

Einer trennt Sätze bei einem Punkt.
Der andere trennt bei einem Ausrufezeichen.

Wenn du beide Zeichen benutzt, reden die Übersetzer aneinander vorbei.

Die Lösung: Beide müssen dieselbe Regel befolgen.

Was du bis hier mitnehmen solltest

HRS entsteht durch Parsing-Unterschiede zwischen Proxy und Backend.
Schutzmaßnahmen:
- Konsistente Regeln für CL/TE.
- Sichere Konfiguration von Apache, Nginx, HAProxy.
- Request-Normalisierung durch den Proxy.
- Monitoring auf verdächtige Header.
- Regelmäßige Updates.
Am besten: Proxy filtert gefährliche Header und reicht nur saubere Requests ans Backend weiter.