Cookies Hacking

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.

Try Hard Security Group

Join the Try Hard Security Discord Server!Discord

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 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

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 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

NotSet*, Lax, None

Prerender

NotSet*, Lax, None

Form GET

NotSet*, Lax, None

Form POST

NotSet*, None

iframe

NotSet*, None

AJAX

$.get("...")

NotSet*, None

Image

NetSet*, None

Table from Invicti and slightly modified. A cookie with SameSite attribute will mitigate CSRF attacks where a logged session is needed.

*Notice that from Chrome80 (feb/2019) the default behaviour of a cookie without a cookie samesite attribute will be lax (https://www.troyhunt.com/promiscuous-cookies-and-their-impending-death-via-the-samesite-policy/). Notice that temporary, after applying this change, the cookies without a SameSite policy in Chrome will be treated as None during the first 2 minutes and then as Lax for top-level cross-site POST request.

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 hii 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 kuandika upya cookies za HttpOnly kwa kufanya shambulio la Cookie Jar overflow:

Cookie Jar Overflow

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 __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 kuandikwa upya 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 __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 underscore, kuruhusu kuandika upya __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 iliyowekwa ndani ya 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 kuficha data zao zilizobadilishwa tena ndani ya cookie.

Session Hijacking

Shambulio hili linahusisha kuiba cookie ya mtumiaji ili kupata ufikiaji usioidhinishwa kwa akaunti yao ndani ya programu. Kwa kutumia cookie iliyibwa, 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, 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:

Cookie Tossing

Session Donation

Hapa, mshambuliaji anamshawishi mwathirika kutumia cookie ya kikao ya mshambuliaji. Mwathirika, akiamini kwamba amejiandikisha kwenye akaunti yake mwenyewe, atafanya vitendo bila kujua katika muktadha wa akaunti ya mshambuliaji.

Ikiwa umepata XSS katika subdomain au unadhibiti subdomain, soma:

Cookie Tossing

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 Kiwango cha Unicode Surrogate

Katika Chrome, ikiwa kiwango cha Unicode surrogate ni sehemu ya cookie iliyowekwa, document.cookie inaharibika, ikirudisha mfuatano wa 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 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 kwa kawaida zinapaswa kutenganisha jozi za funguo-thamani:

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

Uthibitisho wa Uvunjifu 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 kudanganywa.

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 huenda ikamaanisha kuwa 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 kuvunjia 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 kuvunjia 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 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 hatarini.

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 hatarini. 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 zilizofichwa zinaweza kuonekana ikiwa jina la mtumiaji limesimbwa).

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 kisimbaji wa block ya "a" kutoka kwa cookie. Na utakuwa na cookie ya jina la mtumiaji "admin".