mirror of
https://github.com/HackTricks-wiki/hacktricks.git
synced 2025-10-10 18:36:50 +00:00
69 lines
5.1 KiB
Markdown
69 lines
5.1 KiB
Markdown
# 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}}
|