Cookie Tossing
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ć.
Kolejność Cookie
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.
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.
Bomba Cookie
Atak Cookie Tossing może również być wykorzystany do przeprowadzenia ataku Cookie Bomb:
Obrona
Użyj prefiksu __Host w nazwie pliku cookie
__Host w nazwie pliku cookieJeś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
Last updated