Jaki jest pożytek z tokena przeciw fałszerstwu?

Question

w ASP.NET MVC 1.0, jest nowa funkcja obsługi krzyżowej zapytanie site problem bezpieczeństwa fałszerstwo:

<%= Html.AntiForgeryToken() %> 
[ValidateAntiForgeryToken] 
public ViewResult SubmitUpdate() 
{ 
    // ... etc 
} 

znalazłem token generowane w postaci html ciągle się zmienia za każdym razem nowa forma jest renderowane.

Chcę wiedzieć, jak generowany jest token? I kiedy używasz jakiegoś oprogramowania do skanowania tej strony, zgłosi to inny problem bezpieczeństwa: Naprawiono sesję. Czemu? Od czasu zmiany tokena, w jaki sposób ten problem może się pojawić?

I jest jeszcze jedna funkcja, która jest "solą" dla antiForgeryToken, ale naprawdę wiem do czego to służy, nawet jeśli nie używamy "soli" do wygenerowania tokena, token zmienia się cały czas , dlaczego więc ma taką funkcję?

Answer 1

Dużo informacji na AntiForgeryToken tutaj: http://blog.codeville.net/2008/09/01/prevent-cross-site-request-forgery-csrf-using-aspnet-mvcs-antiforgerytoken-helper/

Ma to na celu zapobiec cross-site request forgery (CSRF). Standardowym zachowaniem jest kliknięcie "Zapisz" w formularzu i wykonaj pewne czynności na serwerze, tj. Zapisz dane użytkownika. Skąd wiadomo, że użytkownik przesyłający formularz jest tym, za kogo się podaje? W większości przypadków używałbyś autoryzacji plików cookie lub systemu Windows.

Co się stanie, jeśli atakujący zwabi Cię na stronę, która przesyła dokładnie tę samą formę w małym ukrytym IFRAME? Twoje pliki cookie są przesyłane w stanie nienaruszonym, a serwer nie widzi żądania tak, jak każde inne żądanie legit. (Ponieważ Gmail odkrył: http://www.gnucitizen.org/blog/google-gmail-e-mail-hijack-technique/)

Token zapobiegający fałszerstwom zapobiega tej formie ataku, tworząc dodatkowy token cookie za każdym razem, gdy strona jest generowana. Token jest zarówno w postaci, jak i pliku cookie, jeśli forma i plik cookie nie pasują, mamy atak CSRF (ponieważ atakujący nie będzie w stanie odczytać tokena zapobiegającego fałszerstwu za pomocą ataku opisanego powyżej).

A co robi sól zrobić, z artykułu powyżej:

Sól jest tylko dowolny tekst. Inna wartość soli oznacza wygenerowanie innego tokena przeciw fałszerstwu. Oznacza to, że nawet jeśli atakujący w jakiś sposób udaje się zdobyć ważny token, nie może go użyć ponownie w innych częściach aplikacji, w których wymagana jest inna wartość soli.

Aktualizacja: W jaki sposób generowany jest token? Pobierz source i zajrzyj do klas AntiForgeryDataSerializer, AntiForgeryData.

Answer 2

Masz zadać kilka niepowiązanych problemy:

1. Nie wiem, dlaczego oprogramowanie zabezpieczające donosi „sesji stałe”. Spróbuj przeczytać w dokumentacji dostarczonej z raportem
2. anty-fałszowanie tokena:

Służy (przypuszczalnie), aby potwierdzić, że każde żądanie jest ważne. Należy więc wziąć pod uwagę, że ktoś próbuje podać link do strony ?x=1, jeśli token nie zostanie przekazany, żądanie zostanie odrzucone. Ponadto (może) zapobiegać powielaniu tego samego przedmiotu. Jeśli klikniesz przycisk „post” dwukrotnie, token prawdopodobnie ulegnie zmianie (każdy wniosek), a ta sprawa zostanie wykryty przez coś podobnego:

Session["nextToken"] = token; 
WriteToken(token); 

... 

if(!Request["nextToken"] == Session["nextToken"]){ 
    ... 
} 

// note: order in code is slightly different, you must take the token 
// before regenerating it, obviously 

myślę termin dla tego (ataku chroni) nazywany jest " CSRF "(Cross-Site Request Forgery), te dni.