|
|
Opublikowano 20.02.2021 19:57:29
|
|
|
|

Aby zapobiec atakom CSRF, asp.net mvc udostępnia funkcję ataku przeciw fałszowaniu ValidateAntiForgeryToken, a w nowej wersji podstawowego frameworka asp.net Microsoft udostępnia funkcję AutoValidateAntiforgeryToken, w szczególności ValidateAntiForgeryToken oraz AutoValidateAntiforgeryToken Jaka jest różnica? Ten artykuł wyjaśni szczegółowo.
Koncepcja CSRF
Cross-Site Request Counterfeitry CSRF, podobnie jak ataki XSS, jest niezwykle szkodliwy – można to zrozumieć w ten sposób: atakujący kradnie twoją tożsamość i wysyła złośliwe żądanie na twoje nazwisko, które jest całkowicie legalne dla serwera, ale wykonuje akcję, której atakujący się spodziewa, takie jak wysyłanie e-maili i wiadomości na twoje nazwisko, kradzież konta, dodanie administratorów systemu czy nawet zakup towarów, Transfery walut wirtualnych itd. Web A to strona internetowa z luką CSRF, Web B to złośliwa strona stworzona przez atakującego, a użytkownik C jest legalnym użytkownikiem Web A.
ASP.NET MVC przeciwko atakom CSRF
Na stronie widoku użyj @Html.AntiForgeryToken(), aby dodać tag, a gdy użytkownik utworzy stronę, backend automatycznie wygeneruje ukryty kod html z tym tagiem, w następujący sposób:
<nazwa wejściowa="__RequestVerificationToken" typ="ukryte" value="CfDJ8FBn4LzSYglJpE6Q0fWvZ8WDMTgwK49lDU1XGuP5-5j4JlSCML_IDOO3XDL5EOyI_mS2Ux7lLSfI7ASQnIIxo2ScEJvnABf9v51TUZl_iM2S63zuiPK4lcXRPa_KUUDbK-LS4HD16pJusFRppj-dEGc" /> Kontroler tła musi być ustawiony [ValidateAntiForgeryToken] funkcji zapobiegającej fałszowaniu zgłoszeń formularzy.
ValidateAntiForgeryToken i AutoValidateAntiforgeryToken to różne rzeczy
AutoValidateAntiforgeryTokenAuthorizationFilter dziedziczy ValidateAntiforgeryTokenAuthorizationFilter, ale przepisuje w nim tylko metodę ShouldValidate.
AutoValidateAntiforgeryToken, która powoduje walidację tokenów antyfałszowańskich dla wszystkich niebezpiecznych metod HTTP.Metody HTTP inne niż GET, HEAD, OPTIONS i TRACE wymagają tokena antyfałszującego。 Może to być stosowane jako globalny filtr, aby domyślnie wywołać walidację tokenów antyfałszowacyjnych aplikacji.
Logowanie do linku jest widoczne.
AutoValidateAntiforgeryTokenAttribute waliduje wywołanie do AutoValidateAntiforgeryTokenAuthorizationFilter, które dziedziczy z ValidateAntiforgeryTokenAuthorizationFilter,Metoda ShouldValidate została przepisana, zwracając true oznacza, że trzeba ją zweryfikować, a zwracanie false nie będzie walidowane, jak pokazano na poniższym rysunku:
Analizuj kod źródłowy:
AutoValidateAntiforgeryTokenAttribute pozwala na globalne zastosowanie walidacji tokenów antyfałszujących do wszystkich niebezpiecznych metod, takich jak POST, PUT, PATCH i DELETE. Nie musisz więc dodawać właściwości [ValidateAntiForgeryToken] do każdej akcji, która jej wymaga.
Aby go użyć, dodaj następujący kod do metody klasy Startup w ConfigureServices:
Jeśli musisz zignorować uwierzytelnianie antyfałszerskie, możesz dodać [IgnoreAntiforgeryTokenprzypisz to działaniu.
Czasami możesz zdarzać się w sytuacji, w której musisz oznaczać wiele żądań na kontrolerze, jednocześnie potrzebując takich, których nie trzeba fałszować, jak różne operacje oparte na GET. Istnieje kilka narzędzi, które mogą uczynić ten proces wygodniejszym i bardziej komfortowym. Pierwszą jest własność AutoValidateAntiforgeryToken. Zachowuje się jak własność ValidateAntiForgeryToken. Jednak automatycznie ignoruje działania wywoływane przez metody zaprojektowane do pobierania danych: GET, HEAD, OPTIONS i TRACE. Pozwala to szybko i łatwo dodać metody przeciwdziałania fałszerstwom do wszystkich metod, które mogą zmieniać dane bez wpływu na sposób ich pozyskiwania.
Poniższy kod jest przykładem właściwości AutoValidateAntiforgeryToken:
W tym przykładzie obie normalne operacje Indeksu (GET) działają niezależnie od źródła, podczas gdy zarówno operacja Indeks metodą POST, jak i operacja RemoveUser jako metoda Delete wymagają od klienta użycia tokena antyfałszowanego.
Dostosuj odpowiednie informacje
Wiele osób może się zastanawiać, czy nazwa wygenerowanej ukrytej domeny może zostać zastąpiona własną oraz czy nazwa cookie może zostać zmieniona na ich własną.
Odpowiedź brzmi: tak, pokażmy krótko:
W metodzie ConfigureServices w Startupie dodaj następujące elementy, aby odpowiednio zmodyfikować domyślną nazwę.
Uwaga: Największa różnica między asp.net core a asp.net jest taka,Core obsługuje przekazywanie parametrów walidacyjnych poprzez żądanie nagłówka, nie tworzyć form!
prywatny ciąg konstowy AntiforgeryTokenFieldName = "__RequestVerificationToken"; prywatny ciąg const AntiforgeryTokenHeaderName = "RequestVerificationToken";
Kod źródłowy możesz zobaczyć:Logowanie do linku jest widoczne.
Kod testowy:
Wynik: Próba dostępu do metody test1 zwraca błąd 400, dostęp do metody test2 zwraca parametr str, który przekazaliśmy, i widać, że funkcja AutoValidateAntiforgeryToken nie przechwytuje żądania GET.
(Koniec)
|
Poprzedni:Fiddler zastępuje linki, żądania przekierowująNastępny:[obrót] SQL Server SQL Count
|