hacktricks/pentesting-web/hacking-with-cookies
2024-03-24 13:29:10 +00:00
..
cookie-bomb.md Translated to Serbian 2024-02-10 13:11:20 +00:00
cookie-jar-overflow.md Translated to Serbian 2024-02-10 13:11:20 +00:00
cookie-tossing.md Translated ['README.md', 'backdoors/salseo.md', 'cryptography/certificat 2024-03-17 16:33:13 +00:00
README.md Translated ['forensics/basic-forensic-methodology/partitions-file-system 2024-03-24 13:29:10 +00:00

Hakovanje kolačića

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

Drugi načini podrške HackTricks-u:

Try Hard Security Group

{% embed url="https://discord.gg/tryhardsecurity" %}


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 Ističe. Nasuprot tome, 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 Domen. Podrazumevano, ovo je postavljeno na domaćina koji je izdao kolačić, ne uključujući njegove poddomene. Međutim, kada je atribut Domen eksplicitno postavljen, obuhvata i poddomene. Ovo čini specifikaciju atributa Domen manje restriktivnom opcijom, korisnom za scenarije gde je deljenje kolačića preko poddomena neophodno. Na primer, postavljanje Domen=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 Kolačić označena je atributom Putanja. Ovaj atribut razmatra karakter / kao separator direktorijuma, omogućavajući podudaranja u poddirektorijumima takođe.

Pravila naručivanja

Kada dva kolačića nose isto ime, onaj koji se bira za slanje zavisi od:

  • 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 prvih 2 minuta, a zatim kao Lax za POST zahteve preko glavnog nivoa preko sajta.

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đenja 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:

{% content-ref url="cookie-jar-overflow.md" %} cookie-jar-overflow.md {% endcontent-ref %}

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 za ove kolačiće, 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 poboljšanje 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 napada bacanja kolačića. U predavanju Cookie Crumbles: Otkrivanje ranjivosti integriteta sesije na vebu (rad) prikazano je da je bilo moguće postaviti __HOST- prefiksne kolačiće sa poddomena, prevareći parser, na primer, dodavanjem "=" na početku ili na početku i na kraju...:

Ili u PHP-u bilo je moguće dodati druge znakove na početku imena kolačića koji će biti zamenjeni donjom crtom znakovima, 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 se kao drugi korisnici kodiranje njihovih izmenjenih podataka 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č, koji poseduje 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 obezbedio napadač.

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

{% content-ref url="cookie-tossing.md" %} cookie-tossing.md {% endcontent-ref %}

Donacija Sesije

Ovde, napadač ubedi žrtvu da koristi sesijski kolačić napadača. Žrtva, verujući da je prijavljena na svoj nalog, nenamerno će izvršiti radnje u kontekstu naloga napadača.

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

{% content-ref url="cookie-tossing.md" %} cookie-tossing.md {% endcontent-ref %}

JWT Kolačići

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 pristup 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) Preglednici 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 je to što ovo omogućava manipulaciju kolačićima ako se postavi 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

Ovo dovodi do toga da pregledač šalje zaglavlje kolačića koje svaki veb server tumači kao kolačić pod imenom a sa vrednošću b.

Chrome Bag: Pitanje sa kodnom tačkom 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 rukuju sa kukija stringovima zbog zastarele podrške za RFC2965. Oni čitaju kukija vrednost 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čke-zareza.
  • Zope traži zarez da bi počeo 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 koristiti isti kolačić.
  • Pokušajte se prijaviti 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 ih izmeniti.
  • Pokušajte kreirati 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 kreirati mnogo naloga sa veoma sličnim korisničkim imenima i pokušajte pogoditi kako algoritam funkcioniše.
  • Pokušajte bruteforce 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 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 niz po vašem izboru. 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 uvek mora biti isti.

Kako otkriti i napasti:

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

Napravite 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 šifrovan obrazac bloka "a" iz kolačića. I imaćete kolačić korisničkog imena "admin".

Reference

Try Hard Security Group

{% embed url="https://discord.gg/tryhardsecurity" %}

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

Drugi načini podrške HackTricks-u: