|
|
Geplaatst op 20-02-2021 19:57:29
|
|
|
|
Om CSRF-aanvallen te voorkomen, biedt asp.net mvc de ValidateAntiForgeryToken anti-counterfeiting attack-functie, en in de nieuwe versie van het asp.net kernframework biedt Microsoft de AutoValidateAntiforgeryToken-functie, specifiek ValidateAntiForgeryToken en AutoValidateAntiforgeryToken Wat het verschil is, legt dit artikel in detail uit.
CSRF-concept
CSRF Cross-Site Request Forgery, net als XSS-aanvallen, is extreem schadelijk, je kunt het zo begrijpen: de aanvaller steelt je identiteit en stuurt een kwaadaardig verzoek in jouw naam, wat volledig legitiem is voor de server, maar een handeling uitvoert die de aanvaller verwacht, zoals het versturen van e-mails en berichten op jouw naam, het stelen van je account, het toevoegen van systeembeheerders of zelfs het kopen van goederen. Virtuele valutatransfers, enzovoort. Web A is een website met een CSRF-kwetsbaarheid, Web B is een kwaadaardige website gebouwd door een aanvaller, en gebruiker C is een legitieme gebruiker van Web A.
ASP.NET MVC tegen CSRF-aanvallen
Op de weergavepagina gebruik je @Html.AntiForgeryToken() om een tag toe te voegen, en wanneer de gebruiker de pagina opent, genereert de backend automatisch een verborgen html-code met de tag, als volgt:
<invoernaam="__RequestVerificationToken" type="verborgen" value="CfDJ8FBn4LzSYglJpE6Q0fWvZ8WDMTgwK49lDU1XGuP5-5j4JlSCML_IDOO3XDL5EOyI_mS2Ux7lLSfI7ASQnIIxo2ScEJvnABf9v51TUZl_iM2S63zuiPK4lcXRPa_KUUDbK-LS4HD16pJusFRppj-dEGc" />
ValidateAntiForgeryToken en AutoValidateAntiforgeryToken zijn verschillend
AutoValidateAntiforgeryTokenAuthorizationFilter erft de ValidateAntiforgeryTokenAuthorizationFilter, maar herschrijft alleen de ShouldValidate-methode erin.
AutoValidateAntiforgeryToken-eigenschap die validatie veroorzaakt van anti-vervalsingstokens voor alle onveilige HTTP-methoden.HTTP-methoden anders dan GET, HEAD, OPTIONS en TRACE vereisen allemaal een anti-vervalstingstoken。 Dit kan worden toegepast als een globaal filter om standaard de validatie van anti-vervalsingstokens van de applicatie te activeren.
De hyperlink-login is zichtbaar.
AutoValidateAntiforgeryTokenAttribute valideert de aanroep naar AutoValidateAntiforgeryTokenAuthorizationFilter, die erft van ValidateAntiforgeryTokenAuthorizationFilter,De ShouldValidate-methode is herschreven; true teruggeven betekent dat het gevalideerd moet worden, en returning false wordt niet gevalideerd, zoals getoond in de onderstaande figuur:
Analyseer de broncode:
AutoValidateAntiforgeryTokenAttribute maakt het mogelijk om anti-vervalsingstokenvalidatie wereldwijd toe te passen op alle onveilige methoden, zoals POST, PUT, PATCH en DELETE. Je hoeft dus niet de eigenschap [ValidateAntiForgeryToken] toe te voegen aan elke actie die het vereist.
Om het te gebruiken, voeg je de volgende code toe aan de Startup-klasse methode van je ConfigureServices:
Als je anti-vervalsingsauthenticatie wilt negeren, kun je [NegerAntiforgeryTokenSchrijf toe aan de actie.
Soms moet je meerdere verzoeken taggen op een controller, terwijl je ook verzoeken hebt die niet hoeven te worden vervalst, zoals verschillende GET-gebaseerde bewerkingen. Er zijn verschillende hulpmiddelen die je kunt gebruiken om het proces gemakkelijker en comfortabeler te maken. De eerste is de eigenschap AutoValidateAntiforgeryToken. Het gedraagt zich als de eigenschap ValidateAntiForgeryToken. Het negeert echter automatisch de acties die worden aangeroepen door methoden die voor gegevensopvraging zijn ontworpen: GET, HEAD, OPTIONS en TRACE. Dit stelt je in staat om snel en eenvoudig anti-namaakmethoden toe te voegen aan alle methoden die data kunnen wijzigen zonder de manier waarop data wordt opgehaald te beïnvloeden.
De volgende code is een voorbeeld van de AutoValidateAntiforgeryToken-eigenschap:
In dit voorbeeld werken beide normale Index-operaties (GET) ongeacht de bron, terwijl zowel de Index-operatie met de POST-methode als de RemoveUser-operatie als de Delete-methode vereisen dat de client een anti-vervalstingstoken gebruikt.
Pas de relevante informatie aan
Veel mensen vragen zich misschien af of de naam van het gegenereerde verborgen domein vervangen kan worden door hun eigen domein, en of de naam van de cookie kan worden veranderd in hun eigen domein.
Het antwoord is ja, laten we het kort demonstreren:
Voeg in de ConfigureServices-methode van de Startup het volgende toe om de standaardnaam dienovereenkomstig aan te passen.
Opmerking: Het grootste verschil tussen asp.net core en asp.net is,Core ondersteunt het doorgeven van validatieparameters door een header aan te vragen, geen vormen vormen!
private const string AntiforgeryTokenFieldName = "__RequestVerificationToken";
private const string AntiforgeryTokenHeaderName = "RequestVerificationToken";
Je kunt de broncode bekijken:De hyperlink-login is zichtbaar.
Testcode:
Resultaat: Proberen toegang te krijgen tot de test1-methode geeft een 400-foutmelding, toegang tot de test2-methode geeft de str-parameter die we hebben doorgegeven, en je kunt zien dat de AutoValidateAntiforgeryToken-functie het GET-verzoek niet onderschept.
(Einde)
|
Vorig:Fiddler vervangt links, vraagt doorstuur-redirects aanVolgend:[draait] SQL Server SQL Count
|
Huisbaas|
Geplaatst op 08-07-2023 22:07:08
|
