Cookies Hacking
Cookie Attributes
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 tatu. Inatoa mipangilio mitatu:Strict: Inazuia cookie kutumwa kwenye maombi ya wahusika wengine.
Lax: Inaruhusu cookie kutumwa na maombi ya GET yanayoanzishwa na tovuti za wahusika wengine.
None: Inaruhusu cookie kutumwa kutoka kwa eneo lolote la wahusika wengine.
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.
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 yaTRACE
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
Secure
Ombi litatumwa tu kutuma cookie katika ombi la HTTP tu ikiwa ombi linatumwa kupitia njia salama (kawaida HTTPS).
Cookies Prefixes
Cookies zilizo na prefix __Secure-
zinahitajika kuwekwa pamoja na bendera ya secure
kutoka kurasa ambazo zimehakikishwa na HTTPS.
Kwa cookies zilizo na prefix __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 prefix __Host-
haziruhusiwi kutumwa kwa superdomains au subdomains. Kizuizi hiki kinasaidia katika kutenga cookies za programu. Hivyo, kutumia prefix __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 prefix __Host-
ni kuzuia zisifutwe 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 prefix __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 __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 kufutwa. Udhaifu huu unaruhusu washambuliaji kubadilisha maudhui ya cookie na kujifanya watumiaji wengine kwa kuandika 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 kuwa 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 kuwa mwathirika. Mbinu hii inategemea mwathirika kuingia na cookie iliyotolewa na mshambuliaji.
Ikiwa umepata XSS katika subdomain au unadhibiti subdomain, soma:
Cookie TossingSession Donation
Hapa, mshambuliaji anamshawishi mwathirika kutumia cookie ya kikao ya mshambuliaji. Mwathirika, akiamini kwamba amejiunga na akaunti yake mwenyewe, atafanya vitendo bila kujua 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.
Cross-Site Request Forgery (CSRF)
Shambulio hili linamfanya mtumiaji aliyeingia kutekeleza vitendo visivyotakiwa 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 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
.
Chrome Bug: Tatizo la Kiwango cha Unicode Surrogate
Katika Chrome, ikiwa kiwango cha 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.
Cookie Smuggling Due to Parsing Issues
(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:
Ukatili wa Kuingiza 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.
Ukatili huu ni hatari sana katika programu za wavuti zinazotegemea ulinzi wa CSRF wa keki, kwani inaruhusu washambuliaji kuingiza keki za CSRF-token zilizogaiwa, 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 Ukatili Zaidi
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 (huenda 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 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 itafanya majaribio kadhaa na itakuuliza ni hali ipi ndiyo hali ya kosa (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
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 inayotumika). 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
Last updated