Cookies Hacking

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

Ander maniere om HackTricks te ondersteun:

Probeer Hard Security Group


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 vir Max-age aangesien dit meer moderne praktyke weerspieël.

Domein

Die gasheer wat 'n koekie moet ontvang, word deur die Domain eienskap gespesifiseer. Standaard word dit ingestel op die gasheer wat die koekie uitgereik het, sonder sy subdomeine. 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 is, 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*, Lax, None

Voorlaai

<link rel="prerender" href=".."/>

NotSet*, Lax, None

Vorm KRY

<form method="GET" action="...">

NotSet*, Lax, None

Vorm POS

<form method="POST" action="...">

NotSet*, None

iframe

<iframe src="..."></iframe>

NotSet*, None

AJAX

$.get("...")

NotSet*, None

Beeld

<img src="...">

NetSet*, None

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

*Let daarop 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 sal behandel word as Geen gedurende die eerste 2 minute en dan as Laks vir top-vlak kruis-webwerf POS-versoek.

Koekies Vlae

HttpOnly

Dit verhoed dat die kliënt die koekie kan benader (Via Javascript byvoorbeeld: 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 versoek as 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 die stuur van 'n TRACE versoek vanaf JS toe te laat nie. Tog is daar in sekere sagteware omseilings hiervoor gevind, soos die stuur van \r\nTRACE in plaas van TRACE na IE6.0 SP2.

  • 'n Ander manier is die uitbuiting van nul/dag kwesbaarhede van die blaaier.

  • Dit is moontlik om HttpOnly-koekies te oorskryf deur 'n Koekiepot-oorvloeiingsaanval uit te voer:

pageCookie Jar Overflow
  • 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 van __Host- voorafgegaan koekies is om te voorkom dat hulle vanaf subdomeine oorgeskryf word. Dit voorkom byvoorbeeld Koekie Tossing-aanvalle. In die aanbieding Koekie Kruimels: Ontsluiering van Web-sessie Integriteit Kwesbaarhede (artikel) is dit voorgestel dat dit moontlik was om __HOST- voorafgegaan koekies vanaf subdomein in te stel, deur die parser te mislei, byvoorbeeld, deur "=" by 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

As 'n aangepaste koekie sensitiewe data bevat, moet dit nagegaan word (veral as jy 'n CTF speel), aangesien dit kwesbaar kan wees.

Dekodeer en Manipuleer Koekies

Sensitiewe data wat in koekies ingebed is, moet altyd deeglik ondersoek word. Koekies wat in Base64 of soortgelyke formate gekodeer is, kan dikwels gedekodeer word. Hierdie kwesbaarheid maak dit vir aanvallers moontlik 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 Vaste

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

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

pageCookie Tossing

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:

pageCookie Tossing

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 aksies 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) Webblaaier 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

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";

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

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 oorskryf. Dit wek ook kommer oor __Secure- en __Host- koekies in onveilige kontekste en kan lei tot outorisasie-omleidings wanneer koekies aan agter-eindbedieners 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.

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

  • Kyk na die "onthou my" opsie as dit 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.

  • Kyk 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 uitvind hoe die algoritme werk.

  • Probeer om die gebruikersnaam met bruteforce te raai. As die koekie slegs jou gebruikersnaam as 'n verifikasiemetode stoor, kan jy 'n rekening skep met die gebruikersnaam "Bmin" en elke enkele bit van jou koekie bruteforce omdat een van die koekies wat jy sal probeer, die een sal wees wat aan "admin" behoort.

  • 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 onderneem 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 user=administrator sou wil enkripteer.

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 geskep 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 bykans 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

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

Ander maniere om HackTricks te ondersteun:

Last updated