# Cookies Hacking

{{#include ../../banners/hacktricks-training.md}}

## Cookie Attributes

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:

### Expires and Max-Age

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.**

### Domain

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`.

### Path

Atrybut `Path` wskazuje konkretną ścieżkę URL, która musi być obecna w żądanym URL, aby nagłówek `Cookie` został wysłany. Atrybut ten traktuje znak `/` jako separator katalogów, co pozwala na dopasowania w podkatalogach.

### Ordering Rules

Gdy dwa ciasteczka mają tę samą nazwę, wybór ciasteczka 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.

### SameSite

- 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](https://www.netsparker.com/blog/web-security/same-site-cookie-attribute-prevent-cross-site-request-forgery/) 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/](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.**

## Cookies Flags

### HttpOnly

To uniemożliwia **klientowi** dostęp do ciasteczka (np. za pomocą **Javascript**: `document.cookie`)

#### **Bypasses**

- 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://blog.hackcommander.com/posts/2022/11/12/bypass-httponly-via-php-info-page/](https://blog.hackcommander.com/posts/2022/11/12/bypass-httponly-via-php-info-page/)).
- Można to obejść za pomocą żądań **TRACE** **HTTP**, 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:

{{#ref}}
cookie-jar-overflow.md
{{#endref}}

- Możliwe jest użycie ataku [**Cookie Smuggling**](#cookie-smuggling) do wykradzenia tych ciasteczek.

### Secure

Żądanie **wyśle** ciasteczko w żądaniu HTTP tylko wtedy, gdy żądanie jest przesyłane przez bezpieczny kanał (zazwyczaj **HTTPS**).

## Cookies Prefixes

Ciasteczka z prefiksem `__Secure-` muszą być ustawione wraz z flagą `secure` z stron zabezpieczonych 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.
- Nie mogą określać 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.

### Overwriting cookies

Jedną z ochron prefiksowanych ciasteczek `__Host-` jest zapobieganie ich nadpisywaniu z subdomen. Zapobiega to na przykład [**atakom Cookie Tossing**](cookie-tossing.md). W wykładzie [**Cookie Crumbles: Unveiling Web Session Integrity Vulnerabilities**](https://www.youtube.com/watch?v=F_wAzF4a7Xg) ([**artykuł**](https://www.usenix.org/system/files/usenixsecurity23-squarcina.pdf)) 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...:

<figure><img src="../../images/image (6) (1) (1) (1) (1).png" alt=""><figcaption></figcaption></figure>

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-`:

<figure><img src="../../images/image (7) (1) (1) (1) (1).png" alt="" width="373"><figcaption></figcaption></figure>

## Cookies Attacks

Jeśli niestandardowe ciasteczko zawiera wrażliwe dane, sprawdź je (szczególnie jeśli bierzesz udział w CTF), ponieważ może być podatne.

### Decoding and Manipulating Cookies

Wrażliwe dane osadzone w ciasteczkach powinny być zawsze dokładnie sprawdzane. Ciasteczka zakodowane w Base64 lub podobnych formatach mogą często być dekodowane. Ta luka pozwala atakującym na zmianę zawartości ciasteczka i podszywanie się pod innych użytkowników, kodując ich zmodyfikowane dane z powrotem do ciasteczka.

### Session Hijacking

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 prawdziwego użytkownika.

### Session Fixation

W tym scenariuszu atakujący oszukuje ofiarę, aby użyła konkretnego ciasteczka do logowania. Jeśli aplikacja nie przypisuje nowego ciasteczka po zalogowaniu, 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:

{{#ref}}
cookie-tossing.md
{{#endref}}

### Session Donation

Tutaj 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:

{{#ref}}
cookie-tossing.md
{{#endref}}

### [JWT Cookies](../hacking-jwt-json-web-tokens.md)

Kliknij 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.

### Cross-Site Request Forgery (CSRF)

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.

### Empty Cookies

(Sprawdź dalsze szczegóły w [oryginalnych badaniach](https://blog.ankursundara.com/cookie-bugs/)) Przeglądarki pozwalają na tworzenie ciasteczek bez nazwy, co można zademonstrować za pomocą JavaScript w następujący sposób:
```js
document.cookie = "a=v1"
document.cookie = "=test value;" // Setting an empty named cookie
document.cookie = "b=v2"
```
Wynik w nagłówku cookie wysłanym to `a=v1; test value; b=v2;`. Intrygująco, 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ść:
```js
function setCookie(name, value) {
document.cookie = `${name}=${value}`
}

setCookie("", "a=b") // Setting the empty cookie modifies another cookie's value
```
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`.

#### Błąd Chrome: Problem z kodem zastępczym Unicode

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:
```js
document.cookie = "\ud800=meep"
```
To skutkuje tym, że `document.cookie` zwraca pusty ciąg, co wskazuje na trwałą korupcję.

#### Przemyt ciasteczek z powodu problemów z analizą

(Zobacz szczegóły w [oryginalnych badaniach](https://blog.ankursundara.com/cookie-bugs/)) 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ść:
```
RENDER_TEXT="hello world; JSESSIONID=13371337; ASDF=end";
```
#### Luki w Iniekcji Ciasteczek

(Check further details in the[original research](https://blog.ankursundara.com/cookie-bugs/)) 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 iniekcji ciasteczek. Serwery te 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ą analizowanie od znaku spacji.

Ta luka jest szczególnie niebezpieczna w aplikacjach webowych polegających 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 ten jest zaostrzony przez sposób, w jaki Python obsługuje duplikaty nazw ciasteczek, 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.

### Ciasteczka $version

#### Obejście WAF

Zgodnie z [**tym wpisem na blogu**](https://portswigger.net/research/bypassing-wafs-with-the-phantom-version-cookie), możliwe jest użycie atrybutu ciasteczka **`$Version=1`**, aby backend używał starej logiki do analizy ciasteczka zgodnie z **RFC2109**. Ponadto, inne wartości takie jak **`$Domain`** i **`$Path`** mogą być używane do modyfikacji zachowania backendu z ciasteczkiem.

#### Atak Ciasteczkowy Sandwich

Zgodnie z [**tym wpisem na blogu**](https://portswigger.net/research/stealing-httponly-cookies-with-the-cookie-sandwich-technique), możliwe jest użycie techniki ciasteczkowego sandwichu do kradzieży ciasteczek HttpOnly. Oto wymagania i kroki:

- Znajdź miejsce, w którym pozornie bezużyteczne **ciasteczko jest odzwierciedlane w odpowiedzi**
- **Utwórz ciasteczko o nazwie `$Version`** z wartością `1` (możesz to zrobić w ataku XSS z JS) z bardziej specyficzną ścieżką, aby zajęło początkową pozycję (niektóre frameworki, takie jak Python, nie potrzebują tego kroku)
- **Utwórz ciasteczko, które jest odzwierciedlane** z wartością, która pozostawia **otwarte podwójne cudzysłowy** i z określoną ścieżką, aby było umiejscowione w bazie ciasteczek po poprzednim (`$Version`)
- Następnie, legalne ciasteczko będzie następne w kolejności
- **Utwórz fałszywe ciasteczko, które zamyka podwójne cudzysłowy** wewnątrz swojej wartości

W ten sposób ciasteczko ofiary zostaje uwięzione wewnątrz nowego ciasteczka wersji 1 i będzie odzwierciedlane, gdy tylko zostanie odzwierciedlone.
```javascript
document.cookie = `$Version=1;`;
document.cookie = `param1="start`;
// any cookies inside the sandwich will be placed into param1 value server-side
document.cookie = `param2=end";`;
```
### WAF bypasses

#### Cookies $version

Sprawdź poprzednią sekcję.

#### Bypassing value analysis with quoted-string encoding

To parsowanie 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`

#### Bypassing cookie-name blocklists

W RFC2109 wskazano, że **przecinek może być użyty 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.

#### Bypassing value analysis with cookie splitting

Na koniec różne backdoory mogą łączyć w jeden ciąg różne ciasteczka przekazywane w różnych nagłówkach ciasteczek, jak w:
```
GET / HTTP/1.1
Host: example.com
Cookie: param1=value1;
Cookie: param2=value2;
```
Co mogłoby pozwolić na ominięcie WAF, jak w tym przykładzie:
```
Cookie: name=eval('test//
Cookie: comment')

Resulting cookie: name=eval('test//, comment') => allowed
```
### Dodatkowe kontrole podatnych ciasteczek

#### **Podstawowe kontrole**

- **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 utworzyć kilka kont z prawie tym samym nazwiskiem 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ć podatna, zawsze używaj ciasteczka z **zapamiętaj mnie** bez żadnego innego ciasteczka.
- Sprawdź, czy poprzednie ciasteczko działa nawet po zmianie hasła.

#### **Zaawansowane ataki na ciasteczka**

Jeśli ciasteczko pozostaje takie samo (lub prawie) podczas logowania, prawdopodobnie oznacza to, że ciasteczko jest związane z jakimś polem twojego konta (prawdopodobnie nazwiskiem). Wtedy możesz:

- Spróbować utworzyć wiele **kont** z nazwiskami bardzo **podobnymi** i spróbować **zgadnąć**, jak działa algorytm.
- Spróbować **bruteforce'ować nazwisko**. Jeśli ciasteczko zapisuje się tylko jako metoda uwierzytelniania dla twojego nazwiska, wtedy możesz utworzyć konto z nazwiskiem "**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**
```bash
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 pode podjąć kilka prób i zapyta cię, która z warunków jest warunkiem błędu (tym, który jest nieprawidłowy).

Następnie zacznie deszyfrować ciasteczko (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 **encrypt** **user=administrator**.
```
padbuster http://web.com/index.php 1dMjA5hfXh0jenxJQ0iW6QXKkzAGIWsiDAKV3UwJPT2lBP+zAD0D0w== 8 -cookies thecookie=1dMjA5hfXh0jenxJQ0iW6QXKkzAGIWsiDAKV3UwJPT2lBP+zAD0D0w== -plaintext 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**

1. Uzyskaj podpis nazwy użytkownika **administ** = **t**
2. Uzyskaj podpis nazwy użytkownika **rator\x00\x00\x00 XOR t** = **t'**
3. 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".

## References

- [https://blog.ankursundara.com/cookie-bugs/](https://blog.ankursundara.com/cookie-bugs/)
- [https://www.linkedin.com/posts/rickey-martin-24533653_100daysofhacking-penetrationtester-ethicalhacking-activity-7016286424526180352-bwDd](https://www.linkedin.com/posts/rickey-martin-24533653_100daysofhacking-penetrationtester-ethicalhacking-activity-7016286424526180352-bwDd)
- [https://portswigger.net/research/bypassing-wafs-with-the-phantom-version-cookie](https://portswigger.net/research/bypassing-wafs-with-the-phantom-version-cookie)

{{#include ../../banners/hacktricks-training.md}}