mirror of https://github.com/carlospolop/hacktricks synced 2024-11-26 06:30:37 +00:00

History

Translator fb8b98c0d5 Translated ['binary-exploitation/libc-heap/README.md', 'binary-exploitat		2024-09-19 16:40:33 +00:00
..
cookie-bomb.md	Translated ['generic-methodologies-and-resources/basic-forensic-methodol	2024-07-19 10:17:18 +00:00
cookie-jar-overflow.md	Translated ['generic-methodologies-and-resources/basic-forensic-methodol	2024-07-19 10:17:18 +00:00
cookie-tossing.md	Translated ['pentesting-web/browser-extension-pentesting-methodology/REA	2024-07-19 16:10:31 +00:00
README.md	Translated ['binary-exploitation/libc-heap/README.md', 'binary-exploitat	2024-09-19 16:40:33 +00:00

README.md

Cookies Hacking

{% hint style="success" %} Learn & practice AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
Learn & practice GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)

Support HackTricks

Check the subscription plans!
Join the 💬 Discord group or the telegram group or follow us on Twitter 🐦 @hacktricks_live.
Share hacking tricks by submitting PRs to the HackTricks and HackTricks Cloud github repos.

{% endhint %}

Cookies zina sifa kadhaa ambazo zinadhibiti tabia yao katika kivinjari cha mtumiaji. Hapa kuna muhtasari wa sifa hizi kwa sauti ya chini:

Expires and Max-Age

Tarehe ya kumalizika kwa cookie inamuliwa na sifa ya Expires. Kinyume chake, sifa ya Max-age inaelezea muda kwa sekunde hadi cookie ifutwe. Chagua Max-age kwani inawakilisha mazoea ya kisasa zaidi.

Domain

Wenyeji wa kupokea cookie huainishwa 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, 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

Njia maalum ya URL ambayo lazima iwepo katika URL iliyohitajika ili kichwa cha Cookie kitumwe inaonyeshwa na sifa ya Path. Sifa hii inachukulia herufi / kama separator ya directory, ikiruhusu mechi katika subdirectories pia.

Ordering Rules

Wakati cookies mbili zina jina sawa, ile iliyochaguliwa kutumwa inategemea:

Cookie inayolingana na njia ndefu zaidi katika URL iliyohitajika.
Cookie iliyowekwa hivi karibuni ikiwa njia hizo ni sawa.

SameSite

Sifa ya SameSite inaamuru ikiwa cookies zitatumwa kwenye maombi yanayotokana na maeneo ya upande wa tatu. Inatoa mipangilio mitatu:
Strict: Inazuia cookie kutumwa kwenye maombi ya upande wa tatu.
Lax: Inaruhusu cookie kutumwa na maombi ya GET yanayoanzishwa na tovuti za upande wa tatu.
None: Inaruhusu cookie kutumwa kutoka kwa eneo lolote la upande wa tatu.

Kumbuka, wakati wa kuunda cookies, kuelewa sifa hizi kunaweza kusaidia kuhakikisha zinatenda kama inavyotarajiwa katika hali tofauti.

Request Type	Example Code	Cookies Sent When
Link	<a href="..."></a>	NotSet*, Lax, None
Prerender	<link rel="prerender" href=".."/>	NotSet*, Lax, None
Form GET	<form method="GET" action="...">	NotSet*, Lax, None
Form POST	<form method="POST" action="...">	NotSet*, None
iframe	<iframe src="..."></iframe>	NotSet*, None
AJAX	$.get("...")	NotSet*, None
Image	<img src="...">	NetSet*, None

Table from Invicti and slightly modified.
Cookie yenye sifa ya SameSite itapunguza CSRF attacks ambapo kikao kilichoingia kinahitajika.

*Kumbuka kwamba kuanzia Chrome80 (feb/2019) tabia ya kawaida ya cookie bila sifa ya cookie samesite itakuwa lax (https://www.troyhunt.com/promiscuous-cookies-and-their-impending-death-via-the-samesite-policy/).
Kumbuka kwamba kwa muda wa muda, baada ya kutumia mabadiliko haya, cookies bila sera ya SameSite katika Chrome zitachukuliwa kama None wakati wa dakika 2 za kwanza na kisha kama Lax kwa ombi la POST la juu la tovuti.

Cookies Flags

HttpOnly

Hii inazuia mteja kufikia cookie (Kupitia Javascript kwa mfano: document.cookie)

Bypasses

Ikiwa ukurasa unatumia cookies kama jibu la maombi (kwa mfano katika ukurasa wa PHPinfo), inawezekana kutumia XSS kutuma ombi kwa ukurasa huu na kuiba cookies kutoka kwa jibu (angalia mfano katika https://hackcommander.github.io/posts/2022/11/12/bypass-httponly-via-php-info-page/.
Hii inaweza kupitishwa kwa maombi ya TRACE HTTP kwani jibu kutoka kwa seva (ikiwa njia hii ya HTTP inapatikana) itarudisha cookies zilizotumwa. Mbinu hii inaitwa Cross-Site Tracking.
Mbinu hii inakwepa na vivinjari vya kisasa kwa kutoruhusu kutuma ombi la TRACE kutoka JS. Hata hivyo, baadhi ya njia za kupita zimepatikana katika programu maalum kama kutuma \r\nTRACE badala ya TRACE kwa IE6.0 SP2.
Njia nyingine ni kutumia udhaifu wa zero/day wa vivinjari.
Inawezekana kufuta cookies za HttpOnly kwa kufanya shambulio la Cookie Jar overflow:

{% content-ref url="cookie-jar-overflow.md" %} cookie-jar-overflow.md {% endcontent-ref %}

Inawezekana kutumia Cookie Smuggling shambulio kuhamasisha cookies hizi

Secure

Ombi litatumwa tu kutuma cookie katika ombi la HTTP tu ikiwa ombi linatumwa kupitia njia salama (kawaida HTTPS).

Cookies Prefixes

Cookies zilizo na awali __Secure- zinahitajika kuwekwa pamoja na bendera ya secure kutoka kurasa ambazo zimehakikishwa na HTTPS.

Kwa cookies zilizo na awali __Host-, masharti kadhaa yanapaswa kutimizwa:

Lazima ziwe zimewekwa na bendera ya secure.
Lazima zitoke kwenye ukurasa uliohakikishwa na HTTPS.
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.

Overwriting cookies

Hivyo, moja ya ulinzi wa cookies zilizo na awali ya __Host- ni kuzuia zifutwe kutoka subdomains. Kuzuia kwa mfano Cookie Tossing attacks. Katika mazungumzo Cookie Crumbles: Unveiling Web Session Integrity Vulnerabilities (paper) inawasilishwa kwamba ilikuwa inawezekana kuweka cookies zilizo na awali ya __HOST- kutoka subdomain, kwa kudanganya parser, kwa mfano, kuongeza "=" mwanzoni au mwishoni...:

Au katika PHP ilikuwa inawezekana kuongeza herufi nyingine mwanzoni mwa jina la cookie ambazo zingeondolewa na herufi za chini, kuruhusu kufuta __HOST- cookies:

Cookies Attacks

Ikiwa cookie maalum ina data nyeti angalia hiyo (hasa ikiwa unacheza CTF), kwani inaweza kuwa na udhaifu.

Decoding and Manipulating Cookies

Data nyeti iliyojumuishwa katika cookies inapaswa daima kuchunguzwa. Cookies zilizowekwa katika Base64 au mifumo inayofanana mara nyingi zinaweza kufichuliwa. Udhaifu huu unaruhusu washambuliaji kubadilisha maudhui ya cookie na kujifanya watumiaji wengine kwa kuweka data zao zilizobadilishwa tena kwenye cookie.

Session Hijacking

Shambulio hili linahusisha kuiba cookie ya mtumiaji ili kupata ufikiaji usioidhinishwa kwa akaunti yao ndani ya programu. Kwa kutumia cookie iliyop stolen, mshambuliaji anaweza kujifanya mtumiaji halali.

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.

Ikiwa umepata XSS katika subdomain au unadhibiti subdomain, soma:

{% content-ref url="cookie-tossing.md" %} cookie-tossing.md {% endcontent-ref %}

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.

Ikiwa umepata XSS katika subdomain au unadhibiti subdomain, soma:

{% content-ref url="cookie-tossing.md" %} cookie-tossing.md {% endcontent-ref %}

JWT Cookies

Bonyeza kwenye kiungo kilichotangulia ili kufikia ukurasa unaoelezea udhaifu unaowezekana katika JWT.

JSON Web Tokens (JWT) zinazotumiwa katika cookies pia zinaweza kuonyesha udhaifu. Kwa maelezo ya kina kuhusu udhaifu unaowezekana na jinsi ya kuyatumia, inashauriwa kufikia hati iliyo kwenye udukuzi wa JWT.

Cross-Site Request Forgery (CSRF)

Shambulio hili linamfanya mtumiaji aliyeingia kutekeleza vitendo visivyotakikana kwenye programu ya wavuti ambayo kwa sasa wanaidhinishwa. Washambuliaji wanaweza kutumia cookies ambazo zinasafirishwa kiotomatiki na kila ombi kwa tovuti iliyo hatarini.

Empty Cookies

(Tazama maelezo zaidi katika utafiti wa asili) Vivinjari vinaruhusu kuundwa kwa cookies bila jina, ambayo inaweza kuonyeshwa kupitia JavaScript kama ifuatavyo:

document.cookie = "a=v1"
document.cookie = "=test value;" // Setting an empty named cookie
document.cookie = "b=v2"

Matokeo katika kichwa cha cookie kilichotumwa ni a=v1; test value; b=v2;. Kwa kushangaza, hii inaruhusu udanganyifu wa cookies ikiwa cookie yenye jina tupu imewekwa, ikidhibiti cookies nyingine kwa kuweka cookie hiyo tupu kuwa thamani maalum:

function setCookie(name, value) {
document.cookie = `${name}=${value}`;
}

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 Kodepoint ya Unicode Surrogate

Katika Chrome, ikiwa kodepoint ya Unicode surrogate ni sehemu ya cookie iliyowekwa, document.cookie inaharibika, ikirudisha string tupu baadaye:

document.cookie = "\ud800=meep";

This results in document.cookie outputting an empty string, indicating permanent corruption.

(Check further details in theoriginal research) Seva nyingi 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 semikolon, ambazo kawaida zinapaswa kutenganisha jozi za funguo-thamani:

RENDER_TEXT="hello world; JSESSIONID=13371337; ASDF=end";

Uthibitisho wa Uvunjaji wa Keki

(Tafadhali angalia maelezo zaidi katika utafiti wa asili) 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 kuingiza keki. Seva hizi zinashindwa kuweka mipaka sahihi ya kuanza kwa keki mpya, ikiruhusu washambuliaji kuiga keki:

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.

Uthibitisho huu ni hatari sana katika programu za wavuti zinazotegemea ulinzi wa CSRF wa keki, kwani inaruhusu washambuliaji kuingiza keki za CSRF-token zilizoghushi, na hivyo kuweza kupita hatua za usalama. Tatizo hili linazidishwa na usimamizi wa Python wa majina ya keki yanayojirudia, ambapo tukio la mwisho linabadilisha yale ya awali. Pia linaibua wasiwasi kwa keki za __Secure- na __Host- katika muktadha usio salama na linaweza kusababisha kupita kwa mamlaka wakati keki zinapopita kwa seva za nyuma zinazoweza kuathiriwa na kuiga.

Ukaguzi wa Keki Zenye Uthibitisho wa Ziada

Ukaguzi wa Msingi

Keki ni ile ile kila wakati unapo ingia.
Toka na jaribu kutumia keki ile ile.
Jaribu kuingia na vifaa 2 (au vivinjari) kwa akaunti ile ile ukitumia keki ile ile.
Angalia kama keki ina taarifa yoyote ndani yake na jaribu kuibadilisha.
Jaribu kuunda akaunti kadhaa zikiwa na jina la mtumiaji karibu sawa na angalia kama unaweza kuona kufanana.
Angalia chaguo la "nikumbuke" ikiwa ipo ili kuona jinsi inavyofanya kazi. Ikiwa ipo na inaweza kuwa na udhaifu, daima tumia keki ya nikumbuke bila keki nyingine yoyote.
Angalia kama keki ya awali inafanya kazi hata baada ya kubadilisha nenosiri.

Mashambulizi ya Keki ya Juu

Ikiwa keki inabaki kuwa ile ile (au karibu) unapoingia, hii ina maana kwamba keki hiyo inahusiana na uwanja fulani wa akaunti yako (labda jina la mtumiaji). Kisha unaweza:

Jaribu kuunda akaunti nyingi zikiwa na majina ya watumiaji yanayofanana sana na jaribu kukisia jinsi algorithimu inavyofanya kazi.
Jaribu kuvunjavunja 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 kuvunjavunja 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.

Padding Oracle - Mifano ya Padbuster

padbuster <URL/path/when/successfully/login/with/cookie> <COOKIE> <PAD[8-16]>
# When cookies and regular Base64
padbuster http://web.com/index.php u7bvLewln6PJPSAbMb5pFfnCHSEd6olf 8 -cookies auth=u7bvLewln6PJPSAbMb5pFfnCHSEd6olf

# If Base64 urlsafe or hex-lowercase or hex-uppercase --encoding parameter is needed, for example:
padBuster http://web.com/home.jsp?UID=7B216A634951170FF851D6CC68FC9537858795A28ED4AAC6
7B216A634951170FF851D6CC68FC9537858795A28ED4AAC6 8 -encoding 2

Padbuster itafanya majaribio kadhaa na itakuuliza ni hali ipi ndiyo hali ya makosa (ile ambayo si halali).

Kisha itaanza kufungua siri ya cookie (inaweza kuchukua dakika kadhaa)

Ikiwa shambulio limefanywa kwa mafanikio, basi unaweza kujaribu kuandika upya mfuatano wa chaguo lako. Kwa mfano, ikiwa ungependa encrypt user=administrator

padbuster http://web.com/index.php 1dMjA5hfXh0jenxJQ0iW6QXKkzAGIWsiDAKV3UwJPT2lBP+zAD0D0w== 8 -cookies thecookie=1dMjA5hfXh0jenxJQ0iW6QXKkzAGIWsiDAKV3UwJPT2lBP+zAD0D0w== -plaintext user=administrator

Hii utekelezaji itakupa cookie iliyosimbwa na kuandikwa kwa usahihi na mfuatano user=administrator ndani.

CBC-MAC

Labda cookie inaweza kuwa na thamani fulani na inaweza kusainiwa kwa kutumia CBC. Kisha, uadilifu wa thamani ni saini iliyoundwa kwa kutumia CBC na thamani hiyo hiyo. Kama inavyopendekezwa kutumia kama IV vector ya sifuri, aina hii ya ukaguzi wa uadilifu inaweza kuwa na hatari.

Shambulio

Pata saini ya jina la mtumiaji administ = t
Pata saini ya jina la mtumiaji rator\x00\x00\x00 XOR t = t'
Weka katika cookie thamani administrator+t' (t' itakuwa saini halali ya (rator\x00\x00\x00 XOR t) XOR t = rator\x00\x00\x00

ECB

Ikiwa cookie imesimbwa 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 zilizosimbwa zinaweza kuonekana ikiwa jina la mtumiaji linasimbwa).

Inapaswa kuwa na muundo (kwa ukubwa wa block iliyotumika). Hivyo, ukijua jinsi kundi la "a" linavyosimbwa unaweza kuunda jina la mtumiaji: "a"*(ukubwa wa block)+"admin". Kisha, unaweza kufuta muundo wa kusimbwa wa block ya "a" kutoka kwa cookie. Na utakuwa na cookie ya jina la mtumiaji "admin".

Marejeo