Mirrors/hacktricks
2
0
Fork 0
mirror of https://github.com/carlospolop/hacktricks synced 2024-11-26 22:52:06 +00:00
Code Issues Projects Releases Packages Wiki Activity
hacktricks/pentesting-web/hacking-with-cookies
History
Translator 4ee977c4e5 Translated ['README.md', 'binary-exploitation/arbitrary-write-2-exec/REA
2024-04-07 05:33:57 +00:00
..
cookie-bomb.md Translated to Afrikaans 2024-02-11 02:07:06 +00:00
cookie-jar-overflow.md Translated to Afrikaans 2024-02-11 02:07:06 +00:00
cookie-tossing.md Translated ['pentesting-web/hacking-with-cookies/cookie-tossing.md'] to 2024-04-04 08:57:26 +00:00
README.md Translated ['README.md', 'binary-exploitation/arbitrary-write-2-exec/REA 2024-04-07 05:33:57 +00:00

README.md

Koekies Hack

Leer AWS-hacking van nul tot held met htARTE (HackTricks AWS Red Team Expert)!

Ander maniere om HackTricks te ondersteun:

Probeer Hard Security Group

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

Koekie Eienskappe

Koekies kom met verskeie eienskappe wat hul gedrag in die gebruiker se blaaier beheer. Hier is 'n oorsig van hierdie eienskappe in 'n meer passiewe stem:

Verval en Maksimum-Ouderdom

Die verval datum van 'n koekie word bepaal deur die Expires eienskap. Omgekeerd, definieer die Max-age eienskap die tyd in sekondes totdat 'n koekie verwyder word. Kies Max-age aangesien dit meer moderne praktyke weerspieël.

Domein

Die gasheer wat 'n koekie moet ontvang, word gespesifiseer deur die Domain eienskap. Standaard word dit ingestel op die gasheer wat die koekie uitgereik het, sonder sy subdomeine in te sluit. Wanneer die Domain eienskap egter eksplisiet ingestel word, sluit dit ook subdomeine in. Dit maak die spesifikasie van die Domain eienskap 'n minder beperkende opsie, nuttig vir scenario's waar koekiedeling oor subdomeine nodig is. Byvoorbeeld, deur Domain=mozilla.org in te stel, word koekies toeganklik op sy subdomeine soos developer.mozilla.org.

Pad

'n Spesifieke URL-pad wat teenwoordig moet wees in die versoekte URL vir die Cookie-kop om gestuur te word, word aangedui deur die Path eienskap. Hierdie eienskap beskou die / karakter as 'n gidsafskeider, wat ooreenkomste in subgidse moontlik maak.

Bestellingsreëls

Wanneer twee koekies dieselfde naam dra, word die een wat vir die stuur gekies word, gebaseer op:

  • Die koekie wat die langste pad in die versoekte URL ooreenstem.
  • Die mees onlangs ingestelde koekie as die paaie identies is.

SameSite

  • Die SameSite eienskap bepaal of koekies gestuur word met versoek vanaf derdeparty-domeine. Dit bied drie instellings:
  • Streng: Beperk die koekie vanaf die stuur vanaf derdeparty-versoeke.
  • Laks: Laat die koekie toe om gestuur te word met GET-versoeke wat deur derdeparty-webwerwe geïnisieer is.
  • Geen: Laat die koekie toe om vanaf enige derdeparty-domein gestuur te word.

Onthou, terwyl jy koekies konfigureer, kan begrip van hierdie eienskappe help om te verseker dat hulle soos verwag optree oor verskillende scenario's.

Versoek Tipe Voorbeeld Kode Koekies Gestuur Wanneer
Skakel <a href="..."></a> NotSet*, Laks, Geen
Voorlaai <link rel="prerender" href=".."/> NotSet*, Laks, Geen
Vorm KRY <form method="GET" action="..."> NotSet*, Laks, Geen
Vorm POS <form method="POST" action="..."> NotSet*, Geen
iframe <iframe src="..."></iframe> NotSet*, Geen
AJAX $.get("...") NotSet*, Geen
Beeld <img src="..."> NetSet*, Geen

Tabel van Invicti en effens gewysig.
'n Koekie met SameSite eienskap sal CSRF-aanvalle versag waar 'n ingeteken sessie benodig word.

*Let op dat vanaf Chrome80 (feb/2019) die verstekgedrag van 'n koekie sonder 'n koekie samesite eienskap laks sal wees (https://www.troyhunt.com/promiscuous-cookies-and-their-impending-death-via-the-samesite-policy/).
Let daarop dat tydelik, na die toepassing van hierdie verandering, die koekies sonder 'n SameSite beleid in Chrome as Geen gedurende die eerste 2 minute en dan as Laks vir topvlak kruis-webwerf POS-versoek behandel sal word.

Koekies Vlae

HttpOnly

Dit voorkom dat die klient die koekie kan benader (Byvoorbeeld via Javascript soos: document.cookie)

Omgang

  • As die bladsy die koekies stuur as die respons van 'n versoek (byvoorbeeld in 'n PHPinfo-bladsy), is dit moontlik om die XSS te misbruik om 'n versoek na hierdie bladsy te stuur en die koekies van die respons te steel (kyk na 'n voorbeeld in https://hackcommander.github.io/posts/2022/11/12/bypass-httponly-via-php-info-page/.
  • Dit kan omseil word met TRACE HTTP-versoeke aangesien die respons van die bediener (indien hierdie HTTP-metode beskikbaar is) die gestuurde koekies sal weerspieël. Hierdie tegniek word Cross-Site Tracking genoem.
  • Hierdie tegniek word vermy deur moderne blaaier deur nie toe te laat dat 'n TRACE versoek vanaf JS gestuur word nie. Tog is daar in sekere sagteware soos die stuur van \r\nTRACE in plaas van TRACE na IE6.0 SP2, omseilings hiervan gevind.
  • 'n Ander manier is die uitbuiting van zero/day kwesbaarhede van die blaaier.
  • Dit is moontlik om HttpOnly-koekies te oorskryf deur 'n Koekiepot-oorvloeiingsaanval uit te voer:

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

  • Dit is moontlik om Koekie Smuggling aanval te gebruik om hierdie koekies te eksfiltreer

Veilig

Die versoek sal die koekie slegs stuur in 'n HTTP-versoek as die versoek oorgedra word oor 'n veilige kanaal (tipies HTTPS).

Koekies Voorvoegsels

Koekies met die voorvoegsel __Secure- moet saam met die secure vlag ingestel word vanaf bladsye wat beveilig is deur HTTPS.

Vir koekies met die voorvoegsel __Host- moet aan verskeie voorwaardes voldoen word:

  • Hulle moet met die secure vlag ingestel word.
  • Hulle moet afkomstig wees van 'n bladsy wat beveilig is deur HTTPS.
  • Dit is verbode om 'n domein te spesifiseer vir hierdie koekies, wat voorkom dat hulle na subdomeine gestuur word.
  • Die pad vir hierdie koekies moet op / ingestel word.

Dit is belangrik om te let dat koekies met die voorvoegsel __Host- nie toegelaat word om na superdomeine of subdomeine gestuur te word nie. Hierdie beperking help om aansoekkoekies te isoleer. Gevolglik kan die gebruik van die __Host- voorvoegsel vir alle aansoekkoekies beskou word as 'n goeie praktyk om sekuriteit en isolasie te verbeter.

Oorskrywing van koekies

Dus, een van die beskermingsmaatreëls vir __Host- voorafgegaan koekies is om te voorkom dat hulle vanaf subdomeine oorgeskryf word. Dit voorkom byvoorbeeld Koekie Tossing-aanvalle. In die gesprek Koekie Verbrokkel: Ontsluiering van Web-sessie Integriteitskwesbaarhede (artikel) is dit voorgestel dat dit moontlik was om __HOST- voorafgegaan koekies vanaf subdomeine in te stel, deur die parser te mislei, byvoorbeeld, deur "=" aan die begin of aan die begin en die einde by te voeg...:

Of in PHP was dit moontlik om ander karakters aan die begin van die koekienaam by te voeg wat deur onderstreepkarakters vervang sou word, wat dit moontlik maak om __HOST- koekies te oorskryf:

Koekie Aanvalle

Indien 'n aangepaste koekie sensitiewe data bevat, ondersoek dit (veral as jy 'n CTF speel), aangesien dit kwesbaar kan wees.

Dekodering en Manipulasie van Koekies

Sensitiewe data wat in koekies ingebed is, moet altyd nagegaan word. Koekies wat in Base64 of soortgelyke formate gekodeer is, kan dikwels gedekodeer word. Hierdie kwesbaarheid stel aanvallers in staat om die inhoud van die koekie te verander en ander gebruikers te impersoneer deur hul gewysigde data terug in die koekie te kodeer.

Sessie Kaping

Hierdie aanval behels die steel van 'n gebruiker se koekie om ongemagtigde toegang tot hul rekening binne 'n toepassing te verkry. Deur die gesteelde koekie te gebruik, kan 'n aanvaller die regmatige gebruiker impersoneer.

Sessie Vastehegting

In hierdie scenario mislei 'n aanvaller 'n slagoffer om 'n spesifieke koekie te gebruik om in te teken. As die toepassing nie 'n nuwe koekie toeken met inteken nie, kan die aanvaller, wat die oorspronklike koekie besit, die slagoffer impersoneer. Hierdie tegniek steun op die slagoffer wat inteken met 'n koekie wat deur die aanvaller voorsien is.

As jy 'n XSS in 'n subdomein gevind het of jy beheer 'n subdomein, lees:

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

Sessie Skenking

Hier oortuig die aanvaller die slagoffer om die aanvaller se sessiekoekie te gebruik. Die slagoffer, wat glo dat hulle in hul eie rekening ingeteken is, sal onbedoeld optrede in die konteks van die aanvaller se rekening uitvoer.

As jy 'n XSS in 'n subdomein gevind het of jy beheer 'n subdomein, lees:

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

JWT Koekies

Klik op die vorige skakel om 'n bladsy te besoek wat moontlike foute in JWT verduidelik.

JSON Web Tokens (JWT) wat in koekies gebruik word, kan ook kwesbaarhede vertoon. Vir in-diepte inligting oor potensiële foute en hoe om dit te benut, word dit aanbeveel om die gekoppelde dokument oor die hak van JWT te raadpleeg.

Kruiswebversoekvervalsing (CSRF)

Hierdie aanval dwing 'n ingetekende gebruiker om ongewenste optrede op 'n webtoepassing uit te voer waarin hulle tans geïdentifiseer is. Aanvallers kan koekies wat outomaties met elke versoek na die kwesbare webwerf gestuur word, benut.

Leë Koekies

(Kyk na verdere besonderhede in die oorspronklike navorsing) Webblaaie laat die skepping van koekies sonder 'n naam toe, wat deur JavaScript gedemonstreer kan word as volg:

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

Die resultaat in die gestuurde koekie-kop is a=v1; toetswaarde; b=v2;. Interessant genoeg maak dit die manipulasie van koekies moontlik as 'n leë naam koekie ingestel word, moontlik om ander koekies te beheer deur die leë koekie na 'n spesifieke waarde te stel:

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

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

Dit lei daartoe dat die blaaier 'n koekie-heer stuur wat deur elke webbediener geïnterpreteer word as 'n koekie met die naam a met 'n waarde b.

Chrome-fout: Unicode Surrogaatkodepuntprobleem

In Chrome, as 'n Unicode-surrogaatkodepunt deel is van 'n stel koekie, word document.cookie beskadig, en gee dit daarna 'n leë string terug:

document.cookie = "\ud800=meep";

Dit lei daartoe dat document.cookie 'n leë string uitvoer, wat dui op permanente korruptie.

Koekie Smokkeling as Gevolg van Parsingsprobleme

(Kyk vir verdere besonderhede in die oorspronklike navorsing) Verskeie webbedieners, insluitend dié van Java (Jetty, TomCat, Undertow) en Python (Zope, cherrypy, web.py, aiohttp, bottle, webob), hanteer koekiestrengs verkeerd as gevolg van verouderde RFC2965-ondersteuning. Hulle lees 'n dubbelgekwoteerde koekiewaarde as 'n enkele waarde selfs al sluit dit puntkommas in, wat normaalweg sleutel-waardepare sou moes skei:

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

Koekie-inspuitingskwesbaarhede

(Kyk vir verdere besonderhede in dieoorspronklike navorsing) Die verkeerde ontleding van koekies deur bedieners, veral Undertow, Zope, en diegene wat Python se http.cookie.SimpleCookie en http.cookie.BaseCookie gebruik, skep geleenthede vir koekie-inspuitingsaanvalle. Hierdie bedieners slaag nie daarin om die begin van nuwe koekies behoorlik af te baken nie, wat aanvallers in staat stel om koekies te vervals:

  • Undertow verwag 'n nuwe koekie onmiddellik na 'n aangehaalde waarde sonder 'n puntkomma.
  • Zope soek na 'n komma om die volgende koekie te begin ontleding.
  • Python se koekieklasses begin ontleding op 'n spasie karakter.

Hierdie kwesbaarheid is veral gevaarlik in webtoepassings wat staatmaak op koekie-gebaseerde CSRF-beskerming, aangesien dit aanvallers in staat stel om vervalste CSRF-token-koekies in te spuit, wat moontlik sekuriteitsmaatreëls kan omseil. Die probleem word vererger deur Python se hantering van duplikaat koekienames, waar die laaste voorkoms vroeëre een oorskry. Dit wek ook kommer oor __Secure- en __Host- koekies in onveilige kontekste en kan lei tot outorisasie-omleidings wanneer koekies aan agterste bedieners oorgedra word wat vatbaar is vir vervalsing.

Ekstra Kwesbare Koekie Kontroles

Basiese kontroles

  • Die koekie is elke keer dieselfde wanneer jy aanmeld.
  • Meld af en probeer dieselfde koekie gebruik.
  • Probeer om met 2 toestelle (of blaaier) na dieselfde rekening aan te meld met dieselfde koekie.
  • Kontroleer of die koekie enige inligting bevat en probeer om dit te wysig.
  • Probeer om verskeie rekeninge met bykans dieselfde gebruikersnaam te skep en kyk of jy ooreenkomste kan sien.
  • Kontroleer of die "onthou my" opsie bestaan om te sien hoe dit werk. As dit bestaan en kwesbaar kan wees, gebruik altyd die koekie van onthou my sonder enige ander koekie.
  • Kontroleer of die vorige koekie selfs werk nadat jy die wagwoord verander het.

Gevorderde koekie-aanvalle

As die koekie dieselfde bly (of byna) wanneer jy aanmeld, beteken dit waarskynlik dat die koekie verband hou met 'n veld van jou rekening (waarskynlik die gebruikersnaam). Dan kan jy:

  • Probeer om baie rekeninge met baie soortgelyke gebruikersname te skep en probeer om te raai hoe die algoritme werk.
  • Probeer om die gebruikersnaam te bruteforce. As die koekie slegs as 'n verifikasiemetode vir jou gebruikersnaam stoor, kan jy 'n rekening met die gebruikersnaam "Bmin" skep en elke enkele bit van jou koekie bruteforce omdat een van die koekies wat jy sal probeer, die een behoort aan "admin".
  • Probeer Padding Oracle (jy kan die inhoud van die koekie ontsluit). Gebruik padbuster.

Padding Oracle - Padbuster voorbeelde

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 sal verskeie pogings doen en sal jou vra watter toestand die fouttoestand is (die een wat nie geldig is nie).

Dan sal dit begin om die koekie te dekodeer (dit kan verskeie minute neem)

As die aanval suksesvol uitgevoer is, kan jy probeer om 'n string van jou keuse te enkripteer. Byvoorbeeld, as jy sou wil enkripteer gebruiker=administrateur

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

Hierdie uitvoering sal jou die koekie korrek versleutel en enkodeer met die string user=administrator binne-in.

CBC-MAC

Dalk kan 'n koekie 'n waarde hê en onderteken word met CBC. Dan is die integriteit van die waarde die handtekening wat geskep word deur CBC te gebruik met dieselfde waarde. Aangesien dit aanbeveel word om 'n nul vektor as IV te gebruik, kan hierdie tipe integriteitskontrole kwesbaar wees.

Die aanval

  1. Kry die handtekening van gebruikersnaam administ = t
  2. Kry die handtekening van gebruikersnaam rator\x00\x00\x00 XOR t = t'
  3. Stel in die koekie die waarde administrator+t' (t' sal 'n geldige handtekening wees van (rator\x00\x00\x00 XOR t) XOR t = rator\x00\x00\x00

ECB

As die koekie versleutel word met ECB kan dit kwesbaar wees.
Wanneer jy inlog, moet die koekie wat jy ontvang altyd dieselfde wees.

Hoe om te ontdek en aan te val:

Skep 2 gebruikers met byna dieselfde data (gebruikersnaam, wagwoord, e-pos, ens.) en probeer om 'n patroon binne-in die gegee koekie te ontdek

Skep 'n gebruiker genaamd byvoorbeeld "aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa" en kyk of daar enige patroon in die koekie is (aangesien ECB met dieselfde sleutel elke blok versleutel, kan dieselfde versleutelde bytes voorkom as die gebruikersnaam versleutel word).

Daar behoort 'n patroon te wees (met die grootte van 'n gebruikte blok). Dus, deur te weet hoe 'n klomp "a" versleutel is, kan jy 'n gebruikersnaam skep: "a"*(grootte van die blok)+"admin". Dan kan jy die versleutelde patroon van 'n blok "a" uit die koekie verwyder. En jy sal die koekie van die gebruikersnaam "admin" hê.

Verwysings

Try Hard Security Group

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

Leer AWS hak van nul tot held met htARTE (HackTricks AWS Red Team Expert)!

Ander maniere om HackTricks te ondersteun: