For at forhindre CSRF-angreb tilbyder asp.net mvc funktionen ValidateAntiForgeryToken mod forfalskningsangreb, og i den nye version af asp.net kernerammeværk tilbyder Microsoft funktionen AutoValidateAntiforgeryToken, specifikt ValidateAntiForgeryToken og AutoValidateAntiforgeryToken Hvad forskellen er, vil denne artikel forklare i detaljer.
CSRF-konceptet
CSRF Cross-Site Request Forgery, ligesom XSS-angreb, er ekstremt skadeligt, du kan forstå det sådan her: angriberen stjæler din identitet og sender en ondsindet anmodning i dit navn, hvilket er fuldstændig legitimt for serveren, men udfører en handling, som angriberen forventer, såsom at sende e-mails og beskeder i dit navn, stjæle din konto, tilføje systemadministratorer eller endda købe varer. Virtuelle valutaoverførsler osv. Web A er et website med en CSRF-sårbarhed, Web B er et ondsindet website bygget af en angriber, og Bruger C er en legitim bruger af Web A.
ASP.NET MVC mod CSRF-angreb
På visningssiden bruges @Html.AntiForgeryToken() til at tilføje et tag, og når brugeren tilgår siden, vil backenden automatisk generere en skjult html-kode med tagget, som følger:
<inputnavn="__RequestVerificationToken" type="skjult" value="CfDJ8FBn4LzSYglJpE6Q0fWvZ8WDMTgwK49lDU1XGuP5-5j4JlSCML_IDOO3XDL5EOyI_mS2Ux7lLSfI7ASQnIIxo2ScEJvnABf9v51TUZl_iM2S63zuiPK4lcXRPa_KUUDbK-LS4HD16pJusFRppj-dEGc" />
ValidateAntiForgeryToken og AutoValidateAntiforgeryToken er forskellige
AutoValidateAntiforgeryTokenAuthorizationFilter arver ValidateAntiforgeryTokenAuthorizationFilter, men omskriver kun ShouldValidate-metoden i den.
AutoValidateAntiforgeryToken-egenskaben, der forårsager validering af anti-forfalskningstokens for alle usikre HTTP-metoder.HTTP-metoder bortset fra GET, HEAD, OPTIONS og TRACE kræver alle en anti-forfalskningstoken。 Dette kan anvendes som et globalt filter til at udløse applikationens anti-forfalskningstokenvalidering som standard.
Hyperlink-login er synlig.
AutoValidateAntiforgeryTokenAttribute validerer kaldet til AutoValidateAntiforgeryTokenAuthorizationFilter, som arver fra ValidateAntiforgeryTokenAuthorizationFilter,ShouldValidate-metoden er blevet omskrevet, at returnere true betyder, at den skal valideres, og at returnere false vil ikke blive valideret, som vist i figuren nedenfor:
Analyser kildekoden:
AutoValidateAntiforgeryTokenAttribute gør det muligt at anvende anti-forfalskningstokenvalidering globalt på alle usikre metoder, såsom POST, PUT, PATCH og DELETE. Så du behøver ikke tilføje [ValidateAntiForgeryToken]-egenskaben til hver handling, der kræver det.
For at bruge den, tilføj følgende kode til din ConfigureServices' Startup-klassemetode:
Hvis du skal ignorere anti-forfalskningsautentificering, kan du tilføje [IgnoreAntiforgeryTokenTilskriv handlingen.
Nogle gange kan du opleve, at du skal tagge flere forespørgsler på en controller, mens du har brug for nogle forespørgsler, der ikke behøver at blive forfalsket, såsom forskellige GET-baserede operationer. Der er flere værktøjer, du kan bruge for at gøre processen mere bekvem og behagelig. Den første er AutoValidateAntiforgeryToken-egenskaben. Den opfører sig som ValidateAntiForgeryToken-egenskaben. Dog vil den automatisk ignorere de handlinger, der kaldes af metoder designet til datahentning: GET, HEAD, OPTIONS og TRACE. Dette gør det muligt hurtigt og nemt at tilføje anti-forfalskningsmetoder til alle metoder, der kan ændre data uden at påvirke, hvordan data hentes.
Følgende kode er et eksempel på AutoValidateAntiforgeryToken-egenskaben:
I dette eksempel vil begge normale Index-operationer (GET) fungere uanset kilden, mens både Index-operationen med POST-metoden og RemoveUser-operationen som Delete-metoden vil kræve, at klienten bruger en anti-forfalskningstoken.
Tilpas de relevante oplysninger
Mange mennesker undrer sig måske over, om navnet på det genererede skjulte domæne kan erstattes med deres eget, og om navnet på cookien kan ændres til deres eget.
Svaret er ja, lad os kort demonstrere:
I Startup's ConfigureServices-metode tilføjes følgende for at ændre standardnavnet derefter.
Bemærk: Den største forskel mellem asp.net kerne og asp.net er,Core understøtter overførsel af valideringsparametre ved at anmode om en header, ikke for at danne former!
privat const-streng AntiforgeryTokenFieldName = "__RequestVerificationToken";
privat const-streng AntiforgeryTokenHeaderName = "RequestVerificationToken";
Du kan se kildekoden:Hyperlink-login er synlig.
Testkode:
Resultat: Forsøg på at tilgå test1-metoden giver en 400-fejl, adgang til test2-metoden returnerer den str-parameter, vi sendte, og du kan se, at AutoValidateAntiforgeryToken-funktionen ikke opsnapper GET-anmodningen.
(Slut)
|
Opslået på 20/02/2021 19.57.29
|
|
|
|
Udlejer|
Opslået på 08/07/2023 22.07.08
|
