Jakie są szczegóły implementacji i uzasadnienie AntiForgeryToken programu ASP.NET MVC3?

Question

AntiForgeryToken służy do zapobiegania atakom CSRF, jednak linki w witrynie MSDN nie dają mi wiele informacji na temat tego, co dokładnie robi moduł AntiForgeryToken, jak działa lub dlaczego wszystko jest wykonywane tak, jak jest.

Z tego co wiem, tworzy skrót na stronie internetowej i plik cookie. Jedna lub obie z nich używają zaszyfrowanego IPrincipal.Name i używają szyfrowania symetrycznego.

Czy ktoś może rzucić światło na celu:

1. Jak AntiForgeryToken pracuje wewnętrznie
2. Jakie powinny być wykorzystywane do ochrony
3. Co należy NIE stosować do ochrony
4. Jaki jest rozumowanie za wyborami wdrażania dla nr 1 powyżej?
   • Przykład:
     • jest realizacja bezpieczne od „DoubleSubmit” cookies i innych znanych usterek
     • Czy istnieją kwestie wdrożeniowe, gdy użytkownik otwiera wiele kart
     • Co sprawia, że ​​wdrożenie msft różni się od tej, dostępnej w SANS

Answer 1

Dobra, tutaj to mój najlepszy strzał.

1) Wewnętrznie, mvc używa metod kryptograficznych RNG do utworzenia 128-bitowego łańcucha, który będzie działał jako token XSRF. Ten ciąg jest przechowywany w pliku cookie, a także w ukrytym polu gdzieś w formularzu. Nazwa pliku cookie wydaje się być w formie __RequestVerificationToken + kodowanej wersji ścieżki aplikacji w wersji base 64 (po stronie serwera). Część html tego używa AntiForgeryDataSerializer do serializacji następujących fragmentów danych - sól - wartość (token string) - kleszcze z datą utworzenia - nazwa użytkownika (wydaje się Context.User)

metoda validate w zasadzie deserializuje wartości z pliku cookie i formy i porównuje je na podstawie wartości (salt/value/ticks/username).

2/3) Sądzę, że ta dyskusja jest bardziej uzasadniona, kiedy używać tokenów XSRF, a kiedy nie. Moim zdaniem, powinieneś używać tego na każdej formie (mam na myśli, dlaczego nie). Jedyne, co mogę myśleć o tym, że to nie chroni, to fakt, że faktycznie trafiłeś w dany formularz, czy nie. Znajomość kodowania base64 nazwy aplikacji umożliwi atakującemu możliwość wyświetlenia pliku cookie podczas ataku XSRF. Może moja interpretacja tego jest niepoprawna.

4) Nie wiesz dokładnie, czego szukasz? Sądzę, że zbudowałbym mechanizm, w którym spróbowałbym zapisać token XSRF w sesji (jeśli był już dostępny), a jeśli nie, to wypróbuj metodę cookie. Jeśli chodzi o typ kryptografii, znalazłem ten SO artcile. Pros and cons of RNGCryptoServiceProvider