Cookies Hacking
Last updated
Last updated
Learn & practice AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE) Learn & practice GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
Cookies mają kilka atrybutów, które kontrolują ich zachowanie w przeglądarce użytkownika. Oto przegląd tych atrybutów w bardziej pasywnej formie:
Data wygaśnięcia ciasteczka jest określona przez atrybut Expires. Z kolei atrybut Max-age definiuje czas w sekundach, po którym ciasteczko zostanie usunięte. Wybierz Max-age, ponieważ odzwierciedla to nowocześniejsze praktyki.
Hosty, które mają otrzymać ciasteczko, są określone przez atrybut Domain. Domyślnie jest to ustawione na hosta, który wydał ciasteczko, nie obejmując jego subdomen. Jednak gdy atrybut Domain jest wyraźnie ustawiony, obejmuje również subdomeny. To sprawia, że specyfikacja atrybutu Domain jest mniej restrykcyjną opcją, przydatną w scenariuszach, gdzie konieczne jest udostępnianie ciasteczek między subdomenami. Na przykład, ustawienie Domain=mozilla.org sprawia, że ciasteczka są dostępne na jego subdomenach, takich jak developer.mozilla.org.
Specyficzna ścieżka URL, która musi być obecna w żądanym URL, aby nagłówek Cookie mógł być wysłany, jest wskazana przez atrybut Path. Atrybut ten traktuje znak / jako separator katalogów, co pozwala na dopasowania w podkatalogach.
Gdy dwa ciasteczka mają tę samą nazwę, to, które zostanie wybrane do wysłania, opiera się na:
Ciasteczku pasującym do najdłuższej ścieżki w żądanym URL.
Najnowszym ustawionym ciasteczku, jeśli ścieżki są identyczne.
Atrybut SameSite określa, czy ciasteczka są wysyłane w żądaniach pochodzących z domen trzecich. Oferuje trzy ustawienia:
Strict: Ogranicza wysyłanie ciasteczka w żądaniach z domen trzecich.
Lax: Pozwala na wysyłanie ciasteczka z żądaniami GET inicjowanymi przez strony trzecie.
None: Zezwala na wysyłanie ciasteczka z dowolnej domeny trzeciej.
Pamiętaj, że podczas konfigurowania ciasteczek zrozumienie tych atrybutów może pomóc zapewnić, że będą one działać zgodnie z oczekiwaniami w różnych scenariuszach.
Request Type
Example Code
Cookies Sent When
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
Image
<img src="...">
NetSet*, None
Tabela z Invicti i nieco zmodyfikowana. Ciasteczko z atrybutem SameSite łagodzi ataki CSRF, gdzie potrzebna jest zalogowana sesja.
*Zauważ, że od Chrome80 (lut/2019) domyślne zachowanie ciasteczka bez atrybutu cookie samesite będzie lax (https://www.troyhunt.com/promiscuous-cookies-and-their-impending-death-via-the-samesite-policy/). Zauważ, że tymczasowo, po zastosowaniu tej zmiany, ciasteczka bez polityki SameSite w Chrome będą traktowane jako None przez pierwsze 2 minuty, a następnie jako Lax dla głównych żądań POST między witrynami.
To uniemożliwia klientowi dostęp do ciasteczka (np. za pomocą Javascript: document.cookie)
Jeśli strona wysyła ciasteczka jako odpowiedź na żądania (na przykład na stronie PHPinfo), można wykorzystać XSS, aby wysłać żądanie do tej strony i ukraść ciasteczka z odpowiedzi (sprawdź przykład w https://hackcommander.github.io/posts/2022/11/12/bypass-httponly-via-php-info-page/.
Można to obejść za pomocą TRACE HTTP żądań, ponieważ odpowiedź z serwera (jeśli ta metoda HTTP jest dostępna) odzwierciedli wysłane ciasteczka. Ta technika nazywa się Cross-Site Tracking.
Ta technika jest unika przez nowoczesne przeglądarki, które nie pozwalają na wysyłanie żądania TRACE z JS. Jednak niektóre obejścia tego zostały znalezione w konkretnym oprogramowaniu, na przykład wysyłając \r\nTRACE zamiast TRACE do IE6.0 SP2.
Innym sposobem jest wykorzystanie luk zero-day w przeglądarkach.
Możliwe jest nadpisanie ciasteczek HttpOnly poprzez przeprowadzenie ataku Cookie Jar overflow:
Możliwe jest użycie ataku Cookie Smuggling do eksfiltracji tych ciasteczek.
Żądanie wyśle ciasteczko tylko w żądaniu HTTP, jeśli żądanie jest przesyłane przez bezpieczny kanał (zazwyczaj HTTPS).
Ciasteczka z prefiksem __Secure- muszą być ustawione wraz z flagą secure z stron, które są zabezpieczone przez HTTPS.
Dla ciasteczek z prefiksem __Host- musi być spełnionych kilka warunków:
Muszą być ustawione z flagą secure.
Muszą pochodzić z strony zabezpieczonej przez HTTPS.
Zabrania się określania domeny, co uniemożliwia ich przesyłanie do subdomen.
Ścieżka dla tych ciasteczek musi być ustawiona na /.
Ważne jest, aby zauważyć, że ciasteczka z prefiksem __Host- nie mogą być wysyłane do superdomen ani subdomen. To ograniczenie pomaga w izolacji ciasteczek aplikacji. Dlatego stosowanie prefiksu __Host- dla wszystkich ciasteczek aplikacji można uznać za dobrą praktykę w celu zwiększenia bezpieczeństwa i izolacji.
Jednym z zabezpieczeń ciasteczek z prefiksem __Host- jest zapobieganie ich nadpisywaniu z subdomen. Zapobiega to na przykład atakom Cookie Tossing. W wykładzie Cookie Crumbles: Unveiling Web Session Integrity Vulnerabilities (artykuł) przedstawiono, że możliwe było ustawienie ciasteczek z prefiksem __HOST- z subdomen, oszukując parsera, na przykład dodając "=" na początku lub na końcu...:
Lub w PHP możliwe było dodanie innych znaków na początku nazwy ciasteczka, które miały być zastąpione znakami podkreślenia, co pozwalało na nadpisanie ciasteczek __HOST-:
Jeśli niestandardowe ciasteczko zawiera wrażliwe dane, sprawdź je (szczególnie jeśli bierzesz udział w CTF), ponieważ może być podatne.
Wrażliwe dane osadzone w ciasteczkach powinny być zawsze dokładnie sprawdzane. Ciasteczka zakodowane w Base64 lub podobnych formatach można często dekodować. Ta luka pozwala atakującym na modyfikację zawartości ciasteczka i podszywanie się pod innych użytkowników, kodując ich zmodyfikowane dane z powrotem do ciasteczka.
Ten atak polega na kradzieży ciasteczka użytkownika, aby uzyskać nieautoryzowany dostęp do jego konta w aplikacji. Używając skradzionego ciasteczka, atakujący może podszyć się pod prawowitego użytkownika.
W tym scenariuszu atakujący oszukuje ofiarę, aby użyła konkretnego ciasteczka do logowania. Jeśli aplikacja nie przypisuje nowego ciasteczka po logowaniu, atakujący, posiadający oryginalne ciasteczko, może podszyć się pod ofiarę. Ta technika polega na tym, że ofiara loguje się za pomocą ciasteczka dostarczonego przez atakującego.
Jeśli znalazłeś XSS w subdomenie lub kontrolujesz subdomenę, przeczytaj:
Cookie TossingTutaj atakujący przekonuje ofiarę do użycia ciasteczka sesji atakującego. Ofiara, wierząc, że jest zalogowana na swoje konto, nieświadomie wykonuje działania w kontekście konta atakującego.
Jeśli znalazłeś XSS w subdomenie lub kontrolujesz subdomenę, przeczytaj:
Cookie TossingKliknij na poprzedni link, aby uzyskać dostęp do strony wyjaśniającej możliwe luki w JWT.
JSON Web Tokens (JWT) używane w ciasteczkach mogą również przedstawiać luki. Aby uzyskać szczegółowe informacje na temat potencjalnych luk i sposobów ich wykorzystania, zaleca się dostęp do powiązanego dokumentu dotyczącego hackowania JWT.
Ten atak zmusza zalogowanego użytkownika do wykonywania niechcianych działań w aplikacji internetowej, w której jest aktualnie uwierzytelniony. Atakujący mogą wykorzystać ciasteczka, które są automatycznie wysyłane z każdym żądaniem do podatnej witryny.
(Sprawdź dalsze szczegóły w oryginalnych badaniach) Przeglądarki pozwalają na tworzenie ciasteczek bez nazwy, co można zademonstrować za pomocą JavaScript w następujący sposób:
Wynik w nagłówku cookie wysłanym to a=v1; test value; b=v2;. Interesujące jest to, że umożliwia to manipulację cookie, jeśli ustawione jest cookie o pustej nazwie, potencjalnie kontrolując inne cookie, ustawiając puste cookie na określoną wartość:
To prowadzi do tego, że przeglądarka wysyła nagłówek cookie interpretowany przez każdy serwer WWW jako cookie o nazwie a z wartością b.
W Chrome, jeśli kod zastępczy Unicode jest częścią ustawionego cookie, document.cookie staje się uszkodzone, zwracając pusty ciąg w następstwie:
To skutkuje tym, że document.cookie zwraca pusty ciąg, co wskazuje na trwałe uszkodzenie.
(Zobacz dalsze szczegóły w oryginalnych badaniach) Kilka serwerów internetowych, w tym te z Javy (Jetty, TomCat, Undertow) i Pythona (Zope, cherrypy, web.py, aiohttp, bottle, webob), niewłaściwie obsługuje ciągi ciasteczek z powodu przestarzałego wsparcia dla RFC2965. Odczytują podwójnie cytowaną wartość ciasteczka jako jedną wartość, nawet jeśli zawiera średniki, które normalnie powinny oddzielać pary klucz-wartość:
(Check further details in theoriginal research) Nieprawidłowe analizowanie ciasteczek przez serwery, szczególnie Undertow, Zope oraz te korzystające z http.cookie.SimpleCookie i http.cookie.BaseCookie w Pythonie, stwarza możliwości ataków typu cookie injection. Te serwery nieprawidłowo delimitują początek nowych ciasteczek, co pozwala atakującym na fałszowanie ciasteczek:
Undertow oczekuje nowego ciasteczka natychmiast po wartości w cudzysłowie bez średnika.
Zope szuka przecinka, aby rozpocząć analizowanie następnego ciasteczka.
Klasy ciasteczek Pythona zaczynają analizować od znaku spacji.
Ta podatność jest szczególnie niebezpieczna w aplikacjach internetowych opartych na ochronie CSRF opartej na ciasteczkach, ponieważ pozwala atakującym na wstrzykiwanie fałszywych ciasteczek z tokenami CSRF, co potencjalnie omija środki bezpieczeństwa. Problem jest zaostrzony przez obsługę duplikatów nazw ciasteczek w Pythonie, gdzie ostatnie wystąpienie nadpisuje wcześniejsze. Budzi to również obawy dotyczące ciasteczek __Secure- i __Host- w niebezpiecznych kontekstach i może prowadzić do obejść autoryzacji, gdy ciasteczka są przekazywane do serwerów zaplecza podatnych na fałszowanie.
Zgodnie z tym wpisem na blogu, możliwe jest użycie atrybutu ciasteczka $Version=1, aby backend używał starej logiki do analizy ciasteczka z powodu RFC2109. Ponadto inne wartości, takie jak $Domain i $Path, mogą być używane do modyfikacji zachowania backendu z ciasteczkiem.
Ta analiza wskazuje na usunięcie znaków ucieczki z wartości wewnątrz ciasteczek, więc "\a" staje się "a". Może to być przydatne do obejścia WAFS, ponieważ:
eval('test') => forbidden
"\e\v\a\l\(\'\t\e\s\t\'\)" => allowed
W RFC2109 wskazano, że przecinek może być używany jako separator między wartościami ciasteczek. Możliwe jest również dodanie spacji i tabulatorów przed i po znaku równości. Dlatego ciasteczko takie jak $Version=1; foo=bar, abc = qux nie generuje ciasteczka "foo":"bar, admin = qux", ale ciasteczka foo":"bar" i "admin":"qux". Zauważ, jak generowane są 2 ciasteczka i jak usunięto spację przed i po znaku równości.
Na koniec różne backdoory łączą w jeden ciąg różne ciasteczka przekazywane w różnych nagłówkach ciasteczek, jak w:
Co mogłoby pozwolić na ominięcie WAF, jak w tym przykładzie:
Ciasteczko jest takie samo za każdym razem, gdy się logujesz.
Wyloguj się i spróbuj użyć tego samego ciasteczka.
Spróbuj zalogować się z 2 urządzeń (lub przeglądarek) do tego samego konta, używając tego samego ciasteczka.
Sprawdź, czy ciasteczko zawiera jakiekolwiek informacje i spróbuj je zmodyfikować.
Spróbuj stworzyć kilka kont z prawie tymi samymi nazwami użytkowników i sprawdź, czy możesz dostrzec podobieństwa.
Sprawdź opcję "zapamiętaj mnie", jeśli istnieje, aby zobaczyć, jak działa. Jeśli istnieje i może być wrażliwa, zawsze używaj ciasteczka z zapamiętaj mnie bez żadnego innego ciasteczka.
Sprawdź, czy poprzednie ciasteczko działa nawet po zmianie hasła.
Jeśli ciasteczko pozostaje takie samo (lub prawie takie samo) podczas logowania, prawdopodobnie oznacza to, że ciasteczko jest związane z jakimś polem twojego konta (prawdopodobnie nazwą użytkownika). Wtedy możesz:
Spróbować stworzyć wiele kont z bardzo podobnymi nazwami użytkowników i spróbować zgadnąć, jak działa algorytm.
Spróbować bruteforce'ować nazwę użytkownika. Jeśli ciasteczko jest zapisywane tylko jako metoda uwierzytelniania dla twojej nazwy użytkownika, wtedy możesz stworzyć konto z nazwą użytkownika "Bmin" i bruteforce'ować każdy pojedynczy bit swojego ciasteczka, ponieważ jedno z ciasteczek, które spróbujesz, będzie należało do "admin".
Spróbuj Padding Oracle (możesz odszyfrować zawartość ciasteczka). Użyj padbuster.
Padding Oracle - Przykłady Padbuster
Padbuster pode podjąć kilka prób i zapytać, która z warunków jest warunkiem błędu (tym, który nie jest ważny).
Następnie rozpocznie deszyfrowanie ciasteczka (może to potrwać kilka minut).
Jeśli atak został pomyślnie przeprowadzony, możesz spróbować zaszyfrować ciąg według własnego wyboru. Na przykład, jeśli chcesz zaszyfrować user=administrator.
To wykonanie da ci ciasteczko poprawnie zaszyfrowane i zakodowane z ciągiem user=administrator wewnątrz.
CBC-MAC
Może ciasteczko mogłoby mieć jakąś wartość i mogłoby być podpisane przy użyciu CBC. Wtedy integralność wartości to podpis utworzony przy użyciu CBC z tą samą wartością. Ponieważ zaleca się użycie jako IV wektora zerowego, ten typ sprawdzania integralności może być podatny.
Atak
Uzyskaj podpis nazwy użytkownika administ = t
Uzyskaj podpis nazwy użytkownika rator\x00\x00\x00 XOR t = t'
Ustaw w ciasteczku wartość administrator+t' (t' będzie ważnym podpisem (rator\x00\x00\x00 XOR t) XOR t = rator\x00\x00\x00
ECB
Jeśli ciasteczko jest szyfrowane przy użyciu ECB, może być podatne. Kiedy logujesz się, ciasteczko, które otrzymujesz, musi być zawsze takie samo.
Jak wykryć i zaatakować:
Utwórz 2 użytkowników z prawie tymi samymi danymi (nazwa użytkownika, hasło, e-mail itp.) i spróbuj odkryć jakiś wzór wewnątrz danego ciasteczka.
Utwórz użytkownika o nazwie na przykład "aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa" i sprawdź, czy w ciasteczku jest jakiś wzór (ponieważ ECB szyfruje z tym samym kluczem każdy blok, te same zaszyfrowane bajty mogą się pojawić, jeśli nazwa użytkownika jest szyfrowana).
Powinien być wzór (o rozmiarze używanego bloku). Zatem, wiedząc, jak jest zaszyfrowana masa "a", możesz utworzyć nazwę użytkownika: "a"*(rozmiar bloku)+"admin". Następnie możesz usunąć zaszyfrowany wzór bloku "a" z ciasteczka. I będziesz miał ciasteczko dla nazwy użytkownika "admin".
Learn & practice AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE) Learn & practice GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
