Cookie Tossing
Last updated
Last updated
Learn & practice AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE) Learn & practice GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
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.
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"
To może być niebezpieczne, ponieważ atakujący może być w stanie:
Zafiksować ciasteczko ofiary na konto 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...)
Jeśli ciasteczko nie zmienia się po zalogowaniu, atakujący może po prostu zafiksować 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 sesji 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 samo 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ć.
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ó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 specyficzną ścieżką.
Co więcej, możliwość ustawienia ciasteczka w bardziej specyficznej ścieżce jest bardzo interesująca, ponieważ będziesz mógł sprawić, że ofiara będzie pracować ze swoim ciasteczkiem, z wyjątkiem specyficznej ścieżki, gdzie ustawione zostanie złośliwe ciasteczko.
Możliwą ochroną przed tym atakiem byłoby to, że serwer WWW nie zaakceptuje żądań z dwoma ciasteczkami o tej samej nazwie, ale z dwiema 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.
Cookie Jar OverflowInnym użytecznym ominięciem mogłoby być zakodowanie URL nazwy ciasteczka, ponieważ niektóre zabezpieczenia sprawdzają dwa ciasteczka o tej samej nazwie w żądaniu, a następnie serwer dekoduje nazwy ciasteczek.
Atak Cookie Tossing może być również użyty do przeprowadzenia ataku Cookie Bomb:
Cookie Bomb__Host w nazwie ciasteczkaJeś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"
Learn & practice AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE) Learn & practice GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
