Hakowanie tokenów CSRF przy użyciu hakowania historii CSS

Aktualizacja: Badacze bezpieczeństwa Sirdarckcat i Gareth byli na tyle uprzejmi, że udostępnili tutaj kod dla wyszukiwarki tokenów CSRF opartej wyłącznie na CSS. Jest to bardziej ukryte niż mój PoC poniżej, który używał kombinacji JS i CSS. Tak więc nadal będzie działać, nawet jeśli wyłączysz javascript i nie będziesz już bezpieczny :(:( . Aby ten PoC był bardziej responsywny dla klienta, musisz użyć wielu arkuszy stylów CSS za pomocą polecenia importu. Jedyny problem, jaki widzę w przypadku tego podejścia opartego wyłącznie na CSS, polega na opóźnieniu sieci związanym z dużymi przestrzeniami klawiszy, ponieważ Twój arkusz stylów CSS będzie musiał zostać pobrany przez przeglądarkę.


Myślałem o problemie fałszowania próśb o witryny oraz obecnych strategii łagodzenia skutków stosowanych w branży. W wielu aplikacjach z prawdziwego świata, które testowałem do tej pory, widzę użycie losowych tokenów dołączanych jako część adresu URL. Jeśli żądanie nie zawiera żadnego tokena lub nie zawiera tokenu o niepoprawnej wartości, wówczas żądanie zostaje odrzucone. Zapobiega to nieautoryzowanemu działaniu funkcji CSRF lub innej domeny.

Do tej pory atakujący odkrył token CSRF za pomocą ataków Brute Force na serwerze.

Powody są:

  1. To generuje dużo hałasu w sieci i jest powolny. Najprawdopodobniej więc IDS lub zapora aplikacji sieciowej wykryje złośliwe zachowanie i zablokuje twój ip. Na przykład token Base16 CSRF o długości 5 znaków (zaczynający się od znaku) wygeneruje około 393,216 żądań.
  2. Wiele aplikacji jest zaprogramowanych unieważnij sesję po wykryciu więcej niż określonej liczby żądań z nieprawidłowymi wartościami tokenów. Na przykład. 30.

Zamierzam zmienić to przekonanie, pokazując technikę szybkiego znajdowania tokenów csrf bez generowania alertów. Ta technika to atak po stronie klienta, więc prawie nie generowany jest ruch sieciowy, dlatego wygrał Twój serwer i zapory ogniowe aplikacji IDS / Web’w ogóle to zauważam. Atak ten oparty jest na popularnym haku historii CSS odkrytym przez Jeremiaha Grossmana 3 lata temu.

W tym exploicie odkrywamy token csrf poprzez brutalne wymuszanie różnych zestawów adresów URL w historii przeglądarki. Spróbujemy osadzić różne wartości tokenów csrf jako część adresu URL i sprawdzić, czy użytkownik odwiedził ten adres. Jeśli tak, istnieje duża szansa, że ​​użytkownik używa tego samego tokenu CSRF w bieżącej aktywnej sesji lub mógł użyć tego tokenu w poprzedniej sesji. Kiedy już mamy listę wszystkich takich tokenów, możemy po prostu spróbować naszego ataku csrf na serwer przy użyciu tej małej listy. Obecnie atak ten jest możliwy dla żetonów o długości 5 znaków lub krótszych. Próbowałem go na podstawie 16 sznurka o długości 5 i byłem w stanie brutalnie wymusić całą przestrzeń klawiszy w mniej niż 2 minuty.

Niektóre z warunków koniecznych do działania tego ataku są albo

  1. Token CSRF pozostaje taki sam dla określonej sesji użytkownika. na przykład csrf token = hash (session_id) OR
  2. Token CSRF przesłany w starszych formularzach dla tej samej sesji jest akceptowany. Dzieje się tak wielokrotnie, ponieważ poprawia komfort użytkowania i pozwala na używanie przycisków przeglądarki do przodu i do tyłu.

Dowód koncepcji jest dostępny tutaj.
Przed uruchomieniem PoC musisz zmienić wartości parametrów adresu URL i csrftoken.

Aby przetestować przy użyciu ustawień domyślnych, musisz najpierw odwiedzić jeden z następujących adresów URL, np.

  1. https://securethoughts.com/?param1=val1&csrftoken = b59fe [zmień b59fe na dowolny 5-cyfrowy podstawowy ciąg 16 zaczynający się od znaku, tj. większy niż a0000]
  2. http://tinyurl.com/l2lwgd [który jest przekierowaniem 301 do poprzedniego adresu URL].

Uwaga: Strony http://www.securethoughts.com i https://securethoughts.com są traktowane inaczej podczas przechowywania w historii przeglądarki.

Przykładowy przebieg będzie wyglądał następująco -

hakowanie tokenów csrf przy użyciu hackowania historii csshakowanie tokenów csrf przy użyciu hackowania historii css

Za uczynienie tego ataku niemożliwym,

Rozwiązanie po stronie serwera (dla programistów):

  • Spraw, aby twoje tokeny CSRF były wystarczająco długie (8 lub więcej znaków), aby były niewykonalne dla ataku STRONY KLIENTA. Stale rosnąca moc przetwarzania sprawi, że ten atak będzie możliwy również dla dłuższych żetonów.
  • Przechowuj token CSRF jako część ukrytego pola formularza, zamiast wpisywać adres URL.
  • Użyj innego losowego tokena dla każdego przesłanego formularza i nie akceptuj żadnego przestarzałego tokena, nawet dla tej samej sesji.

Rozwiązanie po stronie klienta (dla klientów / użytkowników):

  • Użyj wtyczki przeglądarki, takiej jak SafeHistory, która chroni przed technikami śledzenia opartymi na odwiedzanych linkach.
  • Użyj prywatnego trybu przeglądania w przeglądarce.

I na koniec, ale nie mniej ważne, XSS niszczy wszystkie możliwe zabezpieczenia CSRF. Najpierw pozbądź się XSS.

Chciałbym podziękować Jeremiaszowi za przekazanie jego wnikliwej opinii na temat tego postu.

Brayan Jackson Administrator
Sorry! The Author has not filled his profile.
follow me