diff --git a/src/pentesting-web/csrf-cross-site-request-forgery.md b/src/pentesting-web/csrf-cross-site-request-forgery.md
index 4212096f3..144b1971d 100644
--- a/src/pentesting-web/csrf-cross-site-request-forgery.md
+++ b/src/pentesting-web/csrf-cross-site-request-forgery.md
@@ -2,85 +2,113 @@
{{#include ../banners/hacktricks-training.md}}
-## Maelezo ya Cross-Site Request Forgery (CSRF)
+## Cross-Site Request Forgery (CSRF) Explained
-**Cross-Site Request Forgery (CSRF)** ni aina ya udhaifu wa usalama unaopatikana katika programu za wavuti. Inawawezesha washambuliaji kufanya vitendo kwa niaba ya watumiaji wasiojua kwa kutumia vikao vyao vilivyothibitishwa. Shambulio linafanyika wakati mtumiaji, ambaye amejiandikisha kwenye jukwaa la mwathirika, anatembelea tovuti mbaya. Tovuti hii kisha inasababisha maombi kwa akaunti ya mwathirika kupitia mbinu kama vile kutekeleza JavaScript, kuwasilisha fomu, au kupakua picha.
+**Cross-Site Request Forgery (CSRF)** ni aina ya udhaifu wa usalama inayopatikana katika web applications. Inaruhusu watapeli kufanya vitendo kwa niaba ya watumiaji wasiofahamu kwa kutumia vikao vyao vilivyoidhinishwa. Shambulio hufanyika wakati mtumiaji aliyeingia kwenye jukwaa la mwathirika anapotembelea tovuti yenye madhara. Tovuti hii kisha inaanzisha maombi kwa akaunti ya mwathirika kupitia njia kama kutekeleza JavaScript, kutuma forms, au kupakua images.
-### Masharti ya Shambulio la CSRF
+### Prerequisites for a CSRF Attack
-Ili kutumia udhaifu wa CSRF, masharti kadhaa yanapaswa kutimizwa:
+Ili kutumia udhaifu wa CSRF, masharti kadhaa yanapaswa kukidhiwa:
-1. **Tambua Kitendo Chenye Thamani**: Mshambuliaji anahitaji kupata kitendo kinachostahili kutumiwa, kama kubadilisha nenosiri la mtumiaji, barua pepe, au kuongeza mamlaka.
-2. **Usimamizi wa Kikao**: Kikao cha mtumiaji kinapaswa kusimamiwa pekee kupitia vidakuzi au kichwa cha HTTP Basic Authentication, kwani vichwa vingine haviwezi kubadilishwa kwa kusudi hili.
-3. **Ukosefu wa Vigezo Visivyoweza Kutabirika**: Ombi halipaswi kuwa na vigezo visivyoweza kutabirika, kwani vinaweza kuzuia shambulio.
+1. **Identify a Valuable Action**: Mshambuliaji anahitaji kupata kitendo chenye thamani ya kuchukuliwa, kama kubadilisha nywila (password) ya mtumiaji, barua pepe (email), au kuongeza privileges.
+2. **Session Management**: Kikao cha mtumiaji kinapaswa kusimamiwa tu kupitia cookies au header ya HTTP Basic Authentication, kwani headers nyingine haziwezi kudhibitiwa kwa madhumuni haya.
+3. **Absence of Unpredictable Parameters**: Ombi halipaswi kuwa na vigezo visivyo tabirika (unpredictable parameters), kwani vinaweza kuzuia shambulio.
-### Ukaguzi wa Haraka
+### Quick Check
-Unaweza **kukamata ombi katika Burp** na kuangalia ulinzi wa CSRF na kujaribu kutoka kwa kivinjari unaweza kubofya **Nakili kama fetch** na kuangalia ombi:
+Unaweza **capture the request in Burp** na kukagua ulinzi wa CSRF; pia kwa kujaribu kutoka kivinjari unaweza kubofya **Copy as fetch** na kukagua ombi:
-### Kujilinda Dhidi ya CSRF
+### Defending Against CSRF
-Mbinu kadhaa zinaweza kutekelezwa ili kujilinda dhidi ya shambulio la CSRF:
+Mbinu kadhaa za kujikinga zinaweza kutumika kuzuia mashambulio ya CSRF:
-- [**Vidakuzi vya SameSite**](hacking-with-cookies/index.html#samesite): Sifa hii inazuia kivinjari kutuma vidakuzi pamoja na maombi ya tovuti tofauti. [Zaidi kuhusu vidakuzi vya SameSite](hacking-with-cookies/index.html#samesite).
-- [**Kushiriki rasilimali za asili tofauti**](cors-bypass.md): Sera ya CORS ya tovuti ya mwathirika inaweza kuathiri uwezekano wa shambulio, hasa ikiwa shambulio linahitaji kusoma jibu kutoka kwa tovuti ya mwathirika. [Jifunze kuhusu CORS bypass](cors-bypass.md).
-- **Uthibitisho wa Mtumiaji**: Kuuliza nenosiri la mtumiaji au kutatua captcha kunaweza kuthibitisha nia ya mtumiaji.
-- **Kuangalia Vichwa vya Referrer au Origin**: Kuangalia vichwa hivi kunaweza kusaidia kuhakikisha maombi yanatoka kwa vyanzo vinavyotegemewa. Hata hivyo, kuunda URL kwa uangalifu kunaweza kupita ukaguzi usiofaa, kama:
-- Kutumia `http://mal.net?orig=http://example.com` (URL inaishia na URL inayotegemewa)
-- Kutumia `http://example.com.mal.net` (URL inaanza na URL inayotegemewa)
-- **Kubadilisha Majina ya Vigezo**: Kubadilisha majina ya vigezo katika maombi ya POST au GET kunaweza kusaidia kuzuia mashambulizi ya kiotomatiki.
-- **Tokens za CSRF**: Kuingiza token ya kipekee ya CSRF katika kila kikao na kuhitaji token hii katika maombi yanayofuata kunaweza kupunguza hatari ya CSRF kwa kiasi kikubwa. Ufanisi wa token unaweza kuimarishwa kwa kutekeleza CORS.
+- [**SameSite cookies**](hacking-with-cookies/index.html#samesite): Sifa hii inazuia kivinjari kutuma cookies pamoja na maombi ya cross-site. [More about SameSite cookies](hacking-with-cookies/index.html#samesite).
+- [**Cross-origin resource sharing**](cors-bypass.md): Sera ya CORS ya tovuti ya mwathirika inaweza kuathiri uwezekano wa shambulio, hasa ikiwa shambulio linahitaji kusoma response kutoka tovuti ya mwathirika. [Learn about CORS bypass](cors-bypass.md).
+- **User Verification**: Kuomba nywila ya mtumiaji au kutatua captcha kunaweza kuthibitisha nia ya mtumiaji.
+- **Checking Referrer or Origin Headers**: Kuthibitisha headers hizi kunaweza kusaidia kuhakikisha maombi yanatoka kwa vyanzo vinavyoaminika. Hata hivyo, uundaji makini wa URL unaweza kuepuka ukaguzi usiofanywa vizuri, kama vile:
+- Using `http://mal.net?orig=http://example.com` (URL ends with the trusted URL)
+- Using `http://example.com.mal.net` (URL starts with the trusted URL)
+- **Modifying Parameter Names**: Kubadilisha majina ya vigezo katika POST au GET requests kunaweza kusaidia kuzuia mashambulizi yaliyopangwa.
+- **CSRF Tokens**: Kuingiza token ya CSRF ya kipekee katika kila session na kuhitaji token hii katika maombi ya baadaye kunaweza kupunguza kwa kiasi kikubwa hatari ya CSRF. Ufanisi wa token unaweza kuongezwa kwa kutekeleza CORS.
-Kuelewa na kutekeleza ulinzi huu ni muhimu kwa kudumisha usalama na uaminifu wa programu za wavuti.
+Kuelewa na kutekeleza kinga hizi ni muhimu kwa kudumisha usalama na uadilifu wa web applications.
-## Kupita Ulinzi
+## Defences Bypass
-### Kutoka POST hadi GET
+### From POST to GET (method-conditioned CSRF validation bypass)
-Labda fomu unayotaka kutumia inPrepared kupeleka **ombii la POST lenye token ya CSRF lakini**, unapaswa **kuangalia** ikiwa **GET** pia ni **halali** na ikiwa unapoweka ombi la GET **token ya CSRF bado inathibitishwa**.
+Baadhi ya applications zinatekeleza uthibitishaji wa CSRF tu kwa POST huku zikiruhusu verbs nyingine bila kuthibitisha. Anti-pattern ya kawaida katika PHP inaonekana kama:
+```php
+public function csrf_check($fatal = true) {
+if ($_SERVER['REQUEST_METHOD'] !== 'POST') return true; // GET, HEAD, etc. bypass CSRF
+// ... validate __csrf_token here ...
+}
+```
+Ikiwa endpoint iliyoko dhaifu inakubali pia vigezo kutoka $_REQUEST, unaweza kuanzisha tena hatua ileile kama ombi la GET na kuondoa kabisa CSRF token. Hii inabadilisha kitendo kilichokengeuzwa kwa POST kuwa kitendo cha GET kinachofanikiwa bila token.
-### Ukosefu wa token
+Example:
-Programu zinaweza kutekeleza mekanismu ya **kuhakiki token** wakati zipo. Hata hivyo, udhaifu unatokea ikiwa uthibitisho unakosekana kabisa wakati token haipo. Washambuliaji wanaweza kutumia hii kwa **kuondoa parameter** inayobeba token, si tu thamani yake. Hii inawawezesha kupita mchakato wa uthibitisho na kufanya shambulio la Cross-Site Request Forgery (CSRF) kwa ufanisi.
+- Original POST with token (intended):
-### Token ya CSRF haijafungwa kwa kikao cha mtumiaji
+```http
+POST /index.php?module=Home&action=HomeAjax&file=HomeWidgetBlockList HTTP/1.1
+Content-Type: application/x-www-form-urlencoded
-Programu **zisizofunga token za CSRF kwa vikao vya watumiaji** zina hatari kubwa ya **usalama**. Mifumo hii inathibitisha token dhidi ya **hifadhi ya kimataifa** badala ya kuhakikisha kila token inafungwa kwa kikao kinachoanzisha.
+__csrf_token=sid:...&widgetInfoList=[{"widgetId":"https://attacker","widgetType":"URL"}]
+```
-Hapa kuna jinsi washambuliaji wanavyotumia hii:
+- Bypass by switching to GET (no token):
-1. **Thibitisha** kwa kutumia akaunti yao wenyewe.
-2. **Pata token halali ya CSRF** kutoka kwa hifadhi ya kimataifa.
-3. **Tumia token hii** katika shambulio la CSRF dhidi ya mwathirika.
+```http
+GET /index.php?module=Home&action=HomeAjax&file=HomeWidgetBlockList&widgetInfoList=[{"widgetId":"https://attacker","widgetType":"URL"}] HTTP/1.1
+```
-Udhaifu huu unawawezesha washambuliaji kufanya maombi yasiyoidhinishwa kwa niaba ya mwathirika, wakitumia **mchakato wa uthibitisho wa token usiofaa** wa programu.
+Notes:
+- Mfumo huu mara nyingi huonekana pamoja na reflected XSS ambapo majibu hutumwa vibaya kama text/html badala ya application/json.
+- Kuunganisha hili na XSS kunapunguza sana vizingiti vya unyonyaji kwa sababu unaweza kuwasilisha kiungo kimoja cha GET kinachosababisha njia ya msimbo iliyo dhaifu na pia kuepuka ukaguzi wa CSRF kabisa.
-### Kupita Mbinu
+### Lack of token
-Ikiwa ombi linatumia "**mbinu**" **isiyo ya kawaida**, angalia ikiwa **kazi ya kubadilisha mbinu** inafanya kazi. Kwa mfano, ikiwa inatumia mbinu ya **PUT** unaweza kujaribu **kutumia mbinu ya POST** na **kutuma**: _https://example.com/my/dear/api/val/num?**\_method=PUT**_
+Programu zinaweza kutekeleza utaratibu wa **thibitisha tokens** wakati zinapokuwepo. Hata hivyo, udhaifu unatokea ikiwa uthibitishaji unarukwa kabisa wakati token haipo. Wadukuzi wanaweza kuchukua fursa ya hili kwa **kuondoa parameter** inayobeba token, si tu thamani yake. Hii inawaruhusu kupita kwenye mchakato wa uthibitishaji na kufanya shambulio la Cross-Site Request Forgery (CSRF) kwa ufanisi.
-Hii inaweza pia kufanya kazi kwa kutuma **parameter ya \_method ndani ya ombi la POST** au kutumia **vichwa**:
+### CSRF token is not tied to the user session
+
+Programu zinazokosa **kufunga CSRF tokens kwa sessions za watumiaji** zinaonyesha hatari kubwa ya **usalama**. Mifumo hii inathibitisha tokens dhidi ya **global pool** badala ya kuhakikisha kila token imefungwa kwa session iliilochochea.
+
+Hivi ndivyo wadukuzi wanavyofaidika na hili:
+
+1. **Jithibitishie** kwa kutumia akaunti yao.
+2. **Pata CSRF token halali** kutoka global pool.
+3. **Tumia token hii** katika shambulio la CSRF dhidi ya mhanga.
+
+Udhaifu huu unawawezesha wadukuzi kufanya maombi yasiyoruhusiwa kwa niaba ya mhanga, kwa kuchukua faida ya **utaratibu usiofaa wa uthibitishaji wa token**.
+
+### Method bypass
+
+Ikiwa ombi linatumia "**weird**" **method**, angalia kama **method override functionality** inafanya kazi. Kwa mfano, ikiwa inatumia **PUT** method unaweza kujaribu **kutumia POST** method na **kutuma**: _https://example.com/my/dear/api/val/num?**\_method=PUT**_
+
+Hii pia inaweza kufanya kazi kwa kutuma **\_method parameter inside the a POST request** au kwa kutumia **headers**:
- _X-HTTP-Method_
- _X-HTTP-Method-Override_
- _X-Method-Override_
-### Kupita Uthibitisho wa Kichwa cha Kijadi
+### Custom header token bypass
-Ikiwa ombi linaongeza **kichwa cha kawaida** chenye **token** kwa ombi kama **mbinu ya ulinzi wa CSRF**, basi:
+Ikiwa ombi linaongeza a **custom header** yenye **token** kwenye ombi kama **CSRF protection method**, basi:
-- Jaribu ombi bila **Token ya Kijadi na pia kichwa.**
-- Jaribu ombi lenye **urefu sawa lakini token tofauti**.
+- Jaribu ombi bila **Customized Token and also header.**
+- Jaribu ombi kwa **ule ule urefu lakini token tofauti**.
-### Token ya CSRF inathibitishwa na cookie
+### CSRF token is verified by a cookie
-Programu zinaweza kutekeleza ulinzi wa CSRF kwa kuiga token katika cookie na parameter ya ombi au kwa kuweka cookie ya CSRF na kuangalia ikiwa token iliyotumwa kwenye backend inalingana na cookie. Programu inathibitisha maombi kwa kuangalia ikiwa token katika parameter ya ombi inalingana na thamani katika cookie.
+Programu zinaweza kutekeleza ulinzi wa CSRF kwa kuiga token katika cookie na pia parameter ya ombi au kwa kuweka CSRF cookie na kuthibitisha kama token iliyotumwa kwa backend inaendana na cookie. Programu inathibitisha maombi kwa kuangalia kama token katika parameter ya ombi inalingana na thamani ya cookie.
-Hata hivyo, mbinu hii ina udhaifu kwa mashambulizi ya CSRF ikiwa tovuti ina kasoro zinazomruhusu mshambuliaji kuweka cookie ya CSRF kwenye kivinjari cha mwathirika, kama vile udhaifu wa CRLF. Mshambuliaji anaweza kutumia hii kwa kupakia picha ya udanganyifu inayoweka cookie, ikifuatiwa na kuanzisha shambulio la CSRF.
+Hata hivyo, njia hii ni nyeti kwa mashambulizi ya CSRF ikiwa tovuti ina kasoro zinazoruhusu mshambuliaji kuweka CSRF cookie katika kivinjari cha mhanga, kama vile udhaifu wa CRLF. Mshambuliaji anaweza kutumia hili kwa kupakia picha ya udanganyifu inayoweka cookie, ikifuatiwa na kuanzisha shambulio la CSRF.
-Hapa kuna mfano wa jinsi shambulio linaweza kuundwa:
+Chini ni mfano wa jinsi shambulio linaweza kujengwa:
```html
@@ -103,19 +131,19 @@ onerror="document.forms[0].submit();" />
```
> [!TIP]
-> Kumbuka kwamba ikiwa **csrf token inahusiana na session cookie shambulio hili halitafanya kazi** kwa sababu utahitaji kuweka mwathirika kwenye session yako, na hivyo utakuwa unajishambulia mwenyewe.
+> Kumbuka kwamba ikiwa **csrf token is related with the session cookie this attack won't work** kwa sababu utahitaji kumtumia victim session yako, na kwa hivyo utakuwa unamshambulia wewe mwenyewe.
-### Mabadiliko ya Aina ya Maudhui
+### Mabadiliko ya Content-Type
-Kulingana na [**hii**](https://developer.mozilla.org/en-US/docs/Web/HTTP/CORS#simple_requests), ili **kuepuka** maombi ya **preflight** kutumia njia ya **POST** hizi ndizo thamani za Aina ya Maudhui zinazoruhusiwa:
+Kwa mujibu wa [**this**](https://developer.mozilla.org/en-US/docs/Web/HTTP/CORS#simple_requests), ili kuepuka **preflight** requests zinapotumia method ya **POST**, haya ni maadili ya Content-Type yaliyoruhusiwa:
- **`application/x-www-form-urlencoded`**
- **`multipart/form-data`**
- **`text/plain`**
-Hata hivyo, kumbuka kwamba **mantiki ya seva inaweza kutofautiana** kulingana na **Aina ya Maudhui** iliyotumika hivyo unapaswa kujaribu thamani zilizotajwa na nyingine kama **`application/json`**_**,**_**`text/xml`**, **`application/xml`**_._
+Hata hivyo, kumbuka kwamba **mantiki ya seva inaweza kutofautiana** kulingana na **Content-Type** inayotumika, hivyo unapaswa kujaribu maadili yaliyotajwa na mengine kama **`application/json`**_**,**_**`text/xml`**, **`application/xml`**_._
-Mfano (kutoka [hapa](https://brycec.me/posts/corctf_2021_challenges)) wa kutuma data ya JSON kama text/plain:
+Mfano (from [here](https://brycec.me/posts/corctf_2021_challenges)) wa kutuma data ya JSON kama text/plain:
```html
@@ -134,23 +162,23 @@ form.submit()
```
-### Kupita Maombi ya Preflight kwa Data ya JSON
+### Kuepuka Maombi ya Preflight kwa Data ya JSON
-Wakati wa kujaribu kutuma data ya JSON kupitia ombi la POST, kutumia `Content-Type: application/json` katika fomu ya HTML si rahisi moja kwa moja. Vivyo hivyo, kutumia `XMLHttpRequest` kutuma aina hii ya maudhui huanzisha ombi la preflight. Hata hivyo, kuna mikakati ya kuweza kupita kikomo hiki na kuangalia kama seva inashughulikia data ya JSON bila kujali Aina ya Maudhui:
+Unapojaribu kutuma data ya JSON kupitia POST request, kutumia `Content-Type: application/json` katika fomu ya HTML siyo moja kwa moja inawezekana. Vivyo hivyo, kutumia `XMLHttpRequest` kutuma aina hii ya maudhui kunaanzisha preflight request. Hata hivyo, kuna mbinu zinazoweza kujaribu kuepuka kikomo hiki na kuangalia kama server inasindika data ya JSON bila kujali Content-Type:
-1. **Tumia Aina Mbadala za Maudhui**: Tumia `Content-Type: text/plain` au `Content-Type: application/x-www-form-urlencoded` kwa kuweka `enctype="text/plain"` katika fomu. Njia hii inajaribu kuangalia kama backend inatumia data bila kujali Aina ya Maudhui.
-2. **Badilisha Aina ya Maudhui**: Ili kuepuka ombi la preflight huku ukihakikisha seva inatambua maudhui kama JSON, unaweza kutuma data na `Content-Type: text/plain; application/json`. Hii haisababishi ombi la preflight lakini inaweza kushughulikiwa ipasavyo na seva ikiwa imewekwa kukubali `application/json`.
-3. **Matumizi ya Faili ya SWF Flash**: Njia isiyo ya kawaida lakini inayowezekana inahusisha kutumia faili ya SWF flash ili kupita vizuizi kama hivi. Kwa ufahamu wa kina wa mbinu hii, rejelea [this post](https://anonymousyogi.medium.com/json-csrf-csrf-that-none-talks-about-c2bf9a480937).
+1. **Tumia Aina Mbadala za Content-Type**: Tumia `Content-Type: text/plain` au `Content-Type: application/x-www-form-urlencoded` kwa kuweka `enctype="text/plain"` kwenye fomu. Njia hii inajaribu kama backend inatumia data bila kujali Content-Type.
+2. **Badilisha Content Type**: Ili kuepuka preflight request wakati ukihakikisha server inatambua maudhui kama JSON, unaweza kutuma data na `Content-Type: text/plain; application/json`. Hii haitasababisha preflight request lakini inaweza kushughulikiwa ipasavyo na server ikiwa imewekwa kukubali `application/json`.
+3. **Matumizi ya faili za SWF Flash**: Njia isiyo ya kawaida lakini inayowezekana inahusisha kutumia faili ya SWF flash kuepuka vikwazo hivi. Kwa ufahamu wa kina wa mbinu hii, rejea [this post](https://anonymousyogi.medium.com/json-csrf-csrf-that-none-talks-about-c2bf9a480937).
-### Kupita Ukaguzi wa Referrer / Origin
+### Kuepuka ukaguzi wa Referrer / Origin
-**Epuka kichwa cha Referrer**
+**Epuka header ya Referer**
-Programu zinaweza kuthibitisha kichwa cha 'Referer' tu wakati kiko. Ili kuzuia kivinjari kutuma kichwa hiki, tag hii ya meta ya HTML inaweza kutumika:
+Maombi yanaweza kuthibitisha header ya 'Referer' tu pale inapokuwepo. Ili kuzuia browser kutuma header hii, tagu ya meta ya HTML ifuatayo inaweza kutumika:
```xml
```
-Hii inahakikisha kuwa kichwa cha 'Referer' hakijajumuishwa, huenda ikapita mchakato wa uthibitishaji katika baadhi ya programu.
+Hii inahakikisha kuwa 'Referer' header haipo, na hivyo inaweza kupitisha ukaguzi wa uthibitisho katika baadhi ya programu.
**Regexp bypasses**
@@ -159,7 +187,7 @@ Hii inahakikisha kuwa kichwa cha 'Referer' hakijajumuishwa, huenda ikapita mchak
ssrf-server-side-request-forgery/url-format-bypass.md
{{#endref}}
-Ili kuweka jina la kikoa la seva katika URL ambayo Referrer itatuma ndani ya vigezo unaweza kufanya:
+Ili kuweka jina la kikoa la server katika URL ambalo Referrer atalituma ndani ya parameta, unaweza kufanya:
```html
@@ -190,23 +218,23 @@ document.forms[0].submit()
```
### **HEAD method bypass**
-Sehemu ya kwanza ya [**hii CTF writeup**](https://github.com/google/google-ctf/tree/master/2023/web-vegsoda/solution) inaelezea kwamba [kanuni ya chanzo ya Oak](https://github.com/oakserver/oak/blob/main/router.ts#L281), router imewekwa **kushughulikia maombi ya HEAD kama maombi ya GET** bila mwili wa jibu - suluhisho la kawaida ambalo si la kipekee kwa Oak. Badala ya mpangilio maalum unaoshughulikia maombi ya HEAD, yanatolewa tu **kwa mpangilio wa GET lakini programu inatoa tu mwili wa jibu**.
+Sehemu ya kwanza ya [**this CTF writeup**](https://github.com/google/google-ctf/tree/master/2023/web-vegsoda/solution) inaeleza kwamba [Oak's source code](https://github.com/oakserver/oak/blob/main/router.ts#L281), router imewekwa ili **handle HEAD requests as GET requests** bila response body - workaround ya kawaida ambayo sio ya Oak pekee. Badala ya handler maalum inayoshughulikia HEAD reqs, zinapelekwa tu kwa **GET handler** lakini app inafuta response body.
-Hivyo, ikiwa ombi la GET linapunguzwa, unaweza tu **kutuma ombi la HEAD ambalo litashughulikiwa kama ombi la GET**.
+Kwa hiyo, ikiwa GET request inazuiliwa, unaweza tu **send a HEAD request that will be processed as a GET request**.
-## **Mifano ya Kutumia**
+## **Exploit Examples**
-### **Kutoa CSRF Token**
+### **Exfiltrating CSRF Token**
-Ikiwa **CSRF token** inatumika kama **kinga** unaweza kujaribu **kutoa** kwa kutumia udhaifu wa [**XSS**](xss-cross-site-scripting/index.html#xss-stealing-csrf-tokens) au udhaifu wa [**Dangling Markup**](dangling-markup-html-scriptless-injection/index.html).
+Ikiwa **CSRF token** inatumiwa kama **defence** unaweza kujaribu **exfiltrate it** kwa kutumia udhaifu wa [**XSS**](xss-cross-site-scripting/index.html#xss-stealing-csrf-tokens) au udhaifu wa [**Dangling Markup**](dangling-markup-html-scriptless-injection/index.html) vulnerability.
-### **GET kwa kutumia vitambulisho vya HTML**
+### **GET using HTML tags**
```xml
404 - Page not found
The URL you are requesting is no longer available
```
-Mengine ya vitambulisho vya HTML5 ambavyo vinaweza kutumika kutuma ombi la GET kiotomatiki ni:
+Tagi nyingine za HTML5 ambazo zinaweza kutumika kutuma ombi la GET moja kwa moja ni:
```html
@@ -235,7 +263,7 @@ background: url("...");
```
-### Ombi la GET la Fomu
+### Ombi la Fomu GET
```html
@@ -253,7 +281,7 @@ document.forms[0].submit()
```
-### Ombi la POST la Fomu
+### Ombi la POST la fomu
```html
@@ -304,7 +332,7 @@ document.forms[0].submit()
```
-### **Ombi la POST la Ajax**
+### **Ajax POST request**
```html
```
-### multipart/form-data POST ombi
+### multipart/form-data POST request
```javascript
myFormData = new FormData()
var blob = new Blob([""], { type: "text/text" })
@@ -346,7 +374,7 @@ headers: { "Content-Type": "application/x-www-form-urlencoded" },
mode: "no-cors",
})
```
-### multipart/form-data POST request v2
+### multipart/form-data POST ombi v2
```javascript
// https://www.exploit-db.com/exploits/20009
var fileSize = fileData.length,
@@ -374,7 +402,7 @@ body += "--" + boundary + "--"
//xhr.send(body);
xhr.sendAsBinary(body)
```
-### Omba la POST kutoka ndani ya iframe
+### Ombi la POST la fomu kutoka ndani ya iframe
```html
<--! expl.html -->
@@ -398,7 +426,7 @@ document.getElementById("formulario").submit()