|
|
Publicerad på 2021-02-20 19:57:29
|
|
|
|
För att förhindra CSRF-attacker tillhandahåller asp.net mvc funktionen ValidateAntiForgeryToken mot förfalskningsattacker, och i den nya versionen av asp.net kärnramverk tillhandahåller Microsoft funktionen AutoValidateAntiforgeryToken, specifikt ValidateAntiForgeryToken och AutoValidateAntiforgeryToken Vad är skillnaden kommer den här artikeln att förklara i detalj.
CSRF-konceptet
CSRF Cross-Site Request Forgery, liksom XSS-attacker, är extremt skadligt, du kan förstå det så här: angriparen stjäl din identitet och skickar en skadlig begäran i ditt namn, vilket är helt legitimt för servern, men som utför en handling som angriparen förväntar sig, såsom att skicka e-post och meddelanden i ditt namn, stjäla ditt konto, lägga till systemadministratörer eller till och med köpa varor, Virtuella valutaöverföringar, etc. Webb A är en webbplats med en CSRF-sårbarhet, Webb B är en skadlig webbplats byggd av en angripare, och Användare C är en legitim användare av Webb A.
ASP.NET MVC mot CSRF-attacker
På visningssidan använder du @Html.AntiForgeryToken() för att lägga till en tagg, och när användaren går in på sidan genererar backend automatiskt en dold html-kod med taggen, enligt följande:
<inmatningsnamn="__RequestVerificationToken" typ="dolt" value="CfDJ8FBn4LzSYglJpE6Q0fWvZ8WDMTgwK49lDU1XGuP5-5j4JlSCML_IDOO3XDL5EOyI_mS2Ux7lLSfI7ASQnIIxo2ScEJvnABf9v51TUZl_iM2S63zuiPK4lcXRPa_KUUDbK-LS4HD16pJusFRppj-dEGc" />
ValidateAntiForgeryToken och AutoValidateAntiforgeryToken är olika
AutoValidateAntiforgeryTokenAuthorizationFilter ärver ValidateAntiforgeryTokenAuthorizationFilter, men skriver endast om ShouldValidate-metoden i den.
AutoValidateAntiforgeryToken-egenskapen som orsakar validering av anti-förfalskningstokens för alla osäkra HTTP-metoder.HTTP-metoder utöver GET, HEAD, OPTIONS och TRACE kräver alla en anti-förfalskningstoken。 Detta kan användas som ett globalt filter för att utlösa applikationens validering av anti-förfalskningstoken som standard.
Inloggningen med hyperlänken är synlig.
AutoValidateAntiforgeryTokenAttribute validerar anropet till AutoValidateAntiforgeryTokenAuthorizationFilter, som ärver från ValidateAntiforgeryTokenAuthorizationFilter,ShouldValidate-metoden har skrivits om, att returnera true betyder att den måste valideras, och att returnera false kommer inte att valideras, som visas i figuren nedan:
Analysera källkoden:
AutoValidateAntiforgeryTokenAttribute tillåter att anti-förfalskningstokenvalidering tillämpas globalt på alla osäkra metoder, såsom POST, PUT, PATCH och DELETE. Så du behöver inte lägga till egenskapen [ValidateAntiForgeryToken] till varje åtgärd som kräver det.
För att använda den, lägg till följande kod i din ConfigureServices Startup-klassmetod:
Om du behöver ignorera anti-förfalskningsautentisering kan du lägga till [IgnoreAntiforgeryTokenTilldela handlingen.
Ibland kan du behöva tagga flera förfrågningar på en kontroller samtidigt som du behöver vissa förfrågningar som inte behöver förfalskas, som olika GET-baserade operationer. Det finns flera verktyg du kan använda för att göra processen mer bekväm och bekväm. Den första är egenskapen AutoValidateAntiforgeryToken. Den beter sig som egenskapen ValidateAntiForgeryToken. Den kommer dock automatiskt att ignorera de åtgärder som anropas av metoder designade för datahämtning: GET, HEAD, OPTIONS och TRACE. Detta gör att du snabbt och enkelt kan lägga till anti-förfalskningsmetoder till alla metoder som kan ändra data utan att påverka hur data hämtas.
Följande kod är ett exempel på egenskapen AutoValidateAntiforgeryToken:
I detta exempel fungerar båda normala Index-operationerna (GET) oavsett källa, medan både Index-operationen med POST-metoden och RemoveUser-operationen som Delete-metoden kräver att klienten använder en anti-förfalskningstoken.
Anpassa relevant information
Många kanske undrar om namnet på den genererade dolda domänen kan ersättas med deras eget, och om namnet på cookien kan ändras till deras eget.
Svaret är ja, låt oss kort demonstrera:
I Startups ConfigureServices-metod, lägg till följande för att ändra standardnamnet därefter.
Obs: Den största skillnaden mellan asp.net kärna och asp.net är,Core stödjer att valideringsparametrar skickas genom att begära en header, inte för att forma former!
privat konststräng AntiforgeryTokenFieldName = "__RequestVerificationToken";
privat konststräng AntiforgeryTokenHeaderName = "RequestVerificationToken";
Du kan se källkoden:Inloggningen med hyperlänken är synlig.
Testkod:
Resultat: Försök att komma åt test1-metoden ger ett 400-fel, att komma åt test2-metoden returnerar str-parametern vi skickade, och du kan se att AutoValidateAntiforgeryToken-funktionen inte fångar upp GET-förfrågan.
(Slut)
|
Föregående:Fiddler ersätter länkar, begär vidarebefordran, omdirigerarNästa:[vänd] SQL Server SQL Count
|
Hyresvärd|
Publicerad på 2023-07-08 22:07:08
|
