Translated ['src/pentesting-web/http-request-smuggling/README.md', 'src/

2025-10-10 18:36:50 +00:00 · 2025-08-20 16:42:37 +00:00 · 2025-08-20 16:42:37 +00:00 · 10471f1e6a
commit 10471f1e6a
parent 4de7345686
2 changed files with 196 additions and 68 deletions
--- a/src/pentesting-web/http-request-smuggling/README.md
+++ b/src/pentesting-web/http-request-smuggling/README.md
@ -15,50 +15,50 @@ Hii inaruhusu mtumiaji **kubadilisha ombi linalofuata linalofika kwa back-end se

 **Content-Length**

-> Kichwa cha Content-Length kinaonyesha ukubwa wa mwili wa kitu, kwa bytes, kilichotumwa kwa mpokeaji.
+> Kichwa cha Content-Length kinadhihirisha ukubwa wa mwili wa kitu, kwa bytes, kilichotumwa kwa mpokeaji.

 **Transfer-Encoding: chunked**

-> Kichwa cha Transfer-Encoding kinaelezea aina ya usimbuaji inayotumika kwa usalama kuhamasisha mwili wa payload kwa mtumiaji.\
-> Chunked inamaanisha kwamba data kubwa inatumwa katika mfululizo wa vipande.
+> Kichwa cha Transfer-Encoding kinabainisha aina ya usimbuaji inayotumika kwa usalama kuhamasisha mwili wa payload kwa mtumiaji.\
+> Chunked inamaanisha kwamba data kubwa inatumwa kwa mfululizo wa vipande.

 ### Reality

 **Front-End** (load-balance / Reverse Proxy) **inasindika** _**content-length**_ au _**transfer-encoding**_ kichwa na **Back-end** server **inasindika** kichwa kingine ikisababisha **desyncronization** kati ya mifumo 2.\
-Hii inaweza kuwa hatari sana kwani **mshambuliaji ataweza kutuma ombi moja** kwa reverse proxy ambalo litatafsiriwa na **back-end** server **kama ombi 2 tofauti**. **Hatari** ya mbinu hii inategemea ukweli kwamba **back-end** server **itaelewa** **ombio la 2 lililoingizwa** kana kwamba **lilitoka kwa mteja anayefuata** na **ombio halisi** la mteja huyo litakuwa **sehemu** ya **ombio lililoingizwa**.
+Hii inaweza kuwa hatari sana kwani **mshambuliaji ataweza kutuma ombi moja** kwa reverse proxy ambalo litatafsiriwa na **back-end** server **kama ombi 2 tofauti**. **Hatari** ya mbinu hii inatokana na ukweli kwamba **back-end** server **itaelewa** **ombio la 2 lililoingizwa** kana kwamba **lilitoka kwa mteja anayefuata** na **ombio halisi** la mteja huyo litakuwa **sehemu** ya **ombio lililoingizwa**.

 ### Particularities

 Kumbuka kwamba katika HTTP **herufi mpya inaundwa na bytes 2:**

 - **Content-Length**: Kichwa hiki kinatumia **nambari ya desimali** kuonyesha **idadi** ya **bytes** za **mwili** wa ombi. Mwili unatarajiwa kumalizika katika herufi ya mwisho, **herufi mpya haitahitajika mwishoni mwa ombi**.
- **Transfer-Encoding:** Kichwa hiki kinatumia katika **mwili** **nambari ya hexadecimal** kuonyesha **idadi** ya **bytes** za **kipande kinachofuata**. **Kipande** lazima **kimalizike** kwa **herufi mpya** lakini herufi hii mpya **haitahesabiwa** na kiashiria cha urefu. Mbinu hii ya usafirishaji lazima ikamilike na **kipande cha ukubwa 0 kinachofuatiwa na herufi 2 mpya**: `0`
- **Connection**: Kulingana na uzoefu wangu, inapendekezwa kutumia **`Connection: keep-alive`** kwenye ombi la kwanza la ombi la Smuggling.
+- **Transfer-Encoding:** Kichwa hiki kinatumia katika **mwili** **nambari ya hexadecimal** kuonyesha **idadi** ya **bytes** za **kipande kinachofuata**. **Kipande** lazima **kimalizike** kwa **herufi mpya** lakini herufi hii mpya **haitahesabiwa** na kiashiria cha urefu. Mbinu hii ya uhamasishaji lazima ikamilike na **kipande cha ukubwa 0 kinachofuatiwa na herufi 2 mpya**: `0`
+- **Connection**: Kulingana na uzoefu wangu, inapendekezwa kutumia **`Connection: keep-alive`** kwenye ombi la kwanza la ombi Smuggling.

 ## Basic Examples

 > [!TIP]
-> Unapojaribu kutumia hii na Burp Suite **zima `Update Content-Length` na `Normalize HTTP/1 line endings`** katika repeater kwa sababu baadhi ya vifaa vinatumia herufi mpya, kurudi kwa gari na maudhui yasiyo sahihi ya urefu.
+> Unapojaribu kutumia hii na Burp Suite **zima `Update Content-Length` na `Normalize HTTP/1 line endings`** katika repeater kwa sababu baadhi ya vifaa vinatumia herufi mpya, kurudi kwa gari na maudhui yasiyo sahihi.

-Mashambulizi ya HTTP request smuggling yanatengenezwa kwa kutuma maombi yasiyo na uwazi ambayo yanatumia tofauti katika jinsi front-end na back-end servers zinavyotafsiri vichwa vya `Content-Length` (CL) na `Transfer-Encoding` (TE). Mashambulizi haya yanaweza kuonekana katika aina tofauti, hasa kama **CL.TE**, **TE.CL**, na **TE.TE**. Kila aina inawakilisha mchanganyiko wa kipekee wa jinsi front-end na back-end servers zinavyopendelea vichwa hivi. Uthibitisho unatokea kutokana na servers kusindika ombi moja kwa njia tofauti, na kusababisha matokeo yasiyotarajiwa na yanaweza kuwa ya uhalifu.
+Mashambulizi ya HTTP request smuggling yanatengenezwa kwa kutuma maombi yasiyo na uwazi yanayatumia tofauti katika jinsi front-end na back-end servers zinavyotafsiri vichwa vya `Content-Length` (CL) na `Transfer-Encoding` (TE). Mashambulizi haya yanaweza kuonekana katika aina tofauti, hasa kama **CL.TE**, **TE.CL**, na **TE.TE**. Kila aina inawakilisha mchanganyiko wa kipekee wa jinsi front-end na back-end servers zinavyopendelea vichwa hivi. Uthibitisho unatokana na servers kusindika ombi moja kwa njia tofauti, na kusababisha matokeo yasiyotarajiwa na yanaweza kuwa ya uhalifu.

 ### Basic Examples of Vulnerability Types

 ![https://twitter.com/SpiderSec/status/1200413390339887104?ref_src=twsrc%5Etfw%7Ctwcamp%5Etweetembed%7Ctwterm%5E1200413390339887104&ref_url=https%3A%2F%2Ftwitter.com%2FSpiderSec%2Fstatus%2F1200413390339887104](../../images/EKi5edAUUAAIPIK.jpg)

-> [!NOTE]
-> Katika jedwali la awali unapaswa kuongeza mbinu ya TE.0, kama mbinu ya CL.0 lakini ukitumia Transfer Encoding.
+> [!TIP]
+> Katika jedwali la awali 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):** Inasindika ombi kulingana na kichwa cha `Content-Length`.
 - **Back-End (TE):** Inasindika ombi kulingana na kichwa cha `Transfer-Encoding`.
- **Kasi ya Shambulio:**
+- **Attack Scenario:**

- Mshambuliaji anatumia ombi ambapo thamani ya kichwa cha `Content-Length` haitosheani na urefu halisi wa maudhui.
+- Mshambuliaji anatumia ombi ambapo thamani ya kichwa cha `Content-Length` haifanani na urefu halisi wa maudhui.
 - Server ya front-end inapeleka ombi lote kwa back-end, kulingana na thamani ya `Content-Length`.
 - Server ya back-end inasindika ombi kama kipande kutokana na kichwa cha `Transfer-Encoding: chunked`, ikitafsiri data iliyobaki kama ombi tofauti, linalofuata.
- **Mfano:**
+- **Example:**

 ```
 POST / HTTP/1.1
@ -77,12 +77,12 @@ Foo: x

 - **Front-End (TE):** Inasindika ombi kulingana na kichwa cha `Transfer-Encoding`.
 - **Back-End (CL):** Inasindika ombi kulingana na kichwa cha `Content-Length`.
- **Kasi ya Shambulio:**
+- **Attack Scenario:**

- Mshambuliaji anatumia ombi lililosambazwa ambapo ukubwa wa kipande (`7b`) na urefu halisi wa maudhui (`Content-Length: 4`) havikubaliani.
+- Mshambuliaji anatumia ombi la kipande ambapo ukubwa wa kipande (`7b`) na urefu halisi wa maudhui (`Content-Length: 4`) havifanani.
 - Server ya front-end, ikiheshimu `Transfer-Encoding`, inapeleka ombi lote kwa back-end.
- Server ya back-end, ikiheshimu `Content-Length`, inasindika tu sehemu ya awali ya ombi (`7b` bytes), ikiacha iliyobaki kama sehemu ya ombi linalofuata lisilotarajiwa.
- **Mfano:**
+- Server ya back-end, ikiheshimu `Content-Length`, inasindika tu sehemu ya awali ya ombi (`7b` bytes), ikiacha yaliyobaki kama sehemu ya ombi linalofuata ambalo halikusudiwa.
+- **Example:**

 ```
 POST / HTTP/1.1
@ -105,12 +105,12 @@ x=
 #### TE.TE Vulnerability (Transfer-Encoding used by both, with obfuscation)

 - **Servers:** Zote zinasaidia `Transfer-Encoding`, lakini moja inaweza kudanganywa kuipuuza kupitia obfuscation.
- **Kasi ya Shambulio:**
+- **Attack Scenario:**

 - Mshambuliaji anatumia ombi lenye vichwa vya `Transfer-Encoding` vilivyofichwa.
 - Kulingana na ni server ipi (front-end au back-end) inashindwa kutambua obfuscation, udhaifu wa CL.TE au TE.CL unaweza kutumika.
 - Sehemu isiyosindikwa ya ombi, kama inavyoonekana na moja ya servers, inakuwa sehemu ya ombi linalofuata, ikisababisha smuggling.
- **Mfano:**
+- **Example:**

 ```
 POST / HTTP/1.1
@ -131,9 +131,9 @@ Transfer-Encoding

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

- Zote servers zinashughulikia ombi kulingana na kichwa cha `Content-Length`.
+- Servers zote zinashughulikia ombi kulingana na kichwa cha `Content-Length` pekee.
 - Hali hii kwa kawaida haipelekei smuggling, kwani kuna ulinganifu katika jinsi servers zote zinavyotafsiri urefu wa ombi.
- **Mfano:**
+- **Example:**

 ```
 POST / HTTP/1.1
@ -146,9 +146,9 @@ Normal Request

 #### **CL.0 Scenario**

- Inahusisha hali ambapo kichwa cha `Content-Length` kinapatikana na kina thamani isiyo sifuri, ikionyesha kwamba mwili wa ombi una maudhui. Back-end inapuuzilia mbali kichwa cha `Content-Length` (ambacho kinachukuliwa kama 0), lakini front-end inakisoma.
+- Inarejelea hali ambapo kichwa cha `Content-Length` kinapatikana na kina thamani isiyo sifuri, ikionyesha kwamba mwili wa ombi una maudhui. Back-end inapuuzilia mbali kichwa cha `Content-Length` (ambacho kinachukuliwa kama 0), lakini front-end inakichambua.
 - Ni muhimu katika kuelewa na kutengeneza mashambulizi ya smuggling, kwani inaathiri jinsi servers zinavyotambua mwisho wa ombi.
- **Mfano:**
+- **Example:**

 ```
 POST / HTTP/1.1
@ -163,7 +163,7 @@ Non-Empty Body

 - Kama ile ya awali lakini ikitumia TE
 - Mbinu [iliyorekodiwa hapa](https://www.bugcrowd.com/blog/unveiling-te-0-http-request-smuggling-discovering-a-critical-vulnerability-in-thousands-of-google-cloud-websites/)
- **Mfano:**
+- **Example**:
 ```
 OPTIONS / HTTP/1.1
 Host: {HOST}
@ -185,7 +185,7 @@ EMPTY_LINE_HERE

 Teknolojia hii pia ni muhimu katika hali ambapo inawezekana **kuvunja seva ya wavuti wakati wa kusoma data ya awali ya HTTP** lakini **bila kufunga muunganisho**. Kwa njia hii, **mwili** wa ombi la HTTP utaonekana kama **ombio la HTTP linalofuata**.

-Kwa mfano, kama ilivyoelezwa katika [**hiki andiko**](https://mizu.re/post/twisty-python), Katika Werkzeug ilikuwa inawezekana kutuma baadhi ya **Unicode** wahusika na itafanya seva **ivunje**. Hata hivyo, ikiwa muunganisho wa HTTP ulianzishwa na kichwa **`Connection: keep-alive`**, mwili wa ombi hautasomwa na muunganisho utaendelea kuwa wazi, hivyo **mwili** wa ombi utaonekana kama **ombio la HTTP linalofuata**.
+Kwa mfano, kama ilivyoelezwa katika [**hati hii**](https://mizu.re/post/twisty-python), Katika Werkzeug ilikuwa inawezekana kutuma baadhi ya **Unicode** wahusika na itafanya seva **ivunjike**. Hata hivyo, ikiwa muunganisho wa HTTP ulianzishwa na kichwa **`Connection: keep-alive`**, mwili wa ombi hautasomwa na muunganisho utaendelea kuwa wazi, hivyo **mwili** wa ombi utaonekana kama **ombio la HTTP linalofuata**.

 #### Kulazimisha kupitia vichwa vya hop-by-hop

@ -207,7 +207,7 @@ Kutambua udhaifu wa HTTP request smuggling mara nyingi kunaweza kufanywa kwa kut

 - **Mbinu:**

- Tuma ombi ambalo, ikiwa programu ina udhaifu, litafanya seva ya nyuma kusubiri data zaidi.
+- Tuma ombi ambalo, ikiwa programu ina udhaifu, litasababisha seva ya nyuma kusubiri data zaidi.
 - **Mfano:**

 ```
@ -223,8 +223,8 @@ A
 ```

 - **Uangalizi:**
- Seva ya mbele inashughulikia ombi kulingana na `Content-Length` na kukata ujumbe mapema.
- Seva ya nyuma, ikitarajia ujumbe wa chunked, inasubiri chunk inayofuata ambayo haitafika, ikisababisha kuchelewesha.
+- Seva ya mbele inashughulikia ombi kulingana na `Content-Length` na inakata ujumbe mapema.
+- Seva ya nyuma, ikitarajia ujumbe wa chunked, inasubiri chunk inayofuata ambayo haitafika, na kusababisha kuchelewesha.

 - **Dalili:**
 - Timeout au ucheleweshaji mrefu katika majibu.
@ -234,7 +234,7 @@ A

 - **Mbinu:**

- Tuma ombi ambalo, ikiwa programu ina udhaifu, litafanya seva ya nyuma kusubiri data zaidi.
+- Tuma ombi ambalo, ikiwa programu ina udhaifu, litasababisha seva ya nyuma kusubiri data zaidi.
 - **Mfano:**

 ```
@ -250,7 +250,7 @@ X

 - **Uangalizi:**
 - Seva ya mbele inashughulikia ombi kulingana na `Transfer-Encoding` na inapeleka ujumbe mzima.
- Seva ya nyuma, ikitarajia ujumbe kulingana na `Content-Length`, inasubiri data zaidi ambayo haitafika, ikisababisha kuchelewesha.
+- Seva ya nyuma, ikitarajia ujumbe kulingana na `Content-Length`, inasubiri data zaidi ambayo haitafika, na kusababisha kuchelewesha.

 ### Mbinu Nyingine za Kupata Udhaifu

@ -265,25 +265,131 @@ X

 ### Upimaji wa Udhaifu wa HTTP Request Smuggling

-Baada ya kuthibitisha ufanisi wa mbinu za wakati, ni muhimu kuthibitisha ikiwa maombi ya mteja yanaweza kubadilishwa. Mbinu rahisi ni kujaribu kuharibu maombi yako, kwa mfano, kufanya ombi kwa `/` kuleta jibu la 404. Mifano ya `CL.TE` na `TE.CL` zilizozungumziwa hapo awali katika [Mifano ya Msingi](#basic-examples) zinaonyesha jinsi ya kuharibu ombi la mteja ili kuleta jibu la 404, licha ya mteja kujaribu kufikia rasilimali tofauti.
+Baada ya kuthibitisha ufanisi wa mbinu za wakati, ni muhimu kuthibitisha ikiwa maombi ya mteja yanaweza kubadilishwa. Mbinu rahisi ni kujaribu kuharibu maombi yako, kwa mfano, kufanya ombi kwa `/` kuleta jibu la 404. Mifano ya `CL.TE` na `TE.CL` zilizozungumziwa hapo awali katika [Mifano ya Msingi](#basic-examples) zinaonyesha jinsi ya kuharibu ombi la mteja ili kuleta jibu la 404, licha ya mteja kutaka kufikia rasilimali tofauti.

 **Mambo Muhimu ya Kuangalia**

 Wakati wa kupima udhaifu wa request smuggling kwa kuingilia maombi mengine, kumbuka:

 - **Mawasiliano Mbalimbali ya Mtandao:** Maombi ya "shambulio" na "ya kawaida" yanapaswa kutumwa kupitia mawasiliano tofauti ya mtandao. Kutumia muunganisho mmoja kwa yote mawili hakuthibitishi uwepo wa udhaifu.
- **URL na Vigezo Vya Kawaida:** Jaribu kutumia URLs na majina ya vigezo sawa kwa maombi yote mawili. Programu za kisasa mara nyingi hupeleka maombi kwa seva maalum za nyuma kulingana na URL na vigezo. Kulinganisha haya kunapanua uwezekano kwamba maombi yote mawili yanashughulikiwa na seva moja, ambayo ni sharti la shambulio lililofanikiwa.
+- **URL na Vigezo Vinavyofanana:** Jaribu kutumia URLs na majina ya vigezo sawa kwa maombi yote mawili. Programu za kisasa mara nyingi hupeleka maombi kwa seva maalum za nyuma kulingana na URL na vigezo. Kulinganisha haya kunapanua uwezekano wa maombi yote mawili kushughulikiwa na seva ile ile, ambayo ni sharti la shambulio lililofanikiwa.
 - **Wakati na Masharti ya Mbio:** Ombi la "kawaida", lililokusudiwa kugundua kuingilia kutoka kwa ombi la "shambulio", linashindana na maombi mengine ya programu yanayoendelea. Kwa hivyo, tuma ombi la "kawaida" mara moja baada ya ombi la "shambulio". Programu zenye shughuli nyingi zinaweza kuhitaji majaribio kadhaa kwa uthibitisho wa udhaifu.
- **Changamoto za Usawa wa Mizigo:** Seva za mbele zinazofanya kazi kama wasambazaji wa mizigo zinaweza kugawa maombi kati ya mifumo mbalimbali ya nyuma. Ikiwa maombi ya "shambulio" na "ya kawaida" yanakutana kwenye mifumo tofauti, shambulio halitafanikiwa. Kipengele hiki cha usawa wa mizigo kinaweza kuhitaji majaribio kadhaa kuthibitisha udhaifu.
+- **Changamoto za Usambazaji wa Mizigo:** Seva za mbele zinazofanya kazi kama wasambazaji wa mizigo zinaweza kugawa maombi kati ya mifumo mbalimbali ya nyuma. Ikiwa maombi ya "shambulio" na "ya kawaida" yanakutana kwenye mifumo tofauti, shambulio halitafanikiwa. Kipengele hiki cha usambazaji wa mizigo kinaweza kuhitaji majaribio kadhaa kuthibitisha udhaifu.
 - **Athari zisizokusudiwa kwa Watumiaji:** Ikiwa shambulio lako kwa bahati mbaya linaathiri ombi la mtumiaji mwingine (sio ombi la "kawaida" ulilotuma kwa ajili ya kugundua), hii inaonyesha kuwa shambulio lako limeathiri mtumiaji mwingine wa programu. Kujaribu mara kwa mara kunaweza kuharibu watumiaji wengine, hivyo inahitajika kuwa na tahadhari.

-## Kutumia HTTP Request Smuggling
+## Kutofautisha kati ya vichwa vya HTTP/1.1 pipelining na udhaifu halisi wa request smuggling

-### Kupita Usalama wa Seva za Mbele kupitia HTTP Request Smuggling
+Kurejea kwa muunganisho (keep-alive) na pipelining kunaweza kwa urahisi kuunda dhana za "smuggling" katika zana za kupima zinazotuma maombi mengi kwenye socket moja. Jifunze kutenganisha vichwa vya upande wa mteja visivyo na madhara kutoka kwa desync halisi ya upande wa seva.

-Wakati mwingine, proxies za mbele zinaweka hatua za usalama, zikichunguza maombi yanayoingia. Hata hivyo, hatua hizi zinaweza kupitishwa kwa kutumia HTTP Request Smuggling, kuruhusu ufikiaji usioidhinishwa kwa maeneo yaliyopigwa marufuku. Kwa mfano, kufikia `/admin` kunaweza kuwa marufuku nje, huku proxy ya mbele ikizuia juhudi kama hizo. Hata hivyo, proxy hii inaweza kukosa kukagua maombi yaliyojumuishwa ndani ya ombi la HTTP lililosafirishwa, na kuacha pengo la kupita marufuku hizi.
+### Kwa nini pipelining inazalisha positives za uwongo

-Fikiria mifano ifuatayo inayoonyesha jinsi HTTP Request Smuggling inaweza kutumika kupita hatua za usalama za mbele, hasa ikilenga njia ya `/admin` ambayo kwa kawaida inalindwa na proxy ya mbele:
+HTTP/1.1 inarejelea muunganisho mmoja wa TCP/TLS na inachanganya maombi na majibu kwenye mtiririko mmoja. Katika pipelining, mteja anatuma maombi mengi mfululizo na kutegemea majibu kwa mpangilio. Positive ya kawaida ya uwongo ni kurudisha payload isiyo sahihi 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
+```
+Majibu yanaweza kuonekana kama:
+```
+HTTP/1.1 200 OK
+Content-Type: text/html
+
+```
+
+```
+HTTP/1.1 200 OK
+Content-Type: text/plain
+
+User-agent: *
+Disallow: /settings
+```
+Ikiwa seva ilipuuzia `Content_Length` isiyo sahihi, hakuna FE↔BE desync. Kwa kutumia tena, mteja wako kwa kweli alituma mtiririko huu wa byte, ambao seva ilichambua 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
+```
+Impact: hakuna. Umeondoa ushirikiano wa mteja wako kutoka kwa muundo wa seva.
+
+> [!TIP]
+> Moduli za Burp zinazotegemea matumizi ya kurudi/kupitisha: Turbo Intruder na `requestsPerConnection>1`, Intruder na "HTTP/1 connection reuse", Repeater "Send group in sequence (single connection)" au "Enable connection reuse".
+
+### Jaribio la Litmus: kupitisha au kweli desync?
+
+1. Zima matumizi ya kurudi na upime 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 inatoweka, ilikuwa labda kupitisha upande wa mteja, isipokuwa unashughulika na malengo yaliyofungwa kwenye muunganisho/yanayohusiana au desync upande wa mteja.
+2. Kagua jibu lililo ndani la HTTP/2
+- Tuma ombi la HTTP/2. Ikiwa mwili wa jibu una jibu kamili la ndani la HTTP/1, umethibitisha hitilafu ya uchambuzi/desync ya nyuma badala ya kipande safi cha mteja.
+3. Uchunguzi wa ombi la sehemu kwa mbele zilizofungwa kwenye muunganisho
+- Baadhi ya FEs hutumia tena muunganisho wa BE wa juu tu ikiwa mteja alitumia tena wao. Tumia ombi la sehemu kugundua tabia ya FE inayofanana na matumizi ya mteja.
+- Tazama PortSwigger "Browser‑Powered Desync Attacks" kwa mbinu ya kufungwa kwa muunganisho.
+4. Uchunguzi wa hali
+- Angalia tofauti za ombi la kwanza na la baadaye kwenye muunganisho mmoja wa TCP (routing/validation ya ombi la kwanza).
+- Burp "HTTP Request Smuggler" inajumuisha uchunguzi wa hali ya muunganisho unaoendesha hii.
+5. Onyesha waya
+- Tumia nyongeza ya Burp "HTTP Hacker" kuchunguza muunganiko na muundo wa ujumbe moja kwa moja wakati wa kujaribu matumizi na maombi ya sehemu.
+
+### Uhamasishaji wa ombi lililofungwa kwenye muunganisho (inahitaji matumizi ya kurudi)
+
+Baadhi ya mbele zinaweza kutumia tena muunganisho wa juu tu wakati mteja anatumia tena wao. Uhamasishaji halisi upo lakini unategemea matumizi ya kurudi upande wa mteja. Ili kutofautisha na kuthibitisha athari:
+- Thibitisha hitilafu upande wa seva
+- Tumia ukaguzi wa jibu lililo ndani la HTTP/2, au
+- Tumia maombi ya sehemu kuonyesha FE inatumia tena muunganisho wa juu tu wakati mteja anafanya hivyo.
+- Onyesha athari halisi hata kama matumizi ya moja kwa moja ya soketi za mtumiaji tofauti yamezuiwa:
+- Uharibifu wa cache: uharibifu wa caches zilizoshirikiwa kupitia desync ili majibu yaathiri watumiaji wengine.
+- Ufunuo wa kichwa cha ndani: rudisha vichwa vilivyowekwa na FE (mfano, vichwa vya uthibitisho/kuamini) na pivot kwa kukwepa uthibitisho.
+- Pita udhibiti wa FE: uhamasishaji wa njia/mifumo iliyozuiwa kupita mbele.
+- Ukatili wa kichwa cha mwenyeji: changanya na tabia za routing za mwenyeji ili pivot kwa vhosts za ndani.
+- Mchakato wa operator
+- Rudia na matumizi ya kudhibiti (Turbo Intruder `requestsPerConnection=2`, au Burp Repeater tab group → "Send group in sequence (single connection)").
+- Kisha ungana na msingi wa uharibifu wa cache/kichwa-leak/kukwepa udhibiti na kuonyesha athari za mtumiaji tofauti au uthibitisho.
+
+> Tazama pia mashambulizi ya hali ya muunganisho, ambayo yana uhusiano wa karibu lakini si uhamasishaji wa kiufundi:
+>
+>{{#ref}}
+>../http-connection-request-smuggling.md
+>{{#endref}}
+
+### Vikwazo vya desync upande wa mteja
+
+Ikiwa unalenga desync inayotokana na kivinjari/upande wa mteja, ombi la uhalifu lazima liweze kutumwa na kivinjari kutoka chanzo tofauti. Hila za kuficha vichwa hazitafanya kazi. Zingatia misingi inayoweza kufikiwa kupitia urambazaji/kuchota, kisha pivot kwa uharibifu wa cache, ufunuo wa kichwa, au kukwepa udhibiti wa mbele ambapo vipengele vya chini vinareflect au kuhifadhi majibu.
+
+Kwa maelezo ya nyuma na michakato ya mwisho hadi mwisho:
+
+{{#ref}}
+-browser-http-request-smuggling.md
+{{#endref}}
+
+### Zana za kusaidia kuamua
+
+- HTTP Hacker (Burp BApp Store): inafichua tabia ya chini ya HTTP na muunganiko wa soketi.
+- "Uhamasishaji au kupitisha?" Burp Repeater Custom Action: https://github.com/PortSwigger/bambdas/blob/main/CustomAction/SmugglingOrPipelining.bambda
+- Turbo Intruder: udhibiti sahihi juu ya matumizi ya kurudi kupitia `requestsPerConnection`.
+- Burp HTTP Request Smuggler: inajumuisha uchunguzi wa hali ya muunganisho ili kugundua routing/validation ya ombi la kwanza.
+
+> [!NOTE]
+> Chukulia athari za matumizi ya kurudi pekee kama si masuala isipokuwa unaweza kuthibitisha desync upande wa seva na kuambatanisha athari halisi (kipande cha cache kilichoharibiwa, kichwa cha ndani kilichovuja kinachowezesha kukwepa mamlaka, udhibiti wa FE ulioepukwa, nk).
+
+## Kutumia Uhamasishaji wa Ombi la HTTP
+
+### Kupita Udhibiti wa Usalama wa Mbele kupitia Uhamasishaji wa Ombi la HTTP
+
+Wakati mwingine, proxies za mbele zinaweka hatua za usalama, zikichunguza maombi yanayoingia. Hata hivyo, hatua hizi zinaweza kupitishwa kwa kutumia Uhamasishaji wa Ombi la HTTP, kuruhusu ufikiaji usioidhinishwa kwa maeneo yaliyopigwa marufuku. Kwa mfano, kufikia `/admin` kunaweza kuwa marufuku nje, huku proxy ya mbele ikizuia juhudi kama hizo. Hata hivyo, proxy hii inaweza kupuuzia maombi yaliyojumuishwa ndani ya ombi la HTTP lililohamishwa, ikiacha pengo la kukwepa vizuizi hivi.
+
+Fikiria mifano ifuatayo inayoonyesha jinsi Uhamasishaji wa Ombi la HTTP unaweza kutumika kukwepa udhibiti wa usalama wa mbele, hasa ikilenga njia ya `/admin` ambayo kwa kawaida inalindwa na proxy ya mbele:

 **Mfano wa CL.TE**
 ```
@ -320,7 +426,7 @@ a=x
 0

 ```
-Kinyume chake, katika shambulio la TE.CL, ombi la awali la `POST` linatumia `Transfer-Encoding: chunked`, na ombi lililoingizwa linasindika kulingana na kichwa cha `Content-Length`. Kama ilivyo katika shambulio la CL.TE, proxy ya mbele inapuuzilia mbali ombi la smuggled `GET /admin`, bila kukusudia ikitoa ufikiaji kwa njia iliyo na vizuizi ya `/admin`.
+Kwa upande mwingine, katika shambulio la TE.CL, ombi la awali la `POST` linatumia `Transfer-Encoding: chunked`, na ombi lililoingizwa linasindika kulingana na kichwa cha `Content-Length`. Kama ilivyo katika shambulio la CL.TE, proxy ya mbele inapuuzilia mbali ombi la smuggled `GET /admin`, bila kukusudia ikitoa ufikiaji kwa njia iliyo na vizuizi ya `/admin`.

 ### Kufichua uandishi wa ombi la mbele <a href="#revealing-front-end-request-rewriting" id="revealing-front-end-request-rewriting"></a>

@ -343,17 +449,17 @@ Content-Length: 100

 search=
 ```
-Katika muundo huu, vipengele vya ombi vinavyofuata vinajumuishwa baada ya `search=`, ambayo ni parameter inayotolewa katika jibu. Hii itafichua vichwa vya ombi vinavyofuata.
+Katika muundo huu, vipengele vya ombi vinavyofuata vinajumuishwa baada ya `search=`, ambayo ni parameter inayojitokeza katika jibu. Hii itafichua vichwa vya ombi vinavyofuata.

-Ni muhimu kulinganisha kichwa cha `Content-Length` cha ombi lililo ndani na urefu halisi wa maudhui. Kuanzia na thamani ndogo na kuongeza taratibu inashauriwa, kwani thamani ya chini sana itakata data iliyotolewa, wakati thamani ya juu sana inaweza kusababisha ombi kufeli.
+Ni muhimu kulinganisha kichwa cha `Content-Length` cha ombi lililo ndani na urefu halisi wa maudhui. Kuanzia na thamani ndogo na kuongezeka taratibu inashauriwa, kwani thamani ya chini sana itakata data iliyojitokeza, wakati thamani ya juu sana inaweza kusababisha ombi kufeli.

-Teknolojia hii pia inatumika katika muktadha wa udhaifu wa TE.CL, lakini ombi linapaswa kumalizika na `search=\r\n0`. Bila kujali wahusika wa newline, thamani zitajumuishwa kwenye parameter ya utafutaji.
+Tekniki hii pia inatumika katika muktadha wa udhaifu wa TE.CL, lakini ombi linapaswa kumalizika na `search=\r\n0`. Bila kujali wahusika wa newline, thamani zitajumuishwa kwenye parameter ya utafutaji.

-Njia hii hasa inatumika kuelewa mabadiliko ya ombi yaliyofanywa na proxy ya mbele, kimsingi ikifanya uchunguzi wa kujiongoza.
+Njia hii hasa inatumika kuelewa mabadiliko ya ombi yaliyofanywa na proxy ya mbele, kimsingi ikifanya uchunguzi wa kujielekeza.

-### Kukamata maombi ya watumiaji wengine <a href="#capturing-other-users-requests" id="capturing-other-users-requests"></a>
+### Kukamata ombi za watumiaji wengine <a href="#capturing-other-users-requests" id="capturing-other-users-requests"></a>

-Ni rahisi kukamata maombi ya mtumiaji anayefuata kwa kuongeza ombi maalum kama thamani ya parameter wakati wa operesheni ya POST. Hapa kuna jinsi hii inaweza kufanywa:
+Ni rahisi kukamata ombi za mtumiaji anayefuata kwa kuongeza ombi maalum kama thamani ya parameter wakati wa operesheni ya POST. Hapa kuna jinsi hii inaweza kufanywa:

 Kwa kuongeza ombi lifuatalo kama thamani ya parameter, unaweza kuhifadhi ombi la mteja anayefuata:
 ```
@ -377,16 +483,16 @@ csrf=gpGAVAbj7pKq7VfFh45CAICeFCnancCM&postId=4&name=asdfghjklo&email=email%40ema
 ```
 Katika hali hii, **parameta ya maoni** inakusudia kuhifadhi maudhui ndani ya sehemu ya maoni ya chapisho kwenye ukurasa unaopatikana hadharani. Kwa hivyo, maudhui ya ombi linalofuata yataonekana kama maoni.

-Hata hivyo, mbinu hii ina mipaka. Kwa ujumla, inakamata data tu hadi kwenye kipimo cha parameta kilichotumika katika ombi lililosafirishwa. Kwa uwasilishaji wa fomu iliyohifadhiwa kwenye URL, kipimo hiki ni herufi `&`. Hii inamaanisha kuwa maudhui yaliyokamatwa kutoka kwa ombi la mtumiaji waathirika yatakoma kwenye `&` ya kwanza, ambayo inaweza hata kuwa sehemu ya mfuatano wa swali.
+Hata hivyo, mbinu hii ina mipaka. Kwa ujumla, inakamata data tu hadi kwenye kipimo cha parameta kilichotumika katika ombi lililosafirishwa. Kwa uwasilishaji wa fomu iliyo na URL-encoded, kipimo hiki ni herufi `&`. Hii ina maana kwamba maudhui yaliyokamatwa kutoka kwa ombi la mtumiaji waathirika yatakoma kwenye `&` ya kwanza, ambayo inaweza hata kuwa sehemu ya mfuatano wa swali.

-Zaidi ya hayo, inafaa kutaja kuwa mbinu hii pia inapatikana na udhaifu wa TE.CL. Katika hali kama hizo, ombi linapaswa kumalizika na `search=\r\n0`. Bila kujali wahusika wa mstari mpya, thamani zitajumuishwa kwenye parameta ya utafutaji.
+Zaidi ya hayo, inafaa kutaja kwamba njia hii pia inapatikana na udhaifu wa TE.CL. Katika hali kama hizo, ombi linapaswa kumalizika na `search=\r\n0`. Bila kujali wahusika wa mistari mipya, thamani zitajumuishwa kwenye parameta ya utafutaji.

 ### Kutumia HTTP request smuggling kutekeleza XSS iliyorejelewa

 HTTP Request Smuggling inaweza kutumika kutekeleza kurasa za wavuti zilizo hatarini kwa **Reflected XSS**, ikitoa faida kubwa:

 - Maingiliano na watumiaji wa lengo **hayahitajiki**.
- Inaruhusu kutekeleza XSS katika sehemu za ombi ambazo **kwa kawaida hazipatikani**, kama vichwa vya ombi la HTTP.
+- Inaruhusu matumizi ya XSS katika sehemu za ombi ambazo **kwa kawaida hazipatikani**, kama vichwa vya ombi la HTTP.

 Katika hali ambapo tovuti inakabiliwa na Reflected XSS kupitia kichwa cha User-Agent, mzigo ufuatao unaonyesha jinsi ya kutumia udhaifu huu:
 ```
@ -411,9 +517,9 @@ A=
 ```
 Hii payload imeundwa ili kutumia udhaifu kwa:

-1. Kuanzisha ombi la `POST`, ambalo linaonekana kuwa la kawaida, lenye kichwa cha `Transfer-Encoding: chunked` kuashiria kuanza kwa smuggling.
+1. Kuanzisha ombi la `POST`, ambalo linaonekana kuwa la kawaida, lenye kichwa cha `Transfer-Encoding: chunked` kuashiria mwanzo wa smuggling.
 2. Kufuatia na `0`, ikionyesha mwisho wa ujumbe wa chunked.
-3. Kisha, ombi la smuggled `GET` linaanzishwa, ambapo kichwa cha `User-Agent` kinachomekwa na script, `<script>alert(1)</script>`, ikichochea XSS wakati seva inashughulikia ombi hili linalofuata.
+3. Kisha, ombi la smuggled `GET` linaanzishwa, ambapo kichwa cha `User-Agent` kinajumuishwa na script, `<script>alert(1)</script>`, ikichochea XSS wakati seva inashughulikia ombi hili linalofuata.

 Kwa kubadilisha `User-Agent` kupitia smuggling, payload inakwepa vikwazo vya kawaida vya ombi, hivyo kutumia udhaifu wa Reflected XSS kwa njia isiyo ya kawaida lakini yenye ufanisi.

@ -422,9 +528,9 @@ Kwa kubadilisha `User-Agent` kupitia smuggling, payload inakwepa vikwazo vya kaw
 > [!CAUTION]
 > Ikiwa maudhui ya mtumiaji yanarejelewa katika jibu lenye **`Content-type`** kama **`text/plain`**, kuzuia utekelezaji wa XSS. Ikiwa seva inasaidia **HTTP/0.9 inaweza kuwa inawezekana kupita hii**!

-Toleo la HTTP/0.9 lilikuwa kabla ya 1.0 na linatumia tu vitenzi vya **GET** na **halijibu** kwa **headers**, bali tu mwili.
+Toleo la HTTP/0.9 lilikuwa kabla ya 1.0 na linatumia tu vitenzi vya **GET** na **halijibu** kwa **kichwa**, bali tu mwili.

-Katika [**hii andiko**](https://mizu.re/post/twisty-python), hii ilitumiwa vibaya na smuggling ya ombi na **nukta ya hatari ambayo itajibu na maudhui ya mtumiaji** ili smuggle ombi na HTTP/0.9. Kigezo ambacho kitarejelewa katika jibu kilikuwa na **jibu la uwongo la HTTP/1.1 (pamoja na headers na mwili)** hivyo jibu litakuwa na msimbo halali wa JS unaoweza kutekelezwa wenye `Content-Type` wa `text/html`.
+Katika [**hii andiko**](https://mizu.re/post/twisty-python), hii ilitumiwa vibaya na smuggling ya ombi na **nukta ya hatari ambayo itajibu na maudhui ya mtumiaji** ili smuggle ombi na HTTP/0.9. Kigezo ambacho kitarejelewa katika jibu kilikuwa na **jibu la uwongo la HTTP/1.1 (pamoja na vichwa na mwili)** hivyo jibu litakuwa na msimbo halali wa JS unaoweza kutekelezwa wenye `Content-Type` wa `text/html`.

 ### Kutumia Mwelekeo wa Kwenye Tovuti kwa HTTP Request Smuggling <a href="#exploiting-on-site-redirects-with-http-request-smuggling" id="exploiting-on-site-redirects-with-http-request-smuggling"></a>

@ -470,11 +576,11 @@ Katika hali hii, ombi la mtumiaji la faili la JavaScript linachukuliwa. Mshambul

 Upoisonaji wa kivinjari cha mtandao unaweza kutekelezwa ikiwa sehemu yoyote ya **miundombinu ya mbele inahifadhi maudhui**, kawaida ili kuboresha utendaji. Kwa kubadilisha jibu la seva, inawezekana **kuponya kivinjari**.

-Awali, tuliona jinsi majibu ya seva yanaweza kubadilishwa ili kurudisha kosa la 404 (rejelea [Mifano ya Msingi](#basic-examples)). Vivyo hivyo, inawezekana kumdanganya seva kutoa maudhui ya `/index.html` kama jibu la ombi la `/static/include.js`. Kwa hivyo, maudhui ya `/static/include.js` yanabadilishwa katika kivinjari na yale ya `/index.html`, na kufanya `/static/include.js` kuwa haipatikani kwa watumiaji, ambayo inaweza kusababisha Kukatizwa kwa Huduma (DoS).
+Awali, tuliona jinsi majibu ya seva yanaweza kubadilishwa ili kurudisha kosa la 404 (rejelea [Mifano ya Msingi](#basic-examples)). Vivyo hivyo, inawezekana kudanganya seva ili kutoa maudhui ya `/index.html` kama jibu la ombi la `/static/include.js`. Kwa hivyo, maudhui ya `/static/include.js` yanabadilishwa katika kivinjari na yale ya `/index.html`, na kufanya `/static/include.js` isiweze kupatikana kwa watumiaji, ambayo inaweza kusababisha Denial of Service (DoS).

-Tekniki hii inakuwa na nguvu hasa ikiwa **udhaifu wa Open Redirect** unapatikana au ikiwa kuna **kuhamasisha kwenye tovuti kwa redirect wazi**. Udhaifu kama huu unaweza kutumika kubadilisha maudhui yaliyohifadhiwa ya `/static/include.js` na skripti chini ya udhibiti wa mshambuliaji, kwa msingi inaruhusu shambulio la Cross-Site Scripting (XSS) dhidi ya wateja wote wanaoomba `/static/include.js` iliyosasishwa.
+Teknolojia hii inakuwa na nguvu hasa ikiwa kuna **udhaifu wa Open Redirect** ulio gundulika au ikiwa kuna **mwelekeo wa ndani kwa mwelekeo wazi**. Udukuzi kama huu unaweza kutumika kubadilisha maudhui yaliyohifadhiwa ya `/static/include.js` na script chini ya udhibiti wa mshambuliaji, hivyo kuwezesha shambulio la Cross-Site Scripting (XSS) dhidi ya wateja wote wanaotafuta `/static/include.js` iliyosasishwa.

-Hapa kuna mfano wa kutumia **upoisonaji wa kivinjari pamoja na kuhamasisha kwenye tovuti kwa redirect wazi**. Lengo ni kubadilisha maudhui ya kivinjari ya `/static/include.js` ili kutoa msimbo wa JavaScript unaodhibitiwa na mshambuliaji:
+Hapa kuna mfano wa kutumia **upoisonaji wa kivinjari pamoja na mwelekeo wa ndani kwa mwelekeo wazi**. Lengo ni kubadilisha maudhui ya kivinjari ya `/static/include.js` ili kutoa msimbo wa JavaScript unaodhibitiwa na mshambuliaji:
 ```
 POST / HTTP/1.1
 Host: vulnerable.net
@ -492,20 +598,20 @@ Content-Length: 10

 x=1
 ```
-Note ombi lililojumuishwa linalolenga `/post/next?postId=3`. Ombi hili litarejelewa kwa `/post?postId=4`, likitumia **thamani ya kichwa cha Host** kubaini kikoa. Kwa kubadilisha **kichwa cha Host**, mshambuliaji anaweza kurejelea ombi hilo kwa kikoa chao (**kuhamasisha kwenye tovuti ili kufungua kuhamasisha**).
+Kumbuka ombi lililojumuishwa linalolenga `/post/next?postId=3`. Ombi hili litarejelewa kwa `/post?postId=4`, likitumia **thamani ya kichwa cha Host** kubaini jina la kikoa. Kwa kubadilisha **kichwa cha Host**, mshambuliaji anaweza kuelekeza ombi hilo kwa kikoa chao (**mwelekeo wa ndani kuelekea mwelekeo wazi**).

-Baada ya **kuambukizwa kwa socket** kufanikiwa, **ombile la GET** kwa `/static/include.js` linapaswa kuanzishwa. Ombi hili litakuwa na maambukizi kutoka kwa ombi la awali la **kuhamasisha kwenye tovuti ili kufungua kuhamasisha** na kuchukua maudhui ya skripti inayodhibitiwa na mshambuliaji.
+Baada ya **kuharibu socket** kwa mafanikio, **ombile la GET** kwa `/static/include.js` linapaswa kuanzishwa. Ombi hili litakuwa na maambukizi kutoka kwa ombi la awali la **mwelekeo wa ndani kuelekea mwelekeo wazi** na kuchukua maudhui ya skripti inayodhibitiwa na mshambuliaji.

 Baadaye, ombi lolote kwa `/static/include.js` litatoa maudhui yaliyohifadhiwa ya skripti ya mshambuliaji, kwa ufanisi kuanzisha shambulio kubwa la XSS.

 ### Kutumia HTTP request smuggling kufanya udanganyifu wa cache ya wavuti <a href="#using-http-request-smuggling-to-perform-web-cache-deception" id="using-http-request-smuggling-to-perform-web-cache-deception"></a>

-> **Ni tofauti gani kati ya kuambukizwa kwa cache ya wavuti na udanganyifu wa cache ya wavuti?**
+> **Ni tofauti gani kati ya kuharibu cache ya wavuti na udanganyifu wa cache ya wavuti?**
 >
-> - Katika **kuambukizwa kwa cache ya wavuti**, mshambuliaji anasababisha programu kuhifadhi maudhui fulani ya uharibifu katika cache, na maudhui haya yanatolewa kutoka kwenye cache kwa watumiaji wengine wa programu.
-> - Katika **udanganyifu wa cache ya wavuti**, mshambuliaji anasababisha programu kuhifadhi maudhui fulani nyeti yanayomilikiwa na mtumiaji mwingine katika cache, na mshambuliaji kisha anachukua maudhui haya kutoka kwenye cache.
+> - Katika **kuharibu cache ya wavuti**, mshambuliaji anasababisha programu kuhifadhi maudhui mabaya katika cache, na maudhui haya yanatolewa kutoka kwenye cache kwa watumiaji wengine wa programu.
+> - Katika **udanganyifu wa cache ya wavuti**, mshambuliaji anasababisha programu kuhifadhi maudhui nyeti yanayomilikiwa na mtumiaji mwingine katika cache, na mshambuliaji kisha anapata maudhui haya kutoka kwenye cache.

-Mshambuliaji anaunda ombi lililofichwa linalochukua maudhui nyeti ya mtumiaji maalum. Fikiria mfano ufuatao:
+Mshambuliaji anaunda ombi lililofichwa linalopata maudhui nyeti ya mtumiaji maalum. Fikiria mfano ufuatao:
 ```markdown
 `POST / HTTP/1.1`\
 `Host: vulnerable-website.com`\
@ -516,11 +622,11 @@ Mshambuliaji anaunda ombi lililofichwa linalochukua maudhui nyeti ya mtumiaji ma
 `GET /private/messages HTTP/1.1`\
 `Foo: X`
 ```
-Ikiwa ombi hili lililofichwa linachafua kipengee cha cache kilichokusudiwa kwa maudhui ya statiki (kwa mfano, `/someimage.png`), data nyeti za mwathirika kutoka `/private/messages` zinaweza kuhifadhiwa chini ya kipengee cha cache cha maudhui ya statiki. Kwa hivyo, mshambuliaji anaweza kupata data hizi nyeti zilizohifadhiwa.
+Ikiwa ombi hili lililofichwa linachafua kipengee cha cache kilichokusudiwa kwa maudhui ya kudumu (kwa mfano, `/someimage.png`), data nyeti za mwathirika kutoka `/private/messages` zinaweza kuhifadhiwa chini ya kipengee cha cache cha maudhui ya kudumu. Kwa hivyo, mshambuliaji anaweza kupata data hizi nyeti zilizohifadhiwa.

 ### Kutumia TRACE kupitia HTTP Request Smuggling <a href="#exploiting-web-cache-poisoning-via-http-request-smuggling" id="exploiting-web-cache-poisoning-via-http-request-smuggling"></a>

-[**Katika chapisho hili**](https://portswigger.net/research/trace-desync-attack) inapendekezwa kwamba ikiwa seva ina njia ya TRACE iliyoanzishwa inaweza kuwa inawezekana kuitumia vibaya na HTTP Request Smuggling. Hii ni kwa sababu njia hii itarejesha kichwa chochote kilichotumwa kwa seva kama sehemu ya mwili wa jibu. Kwa mfano:
+[**Katika chapisho hili**](https://portswigger.net/research/trace-desync-attack) inapendekezwa kwamba ikiwa seva ina njia ya TRACE iliyoanzishwa inaweza kuwa inawezekana kuitumia vibaya na HTTP Request Smuggling. Hii ni kwa sababu njia hii itareflect kila kichwa kilichotumwa kwa seva kama sehemu ya mwili wa jibu. Kwa mfano:
 ```
 TRACE / HTTP/1.1
 Host: example.com
@ -539,13 +645,13 @@ X-Forwarded-For: xxx.xxx.xxx.xxx
 ```
 Mfano wa jinsi ya kutumia tabia hii ungekuwa **kuficha kwanza ombi la HEAD**. Ombi hili litajibiwa kwa **vichwa** vya ombi la GET (**`Content-Type`** miongoni mwao). Na kuficha **moja kwa moja baada ya HEAD ombi la TRACE**, ambalo litakuwa **linarejelea data iliyotumwa**.\
 Kwa kuwa jibu la HEAD litakuwa na kichwa cha `Content-Length`, **jibu la ombi la TRACE litachukuliwa kama mwili wa jibu la HEAD, hivyo kuonyesha data isiyo na mipaka** katika jibu.\
-Jibu hili litatumwa kwa ombi linalofuata kupitia muunganisho, hivyo hili linaweza **kutumika katika faili ya JS iliyohifadhiwa kwa mfano kuingiza msimbo wa JS usio na mipaka**.
+Jibu hili litatumwa kwa ombi linalofuata kupitia muunganisho, hivyo hili linaweza **kutumika katika faili la JS lililohifadhiwa kwa mfano kuingiza msimbo wa JS usio na mipaka**.

 ### Kutumia TRACE kupitia HTTP Response Splitting <a href="#exploiting-web-cache-poisoning-via-http-request-smuggling" id="exploiting-web-cache-poisoning-via-http-request-smuggling"></a>

-Endelea kufuata [**hii chapisho**](https://portswigger.net/research/trace-desync-attack) inapendekezwa njia nyingine ya kutumia mbinu ya TRACE. Kama ilivyotajwa, kuficha ombi la HEAD na ombi la TRACE inawezekana **kudhibiti baadhi ya data inayorejelewa** katika jibu la ombi la HEAD. Urefu wa mwili wa ombi la HEAD kimsingi unatajwa katika kichwa cha Content-Length na unaundwa na jibu la ombi la TRACE.
+Endelea kufuata [**hiki kipande**](https://portswigger.net/research/trace-desync-attack) kinapendekeza njia nyingine ya kutumia mbinu ya TRACE. Kama ilivyotajwa, kuficha ombi la HEAD na ombi la TRACE inawezekana **kudhibiti baadhi ya data inayorejelewa** katika jibu la ombi la HEAD. Urefu wa mwili wa ombi la HEAD kimsingi unashauriwa katika kichwa cha Content-Length na unaundwa na jibu la ombi la TRACE.

-Hivyo, wazo jipya lingeweza kuwa, kujua Content-Length hii na data iliyotolewa katika jibu la TRACE, inawezekana kufanya jibu la TRACE liwe na jibu halali la HTTP baada ya byte ya mwisho ya Content-Length, ikiruhusu mshambuliaji kudhibiti kabisa ombi kwa jibu linalofuata (ambalo linaweza kutumika kufanya uchafuzi wa cache).
+Kwa hivyo, wazo jipya lingeweza kuwa, kujua Content-Length hii na data iliyotolewa katika jibu la TRACE, inawezekana kufanya jibu la TRACE liwe na jibu halali la HTTP baada ya byte ya mwisho ya Content-Length, ikiruhusu mshambuliaji kudhibiti kabisa ombi kwa jibu linalofuata (ambalo linaweza kutumika kufanya uharibifu wa cache).

 Mfano:
 ```
@ -609,7 +715,7 @@ browser-http-request-smuggling.md
 request-smuggling-in-http-2-downgrades.md
 {{#endref}}

-## Skripti za Turbo intruder
+## Turbo intruder scripts

 ### CL.TE

@ -698,12 +804,14 @@ table.add(req)
 ```
 ## Tools

+- HTTP Hacker (Burp BApp Store) – onyesha muunganiko/uundaji na tabia ya chini ya HTTP
+- 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/anshumanpattnaik/http-request-smuggling)
 - [https://github.com/PortSwigger/http-request-smuggler](https://github.com/PortSwigger/http-request-smuggler)
 - [https://github.com/gwen001/pentest-tools/blob/master/smuggler.py](https://github.com/gwen001/pentest-tools/blob/master/smuggler.py)
 - [https://github.com/defparam/smuggler](https://github.com/defparam/smuggler)
 - [https://github.com/Moopinger/smugglefuzz](https://github.com/Moopinger/smugglefuzz)
- [https://github.com/bahruzjabiyev/t-reqs-http-fuzzer](https://github.com/bahruzjabiyev/t-reqs-http-fuzzer): Chombo hiki ni Fuzzer ya HTTP inayotumia sarufi ambayo ni muhimu katika kutafuta tofauti za ajabu za kuomba smuggling.
+- [https://github.com/bahruzjabiyev/t-reqs-http-fuzzer](https://github.com/bahruzjabiyev/t-reqs-http-fuzzer): Chombo hiki ni Fuzzer ya HTTP inayotegemea sarufi inayofaa kutafuta tofauti za ajabu za uundaji wa ombi.

 ## References

@ -716,6 +824,10 @@ table.add(req)
 - [https://standoff365.com/phdays10/schedule/tech/http-request-smuggling-via-higher-http-versions/](https://standoff365.com/phdays10/schedule/tech/http-request-smuggling-via-higher-http-versions/)
 - [https://portswigger.net/research/trace-desync-attack](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/](https://www.bugcrowd.com/blog/unveiling-te-0-http-request-smuggling-discovering-a-critical-vulnerability-in-thousands-of-google-cloud-websites/)
+- Jihadharini na false false‑positive: jinsi ya kutofautisha HTTP pipelining kutoka kwa uundaji wa ombi – [https://portswigger.net/research/how-to-distinguish-http-pipelining-from-request-smuggling](https://portswigger.net/research/how-to-distinguish-http-pipelining-from-request-smuggling)
+- [https://http1mustdie.com/](https://http1mustdie.com/)
+- Browser‑Powered Desync Attacks – [https://portswigger.net/research/browser-powered-desync-attacks](https://portswigger.net/research/browser-powered-desync-attacks)
+- PortSwigger Academy – desync upande wa mteja – [https://portswigger.net/web-security/request-smuggling/browser/client-side-desync](https://portswigger.net/web-security/request-smuggling/browser/client-side-desync)


 {{#include ../../banners/hacktricks-training.md}}
--- a/src/pentesting-web/http-request-smuggling/browser-http-request-smuggling.md
+++ b/src/pentesting-web/http-request-smuggling/browser-http-request-smuggling.md
@ -2,6 +2,22 @@

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

-**Angalia posti [https://portswigger.net/research/browser-powered-desync-attacks](https://portswigger.net/research/browser-powered-desync-attacks)**
+Browser-powered desync (pia client-side request smuggling) inatumia kivinjari cha mwathirika kuingiza ombi lililo na muundo mbaya kwenye muunganisho wa pamoja ili ombi zinazofuata zipaswe kwa kutokulingana na kipengele cha chini. Tofauti na smuggling ya jadi ya FE↔BE, mzigo umefungwa na kile ambacho kivinjari kinaweza kutuma kisheria kati ya vyanzo tofauti.
+
+Key constraints and tips
+- Tumia tu vichwa na sintaksia ambayo kivinjari kinaweza kutoa kupitia urambazaji, fetch, au uwasilishaji wa fomu. Ujanja wa vichwa (LWS tricks, duplicate TE, invalid CL) kwa ujumla hautatumika.
+- Lenga maeneo ya mwisho na wapatanishi wanaoonyesha maoni au kuhifadhi majibu. Athari zinazofaa ni pamoja na kuharibu cache, kuvuja vichwa vilivyowekwa kwenye upande wa mbele, au kupita udhibiti wa njia/method kwenye upande wa mbele.
+- Kurejelea ni muhimu: sambaza ombi lililotengenezwa ili liwe na muunganisho sawa wa HTTP/1.1 au H2 kama ombi la mwathirika wa thamani kubwa. Tabia zilizofungwa kwenye muunganisho/zilizo na hali huongeza athari.
+- Prefer primitives ambazo hazihitaji vichwa maalum: kuchanganya njia, kuingiza mfuatano wa swali, na kuunda mwili kupitia POST zilizowekwa kwa fomu.
+- Thibitisha kutokulingana kwa upande wa seva halisi dhidi ya artefacts za tu pipelining kwa kujaribu tena bila kurejelea, au kwa kutumia ukaguzi wa majibu ya ndani ya HTTP/2.
+
+For end-to-end techniques and PoCs see:
+- PortSwigger Research – 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
+
+## References
+- [https://portswigger.net/research/browser-powered-desync-attacks](https://portswigger.net/research/browser-powered-desync-attacks)
+- [https://portswigger.net/web-security/request-smuggling/browser/client-side-desync](https://portswigger.net/web-security/request-smuggling/browser/client-side-desync)
+- Distinguishing pipelining vs smuggling (background on reuse false-positives): https://portswigger.net/research/how-to-distinguish-http-pipelining-from-request-smuggling

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