|
|
Publisert på 20.02.2021 19:57:29
|
|
|
|
For å forhindre CSRF-angrep tilbyr asp.net mvc funksjonen ValidateAntiForgeryToken mot forfalskningsangrep, og i den nye versjonen av asp.net kjernerammeverk tilbyr Microsoft AutoValidateAntiforgeryToken-funksjonen, spesielt ValidateAntiForgeryToken og AutoValidateAntiforgeryToken Hva forskjellen er, vil denne artikkelen forklare i detalj.
CSRF-konseptet
CSRF Cross-Site Request Forgery, som XSS-angrep, er ekstremt skadelig, du kan forstå det slik: angriperen stjeler identiteten din og sender en ondsinnet forespørsel i ditt navn, som er helt legitim for serveren, men som utfører en handling angriperen forventer, som å sende e-poster og meldinger i ditt navn, stjele kontoen din, legge til systemadministratorer eller til og med kjøpe varer. Virtuelle valutaoverføringer, osv. Web A er et nettsted med en CSRF-sårbarhet, Web B er et ondsinnet nettsted laget av en angriper, og bruker C er en legitim bruker av Web A.
ASP.NET MVC mot CSRF-angrep
På visningssiden bruker du @Html.AntiForgeryToken() for å legge til en tag, og når brukeren får tilgang til siden, vil backend automatisk generere en skjult html-kode med taggen, som følger:
<inngangsnavn="__RequestVerificationToken" type="skjult" value="CfDJ8FBn4LzSYglJpE6Q0fWvZ8WDMTgwK49lDU1XGuP5-5j4JlSCML_IDOO3XDL5EOyI_mS2Ux7lLSfI7ASQnIIxo2ScEJvnABf9v51TUZl_iM2S63zuiPK4lcXRPa_KUUDbK-LS4HD16pJusFRppj-dEGc" />
ValidateAntiForgeryToken og AutoValidateAntiforgeryToken er forskjellige
AutoValidateAntiforgeryTokenAuthorizationFilter arver ValidateAntiforgeryTokenAuthorizationFilter, men omskriver kun ShouldValidate-metoden i den.
AutoValidateAntiforgeryToken-egenskapen som forårsaker validering av anti-forfalskningstokens for alle usikre HTTP-metoder.HTTP-metoder andre enn GET, HEAD, OPTIONS og TRACE krever alle en anti-forfalskningstoken。 Dette kan brukes som et globalt filter for å utløse applikasjonens validering av anti-forfalskningstoken som standard.
Innloggingen med hyperkoblingen er synlig.
AutoValidateAntiforgeryTokenAttribute validerer kallet til AutoValidateAntiforgeryTokenAuthorizationFilter, som arver fra ValidateAntiforgeryTokenAuthorizationFilter,ShouldValidate-metoden er omskrevet, å returnere sann betyr at den må valideres, og å returnere falsk vil ikke bli validert, som vist i figuren nedenfor:
Analyser kildekoden:
AutoValidateAntiforgeryTokenAttribute gjør det mulig å anvende anti-forfalskningstokenvalidering globalt på alle usikre metoder, som POST, PUT, PATCH og DELETE. Så du trenger ikke å legge til egenskapen [ValidateAntiForgeryToken] til hver handling som krever det.
For å bruke den, legg til følgende kode i ConfigureServices' oppstartsklasse-metode:
Hvis du må ignorere anti-forfalskningsautentisering, kan du legge til [IgnoreAntiforgeryTokenTilskriv handlingen.
Noen ganger kan du oppleve at du må tagge flere forespørsler på en kontroller, samtidig som du trenger noen forespørsler som ikke trenger å forfalskes, som for eksempel ulike GET-baserte operasjoner. Det finnes flere verktøy du kan bruke for å gjøre prosessen mer praktisk og komfortabel. Den første er AutoValidateAntiforgeryToken-egenskapen. Den oppfører seg som egenskapen ValidateAntiForgeryToken. Den vil imidlertid automatisk ignorere handlingene som kalles av metoder designet for datahenting: GET, HEAD, OPTIONS og TRACE. Dette gjør at du raskt og enkelt kan legge til anti-forfalskningsmetoder til alle metoder som kan endre data uten å påvirke hvordan data hentes.
Følgende kode er et eksempel på AutoValidateAntiforgeryToken-egenskapen:
I dette eksempelet vil begge normale Index-operasjoner (GET) fungere uavhengig av kilden, mens både Index-operasjonen med POST-metoden og RemoveUser-operasjonen som Delete-metoden vil kreve at klienten bruker en anti-forfalskningstoken.
Tilpass relevant informasjon
Mange lurer kanskje på om navnet på det genererte skjulte domenet kan erstattes med deres eget, og om navnet på informasjonskapselen kan endres til deres eget.
Svaret er ja, la oss kort demonstrere:
I Startup's ConfigureServices-metoden, legg til følgende for å endre standardnavnet deretter.
Merk: Den største forskjellen mellom asp.net kjerne og asp.net er,Core støtter å sende valideringsparametere ved å be om en header, ikke for å danne former!
privat const-streng AntiforgeryTokenFieldName = "__RequestVerificationToken";
privat konst-streng AntiforgeryTokenHeaderName = "RequestVerificationToken";
Du kan se kildekoden:Innloggingen med hyperkoblingen er synlig.
Testkode:
Resultat: Forsøk på å få tilgang til test1-metoden gir en 400-feil, tilgang til test2-metoden returnerer str-parameteren vi sendte, og du kan se at AutoValidateAntiforgeryToken-funksjonen ikke fanger opp GET-forespørselen.
(Slutt)
|
Foregående:Fiddler erstatter lenker, ber om videresending omdirigeringerNeste:[snu] SQL Server SQL-telling
|
Vert|
Publisert på 08.07.2023 22:07:08
|
