Cookies Hacking
Last updated
Last updated
Learn & practice AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE) Learn & practice GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
Cookies zina sifa kadhaa ambazo zinadhibiti tabia yao katika kivinjari cha mtumiaji. Hapa kuna muhtasari wa sifa hizi kwa sauti ya chini:
Tarehe ya kumalizika kwa cookie inamuliwa na sifa ya Expires. Kinyume chake, sifa ya Max-age inaelezea muda kwa sekunde hadi cookie itakapofutwa. Chagua Max-age kwani inawakilisha mazoea ya kisasa zaidi.
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.
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 saraka, ikiruhusu mechi katika saraka ndogo pia.
Wakati cookies mbili zina jina sawa, ile iliyochaguliwa kutumwa inategemea:
Cookie inayolingana na njia ndefu zaidi katika URL iliyohitajika.
Cookie iliyowekwa hivi karibuni zaidi ikiwa njia hizo ni sawa.
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. 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.
Hii inazuia mteja kufikia cookie (Kupitia Javascript kwa mfano: document.cookie)
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 kufuta cookies za HttpOnly kwa kufanya shambulio la Cookie Jar overflow:
Inawezekana kutumia Cookie Smuggling shambulio kuhamasisha cookies hizi
Ombi litatumwa tu kutuma cookie katika ombi la HTTP tu ikiwa ombi linatumwa kupitia njia salama (kawaida HTTPS).
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 kwenye /.
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.
Hivyo, moja ya ulinzi wa cookies zilizo na awali __Host- ni kuzuia ziweze kufutwa 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 zingeweza kubadilishwa na herufi za underscore, kuruhusu kufuta cookies za __HOST-:
Ikiwa cookie maalum ina data nyeti angalia hiyo (hasa ikiwa unacheza CTF), kwani inaweza kuwa na udhaifu.
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 kuandika data zao zilizobadilishwa tena ndani ya cookie.
Shambulio hili linahusisha kuiba cookie ya mtumiaji ili kupata ufikiaji usioidhinishwa kwa akaunti yao ndani ya programu. Kwa kutumia cookie iliyibwa, mshambuliaji anaweza kujifanya kuwa mtumiaji halali.
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 kuwa mwathirika. Mbinu hii inategemea mwathirika kuingia na cookie iliyotolewa na mshambuliaji.
Ikiwa umepata XSS katika subdomain au unadhibiti subdomain, soma:
Cookie TossingHapa, mshambuliaji anamshawishi mwathirika kutumia cookie ya kikao ya mshambuliaji. Mwathirika, akiamini kuwa amejiandikisha kwenye akaunti yake mwenyewe, atafanya vitendo bila kukusudia katika muktadha wa akaunti ya mshambuliaji.
Ikiwa umepata XSS katika subdomain au unadhibiti subdomain, soma:
Cookie TossingBonyeza 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.
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.
(Tazama maelezo zaidi katika utafiti wa asili) Vivinjari vinaruhusu kuunda cookies bila jina, ambayo inaweza kuonyeshwa kupitia JavaScript kama ifuatavyo:
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 na thamani maalum:
Hii inasababisha kivinjari kutuma kichwa cha cookie kinachotafsiriwa na kila seva ya wavuti kama cookie iliyo na jina a na thamani b.
Katika Chrome, ikiwa kodepoint ya Unicode surrogate ni sehemu ya cookie iliyowekwa, document.cookie inaharibika, ikirudisha string tupu baadaye:
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. 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:
(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 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 zinapopelekwa kwa seva za nyuma zinazoweza kudanganywa.
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.
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 za jina la mtumiaji zikiwa na ufanano mkubwa 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 itafanya majaribio kadhaa na itakuuliza ni hali ipi ndiyo hali ya kosa (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
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".
Learn & practice AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE) Learn & practice GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
