Cookies Hacking

Reading time: 14 minutes

tip

Jifunze na fanya mazoezi ya AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
Jifunze na fanya mazoezi ya GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)

Support HackTricks

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 inaakisi mazoea ya kisasa zaidi.

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

Jedwali kutoka Invicti na kidogo kubadilishwa.
Cookie yenye sifa ya SameSite itapunguza shambulio la CSRF 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, 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 msalaba.

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

Cookie Jar Overflow

Secure

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

Cookies Prefixes

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

Kwa cookies zilizo na kiambishi __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 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 kiambishi __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 kiambishi __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 chini , kuruhusu kufuta cookies za __HOST-:

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 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 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 ameingia 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 kilichopita kupata ukurasa unaofafanua 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 kuhamasisha 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:

js
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, ikifanya iwezekane kudhibiti cookies nyingine kwa kuweka cookie hiyo tupu kwa thamani maalum:

js
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 Unicode Surrogate Codepoint

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

js
document.cookie = "\ud800=meep"

Hii inasababisha document.cookie kutoa string tupu, ikionyesha uharibifu wa kudumu.

(Tazama maelezo zaidi katika utafiti wa asili) 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";

Ukatili wa Kuingiza Cookies

(Tafadhali angalia maelezo zaidi katika utafiti wa asili) 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 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.

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.

Cookies $version

Kupita WAF

Kulingana na hiki blogpost, 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.

Kulingana na hiki blogpost 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

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.

Hatimaye backdoors tofauti zingeungana katika string cookies tofauti zilizopitishwa katika vichwa tofauti vya cookie kama katika:

GET / HTTP/1.1
Host: example.com
Cookie: param1=value1;
Cookie: param2=value2;

Ambayo inaweza kuruhusu kupita WAF kama katika mfano huu:

Cookie: name=eval('test//
Cookie: comment')

Resulting cookie: name=eval('test//, comment') => allowed

Extra Vulnerable Cookies Checks

Basic checks

  • Keki ni ile ile kila wakati unapo ingia.
  • Toka na jaribu kutumia keki ile ile.
  • Jaribu kuingia na vifaa 2 (au vivinjari) kwenye 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.

Advanced cookies attacks

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

Padding Oracle - Padbuster examples

bash
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 kufichua cookie (inaweza kuchukua dakika kadhaa)

Ikiwa shambulio limefanikiwa, basi unaweza kujaribu kuficha 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, 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

  1. Pata saini ya jina la mtumiaji administ = t
  2. Pata saini ya jina la mtumiaji rator\x00\x00\x00 XOR t = t'
  3. 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 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 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" 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

tip

Jifunze na fanya mazoezi ya AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
Jifunze na fanya mazoezi ya GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)

Support HackTricks