Mirrors/hacktricks
2
0
Fork 0
mirror of https://github.com/carlospolop/hacktricks synced 2025-02-17 14:38:27 +00:00
Code Issues Projects Releases Packages Wiki Activity
hacktricks/pentesting-web/hacking-with-cookies/cookie-tossing.md

7 KiB
Raw Blame History

Cookie Tossing

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

Inne sposoby wsparcia HackTricks:

Opis

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

Jak wskazano w sekcji Hacking Cookies, gdy cookie jest ustawione dla domeny (specyfikując ją), będzie używane w domenie i subdomenach.

{% hint style="danger" %} Dlatego atakujący będzie mógł ustawić dla domeny i subdomen określone cookie, wykonując coś w rodzaju document.cookie="session=1234; Path=/app/login; domain=.example.com" {% endhint %}

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

  • Zafiksować cookie ofiary na konto atakującego, więc jeśli użytkownik tego nie zauważy, wykona czynności na koncie atakującego, a atakujący może uzyskać pewne interesujące informacje (sprawdź historię wyszukiwań użytkownika na platformie, ofiara może wprowadzić swój numer karty kredytowej do konta...)
  • Jeśli cookie nie zmienia się po zalogowaniu, atakujący może po prostu zafiksować cookie (session-fixation), poczekać aż ofiara się zaloguje, a następnie użyć tego cookie do zalogowania się jako ofiara.
  • Czasami, nawet jeśli ciasteczko sesji się zmienia, atakujący może użyć poprzedniego i otrzyma również nowe.
  • Jeśli cookie ustawia jakąś początkową wartość (jak w przypadku flask, gdzie cookie może ustawić token CSRF sesji, a ta wartość będzie utrzymywana po zalogowaniu ofiary), atakujący może ustawić tę znaną wartość, a następnie z niej skorzystać (w tym scenariuszu atakujący może sprawić, że użytkownik wyśle żądanie CSRF, ponieważ zna token CSRF).
  • Podobnie jak ustawianie wartości, atakujący mógłby również uzyskać nieuwierzytelnione cookie wygenerowane przez serwer, pobrać z niego token CSRF i go użyć.

Kolejność Cookie

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 specyficzną ścieżkę lub który jest starszy, przeglądarka ustawi najpierw wartość ciasteczka, 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 je ustawić przed ustawieniem innego lub ustawić je z bardziej specyficzną ścieżką.

{% hint style="warning" %} Co więcej, możliwość ustawienia ciasteczka w bardziej specyficznej ścieżce jest bardzo interesująca, ponieważ pozwala ofiary pracować z jej ciasteczkiem z wyjątkiem określonej ścieżki, gdzie ustawione zostanie złośliwe ciasteczko. {% endhint %}

Ominięcie Ochrony

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

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

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

Innym przydatnym sposobem ominięcia mogłoby być kodowanie URL nazwy ciasteczka, ponieważ niektóre zabezpieczenia sprawdzają, czy w żądaniu są 2 ciasteczka o tej samej nazwie, a następnie serwer zdekoduje nazwy ciasteczek.

Bomba Cookie

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

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

Obrona

Użyj prefiksu __Host w nazwie ciasteczka

  • Jeśli nazwa ciasteczka ma ten prefiks, będzie akceptowana tylko w dyrektywie Set-Cookie, jeśli jest oznaczona jako Secure, została wysłana z bezpiecznego źródła, nie zawiera atrybutu Domain i ma ustawiony atrybut Path na /
  • Zapobiega to subdomenom narzucania ciasteczka na domenę nadrzędną, ponieważ te ciasteczka mogą być postrzegane jako "zablokowane dla domeny"

Referencje

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

Inne sposoby wsparcia HackTricks: