# Cookie Tossing

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

### Opis

Jeśli atakujący może **kontrolować subdomenę lub domenę firmy lub znajdzie XSS w subdomenie**, będzie w stanie przeprowadzić ten atak.

Jak wskazano w sekcji Hacking Cookies, gdy **ciasteczko jest ustawione na domenę (określając ją), będzie używane w domenie i subdomenach.**

> [!CAUTION]
> Dlatego **atakujący będzie mógł ustawić na domenie i subdomenach konkretne ciasteczko, robiąc coś takiego jak** `document.cookie="session=1234; Path=/app/login; domain=.example.com"`

Może to być niebezpieczne, ponieważ atakujący może być w stanie:

- **Przywiązać ciasteczko ofiary do konta atakującego**, więc jeśli użytkownik nie zauważy, **wykona działania na koncie atakującego**, a atakujący może uzyskać interesujące informacje (sprawdzić historię wyszukiwań użytkownika na platformie, ofiara może ustawić swoją kartę kredytową na koncie...)
- Przykład tego [można znaleźć tutaj](https://snyk.io/articles/hijacking-oauth-flows-via-cookie-tossing/), gdzie atakujący ustawił swoje ciasteczko w konkretnych sekcjach, które ofiara użyje do autoryzacji **dostępu do swoich repozytoriów git, ale z konta atakującego**, ponieważ ustawi swoje ciasteczka w potrzebnych punktach końcowych.
- Jeśli **ciasteczko nie zmienia się po zalogowaniu**, atakujący może po prostu **przywiązać ciasteczko (session-fixation)**, poczekać, aż ofiara się zaloguje, a następnie **użyć tego ciasteczka, aby zalogować się jako ofiara**.
- Czasami, nawet jeśli ciasteczka sesyjne się zmieniają, atakujący używa poprzedniego i również otrzyma nowe.
- Jeśli **ciasteczko ustawia jakąś wartość początkową** (jak w flask, gdzie **ciasteczko** może **ustawić** **token CSRF** sesji i ta wartość będzie utrzymywana po zalogowaniu ofiary), **atakujący może ustawić tę znaną wartość, a następnie ją wykorzystać** (w tym scenariuszu atakujący może zmusić użytkownika do wykonania żądania CSRF, ponieważ zna token CSRF).
- Tak jak ustawienie wartości, atakujący mógłby również uzyskać nieautoryzowane ciasteczko generowane przez serwer, uzyskać z niego token CSRF i go użyć.

### Kolejność Ciasteczek

Gdy przeglądarka otrzymuje dwa ciasteczka o tej samej nazwie **częściowo wpływające na ten sam zakres** (domena, subdomeny i ścieżka), **przeglądarka wyśle obie wartości ciasteczka**, gdy obie są ważne dla żądania.

W zależności od tego, kto ma **najbardziej szczegółową ścieżkę** lub które z nich jest **najstarsze**, przeglądarka **ustawi wartość ciasteczka najpierw**, a następnie wartość drugiego, jak w: `Cookie: iduser=MoreSpecificAndOldestCookie; iduser=LessSpecific;`

Większość **stron internetowych użyje tylko pierwszej wartości**. Dlatego, jeśli atakujący chce ustawić ciasteczko, lepiej ustawić je przed ustawieniem innego lub ustawić je z bardziej szczegółową ścieżką.

> [!WARNING]
> Co więcej, możliwość **ustawienia ciasteczka w bardziej szczegółowej ścieżce** jest bardzo interesująca, ponieważ będziesz mógł sprawić, że **ofiara będzie pracować ze swoim ciasteczkiem, z wyjątkiem konkretnej ścieżki, gdzie złośliwe ciasteczko zostanie wysłane jako pierwsze**.

### Ominięcie Ochrony

Możliwą ochroną przed tym atakiem byłoby to, że **serwer WWW nie zaakceptuje żądań z dwoma ciasteczkami o tej samej nazwie, ale z dwoma różnymi wartościami**.

Aby obejść scenariusz, w którym atakujący ustawia ciasteczko po tym, jak ofiara już otrzymała ciasteczko, atakujący mógłby spowodować **przepełnienie ciasteczka**, a następnie, gdy **legitne ciasteczko zostanie usunięte, ustawić złośliwe**.

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

Innym użytecznym **obejściem** mogłoby być **URL zakodowanie nazwy ciasteczka**, ponieważ niektóre zabezpieczenia sprawdzają 2 ciasteczka o tej samej nazwie w żądaniu, a następnie serwer zdekoduje nazwy ciasteczek.

### Cookie Bomb

Atak Cookie Tossing może być również użyty do przeprowadzenia ataku **Cookie Bomb**:

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

### Ochrona

#### **Użyj prefiksu `__Host` w nazwie ciasteczka**

- Jeśli nazwa ciasteczka ma ten prefiks, **zostanie zaakceptowana** w dyrektywie Set-Cookie tylko wtedy, gdy jest oznaczona jako Secure, została wysłana z bezpiecznego źródła, nie zawiera atrybutu Domain i ma ustawiony atrybut Path na /
- **To zapobiega subdomenom wymuszającym ciasteczko na domenę główną, ponieważ te ciasteczka mogą być postrzegane jako "zablokowane na domenie"**

### Referencje

- [**@blueminimal**](https://twitter.com/blueminimal)
- [**https://speakerdeck.com/filedescriptor/the-cookie-monster-in-your-browsers**](https://speakerdeck.com/filedescriptor/the-cookie-monster-in-your-browsers)
- [**https://github.blog/2013-04-09-yummy-cookies-across-domains/**](https://github.blog/2013-04-09-yummy-cookies-across-domains/)
- [**Cookie Crumbles: Unveiling Web Session Integrity Vulnerabilities**](https://www.youtube.com/watch?v=F_wAzF4a7Xg)

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