Translated ['src/pentesting-web/domain-subdomain-takeover.md', 'src/pent

This commit is contained in:
Translator 2025-02-04 18:54:59 +00:00
parent 9d785aa0e5
commit 53a3cb3453
2 changed files with 88 additions and 45 deletions

View File

@ -5,11 +5,11 @@
## Domain takeover
Ikiwa unagundua jina la kikoa (domain.tld) ambalo **linatumika na huduma fulani ndani ya upeo** lakini **kampuni** ime **poteza** **umiliki** wake, unaweza kujaribu **kujisajili** (ikiwa ni ya bei nafuu) na kuwajulisha kampuni hiyo. Ikiwa jina hili la kikoa linapokea **habari nyeti** kama vile cookie ya kikao kupitia **GET** parameter au katika kichwa cha **Referer**, hii ni hakika **udhaifu**.
Ikiwa unagundua jina la kikoa (domain.tld) ambalo **linatumika na huduma fulani ndani ya upeo** lakini **kampuni** ime **poteza** **umiliki** wake, unaweza kujaribu **kujiandikisha** nalo (ikiwa ni bei nafuu) na kuwajulisha kampuni hiyo. Ikiwa jina hili la kikoa linapokea **taarifa nyeti** kama vile cookie ya kikao kupitia **GET** parameter au katika kichwa cha **Referer**, hii ni hakika **udhaifu**.
### Subdomain takeover
Subdomain ya kampuni in pointing kwa **huduma ya mtu wa tatu yenye jina ambalo halijasajiliwa**. Ikiwa unaweza **kuunda** **akaunti** katika **huduma hii ya mtu wa tatu** na **kujisajili** jina linalotumika, unaweza kufanya subdomain takeover.
Subdomain ya kampuni inashikilia **huduma ya mtu wa tatu yenye jina ambalo halijajiandikisha**. Ikiwa unaweza **kuunda** akaunti katika **huduma hii ya mtu wa tatu** na **kujiandikisha** jina linalotumika, unaweza kufanya subdomain takeover.
Kuna zana kadhaa zenye kamusi za kuangalia uwezekano wa takeover:
@ -29,17 +29,17 @@ Kuna zana kadhaa zenye kamusi za kuangalia uwezekano wa takeover:
### Subdomain Takeover Generation via DNS Wildcard
Wakati wildcard ya DNS inatumika katika kikoa, subdomain yoyote inayohitajika ya kikoa hicho ambayo haina anwani tofauti wazi wazi itakuwa **imeelekezwa kwa habari sawa**. Hii inaweza kuwa anwani ya A, CNAME...
Wakati wildcard ya DNS inatumika katika kikoa, subdomain yoyote inayohitajika ya kikoa hicho ambayo haina anwani tofauti wazi itakuwa **imeelekezwa kwa taarifa sawa**. Hii inaweza kuwa anwani ya A, CNAME...
Kwa mfano, ikiwa `*.testing.com` imewekwa kama wildcard kwa `1.1.1.1`. Kisha, `not-existent.testing.com` itakuwa ikielekezwa kwa `1.1.1.1`.
Hata hivyo, ikiwa badala ya kuelekeza kwa anwani ya IP, msimamizi wa mfumo anaielekeza kwa **huduma ya mtu wa tatu kupitia CNAME**, kama subdomain ya G**ithub kwa mfano (`sohomdatta1.github.io`). Mshambuliaji anaweza **kuunda ukurasa wake wa mtu wa tatu** (katika Gihub katika kesi hii) na kusema kwamba `something.testing.com` inaelekezwa huko. Kwa sababu, **CNAME wildcard** itakubali mshambuliaji atakuwa na uwezo wa **kuunda subdomains zisizo na mipaka kwa kikoa cha mwathirika zikielekezwa kwa kurasa zake**.
Hata hivyo, ikiwa badala ya kuelekeza kwa anwani ya IP, msimamizi wa mfumo anaielekeza kwa **huduma ya mtu wa tatu kupitia CNAME**, kama subdomain ya G**ithub kwa mfano (`sohomdatta1.github.io`). Mshambuliaji anaweza **kuunda ukurasa wake wa mtu wa tatu** (katika Gihub katika kesi hii) na kusema kwamba `something.testing.com` inashikilia hapo. Kwa sababu, **CNAME wildcard** itakubali mshambuliaji atakuwa na uwezo wa **kuunda subdomains zisizo na mipaka kwa kikoa cha mwathirika zikielekezwa kwa kurasa zake**.
Unaweza kupata mfano wa udhaifu huu katika andiko la CTF: [https://ctf.zeyu2001.com/2022/nitectf-2022/undocumented-js-api](https://ctf.zeyu2001.com/2022/nitectf-2022/undocumented-js-api)
## Exploiting a subdomain takeover
Subdomain takeover ni kimsingi DNS spoofing kwa kikoa maalum kwenye mtandao, ikiruhusu washambuliaji kuweka rekodi za A kwa kikoa, na kupeleka vivinjari kuonyesha maudhui kutoka kwa seva ya mshambuliaji. Hii **uwazi** katika vivinjari inafanya majina ya kikoa kuwa hatarini kwa phishing. Washambuliaji wanaweza kutumia [_typosquatting_](https://en.wikipedia.org/wiki/Typosquatting) au [_Doppelganger domains_](https://en.wikipedia.org/wiki/Doppelg%C3%A4nger) kwa kusudi hili. Majina ya kikoa ambayo URL katika barua pepe ya phishing inaonekana halali, yanakuwa hatarini zaidi, yakidanganya watumiaji na kukwepa vichujio vya spam kutokana na uaminifu wa kikoa.
Subdomain takeover kimsingi ni DNS spoofing kwa kikoa maalum kwenye mtandao, ikiruhusu washambuliaji kuweka rekodi za A kwa kikoa, na kupeleka vivinjari kuonyesha maudhui kutoka kwa seva ya mshambuliaji. Hii **uwazi** katika vivinjari inafanya majina ya kikoa kuwa hatarini kwa phishing. Washambuliaji wanaweza kutumia [_typosquatting_](https://en.wikipedia.org/wiki/Typosquatting) au [_Doppelganger domains_](https://en.wikipedia.org/wiki/Doppelg%C3%A4nger) kwa ajili ya hili. Majina ya kikoa ambayo URL katika barua pepe ya phishing inaonekana halali, yanakuwa hatarini, yakiwadanganya watumiaji na kukwepa vichujio vya spam kutokana na uaminifu wa kikoa.
Angalia hii [post kwa maelezo zaidi](https://0xpatrik.com/subdomain-takeover/)
@ -49,33 +49,50 @@ Vyeti vya SSL, ikiwa vimeundwa na washambuliaji kupitia huduma kama [_Let's Encr
### **Cookie Security and Browser Transparency**
Uwazi wa kivinjari pia unapanuka kwa usalama wa cookie, unaodhibitiwa na sera kama [Same-origin policy](https://en.wikipedia.org/wiki/Same-origin_policy). Cookies, mara nyingi hutumiwa kusimamia vikao na kuhifadhi alama za kuingia, zinaweza kutumiwa vibaya kupitia subdomain takeover. Washambuliaji wanaweza **kusanya cookie za kikao** kwa urahisi kwa kuongoza watumiaji kwenye subdomain iliyovunjwa, wakihatarisha data na faragha ya mtumiaji.
Uwazi wa kivinjari pia unahusisha usalama wa cookie, unaodhibitiwa na sera kama [Same-origin policy](https://en.wikipedia.org/wiki/Same-origin_policy). Cookies, ambazo mara nyingi hutumiwa kusimamia vikao na kuhifadhi token za kuingia, zinaweza kutumiwa vibaya kupitia subdomain takeover. Washambuliaji wanaweza **kusanya cookie za kikao** kwa urahisi kwa kuongoza watumiaji kwenye subdomain iliyovunjwa, wakihatarisha data na faragha ya mtumiaji.
### CORS Bypass
Inaweza kuwa inawezekana kwamba kila subdomain inaruhusiwa kufikia rasilimali za CORS kutoka kwa kikoa kuu au subdomains nyingine. Hii inaweza kutumiwa vibaya na mshambuliaji ili **kupata taarifa nyeti** kwa kutumia maombi ya CORS.
### CSRF - Same-Site Cookies bypass
Inaweza kuwa inawezekana kwamba subdomain inaruhusiwa kutuma cookies kwa kikoa au subdomains nyingine ambazo zilizuia na sifa ya `Same-Site` ya cookies. Hata hivyo, kumbuka kwamba token za anti-CSRF bado zitazuia shambulio hili ikiwa zitatekelezwa ipasavyo.
### OAuth tokens redirect
Inaweza kuwa inawezekana kwamba subdomain iliyovunjwa inaruhusiwa kutumika katika URL ya `redirect_uri` ya mtiririko wa OAuth. Hii inaweza kutumiwa vibaya na mshambuliaji ili **kuiba token ya OAuth**.
### CSP Bypass
Inaweza kuwa inawezekana kwamba subdomain iliyovunjwa (au kila subdomain) inaruhusiwa kutumika kwa mfano `script-src` ya CSP. Hii inaweza kutumiwa vibaya na mshambuliaji ili **kuingiza scripts za uhalifu** na kutumia udhaifu wa XSS.
### **Emails and Subdomain Takeover**
Nafasi nyingine ya subdomain takeover inahusisha huduma za barua pepe. Washambuliaji wanaweza kubadilisha **rekodi za MX** kupokea au kutuma barua pepe kutoka subdomain halali, wakiongeza ufanisi wa mashambulizi ya phishing.
Nafasi nyingine ya subdomain takeover inahusisha huduma za barua pepe. Washambuliaji wanaweza kubadilisha **rekodi za MX** ili kupokea au kutuma barua pepe kutoka subdomain halali, wakiongeza ufanisi wa mashambulizi ya phishing.
### **Higher Order Risks**
Hatari zaidi ni pamoja na **NS record takeover**. Ikiwa mshambuliaji anapata udhibiti wa rekodi moja ya NS ya kikoa, wanaweza kwa urahisi kuelekeza sehemu ya trafiki kwa seva chini ya udhibiti wao. Hatari hii inazidi kuwa kubwa ikiwa mshambuliaji ataweka **TTL (Time to Live)** ya juu kwa rekodi za DNS, kuongezea muda wa shambulizi.
Hatari zaidi ni pamoja na **NS record takeover**. Ikiwa mshambuliaji anapata udhibiti wa rekodi moja ya NS ya kikoa, wanaweza kwa urahisi kuelekeza sehemu ya trafiki kwa seva chini ya udhibiti wao. Hatari hii inazidishwa ikiwa mshambuliaji ataweka **TTL (Time to Live)** ya juu kwa rekodi za DNS, kuongezea muda wa shambulio.
### CNAME Record Vulnerability
Washambuliaji wanaweza kutumia rekodi za CNAME zisizodaiwa zinazoelekezwa kwa huduma za nje ambazo hazitumiki tena au zimeondolewa. Hii inawaruhusu kuunda ukurasa chini ya kikoa kinachotambulika, ikisaidia zaidi katika phishing au usambazaji wa malware.
Washambuliaji wanaweza kutumia vibaya rekodi za CNAME zisizodaiwa zinazoshikilia huduma za nje ambazo hazitumiki tena au zimeondolewa. Hii inawaruhusu kuunda ukurasa chini ya kikoa kinachotambulika, ikisaidia zaidi katika phishing au usambazaji wa malware.
### **Mitigation Strategies**
Mikakati ya kupunguza hatari ni pamoja na:
1. **Kuondoa rekodi za DNS zenye udhaifu** - Hii ni bora ikiwa subdomain haitahitajika tena.
2. **Kudai jina la kikoa** - Kujiandikisha rasilimali hiyo na mtoa huduma wa wingu husika au kununua tena kikoa kilichokwisha.
2. **Kudai jina la kikoa** - Kujiandikisha rasilimali hiyo na mtoa huduma husika wa wingu au kununua tena kikoa kilichokwisha.
3. **Kufanya ufuatiliaji wa mara kwa mara kwa udhaifu** - Zana kama [aquatone](https://github.com/michenriksen/aquatone) zinaweza kusaidia kubaini majina ya kikoa yanayoweza kuathiriwa. Mashirika yanapaswa pia kupitia mchakato wao wa usimamizi wa miundombinu, kuhakikisha kwamba uundaji wa rekodi za DNS ni hatua ya mwisho katika uundaji wa rasilimali na hatua ya kwanza katika uharibifu wa rasilimali.
Kwa watoa huduma wa wingu, kuthibitisha umiliki wa kikoa ni muhimu ili kuzuia subdomain takeovers. Wengine, kama [GitLab](https://about.gitlab.com/2018/02/05/gitlab-pages-custom-domain-validation/), wamegundua tatizo hili na kutekeleza mifumo ya uthibitishaji wa kikoa.
Kwa watoa huduma wa wingu, kuthibitisha umiliki wa kikoa ni muhimu ili kuzuia subdomain takeovers. Wengine, kama [GitLab](https://about.gitlab.com/2018/02/05/gitlab-pages-custom-domain-validation/), wamegundua tatizo hili na kutekeleza mitambo ya uthibitishaji wa kikoa.
## References
- [https://0xpatrik.com/subdomain-takeover/](https://0xpatrik.com/subdomain-takeover/)
- [https://www.stratussecurity.com/post/subdomain-takeover-guide](https://www.stratussecurity.com/post/subdomain-takeover-guide)
- [https://www.hackerone.com/blog/guide-subdomain-takeovers-20](https://www.hackerone.com/blog/guide-subdomain-takeovers-20)
{{#include ../banners/hacktricks-training.md}}

View File

@ -12,7 +12,7 @@ Tarehe ya kumalizika kwa cookie inamuliwa na sifa ya `Expires`. Kinyume chake, s
### Domain
Wenyeji wa kupokea cookie wanaelezwa na sifa ya `Domain`. Kwa kawaida, hii imewekwa kwa mwenyeji aliyeitoa cookie, bila kujumuisha subdomains zake. Hata hivyo, wakati sifa ya `Domain` imewekwa wazi, inajumuisha subdomains pia. Hii inafanya uwekaji wa sifa ya `Domain` kuwa chaguo lenye ukomo mdogo, muhimu kwa hali ambapo kushiriki cookie kati ya subdomains kunahitajika. Kwa mfano, kuweka `Domain=mozilla.org` kunafanya cookies zipatikane kwenye subdomains zake kama `developer.mozilla.org`.
Wenyeji wa kupokea cookie wanaelezwa na sifa ya `Domain`. Kwa kawaida, hii imewekwa kwa mwenyeji aliyeitoa cookie, bila kujumuisha subdomains zake. Hata hivyo, wakati sifa ya `Domain` imewekwa wazi, inajumuisha subdomains pia. Hii inafanya ufafanuzi wa sifa ya `Domain` kuwa chaguo lenye ukomo mdogo, muhimu kwa hali ambapo kushiriki cookie kati ya subdomains kunahitajika. Kwa mfano, kuweka `Domain=mozilla.org` kunafanya cookies zipatikane kwenye subdomains zake kama `developer.mozilla.org`.
### Path
@ -76,24 +76,24 @@ Ombi litatumwa **tu** kutuma cookie katika ombi la HTTP tu ikiwa ombi linatumwa
## Cookies Prefixes
Cookies zilizo na awali `__Secure-` zinahitajika kuwekwa pamoja na bendera ya `secure` kutoka kurasa ambazo zimehakikishwa na HTTPS.
Cookies zilizo na kiambishi `__Secure-` zinahitajika kuwekwa pamoja na bendera ya `secure` kutoka kurasa ambazo zimehakikishwa na HTTPS.
Kwa cookies zilizo na awali `__Host-`, masharti kadhaa yanapaswa kutimizwa:
Kwa cookies zilizo na kiambishi `__Host-`, masharti kadhaa yanapaswa kutimizwa:
- Lazima ziwe na bendera ya `secure`.
- Lazima ziwe zimewekwa na bendera ya `secure`.
- Lazima zitoke kwenye ukurasa uliohakikishwa na HTTPS.
- Zinakatazwa kutaja domain, kuzuia usafirishaji wao kwa subdomains.
- Zinakatazwa kuainisha domain, kuzuia usafirishaji wao kwa subdomains.
- Njia ya cookies hizi lazima iwekwe kwa `/`.
Ni muhimu kutambua kwamba cookies zilizo na awali `__Host-` haziruhusiwi kutumwa kwa superdomains au subdomains. Kizuizi hiki kinasaidia katika kutenga cookies za programu. Hivyo, kutumia awali ya `__Host-` kwa cookies zote za programu inaweza kuzingatiwa kama mazoea mazuri ya kuboresha usalama na kutengwa.
Ni muhimu kutambua kwamba cookies zilizo na kiambishi `__Host-` haziruhusiwi kutumwa kwa superdomains au subdomains. Kizuizi hiki kinasaidia katika kutenga cookies za programu. Hivyo, kutumia kiambishi `__Host-` kwa cookies zote za programu inaweza kuzingatiwa kama mazoea mazuri ya kuboresha usalama na kutengwa.
### Overwriting cookies
Hivyo, moja ya ulinzi wa cookies zilizo na awali `__Host-` ni kuzuia ziweze kufutwa kutoka subdomains. Kuzuia kwa mfano [**Cookie Tossing attacks**](cookie-tossing.md). Katika mazungumzo [**Cookie Crumbles: Unveiling Web Session Integrity Vulnerabilities**](https://www.youtube.com/watch?v=F_wAzF4a7Xg) ([**paper**](https://www.usenix.org/system/files/usenixsecurity23-squarcina.pdf)) inawasilishwa kwamba ilikuwa inawezekana kuweka cookies zilizo na awali \_\_HOST- kutoka subdomain, kwa kudanganya parser, kwa mfano, kuongeza "=" mwanzoni au mwishoni...:
Hivyo, moja ya ulinzi wa cookies zilizo na kiambishi `__Host-` ni kuzuia ziweze kufutwa kutoka subdomains. Kuzuia kwa mfano [**Cookie Tossing attacks**](cookie-tossing.md). Katika mazungumzo [**Cookie Crumbles: Unveiling Web Session Integrity Vulnerabilities**](https://www.youtube.com/watch?v=F_wAzF4a7Xg) ([**paper**](https://www.usenix.org/system/files/usenixsecurity23-squarcina.pdf)) inawasilishwa kwamba ilikuwa inawezekana kuweka cookies zilizo na kiambishi \_\_HOST- kutoka subdomain, kwa kudanganya parser, kwa mfano, kuongeza "=" mwanzoni au mwishoni...:
<figure><img src="../../images/image (6) (1) (1) (1) (1).png" alt=""><figcaption></figcaption></figure>
Au katika PHP ilikuwa inawezekana kuongeza **herufi nyingine mwanzoni** mwa jina la cookie ambazo zingeweza **kubadilishwa na herufi za underscore**, kuruhusu kufuta cookies za `__HOST-`:
Au katika PHP ilikuwa inawezekana kuongeza **herufi nyingine mwanzoni** mwa jina la cookie ambazo zingeweza **kubadilishwa na herufi za chini** , kuruhusu kufuta cookies za `__HOST-`:
<figure><img src="../../images/image (7) (1) (1) (1) (1).png" alt="" width="373"><figcaption></figcaption></figure>
@ -111,7 +111,7 @@ Shambulio hili linahusisha kuiba cookie ya mtumiaji ili kupata ufikiaji usioidhi
### Session Fixation
Katika hali hii, mshambuliaji anamdanganya mwathirika kutumia cookie maalum kuingia. Ikiwa programu haitoi cookie mpya wakati wa kuingia, mshambuliaji, mwenye cookie ya awali, anaweza kujifanya mwathirika. Mbinu hii inategemea mwathirika kuingia na cookie iliyotolewa na mshambuliaji.
Katika hali hii, mshambuliaji anamdanganya mwathirika kutumia cookie maalum kuingia. Ikiwa programu haitoi cookie mpya wakati wa kuingia, mshambuliaji, akiwa na cookie ya awali, anaweza kujifanya mwathirika. Mbinu hii inategemea mwathirika kuingia na cookie iliyotolewa na mshambuliaji.
Ikiwa umepata **XSS katika subdomain** au unadhibiti **subdomain**, soma:
@ -121,7 +121,7 @@ cookie-tossing.md
### Session Donation
Hapa, mshambuliaji anamshawishi mwathirika kutumia cookie ya kikao ya mshambuliaji. Mwathirika, akiamini kwamba amejiingia kwenye akaunti yake mwenyewe, atafanya vitendo bila kukusudia katika muktadha wa akaunti ya mshambuliaji.
Hapa, mshambuliaji anamshawishi mwathirika kutumia cookie ya kikao ya mshambuliaji. Mwathirika, akiamini kwamba ameingia kwenye akaunti yake mwenyewe, atafanya vitendo bila kujua katika muktadha wa akaunti ya mshambuliaji.
Ikiwa umepata **XSS katika subdomain** au unadhibiti **subdomain**, soma:
@ -141,7 +141,7 @@ Shambulio hili linamfanya mtumiaji aliyeingia kutekeleza vitendo visivyotakikana
### Empty Cookies
(Tazama maelezo zaidi katika [utafiti wa asili](https://blog.ankursundara.com/cookie-bugs/)) Vivinjari vinaruhusu kuunda cookies bila jina, ambayo inaweza kuonyeshwa kupitia JavaScript kama ifuatavyo:
(Tazama maelezo zaidi katika [utafiti wa asili](https://blog.ankursundara.com/cookie-bugs/)) Vivinjari vinaruhusu kuundwa kwa cookies bila jina, ambayo inaweza kuonyeshwa kupitia JavaScript kama ifuatavyo:
```js
document.cookie = "a=v1"
document.cookie = "=test value;" // Setting an empty named cookie
@ -157,9 +157,9 @@ setCookie("", "a=b") // Setting the empty cookie modifies another cookie's value
```
Hii inasababisha kivinjari kutuma kichwa cha cookie kinachotafsiriwa na kila seva ya wavuti kama cookie iliyo na jina `a` na thamani `b`.
#### Chrome Bug: Tatizo la Kiwango cha Unicode Surrogate
#### Chrome Bug: Tatizo la Unicode Surrogate Codepoint
Katika Chrome, ikiwa kiwango cha Unicode surrogate ni sehemu ya cookie iliyowekwa, `document.cookie` inaharibika, ikirudisha string tupu baadaye:
Katika Chrome, ikiwa codepoint ya Unicode surrogate ni sehemu ya cookie iliyowekwa, `document.cookie` inaharibika, ikirudisha string tupu baadaye:
```js
document.cookie = "\ud800=meep"
```
@ -167,38 +167,64 @@ Hii inasababisha `document.cookie` kutoa string tupu, ikionyesha uharibifu wa ku
#### Cookie Smuggling Kutokana na Masuala ya Parsing
(Tazama maelezo zaidi katika [utafiti wa asili](https://blog.ankursundara.com/cookie-bugs/)) Seva kadhaa za wavuti, ikiwa ni pamoja na zile za Java (Jetty, TomCat, Undertow) na Python (Zope, cherrypy, web.py, aiohttp, bottle, webob), zinashughulikia vibaya nyuzi za cookie kutokana na msaada wa zamani wa RFC2965. Wanaweza kusoma thamani ya cookie iliyo na nukuu mbili kama thamani moja hata kama inajumuisha alama za semicolon, ambazo kawaida zinapaswa kutenganisha jozi za funguo-thamani:
(Tazama maelezo zaidi katika [utafiti wa asili](https://blog.ankursundara.com/cookie-bugs/)) Seva kadhaa za wavuti, ikiwa ni pamoja na zile za Java (Jetty, TomCat, Undertow) na Python (Zope, cherrypy, web.py, aiohttp, bottle, webob), zinashughulikia nyuzi za cookie vibaya kutokana na msaada wa zamani wa RFC2965. Wanasoma thamani ya cookie iliyo na nukuu mbili kama thamani moja hata kama inajumuisha alama za semikolon, ambazo kawaida zinapaswa kutenganisha jozi za funguo-thamani:
```
RENDER_TEXT="hello world; JSESSIONID=13371337; ASDF=end";
```
#### Ukatishaji wa Uthibitisho wa Keki
#### Ukatili wa Kuingiza Cookies
(Tazama maelezo zaidi katika [utafiti wa asili](https://blog.ankursundara.com/cookie-bugs/)) Ufafanuzi usio sahihi wa keki na seva, hasa Undertow, Zope, na zile zinazotumia `http.cookie.SimpleCookie` na `http.cookie.BaseCookie` za Python, unatoa fursa za mashambulizi ya ukatishaji wa keki. Seva hizi zinashindwa kuweka mipaka sahihi ya kuanza kwa keki mpya, ikiruhusu washambuliaji kuiga keki:
(Tafadhali angalia maelezo zaidi katika [utafiti wa asili](https://blog.ankursundara.com/cookie-bugs/)) Ufafanuzi usio sahihi wa cookies na seva, hasa Undertow, Zope, na zile zinazotumia `http.cookie.SimpleCookie` na `http.cookie.BaseCookie` za Python, unatoa fursa za mashambulizi ya kuingiza cookies. Seva hizi zinashindwa kuweka mipaka sahihi ya kuanza kwa cookies mpya, ikiruhusu washambuliaji kuiga cookies:
- Undertow inatarajia keki mpya mara moja baada ya thamani iliyonukuliwa bila alama ya semikolon.
- Zope inatafuta koma ili kuanza kufafanua keki inayofuata.
- Madarasa ya keki ya Python yanaanza kufafanua kwenye herufi ya nafasi.
- Undertow inatarajia cookie mpya mara moja baada ya thamani iliyonukuliwa bila alama ya semikolon.
- Zope inatafuta koma ili kuanza kufafanua cookie inayofuata.
- Madarasa ya cookie ya Python yanaanza kufafanua kwenye herufi ya nafasi.
Ukatishaji huu ni hatari sana katika programu za wavuti zinazotegemea ulinzi wa CSRF wa keki, kwani unaruhusu washambuliaji kuingiza keki za CSRF-token zilizoghushi, na hivyo kuweza kupita hatua za usalama. Tatizo hili linazidishwa na jinsi Python inavyoshughulikia majina ya keki yanayojirudia, ambapo tukio la mwisho linazidi yale ya awali. Pia linaibua wasiwasi kwa keki za `__Secure-` na `__Host-` katika muktadha usio salama na linaweza kusababisha kupita kwa uthibitisho wakati keki zinapopita kwa seva za nyuma zinazoweza kudanganywa.
Ukatili huu ni hatari hasa katika programu za wavuti zinazotegemea ulinzi wa CSRF wa msingi wa cookies, kwani unaruhusu washambuliaji kuingiza cookies za CSRF-token zilizoghushi, na hivyo kuweza kupita hatua za usalama. Tatizo hili linazidishwa na jinsi Python inavyoshughulikia majina ya cookie yanayojirudia, ambapo tukio la mwisho linazidi yale ya awali. Pia linaibua wasiwasi kwa `__Secure-` na `__Host-` cookies katika muktadha usio salama na linaweza kusababisha kupita kwa mamlaka wakati cookies zinapopita kwa seva za nyuma zinazoweza kudanganywa.
### Keki $version na kupita kwa WAF
### Cookies $version
Kulingana na [**hiki blogpost**](https://portswigger.net/research/bypassing-wafs-with-the-phantom-version-cookie), inaweza kuwa inawezekana kutumia sifa ya keki **`$Version=1`** ili kufanya backend itumie mantiki ya zamani kufafanua keki kutokana na **RFC2109**. Zaidi ya hayo, thamani nyingine kama **`$Domain`** na **`$Path`** zinaweza kutumika kubadilisha tabia ya backend na keki.
#### Kupita WAF
#### Uchambuzi wa kupita wa thamani na usimbaji wa mfuatano wa nukuu
Kulingana na [**hiki blogpost**](https://portswigger.net/research/bypassing-wafs-with-the-phantom-version-cookie), inaweza kuwa inawezekana kutumia sifa ya cookie **`$Version=1`** ili kufanya backend itumie mantiki ya zamani kufafanua cookie kutokana na **RFC2109**. Zaidi ya hayo, thamani nyingine kama **`$Domain`** na **`$Path`** zinaweza kutumika kubadilisha tabia ya backend na cookie.
Ufafanuzi huu unaonyesha kuondoa usimbaji wa thamani zilizofichwa ndani ya keki, hivyo "\a" inakuwa "a". Hii inaweza kuwa na manufaa kupita WAFS kama:
#### Shambulio la Sandwich ya Cookie
Kulingana na [**hiki blogpost**](https://portswigger.net/research/stealing-httponly-cookies-with-the-cookie-sandwich-technique) inawezekana kutumia mbinu ya sandwich ya cookie kuiba cookies za HttpOnly. Hizi ndizo mahitaji na hatua:
- Pata mahali ambapo **cookie isiyo na maana inaonyeshwa katika jibu**
- **Unda cookie inayoitwa `$Version`** yenye thamani `1` (unaweza kufanya hivi katika shambulio la XSS kutoka JS) yenye njia maalum ili ipate nafasi ya awali (mifumo mingine kama python haitaji hatua hii)
- **Unda cookie inayonyeshwa** yenye thamani inayowacha **nukta mbili wazi** na yenye njia maalum ili iwe katika hifadhidata ya cookie baada ya ile ya awali (`$Version`)
- Kisha, cookie halali itafuata katika mpangilio
- **Unda cookie ya dummy inayofunga nukta mbili** ndani ya thamani yake
Kwa njia hii, cookie ya mwathirika inakwama ndani ya toleo jipya la cookie 1 na itajitokeza kila wakati inapoonyeshwa.
e.g. kutoka kwa chapisho:
```javascript
document.cookie = `$Version=1;`;
document.cookie = `param1="start`;
// any cookies inside the sandwich will be placed into param1 value server-side
document.cookie = `param2=end";`;
```
### WAF bypasses
#### Cookies $version
Angalia sehemu ya awali.
#### Bypassing value analysis with quoted-string encoding
Hii parsing inaonyesha kuondoa uakifishaji wa thamani ndani ya cookies, hivyo "\a" inakuwa "a". Hii inaweza kuwa na manufaa kuzunguka WAFS kama:
- `eval('test') => forbidden`
- `"\e\v\a\l\(\'\t\e\s\t\'\)" => allowed`
#### Kupita kwa orodha za keki za jina
#### Bypassing cookie-name blocklists
Katika RFC2109 inabainishwa kuwa **koma inaweza kutumika kama mpasuo kati ya thamani za keki**. Na pia inawezekana kuongeza **nafasi na tabo kabla na baada ya alama ya usawa**. Hivyo keki kama `$Version=1; foo=bar, abc = qux` haisababishi keki `"foo":"bar, admin = qux"` bali keki `foo":"bar"` na `"admin":"qux"`. Angalia jinsi keki 2 zinavyoundwa na jinsi admin aliondolewa nafasi kabla na baada ya alama ya usawa.
Katika RFC2109 inabainishwa kwamba **comma inaweza kutumika kama separator kati ya thamani za cookie**. Na pia inawezekana kuongeza **nafasi na tabs kabla na baada ya alama ya sawa**. Hivyo cookie kama `$Version=1; foo=bar, abc = qux` haisababishi cookie `"foo":"bar, admin = qux"` bali cookies `foo":"bar"` na `"admin":"qux"`. Angalia jinsi cookies 2 zinavyoundwa na jinsi admin ilivyondolewa nafasi kabla na baada ya alama ya sawa.
#### Uchambuzi wa kupita wa thamani na kugawanya keki
#### Bypassing value analysis with cookie splitting
Hatimaye, milango tofauti ya nyuma itajumuisha katika mfuatano keki tofauti zilizopitishwa katika vichwa tofauti vya keki kama katika:
Hatimaye backdoors tofauti zingeungana katika string cookies tofauti zilizopitishwa katika vichwa tofauti vya cookie kama katika:
```
GET / HTTP/1.1
Host: example.com
@ -228,7 +254,7 @@ Resulting cookie: name=eval('test//, comment') => allowed
Ikiwa keki inabaki kuwa ile ile (au karibu) unapoingia, hii huenda ikamaanisha kwamba keki inahusiana na uwanja fulani wa akaunti yako (huenda jina la mtumiaji). Kisha unaweza:
- Jaribu kuunda akaunti nyingi zikiwa na majina ya mtumiaji yanayofanana sana na jaribu **kukisia** jinsi algorithimu inavyofanya kazi.
- Jaribu kuunda **akaunti** nyingi zikiwa na majina ya mtumiaji yanayofanana sana na jaribu **kukisia** jinsi algorithimu inavyofanya kazi.
- Jaribu **bruteforce jina la mtumiaji**. Ikiwa keki inahifadhiwa tu kama njia ya uthibitishaji kwa jina lako la mtumiaji, basi unaweza kuunda akaunti yenye jina la mtumiaji "**Bmin**" na **bruteforce** kila **bit** ya keki yako kwa sababu moja ya keki ambazo utajaribu itakuwa ile inayomilikiwa na "**admin**".
- Jaribu **Padding** **Oracle** (unaweza kufichua maudhui ya keki). Tumia **padbuster**.
@ -244,7 +270,7 @@ padBuster http://web.com/home.jsp?UID=7B216A634951170FF851D6CC68FC9537858795A28E
```
Padbuster itafanya majaribio kadhaa na itakuuliza ni hali ipi ndiyo hali ya makosa (ile ambayo si halali).
Kisha itaanza kufungua siri cookie (inaweza kuchukua dakika kadhaa)
Kisha itaanza kufichua cookie (inaweza kuchukua dakika kadhaa)
Ikiwa shambulio limefanikiwa, basi unaweza kujaribu kuficha mfuatano wa chaguo lako. Kwa mfano, ikiwa ungependa **encrypt** **user=administrator**
```
@ -254,7 +280,7 @@ Hii utekelezaji itakupa cookie iliyosimbwa na kuandikwa kwa usahihi na mfuatano
**CBC-MAC**
Labda cookie inaweza kuwa na thamani fulani na inaweza kusainiwa kwa kutumia CBC. Kisha, uaminifu wa thamani hiyo ni saini iliyoundwa kwa kutumia CBC na thamani hiyo hiyo. Kama inavyopendekezwa kutumia kama IV vector isiyo na thamani, aina hii ya ukaguzi wa uaminifu inaweza kuwa hatarini.
Labda cookie inaweza kuwa na thamani fulani na inaweza kusainiwa kwa kutumia CBC. Kisha, uaminifu wa thamani hiyo ni saini iliyoundwa kwa kutumia CBC na thamani hiyo hiyo. Kama inavyopendekezwa kutumia kama IV vector isiyo na kitu, aina hii ya ukaguzi wa uaminifu inaweza kuwa na hatari.
**Shambulio**
@ -264,16 +290,16 @@ Labda cookie inaweza kuwa na thamani fulani na inaweza kusainiwa kwa kutumia CBC
**ECB**
Ikiwa cookie imefungwa kwa kutumia ECB inaweza kuwa hatarini.\
Ikiwa cookie imefungwa kwa kutumia ECB inaweza kuwa na hatari.\
Wakati unapoingia, cookie unayopokea inapaswa kuwa kila wakati sawa.
**Jinsi ya kugundua na kushambulia:**
Unda watumiaji 2 wenye takwimu karibu sawa (jina la mtumiaji, nenosiri, barua pepe, nk.) na jaribu kugundua muundo wowote ndani ya cookie iliyotolewa.
Unda mtumiaji anayeitwa kwa mfano "aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa" na angalia ikiwa kuna muundo wowote katika cookie (kama ECB inasimba kwa kutumia funguo sawa kila block, bytes sawa zilizofungwa zinaweza kuonekana ikiwa jina la mtumiaji linapofungwa).
Unda mtumiaji anayeitwa kwa mfano "aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa" na angalia ikiwa kuna muundo wowote katika cookie (kama ECB inasimbwa kwa kutumia funguo sawa kila block, bytes sawa zilizofungwa zinaweza kuonekana ikiwa jina la mtumiaji linapofungwa).
Inapaswa kuwa na muundo (kwa ukubwa wa block inayotumika). Hivyo, ukijua jinsi kundi la "a" linavyofungwa unaweza kuunda jina la mtumiaji: "a"\*(ukubwa wa block)+"admin". Kisha, unaweza kufuta muundo wa funguo wa block ya "a" kutoka kwa cookie. Na utakuwa na cookie ya jina la mtumiaji "admin".
Inapaswa kuwa na muundo (kwa ukubwa wa block inayotumika). Hivyo, ukijua jinsi kundi la "a" linavyosimbwa unaweza kuunda jina la mtumiaji: "a"\*(ukubwa wa block)+"admin". Kisha, unaweza kufuta muundo wa funguo wa block ya "a" kutoka kwa cookie. Na utakuwa na cookie ya jina la mtumiaji "admin".
## Marejeo