Używanie tokena sesji lub nonce dla Cross-site Request Forgery Protection (CSRF)?

Question

Odziedziczyłem kod, który został niedawno zaatakowany, gdy atakujący wysłał wielokrotne zdalne wysyłanie formularzy.

Zaimplementowałem profilowanie przy użyciu tokenu uwierzytelniania sesji , który utworzę dla każdego użytkownika (nie identyfikator sesji). Chociaż zdaję sobie sprawę, że ten konkretny atak nie jest CSRF, dostosowałem moje rozwiązanie z tych postów (choć z datą).

• https://www.owasp.org/index.php/Cross-Site_Request_Forgery_%28CSRF%29
• http://tyleregeto.com/a-guide-to-nonce
• http://shiflett.org/articles/cross-site-request-forgeries

jednak nadal czuje istnieje pewna luka tutaj. Chociaż rozumiem, że nic nie jest w 100% bezpieczne, mam kilka pytań:

• Czy potencjalny napastnik nie może po prostu rozpocząć prawidłowej sesji, a następnie dołączyć identyfikator sesji (za pośrednictwem cookie) do każdego z wniosków?
• Wygląda na to, że nonce byłby lepszy niż token sesji. Jaki jest najlepszy sposób generowania i śledzenia numeru nonce?
• Znalazłem kilka punktów o tym, że te rozwiązania to tylko jedno okno. Czy ktoś mógłby rozwinąć tę kwestię?
• Czy te rozwiązania wymagają zawsze sesji? Czy te żetony mogą być tworzone bez sesji? UPDATE, ta strona to tylko pojedynczy formularz strony (bez logowania). Zatem rozpoczęcie sesji tylko po to, by wygenerować token wydaje się nadmierne.
• Czy istnieje prostsze rozwiązanie (nie CAPTCHA), które mógłbym wdrożyć w celu ochrony przed tym konkretnym atakiem, który nie używałby sesji.

W końcu szukam lepszego zrozumienia, aby móc wdrożyć bardziej niezawodne rozwiązanie.

Answer 1

Z tego co rozumiem, musisz zrobić trzy rzeczy: sprawić, aby wszystkie twoje zmiany danych były dostępne tylko z żądaniem POST, odrzucać żądania POST bez ważnego referrer (musi to być z tej samej domeny) i sprawdzać token uwierzytelnienia w każde żądanie POST (wartość tokenu POST musi być taka sama, jak token w pliku cookie).

Pierwsze dwa sprawiają, że naprawdę trudno jest wykonać dowolne szkodliwe żądanie CSRF, ponieważ zazwyczaj są to ukryte obrazy w wiadomościach e-mail, na innych stronach itp., A przesłanie żądania POST z ważnym odnośnikiem powinno być niemożliwe/trudne w nowoczesne przeglądarki. Liczba ta uniemożliwi wykonanie jakichkolwiek działań szkodliwych bez kradzieży plików cookie użytkownika/wykradzenia ruchu.

Teraz o pytania:

1. To pytanie naprawdę mylą mnie: jeśli używasz uwierzytelniania żetony poprawnie wtedy atakujący musi znać tokenu użytkownika z pliku cookie, aby wysłać go wraz z wnioskiem, więc dlaczego począwszy ważny napastnik własnego sesja może wyrządzić jakąkolwiek krzywdę?
2. Nonces sprawi, że wszystkie twoje linki będą brzydkie - nigdy nie widziałam, żeby ktokolwiek z nich korzystał. I myślę, że twoja strona może zostać wykorzystana, ponieważ musisz zapisywać/przeszukiwać wszystkie rzeczowniki w bazie danych - wiele żądań generowania rzeczowników może bardzo szybko zwiększyć rozmiar bazy danych (a wyszukiwanie ich będzie powolne).
3. Jeśli zezwalasz na odrzucenie ataku Dos tylko jednemu noun na identyfikator użytkownika, to jeśli użytkownik otworzy stronę, otwiera kolejną stronę, a następnie przesyła pierwszą stronę - jego żądanie zostanie odrzucone, gdy wygenerowany zostanie nowy noun, a stary jeden jest już nieważny.
4. Jak inaczej można zidentyfikować unikalnego użytkownika bez identyfikatora sesji, czy jest to plik cookie, GET lub POST?

UPD: jak nie mówimy abot CSRF więcej: można realizować wiele niejasnych obronne, które będą zapobiegać boty pająk z wysłaniem formularza:

1. ukrytych pól formularzy, które nie powinny być wypełnione (boty zwykle wypełnij większość pól formularza, które widzą, które mają dobre nazwy, nawet jeśli są naprawdę ukryte dla użytkownika)
2. Javascript trackers myszy (można analizować nagrane ruchy myszy w celu wykrycia botów)
3. Analiza dzienników żądań plików (gdy Strona jest załadowana javascript/css/images powinno być loa w większości przypadków dedowane, ale niektórzy (naprawdę rzadcy) użytkownicy mają to wyłączone)
4. Zmiany w formularzu JavaScript (gdy do formularza jest dodawane ukryte (lub nie) pole z javascript, które jest wymagane na serwerze: boty zwykle nie uruchamiaj javascript)
5. Narzędzia do analizy ruchu, takie jak Snort, aby wykrywać wzorce botów (dziwne programy użytkownika, zbyt szybkie przesyłanie formularzy itp.).

i więcej, ale na koniec dnia, niektóre nowoczesne boty używać całkowitą emulację prawdziwego zachowania użytkownika (za pomocą połączenia prawdziwa przeglądarka API) - więc jeśli ktoś naprawdę chcą zaatakować swoją stronę, nie ma obrony takiego pomoże Ci. Nawet obecnie CAPTCHA nie jest bardzo wiarygodna - oprócz złożonych algorytmów rozpoznawania obrazów, możesz teraz kupić 1000 CAPTCHA rozwiązanych przez ludzi dla dowolnej witryny za jedyne 1 $ (możesz znaleźć takie usługi głównie w krajach rozwijających się). Tak naprawdę, nie ma 100% obrony przed botami - każdy przypadek jest inny: czasami będziesz musiał stworzyć kompleksowy system obronny sam, czasem wystarczy odrobina regulacji.