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.

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"

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 podać swój numer karty kredytowej w koncie...)

  • 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 cookie sesji się zmienia, atakujący może użyć poprzedniego i otrzyma również nowy.

  • 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 takim 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ć.

Gdy przeglądarka otrzymuje dwa pliki cookie 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 cookie, 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ść cookie, 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ć cookie, lepiej je ustawić przed ustawieniem innego lub ustawić je z bardziej specyficzną ścieżką.

Co więcej, możliwość ustawienia cookie w bardziej specyficznej ścieżce jest bardzo interesująca, ponieważ pozwala to ofiary pracować z jej cookie, z wyjątkiem konkretnej ścieżki, gdzie ustawione zostanie złośliwe cookie.

Ominięcie Ochrony

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

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

pageCookie Jar Overflow

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

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

pageCookie Bomb

Obrona

  • Jeśli nazwa pliku cookie 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 wymuszającym cookie na domenę apex, ponieważ te pliki cookie 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:

Last updated