Mirrors/hacktricks
2
0
Fork 0
mirror of https://github.com/carlospolop/hacktricks synced 2024-11-22 20:53:37 +00:00
Code Issues Projects Releases Packages Wiki Activity
hacktricks/pentesting-web/hacking-with-cookies
History
Translator 97f0308f3a Translated ['README.md', 'binary-exploitation/arbitrary-write-2-exec/REA
2024-04-07 04:23:52 +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 ['pentesting-web/hacking-with-cookies/cookie-tossing.md'] to 2024-04-04 08:57:49 +00:00
README.md Translated ['README.md', 'binary-exploitation/arbitrary-write-2-exec/REA 2024-04-07 04:23:52 +00:00

README.md

Hakovanje kolačića

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

{% 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 Expires. 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 Domain. Podrazumevano, postavljen je 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 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 određuje 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 lokacija.
  • 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 smanjiti 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 politiike u Chrome-u će biti tretirani kao None tokom prva 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, 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 njihovog 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, trikujuć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 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 se kao drugi korisnici enkodirajući svoje izmenjene 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č, 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) 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 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 tačke kôda zamene Unicode znakova

U Chrome-u, ako je zamenski kôd Unicode znaka 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 ispisuje 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 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 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 poč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 serverskim aplikacijama koje su podložne falsifikovanju.

Dodatne provere ranjivosti kolačića

Osnovne provere

  • Kolačić je uvek 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 ga 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" i kako funkcioniše. Ako postoji i može biti ranjiva, uvek koristite kolačić od zapamti me bez bilo kojeg 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 gotovo 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 vrlo 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 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 komanda će vam dati kolačić pravilno š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 (veličine 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

{% 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: