hacktricks

mirror of https://github.com/carlospolop/hacktricks synced 2025-02-17 06:28:27 +00:00

History

Translator workflow 5e0daf0e23 Translated to Polish		2024-02-11 01:46:25 +00:00
..
cookie-bomb.md	Translated to Polish	2024-02-11 01:46:25 +00:00
cookie-jar-overflow.md	Translated to Polish	2024-02-11 01:46:25 +00:00
cookie-tossing.md	Translated to Polish	2024-02-11 01:46:25 +00:00
README.md	Translated to Polish	2024-02-11 01:46:25 +00:00

README.md

Naucz się hakować AWS od zera do bohatera z htARTE (HackTricks AWS Red Team Expert)!

Inne sposoby wsparcia HackTricks:

Jeśli chcesz zobaczyć swoją firmę reklamowaną w HackTricks lub pobrać HackTricks w formacie PDF, sprawdź SUBSCRIPTION PLANS!
Zdobądź oficjalne gadżety PEASS & HackTricks
Odkryj Rodzinę PEASS, naszą kolekcję ekskluzywnych NFT
Dołącz do 💬 grupy Discord lub grupy telegramowej lub śledź nas na Twitterze 🐦 @carlospolopm.
Podziel się swoimi sztuczkami hakerskimi, przesyłając PR-y do HackTricks i HackTricks Cloud repozytoriów GitHub.

Znajdź najważniejsze podatności, aby móc je szybko naprawić. Intruder śledzi powierzchnię ataku, wykonuje proaktywne skanowanie zagrożeń, znajduje problemy w całym stosie technologicznym, od interfejsów API po aplikacje internetowe i systemy chmurowe. Wypróbuj go za darmo już dziś.

{% embed url="https://www.intruder.io/?utm_campaign=hacktricks&utm_source=referral" %}

Pliki cookie posiadają kilka atrybutów, które kontrolują ich zachowanie w przeglądarce użytkownika. Oto przegląd tych atrybutów w bardziej pasywnym tonie:

Wygaśnięcie i Max-Age

Data wygaśnięcia pliku cookie jest określana przez atrybut Expires. Natomiast atrybut Max-age definiuje czas w sekundach, po którym plik cookie zostanie usunięty. Wybierz Max-age, ponieważ odzwierciedla on nowoczesne praktyki.

Domena

Hosty, które otrzymują plik cookie, są określane przez atrybut Domain. Domyślnie jest on ustawiony na host, który wydał plik cookie, nie obejmując jego subdomen. Jednak gdy atrybut Domain jest jawnie ustawiony, obejmuje on również subdomeny. Sprawia to, że określenie atrybutu Domain jest mniej restrykcyjną opcją, przydatną w scenariuszach, gdzie konieczne jest udostępnianie plików cookie między subdomenami. Na przykład, ustawienie Domain=mozilla.org umożliwia dostęp do plików cookie na jego subdomenach, takich jak developer.mozilla.org.

Ścieżka

Określona ścieżka URL, która musi być obecna w żądanym URL, aby został wysłany nagłówek Cookie, jest wskazywana przez atrybut Path. Ten atrybut traktuje znak / jako separator katalogów, umożliwiając dopasowanie w podkatalogach.

Zasady kolejności

Gdy dwa pliki cookie mają tę samą nazwę, wybór pliku do wysłania jest oparty na:

Pliku cookie, który najlepiej pasuje do najdłuższej ścieżki w żądanym URL.
Najnowszym pliku cookie, jeśli ścieżki są identyczne.

SameSite

Atrybut SameSite określa, czy pliki cookie są wysyłane w żądaniach pochodzących z domen innych niż strona. Oferuje trzy ustawienia:
Strict: Ogranicza wysyłanie pliku cookie w żądaniach pochodzących z domen innych niż strona.
Lax: Pozwala na wysyłanie pliku cookie w żądaniach GET inicjowanych przez strony innych niż strona.
None: Pozwala na wysyłanie pliku cookie z dowolnej domeny innej niż strona.

Pamiętaj, że podczas konfigurowania plików cookie zrozumienie tych atrybutów może pomóc w zapewnieniu, że zachowują się one zgodnie z oczekiwaniami w różnych scenariuszach.

Rodzaj żądania	Przykładowy kod	Wysyłane pliki cookie, gdy
Link	<a href="..."></a>	NotSet*, Lax, None
Prerender	<link rel="prerender" href=".."/>	NotSet*, Lax, None
Formularz GET	<form method="GET" action="...">	NotSet*, Lax, None
Formularz POST	<form method="POST" action="...">	NotSet*, None
iframe	<iframe src="..."></iframe>	NotSet*, None
AJAX	$.get("...")	NotSet*, None
Obraz	<img src="...">	NetSet*, None

Tabela pochodzi z Invicti i została nieznacznie zmodyfikowana.
Plik cookie z atrybutem SameSite zmniejsza ryzyko ataków CSRF, w których wymagana jest zalogowana sesja.

*Zauważ, że od Chrome 80 (luty 2019) domyślne zachowanie pliku cookie bez atrybutu 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, pliki cookie bez polityki SameSite w Chrome będą traktowane jako None przez pierwsze 2 minuty, a następnie jako Lax dla żądań POST między stronami najwyższego poziomu.

HttpOnly

Uniemożliwia klientowi dostęp do pliku cookie (na przykład za pomocą JavaScriptu: document.cookie)

Omijanie

Jeśli strona wysyła pliki cookie jako odpowiedź na żądania (na przykład na stronie PHPinfo), możliwe jest wykorzystanie XSS do wysłania żądania do tej strony i ukradzenia plików cookie 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ą żądań HTTP TRACE, ponieważ odpowiedź serwera (jeśli ta metoda HTTP jest dostępna) odzwierciedli wysłane pliki cookie. Technika ta nazywa się śledzeniem międzywitrynowym.
Ta technika jest unikana przez nowoczesne przeglądarki, które nie pozwalają na wysyłanie żądania TRACE z poziomu JS. Jednak znaleziono pewne obejścia tego w określonym oprogramowaniu, takie jak wysyłanie \r\nTRACE zamiast TRACE do IE6.0 SP2.
Innym sposobem jest wykorzystanie podatności zero/day przeglądarek.
Możliwe jest nadpisanie plików cookie HttpOnly za pomocą ataku przepełnienia schowka plików cookie:

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

Możliwe jest wykorzystanie ataku Cookie Smuggling do wykradzenia tych plików cookie

Secure

Żądanie tylko wysyła plik cookie w żądaniu HTTP, jeśli

Pliki cookie z prefiksem __Secure- muszą być ustawione wraz z flagą secure na stronach zabezpieczonych protokołem HTTPS.

W przypadku plików cookie z prefiksem __Host-, muszą zostać spełnione następujące warunki:

Muszą być ustawione z flagą secure.
Muszą pochodzić ze strony zabezpieczonej protokołem HTTPS.
Nie mogą określać domeny, co uniemożliwia ich przesyłanie do subdomen.
Ścieżka dla tych plików cookie musi być ustawiona na /.

Warto zauważyć, że pliki cookie z prefiksem __Host- nie mogą być wysyłane do naddomen ani subdomen. Ograniczenie to pomaga w izolowaniu plików cookie aplikacji. Dlatego stosowanie prefiksu __Host- dla wszystkich plików cookie aplikacji można uznać za praktykę zwiększającą bezpieczeństwo i izolację.

Jeśli niestandardowe pliki cookie zawierają wrażliwe dane, należy je sprawdzić (szczególnie jeśli bierzesz udział w CTF), ponieważ mogą być podatne na ataki.

Wrażliwe dane osadzone w plikach cookie powinny zawsze być dokładnie sprawdzane. Pliki cookie zakodowane w formacie Base64 lub podobnych często mogą być odkodowane. Ta podatność pozwala atakującym zmieniać zawartość pliku cookie i podszywać się pod innych użytkowników, kodując zmodyfikowane dane z powrotem do pliku cookie.

Przechwycenie sesji

Ten atak polega na kradzieży pliku cookie użytkownika w celu nieautoryzowanego dostępu do jego konta w aplikacji. Za pomocą skradzionego pliku cookie atakujący może podszywać się pod prawdziwego użytkownika.

Ustalanie sesji

W tym scenariuszu atakujący oszukuje ofiarę, aby użyła określonego pliku cookie do zalogowania się. Jeśli aplikacja nie przypisuje nowego pliku cookie po zalogowaniu, atakujący, posiadając oryginalny plik cookie, może podszywać się pod ofiarę. Ta technika polega na zalogowaniu się ofiary za pomocą pliku cookie dostarczonego przez atakującego.

Jeśli znalazłeś XSS w subdomenie lub masz kontrolę nad subdomeną, przeczytaj:

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

Przekazanie sesji

W tym przypadku atakujący przekonuje ofiarę, aby użyła pliku cookie atakującego. Ofiara, wierząc, że jest zalogowana na swoje konto, nieświadomie wykonuje czynności w kontekście konta atakującego.

Jeśli znalazłeś XSS w subdomenie lub masz kontrolę nad subdomeną, przeczytaj:

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

Kliknij na powyższy link, aby uzyskać dostęp do strony wyjaśniającej możliwe luki w JWT.

Pliki cookie JSON Web Tokens (JWT) mogą również zawierać podatności. Aby uzyskać szczegółowe informacje na temat potencjalnych luk i sposobów ich wykorzystania, zaleca się zapoznanie się z powiązanym dokumentem dotyczącym hakowania JWT.

Cross-Site Request Forgery (CSRF)

Ten atak zmusza zalogowanego użytkownika do wykonania niechcianych działań w aplikacji internetowej, w której jest obecnie uwierzytelniony. Atakujący może wykorzystać pliki cookie, które są automatycznie wysyłane wraz z każdym żądaniem do podatnej strony.

(Sprawdź szczegóły w oryginalnym badaniu) Przeglądarki pozwalają na tworzenie plików cookie bez nazwy, co można zademonstrować za pomocą JavaScriptu, jak pokazano poniżej:

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

Wynik w nagłówku wysłanego ciasteczka to a=v1; test value; b=v2;. Co ciekawe, umożliwia to manipulację ciasteczkami, jeśli ustawione jest puste ciasteczko o nazwie, co potencjalnie pozwala kontrolować inne ciasteczka, ustawiając puste ciasteczko na określoną wartość:

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

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

To prowadzi do przeglądarki wysyłającej nagłówek cookie, który jest interpretowany przez każdy serwer WWW jako cookie o nazwie a o wartości b.

Błąd w Chrome: problem z kodem punktu kodowego Unicode Surrogate

W Chrome, jeśli punkt kodowy Unicode Surrogate jest częścią ustawionego ciasteczka, document.cookie zostaje uszkodzone, a następnie zwraca pusty ciąg znaków:

document.cookie = "\ud800=meep";

To prowadzi do tego, że document.cookie zwraca pusty ciąg znaków, co wskazuje na trwałe uszkodzenie.

Przemyt ciasteczek z powodu problemów z parsowaniem

(Sprawdź szczegóły w oryginalnym badaniu) Kilka serwerów internetowych, w tym te oparte na Java (Jetty, TomCat, Undertow) i Pythonie (Zope, cherrypy, web.py, aiohttp, bottle, webob), nieprawidłowo obsługuje ciągi ciasteczek ze względu na przestarzałe wsparcie dla RFC2965. Odczytują wartość ciasteczka w podwójnych cudzysłowach jako pojedynczą wartość, nawet jeśli zawiera średniki, które normalnie powinny oddzielać pary klucz-wartość:

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

Podatności związane z wstrzykiwaniem ciasteczek

(Szczegóły można znaleźć w oryginalnym badaniu) Nieprawidłowe parsowanie ciasteczek przez serwery, w szczególności Undertow, Zope i te korzystające z http.cookie.SimpleCookie i http.cookie.BaseCookie w Pythonie, tworzy możliwości ataków wstrzykiwania ciasteczek. Te serwery niepoprawnie ograniczają początek nowych ciasteczek, co pozwala atakującym podszywać się pod ciasteczka:

Undertow oczekuje nowego ciasteczka bezpośrednio po wartości w cudzysłowie, bez średnika.
Zope szuka przecinka, aby rozpocząć parsowanie kolejnego ciasteczka.
Klasy ciasteczek w Pythonie rozpoczynają parsowanie od znaku spacji.

Ta podatność jest szczególnie niebezpieczna w aplikacjach internetowych polegających na ochronie przed CSRF opartej na ciasteczkach, ponieważ pozwala atakującym wstrzykiwać podszyte ciasteczka z tokenem CSRF, co potencjalnie umożliwia obejście środków bezpieczeństwa. Problem jest pogłębiony przez obsługę przez Pythona zduplikowanych nazw ciasteczek, gdzie ostatnie wystąpienie zastępuje wcześniejsze. Powoduje to również obawy dotyczące ciasteczek __Secure- i __Host- w niebezpiecznych kontekstach oraz może prowadzić do obejścia autoryzacji, gdy ciasteczka są przekazywane do serwerów back-endowych podatnych na podszywanie się.

Dodatkowe sprawdzenia podatności ciasteczek

Podstawowe sprawdzenia

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ę na dwóch urządzeniach (lub przeglądarkach) na to samo konto, używając tego samego ciasteczka.
Sprawdź, czy ciasteczko zawiera jakieś informacje i spróbuj je zmodyfikować.
Spróbuj utworzyć kilka kont o prawie takiej samej nazwie użytkownika i sprawdź, czy można zauważyć podobieństwa.
Sprawdź, czy istnieje opcja "zapamiętaj mnie" i zobacz, jak działa. Jeśli istnieje i może być podatna, zawsze używaj tylko ciasteczka z opcją zapamiętaj mnie bez żadnych innych ciasteczek.
Sprawdź, czy poprzednie ciasteczko działa nawet po zmianie hasła.

Zaawansowane ataki na ciasteczka

Jeśli ciasteczko pozostaje takie samo (lub prawie takie samo) po zalogowaniu, prawdopodobnie oznacza to, że ciasteczko jest powiązane z pewnym polem twojego konta (prawdopodobnie z nazwą użytkownika). W takim przypadku można:

Spróbuj utworzyć wiele kont o bardzo podobnych nazwach użytkowników i spróbuj odgadnąć, jak działa algorytm.
Spróbuj brute force nazwy użytkownika. Jeśli ciasteczko zapisuje się tylko jako metoda uwierzytelniania dla twojej nazwy użytkownika, możesz utworzyć konto o nazwie "Bmin" i brute force każdy pojedynczy bit ciasteczka, ponieważ jedno z ciasteczek, które będziesz próbować, 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 <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 będzie podejmował kilka prób i zapyta cię, która z nich jest warunkiem błędu (ten, który nie jest prawidłowy).

Następnie rozpocznie deszyfrowanie ciasteczka (może to potrwać kilka minut).

Jeśli atak zakończył się sukcesem, możesz spróbować zaszyfrować wybrany ciąg znaków. Na przykład, jeśli chciałbyś zaszyfrować user=administrator

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

To wykonanie da ci poprawnie zaszyfrowane i zakodowane ciasteczko z ciągiem user=administrator w środku.

CBC-MAC

Może się zdarzyć, że ciasteczko ma jakąś wartość i jest podpisane za pomocą CBC. Wtedy integralność wartości jest podpisem utworzonym za pomocą CBC z tą samą wartością. Ponieważ zaleca się użycie wektora zerowego jako IV, ten rodzaj sprawdzania integralności może być podatny na atak.

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 zaszyfrowane za pomocą ECB, może być podatne na atak.
Po zalogowaniu otrzymywane ciasteczko musi być zawsze takie samo.

Jak wykryć i zaatakować:

Utwórz 2 użytkowników o prawie takich samych danych (nazwa użytkownika, hasło, e-mail itp.) i spróbuj odkryć pewien wzór w danym ciasteczku.

Utwórz użytkownika o nazwie na przykład "aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa" i sprawdź, czy w ciasteczku występuje jakiś wzór (ponieważ ECB szyfruje każdy blok tym samym kluczem, te same zaszyfrowane bajty mogą się pojawić, jeśli nazwa użytkownika jest zaszyfrowana).

Powinien być wzór (o rozmiarze używanego bloku). Więc, znając zaszyfrowane "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".

Referencje

Znajduj podatności, które mają największe znaczenie, abyś mógł je szybko naprawić. Intruder śledzi twoją powierzchnię ataku, wykonuje proaktywne skanowanie zagrożeń, znajduje problemy w całym stosie technologicznym, od interfejsów API po aplikacje internetowe i systemy chmurowe. Wypróbuj go za darmo już dziś.