Cookies Hacking

Naučite hakovanje AWS-a od nule do heroja sa htARTE (HackTricks AWS Red Team Expert)!

Drugi načini podrške HackTricks-u:

Try Hard Security Group


Atributi Kolačića

Kolačići dolaze sa nekoliko atributa koji kontrolišu njihovo ponašanje u korisnikovom pregledaču. Evo pregleda ovih atributa u pasivnijem tonu:

Ističe i Max-Age

Datum isteka kolačića određen je atributom Expires. S druge strane, atribut Max-age definiše vreme u sekundama dok se kolačić ne obriše. Izaberite Max-age jer odražava modernije prakse.

Domen

Domaćini koji primaju kolačić su navedeni atributom Domain. Podrazumevano, ovo je postavljeno na domaćina koji je izdao kolačić, ne uključujući njegove poddomene. Međutim, kada je atribut Domain eksplicitno postavljen, obuhvata i poddomene. Ovo čini specifikaciju atributa Domain manje restriktivnom opcijom, korisnom za scenarije gde je deljenje kolačića preko poddomena neophodno. Na primer, postavljanje Domain=mozilla.org omogućava pristup kolačićima na njenim poddomenima poput developer.mozilla.org.

Putanja

Specifična URL putanja koja mora biti prisutna u zahtevanom URL-u za slanje zaglavlja Cookie označena je atributom Path. Ovaj atribut razmatra karakter / kao separator direktorijuma, omogućavajući podudaranja u poddirektorijumima takođe.

Pravila za Redosled

Kada dva kolačića nose isto ime, onaj koji se bira za slanje zasnovan je na:

  • Kolačić koji se podudara sa najdužom putanjom u zahtevanom URL-u.

  • Najskorije postavljen kolačić ako su putanje identične.

SameSite

  • Atribut SameSite diktira da li se kolačići šalju na zahteve koji potiču sa domena treće strane. Nudi tri podešavanja:

  • Strict: Ograničava slanje kolačića na zahtevima trećih strana.

  • Lax: Dozvoljava slanje kolačića sa GET zahtevima pokrenutim od strane trećih veb sajtova.

  • None: Dozvoljava slanje kolačića sa bilo kog domena treće strane.

Zapamtite, prilikom konfigurisanja kolačića, razumevanje ovih atributa može pomoći da se osigura da se ponašaju kako se očekuje u različitim scenarijima.

Tip Zahteva

Primer Koda

Kolačići Poslati Kada

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

Slika

<img src="...">

NetSet*, None

Tabela preuzeta sa Invicti i blago modifikovana. Kolačić sa SameSite atributom će umanjiti CSRF napade gde je potrebna prijavljena sesija.

*Primetite da od Chrome80 (feb/2019) podrazumevano ponašanje kolačića bez SameSite atributa će biti lax (https://www.troyhunt.com/promiscuous-cookies-and-their-impending-death-via-the-samesite-policy/). Primetite da privremeno, nakon primene ove promene, kolačići bez SameSite političke u Chrome-u će biti tretirani kao None tokom prva 2 minuta, a zatim kao Lax za POST zahteve preko cross-site.

Zastave Kolačića

HttpOnly

Ovo sprečava klijenta da pristupi kolačiću (Na primer putem Javascript-a: document.cookie)

Bypass-ovi

  • Ako stranica šalje kolačiće kao odgovor na zahteve (na primer na PHPinfo stranici), moguće je zloupotrebiti XSS da se pošalje zahtev ovoj stranici i ukrade kolačiće iz odgovora (proverite primer na https://hackcommander.github.io/posts/2022/11/12/bypass-httponly-via-php-info-page/.

  • Ovo može biti zaobiđeno sa TRACE HTTP zahtevima jer će odgovor sa servera (ako je ovaj HTTP metod dostupan) odražavati poslate kolačiće. Ova tehnika se naziva Cross-Site Tracking.

  • Ova tehnika se izbegava od strane modernih pregledača ne dozvoljavajući slanje TRACE zahteva iz JS-a. Međutim, neki načini zaobiđanja ove zabrane su pronađeni u specifičnim softverima poput slanja \r\nTRACE umesto TRACE ka IE6.0 SP2.

  • Drugi način je iskorišćavanje zero/day ranjivosti pregledača.

  • Moguće je prepisati HttpOnly kolačiće izvođenjem napada prelivanja Cookie Jar-a:

pageCookie Jar Overflow

Secure

Zahtev će samo poslati kolačić u HTTP zahtevu samo ako je zahtev prenet preko sigurnog kanala (tipično HTTPS).

Prefiksi Kolačića

Kolačići sa prefiksom __Secure- moraju biti postavljeni zajedno sa zastavicom secure na stranicama koje su obezbeđene HTTPS-om.

Za kolačiće sa prefiksom __Host-, moraju se ispuniti nekoliko uslova:

  • Moraju biti postavljeni sa zastavicom secure.

  • Moraju poticati sa stranice obezbeđene HTTPS-om.

  • Zabranjeno je specificiranje domena, sprečavajući njihovo slanje poddomenima.

  • Putanja za ove kolačiće mora biti postavljena na /.

Važno je napomenuti da kolačići sa prefiksom __Host- nisu dozvoljeni da se šalju superdomenima ili poddomenima. Ova zabrana pomaže u izolovanju aplikacionih kolačića. Stoga, korišćenje prefiksa __Host- za sve aplikacione kolačiće može se smatrati dobrom praksom za unapređenje sigurnosti i izolacije.

Prepisivanje kolačića

Dakle, jedna od zaštita __Host- prefiksnih kolačića je sprečavanje prepisivanja sa poddomena. Na primer, sprečavanje Cookie Tossing napada. U predavanju Cookie Crumbles: Otkrivanje ranjivosti integriteta web sesije (rad) prikazano je da je bilo moguće postaviti __HOST- prefiksne kolačiće sa poddomena, trikomiranje parsera, na primer, dodavanjem "=" na početku ili na početku i na kraju...:

Ili u PHP-u bilo je moguće dodati druge karaktere na početku imena kolačića koji će biti zamenjeni donjom crtom karakterima, omogućavajući prepisivanje __HOST- kolačića:

Napadi na Kolačiće

Ako prilagođeni kolačić sadrži osetljive podatke, proverite ga (posebno ako igrate CTF), jer može biti ranjiv.

Dekodiranje i Manipulacija Kolačićima

Osetljivi podaci ugrađeni u kolačiće uvek treba da budu pažljivo pregledani. Kolačići kodirani u Base64 ili sličnim formatima često mogu biti dekodirani. Ova ranjivost omogućava napadačima da promene sadržaj kolačića i predstavljaju druge korisnike enkodirajući svoje modifikovane podatke nazad u kolačić.

Hakovanje Sesije

Ovaj napad uključuje krađu korisnikovog kolačića kako bi se stekao neovlašćen pristup njihovom nalogu unutar aplikacije. Korišćenjem ukradenog kolačića, napadač može da se predstavi kao legitimni korisnik.

Fiksacija Sesije

U ovom scenariju, napadač vara žrtvu da koristi određeni kolačić za prijavljivanje. Ako aplikacija ne dodeli novi kolačić prilikom prijavljivanja, napadač, posedujući originalni kolačić, može da se predstavi kao žrtva. Ova tehnika se oslanja na to da žrtva prijavljivanje vrši sa kolačićem koji je dostavio napadač.

Ako pronađete XSS u poddomenu ili kontrolišete poddomen, pročitajte:

pageCookie Tossing

Donacija Sesije

Ovde, napadač ubedi žrtvu da koristi sesioni kolačić napadača. Žrtva, verujući da je prijavljena na svoj nalog, nenamerno obavlja radnje u kontekstu naloga napadača.

Ako pronađete XSS u poddomenu ili kontrolišete poddomen, pročitajte:

pageCookie Tossing

Kliknite na prethodni link da biste pristupili stranici koja objašnjava moguće propuste u JWT.

JSON Web Tokens (JWT) korišćeni u kolačićima takođe mogu imati ranjivosti. Za detaljne informacije o potencijalnim propustima i kako ih iskoristiti, preporučuje se pristupanje povezanom dokumentu o hakovanju JWT.

CSRF (Cross-Site Request Forgery)

Ovaj napad prisiljava prijavljenog korisnika da izvrši neželjene radnje na veb aplikaciji na kojoj je trenutno autentifikovan. Napadači mogu iskoristiti kolačiće koji se automatski šalju sa svakim zahtevom ka ranjivoj stranici.

Prazni Kolačići

(Proverite dalje detalje u originalnom istraživanju) Pretraživači dozvoljavaju kreiranje kolačića bez imena, što se može demonstrirati putem JavaScript-a kako sledi:

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

Rezultat u poslatom zaglavlju kolačića je a=v1; test vrednost; b=v2;. Zanimljivo, ovo omogućava manipulaciju kolačićima ako je postavljen prazan kolačić sa imenom, potencijalno kontrolišući druge kolačiće postavljanjem praznog kolačića na određenu vrednost:

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

setCookie("", "a=b"); // Setting the empty cookie modifies another cookie's value

Chrome Bag: Pitanje o kodnoj tački zamene Unicode

U Chrome-u, ako je kodna tačka zamene Unicode-a deo postavljenog kolačića, document.cookie postaje oštećen, vraćajući prazan niz naknadno:

document.cookie = "\ud800=meep";

Ovo rezultira time da document.cookie ispiše prazan string, što ukazuje na trajnu korupciju.

Kukija krijumčarenje zbog problema sa parsiranjem

(Proverite detalje u originalnom istraživanju) Neki web serveri, uključujući one iz Java (Jetty, TomCat, Undertow) i Python (Zope, cherrypy, web.py, aiohttp, bottle, webob), nepravilno obrađuju cookie stringove zbog zastarele podrške za RFC2965. Oni čitaju vrednost kukija u dvostrukim navodnicima kao jednu vrednost čak i ako sadrži tačkazareze, koje bi normalno trebalo da razdvajaju parove ključ-vrednost:

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

Vulnerabilnosti ubacivanja kolačića

(Proverite dalje detalje u originalnom istraživanju) Neispravno parsiranje kolačića od strane servera, posebno Undertow-a, Zope-a, i onih koji koriste Python-ove http.cookie.SimpleCookie i http.cookie.BaseCookie, stvara mogućnosti za napade ubacivanjem kolačića. Ovi serveri ne uspevaju pravilno da ograniče početak novih kolačića, omogućavajući napadačima da falsifikuju kolačiće:

  • Undertow očekuje novi kolačić odmah nakon navodne vrednosti bez tačkazareza.

  • Zope traži zarez da započne parsiranje sledećeg kolačića.

  • Python-ove klase kolačića počinju parsiranje na znaku razmaka.

Ova ranjivost je posebno opasna u veb aplikacijama koje se oslanjaju na CSRF zaštitu zasnovanu na kolačićima, jer omogućava napadačima da ubace lažne CSRF-token kolačiće, potencijalno zaobilazeći sigurnosne mere. Problem se pogoršava Python-ovim rukovanjem duplikatima imena kolačića, gde poslednje pojavljivanje zamenjuje prethodne. Takođe postavlja pitanja za __Secure- i __Host- kolačiće u nesigurnim kontekstima i može dovesti do zaobilaženja autorizacije kada se kolačići prosleđuju serverima na pozadini koji su podložni falsifikovanju.

Dodatne provere ranjivih kolačića

Osnovne provere

  • Kolačić je isti svaki put kada se prijavite.

  • Odjavite se i pokušajte da koristite isti kolačić.

  • Pokušajte da se prijavite sa 2 uređaja (ili pregledača) na isti nalog koristeći isti kolačić.

  • Proverite da li kolačić sadrži neke informacije i pokušajte da ih izmenite.

  • Pokušajte da kreirate nekoliko naloga sa gotovo istim korisničkim imenima i proverite da li možete primetiti sličnosti.

  • Proverite da li postoji opcija "zapamti me" da biste videli kako funkcioniše. Ako postoji i može biti ranjiva, uvek koristite kolačić od zapamti me bez bilo kog drugog kolačića.

  • Proverite da li prethodni kolačić radi čak i nakon što promenite lozinku.

Napadi naprednih kolačića

Ako kolačić ostaje isti (ili skoro isti) kada se prijavite, to verovatno znači da je kolačić povezan sa nekim poljem vašeg naloga (verovatno korisničkim imenom). Tada možete:

  • Pokušajte da kreirate mnogo naloga sa veoma sličnim korisničkim imenima i pokušajte da pogodite kako algoritam funkcioniše.

  • Pokušajte da bruteforce-ujete korisničko ime. Ako kolačić čuva samo kao metod autentifikacije za vaše korisničko ime, možete kreirati nalog sa korisničkim imenom "Bmin" i bruteforce-ovati svaki pojedinačni bit vašeg kolačića jer će jedan od kolačića koje ćete probati biti onaj koji pripada "admin".

  • Pokušajte Padding Oracle (možete dešifrovati sadržaj kolačića). Koristite padbuster.

Padding Oracle - Primeri Padbuster-a

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 će napraviti nekoliko pokušaja i pitati vas koja je uslovna greška (onaj koji nije validan).

Zatim će početi dešifrovanje kolačića (može potrajati nekoliko minuta).

Ako je napad uspešno izvršen, možete pokušati da šifrujete željeni niz. Na primer, ako biste želeli da šifrujete user=administrator

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

Ova izvršna datoteka će vam dati kolačić ispravno šifrovan i enkodiran sa stringom user=administrator unutar.

CBC-MAC

Možda bi kolačić mogao imati neku vrednost i biti potpisan korišćenjem CBC. Zatim, celovitost vrednosti je potpis kreiran korišćenjem CBC sa istom vrednošću. Kako se preporučuje korišćenje nultog vektora kao IV, ovaj tip provere celovitosti može biti ranjiv.

Napad

  1. Dobiti potpis korisničkog imena administ = t

  2. Dobiti potpis korisničkog imena rator\x00\x00\x00 XOR t = t'

  3. Postaviti u kolačić vrednost administrator+t' (t' će biti validan potpis za (rator\x00\x00\x00 XOR t) XOR t = rator\x00\x00\x00

ECB

Ako je kolačić šifrovan korišćenjem ECB, može biti ranjiv. Kada se prijavite, kolačić koji dobijete mora uvek biti isti.

Kako otkriti i napasti:

Kreirajte 2 korisnika sa skoro istim podacima (korisničko ime, lozinka, email, itd.) i pokušajte otkriti neki obrazac unutar datog kolačića

Kreirajte korisnika nazvanog na primer "aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa" i proverite da li postoji neki obrazac u kolačiću (kako ECB šifruje sa istim ključem svaki blok, isti šifrovani bajtovi mogu se pojaviti ako je korisničko ime šifrovano).

Treba da postoji obrazac (sa veličinom korišćenog bloka). Tako, znajući kako su grupa "a" šifrovani, možete kreirati korisničko ime: "a"*(veličina bloka)+"admin". Zatim, možete izbrisati šifrovani obrazac bloka "a" iz kolačića. I imaćete kolačić korisničkog imena "admin".

Reference

Try Hard Security Group

Naučite hakovanje AWS-a od nule do heroja sa htARTE (HackTricks AWS Red Team Expert)!

Drugi načini podrške HackTricks-u:

Last updated