|
|
Publié sur 20/02/2021 19:57:29
|
|
|
|
Pour prévenir les attaques CSRF, asp.net mvc propose la fonctionnalité anti-contrefaçon ValidateAntiForgeryToken, et dans la nouvelle version du cadre central asp.net, Microsoft propose la fonctionnalité AutoValidateAntiforgeryToken, spécifiquement ValidateAntiForgeryToken et AutoValidateAntiforgeryToken Quelle est la différence, cet article l’expliquera en détail.
Concept CSRF
La falsification de requêtes inter-sites CSRF, comme les attaques XSS, est extrêmement nuisible, vous pouvez la comprendre ainsi : l’attaquant vole votre identité et envoie une requête malveillante en votre nom, ce qui est totalement légitime pour le serveur, mais accomplit une action attendue, comme envoyer des e-mails et des messages à votre nom, voler votre compte, ajouter des administrateurs système, voire acheter des biens, Transferts de monnaie virtuelle, etc. Le Web A est un site web avec une vulnérabilité CSRF, le Web B est un site malveillant construit par un attaquant, et l’utilisateur C est un utilisateur légitime du Web A.
ASP.NET MVC contre les attaques de la CSRF
Sur la page de vue, utilisez @Html.AntiForgeryToken() pour ajouter un tag, et lorsque l’utilisateur accède à la page, le backend génère automatiquement un code HTML caché avec le tag, comme suit :
<nom d’entrée="__RequestVerificationToken » type="caché » value="CfDJ8FBn4LzSYglJpE6Q0fWvZ8WDMTgwK49lDU1XGuP5-5j4JlSCML_IDOO3XDL5EOyI_mS2Ux7lLSfI7ASQnIIxo2ScEJvnABf9v51TUZl_iM2S63zuiPK4lcXRPa_KUUDbK-LS4HD16pJusFRppj-dEGc » />
ValidateAntiForgeryToken et AutoValidateAntiforgeryToken sont différents
AutoValidateAntiforgeryTokenAuthorizationFilter hérite du ValidateAntiforgeryTokenAuthorizationFilter, mais ne réécrit que la méthode ShouldValidate dans celui-ci.
AutoValidateAntiforgeryToken qui permet la validation des jetons anti-contrefaçon pour toutes les méthodes HTTP non sécurisées.Les méthodes HTTP autres que GET, HEAD, OPTIONS et TRACE nécessitent toutes un jeton anti-contrefaçon。 Cela peut être appliqué comme un filtre global pour déclencher par défaut la validation anti-contrefaçon de token de l’application.
La connexion hyperlientérée est visible.
AutoValidateAntiforgeryTokenAttribute valide l’appel à AutoValidateAntiforgeryTokenAuthorizationFilter, qui hérite de ValidateAntiforgeryTokenAuthorizationFilter,La méthode ShouldValidate a été réécrite, retourner true signifie qu’elle doit être validée, et retourner false ne sera pas validée, comme montré dans la figure ci-dessous :
Analysez le code source :
AutoValidateAntiforgeryTokenAttribute permet d’appliquer globalement la validation anti-contrefaçon des jetons à toutes les méthodes non sécurisées, telles que POST, PUT, PATCH et DELETE. Vous n’avez donc pas besoin d’ajouter la propriété [ValidateAntiForgeryToken] à chaque action qui l’exige.
Pour l’utiliser, ajoutez le code suivant à la méthode de la classe Démarrage de votre ConfigureServices :
Si vous devez ignorer l’authentification anti-contrefaçon, vous pouvez ajouter [IgnorerAntifauxTokenattribue à l’action.
Parfois, vous devrez taguer plusieurs requêtes sur un contrôleur tout en nécessitant d’autres requêtes qui n’ont pas besoin d’être forgées, comme diverses opérations basées sur GET. Il existe plusieurs outils que vous pouvez utiliser pour rendre le processus plus pratique et confortable. La première est la propriété AutoValidateAntiforgeryToken. Il se comporte comme la propriété ValidateAntiForgeryToken. Cependant, il ignorera automatiquement les actions appelées par les méthodes conçues pour la récupération de données : GET, HEAD, OPTIONS et TRACE. Cela vous permet d’ajouter rapidement et facilement des méthodes anti-contrefaçon à toutes les méthodes pouvant modifier les données sans affecter la manière dont les données sont récupérées.
Le code suivant est un exemple de la propriété AutoValidateAntiforgeryToken :
Dans cet exemple, les deux opérations normales Index (GET) fonctionneront quelle que soit la source, tandis que l’opération Index avec la méthode POST et l’opération RemoveUser comme méthode Delete exigeront que le client utilise un jeton anti-contrefaçon.
Personnalisez les informations pertinentes
Beaucoup de gens peuvent se demander si le nom du domaine caché généré peut être remplacé par le leur, et si le nom du cookie peut être changé par le leur.
La réponse est oui, montrons brièvement :
Dans la méthode ConfigureServices du démarrage, ajoutez ce qui suit pour modifier le nom par défaut en conséquence.
Note : La plus grande différence entre asp.net cœur et asp.net est :Core supporte la transmission des paramètres de validation en demandant un en-tête, pas pour former des formulaires !
chaîne de const privée AntiforgeryTokenFieldName = « __RequestVerificationToken » ;
chaîne const privée AntiforgeryTokenHeaderName = « RequestVerificationToken » ;
Vous pouvez consulter le code source :La connexion hyperlientérée est visible.
Code de test :
Résultat : En essayant d’accéder à la méthode test1, une erreur 400, accéder à la méthode test2 renvoie le paramètre str que nous avons passé, et vous pouvez voir que la fonctionnalité AutoValidateAntiforgeryToken n’intercepte pas la requête GET.
(Fin)
|
Précédent:Fiddler remplace les liens, demande des redirectionsProchain:[tourne] SQL Server SQL Count
|
Propriétaire|
Publié sur 08/07/2023 22:07:08
|
