Z powodów już omówionych nie jest konieczne generowanie nowego tokena na żądanie. Zapewnia prawie zerową przewagę w zakresie bezpieczeństwa i kosztuje użytkownika pod względem użyteczności: mając tylko jeden ważny token naraz, użytkownik nie będzie mógł normalnie poruszać się po aplikacji internetowej. Na przykład, jeśli klikną przycisk „wstecz” i prześlą formularz z nowymi wartościami, przesyłanie zakończy się niepowodzeniem i prawdopodobnie powitają ich wrogim komunikatem o błędzie. Jeśli spróbują otworzyć zasób na drugiej karcie, stwierdzą, że sesja jest losowo przerywana w jednej lub obu kartach. Zwykle nie warto okaleczać użyteczności aplikacji, aby spełnić to bezsensowne wymaganie.

Jest jednak miejsce, w którym warto wydać nowy token CSRF: po zmianie podmiotu w środku Sesja. To znaczy przede wszystkim przy logowaniu. Ma to na celu zapobieżenie atakowi polegającemu na utrwaleniu sesji, prowadzącemu do możliwości ataku CSRF.

Na przykład: atakujący uzyskuje dostęp do witryny i generuje nową sesję. Pobierają identyfikator sesji i wstrzykują go do przeglądarki ofiary (np. Zapisując plik cookie z podatnej na atak domeny sąsiedniej lub wykorzystując inną lukę, taką jak adresy URL jsessionid), a także wstrzykują token CSRF do formularza w przeglądarce ofiary. Czekają, aż ofiara zaloguje się za pomocą tego formularza, a następnie używają innego postu formularza, aby skłonić ofiarę do wykonania akcji z wciąż aktywnym tokenem CSRF.

Aby temu zapobiec, unieważnij token CSRF i wydaj nowy w miejscach (takich jak logowanie), w których już robisz to samo z identyfikatorem sesji, aby zapobiec atakom utrwalania sesji.

Omówienie. Standardową radą jest użycie unikalnego tokena CSRF, który jest unikalny dla każdego żądania. Czemu? Ponieważ token na żądanie jest nieco bardziej odporny na niektóre rodzaje błędów implementacji niż token na sesję. To sprawia, że ​​tokeny na żądanie są prawdopodobnie najlepszym wyborem do tworzenia nowych aplikacji internetowych. Żaden audytor bezpieczeństwa nie będzie też kłopotać się z używaniem tokena CSRF na żądanie.

Jeśli jesteś programistą aplikacji internetowych, to wszystko, co musisz wiedzieć i możesz przestać czytać tutaj. Ale jeśli jesteś ekspertem ds. Bezpieczeństwa i zastanawiasz się nad szczegółowym uzasadnieniem tej porady lub zastanawiasz się, jak duże jest ryzyko, jeśli używasz tokena na sesję, czytaj dalej ....

Zagłębianie się nieco głębiej. Prawda jest taka, że ​​jeśli nie masz żadnych innych luk w swojej witrynie internetowej, pojedynczy token CSRF na sesję jest w porządku. Nie ma powodu, dla którego musisz mieć generować nowy token CSRF na żądanie.

Dowodzi tego fakt, że znajdziesz również renomowanych ekspertów ds. Bezpieczeństwa, którzy twierdzą, że inny rozsądny Sposobem obrony przed CSRF jest użycie podwójnego przesyłania plików cookie: innymi słowy, używasz kodu JavaScript po stronie klienta, który oblicza hash pliku cookie sesji i dodaje go do każdego żądania POST, traktując hash jako token CSRF. Możesz zobaczyć, że zasadniczo generuje to w locie token CSRF, który jest taki sam dla całej sesji.

Oczywiście znam argument, dlaczego niektórzy ludzie mogą zalecać generowanie nowego tokena CSRF dla każdego żądania. Myślą, że jeśli masz również lukę XSS w swojej witrynie, to jeśli użyjesz jednego tokena CSRF na sesję, łatwo będzie użyć XSS do odzyskania tokena CSRF, podczas gdy jeśli wygenerujesz nowy token CSRF na żądanie, zajmie więcej pracy, aby odzyskać token CSRF. Osobiście nie uważam tego za zbyt przekonujący argument. Jeśli masz lukę w zabezpieczeniach XSS w swojej witrynie, nadal można odzyskać tokeny CSRF, nawet jeśli wygenerujesz nowy token CSRF dla każdego żądania, wystarczy kilka dodatkowych wierszy złośliwego kodu JavaScript. Tak czy inaczej, jeśli masz lukę w zabezpieczeniach XSS w swojej witrynie i napotykasz poważnego, znającego się na rzeczy napastnika, trudno jest zagwarantować bezpieczeństwo, niezależnie od sposobu generowania tokenów CSRF.

Ogólnie rzecz biorąc, nie zaszkodzi aby wygenerować nowy token CSRF dla każdego żądania. I może lepiej zrobić to w ten sposób, żeby odciągnąć audytorów bezpieczeństwa. Ale jeśli masz już starszą aplikację, która używa jednego tokena CSRF przez całą sesję, wydanie pieniędzy na konwersję go w celu wygenerowania nowego tokena CSRF dla każdego żądania prawdopodobnie nie byłoby super wysoko na mojej liście priorytetów: Założę się, że mógłby znaleźć inne zastosowania dla tych pieniędzy i energii deweloperów, które jeszcze bardziej poprawiłyby bezpieczeństwo.

XSS może służyć do odczytywania tokena CSRF, nawet jeśli jest to pojedynczy token przesyłania, to dziecinnie proste. Jest prawdopodobne, że ta rekomendacja dotycząca pojedynczego tokena przesyłania pochodzi od kogoś, kto nie rozumie CSRF.

Jedynym powodem używania „pojedynczego tokena przesyłania” jest chęć zapobieżenia przypadkowemu kliknięciu przez użytkownika prześlij dwa razy. Dobrym zastosowaniem tego jest zapobieganie dwukrotnemu kliknięciu „kasy” przez użytkownika i przypadkowemu dwukrotnemu obciążeniu klienta.

CAPTCHA lub prośba o podanie aktualnego hasła użytkownika może służyć jako środek ochrony przed csrf być omijane przez XSS.

Polecam przeczytanie CSRF Prevention Cheat Sheet.

Jeśli token jest taki sam w całej sesji, osoba atakująca może wyciec token z jednej strony i użyć go do innego działania.

Na przykład możesz użyć iframe, aby załadować stronę, a następnie wyodrębnij token, korzystając z luki XSS. Stamtąd możesz użyć tego tokena do przesłania formularza zmiany hasła

Używanie tokena na żądanie zamiast tokena obejmującego całą sesję utrudnia, ale nie zapobiega CSRF. Atakujący może po prostu wykorzystać XSS, aby odczytać token ze strony, a następnie go odpalić. Jeśli jednak token jest globalny, a nie ograniczony do tej konkretnej strony, osoba atakująca może zaatakować dowolną stronę, aby ukraść token. Używanie oddzielnych tokenów dla każdego żądania znacznie utrudnia to.

Oprócz innych odpowiedzi, rozsądne może być również odświeżenie tokena, jeśli Twój serwer jest podatny na atak BREACH.

Wymaga to spełnienia trzech warunków:

• Być obsługiwane z serwera, który używa kompresji na poziomie HTTP
• Odzwierciedlaj dane wejściowe użytkownika w treściach odpowiedzi HTTP
• Odzwierciedlaj tajny (taki jako token CSRF ) w treściach odpowiedzi HTTP

Aby złagodzić BREACH, należałoby odświeżyć token CSRF w żądaniu GET ładującym formularz unieważnić wszystkie poprzednie tokeny. W ten sposób MITM (Man-In-The-Middle) tworzący dodatkowe żądania wykrycia tokena na stronie otrzyma za każdym razem inny token. Oznacza to, że prawdziwy użytkownik nie będzie mógł przesłać formularza w sytuacji MITM.

Oczywiście pozostałe dwa warunki również są spełnione. Prawdopodobnie byłoby łatwiej utrzymać token CSRF na sesję i wyłączyć kompresję na poziomie HTTP dla wszystkich stron obsługujących formularze.

Nie jest to zbyt znany fakt, ale zwykłe porównanie ciągów jest podatne na ataki czasowe ( takie jak ten. Krótko mówiąc, normalne operacje porównywania ciągów ( == lub === ) porówna dwa ciągi znak po znaku od lewej do prawej i zwróci fałsz, gdy napotkają dowolny znak, który nie jest równy w danej pozycji w obu łańcuchach. różnica w czasie, która została potwierdzona jako wykrywalna.

Korzystając z ataku czasowego w celu wypróbowania każdego możliwego znaku dla każdej pozycji, można ustalić, jaki jest rzeczywisty token. Tworząc nowy token za każdym razem, gdy przesyłane jest żądanie z tokenem, można zapobiec temu atakowi.

Oczywiście działa to tylko wtedy, gdy ponownie utworzysz token, jeśli nieprawidłowy token został przesłany, co może być niepożądane. Dlatego lepiej rozwiązać ten problem za pomocą niezależnej od czasu funkcji porównywania ciągów, takiej jak ta.

Jednym z powodów, dla których warto zmienić token CSRF na żądanie, jest ograniczenie wycieku tokenu przez kompresję. Rozumiem przez to, że jeśli atakująca Ewa może wstrzyknąć dane na stronę zawierającą token, na który strona jest wysyłana, skompresowana Ewa może następnie odgadnąć, czy pierwszy znak ciągu otrzymuje mniejszy zestaw danych dla strony, wiedząc, że zgadła od razu do następnego znaku.

Jest to podobne do ataku czasowego.

W tej chwili nie ma powodu (o którym wiem), aby zmieniać token, jeśli jest on wysyłany tylko w nagłówkach HTTP.

Inną metodą jest zmiana tokena, gdy tylko zostanie wykryte nieudane żądanie, ale może to spowodować problemy z tym, że użytkownik nie będzie mógł przesłać żadnego formularza.

Jeśli ten sam token jest używany przez całą sesję, istnieje prawdopodobieństwo, że atakujący może przejąć token za pomocą XSS i użyć sesji ofiary do wykonania złośliwych działań, takich jak zmiana hasła .

Mogą usuwać hasła, umieszczając ramkę iframe w witrynie, z której korzystasz.

Dlatego lepiej jest użyć jednego tokena na żądanie, aby uniemożliwić atakującemu uzyskanie dostęp do tego tokena.