Question:
Dois-je utiliser AntiForgeryToken sous toutes les formes, même la connexion et l'inscription?
Artiom Chilaru
2011-02-12 03:08:46 UTC
view on stackexchange narkive permalink

Je gère un site assez volumineux avec des milliers de visites chaque jour et une base d'utilisateurs assez importante. Depuis que j'ai commencé à migrer vers MVC 3, j'ai mis l'AntiForgeryToken sous un certain nombre de formes, qui modifient les données protégées, etc.

D'autres formes, comme la connexion et l'enregistrement utilisent également l'AntiForgeryToken maintenant, mais Je commence à douter de leur besoin là-bas, pour plusieurs raisons ...

Le formulaire de connexion demande à l'affiche de connaître les informations d'identification correctes. Je ne peux pas vraiment penser à une quelconque manière dont une attaque CSRF pourrait bénéficier ici, surtout si je vérifie que la requête provient du même hôte (en vérifiant l'en-tête Referer).

Le jeton AntiForgeryToken génère des valeurs différentes à chaque fois la page est chargée. Si j'ai deux onglets ouverts avec la page de connexion et que j'essaye de les publier, le premier se chargera avec succès. La seconde échouera avec une AntiForgeryTokenException (commencez par charger les deux pages, puis essayez de les publier). Avec des pages plus sécurisées - c'est évidemment un mal nécessaire, avec les pages de connexion - semble exagéré, et ne demande que des problèmes.

Il y a peut-être d'autres raisons pour lesquelles on devrait utiliser ou non le jeton dans certaines formes. Ai-je raison de supposer que l'utilisation du jeton dans chaque formulaire de publication est exagérée, et si tel est le cas, quels types de formulaires en bénéficieraient et lesquels n'en bénéficieraient certainement pas ?

PS Cette question est également posée sur StackOverflow, mais je ne suis pas entièrement convaincu. J'ai pensé le poser ici, pour plus de couverture sécurité

Y a-t-il eu une mise à jour de cette question? Concernant le problème avec plusieurs pages de connexion simultanées soumises? Ma solution actuelle consiste à supprimer le jeton anti-falsification de la page de connexion.
Je ne pense plus que cela devrait être un problème. J'ai le jeton anti-contrefaçon sur notre page de connexion, et ce n'est plus un problème.
Je me suis également assuré que mon web.config a une machineKey spécifiée, ce qui a exclu un certain nombre de problèmes que j'avais initialement
Deux réponses:
#1
+73
D.W.
2011-02-12 08:32:14 UTC
view on stackexchange narkive permalink

Oui, il est important d'inclure des jetons anti-falsification pour les pages de connexion.

Pourquoi? En raison du potentiel d'attaques "login CSRF". Dans une attaque CSRF de connexion, l'attaquant connecte la victime au site cible avec le compte de l'attaquant. Considérez, par exemple, une attaque contre Alice, qui est un utilisateur de Paypal, par un attaquant diabolique Evelyn. Si Paypal n'a pas protégé ses pages de connexion contre les attaques CSRF (par exemple, avec un jeton anti-contrefaçon), alors l'attaquant peut silencieusement connecter le navigateur d'Alice au compte d'Evelyn sur Paypal. Alice est redirigée vers le site Web de Paypal et Alice est connectée, mais connectée en tant qu'Evelyn. Supposons qu'Alice clique ensuite sur la page pour lier sa carte de crédit à son compte Paypal, et entre son numéro de carte de crédit. Alice pense qu'elle associe sa carte de crédit à son compte Paypal, mais en fait elle l'a liée au compte d'Evelyn. Maintenant, Evelyn peut acheter des choses et les faire payer sur la carte de crédit d'Alice. Oups. C'est subtil et un peu obscur, mais suffisamment sérieux pour que vous incluiez des jetons anti-contrefaçon pour la cible d'action de formulaire utilisée pour vous connecter. Consultez cet article pour plus de détails et quelques exemples concrets vulnérabilités.

Quand est-il possible de supprimer le jeton anti-contrefaçon? En général, si la cible est une URL et que l'accès à cette URL n'a aucun effet secondaire, vous n'avez pas besoin d'inclure un jeton anti-contrefaçon dans cette URL.

La règle de base approximative est la suivante: incluez un jeton anti-falsification dans toutes les requêtes POST, mais vous n'en avez pas besoin pour les requêtes GET. Cependant, cette règle empirique approximative est une approximation très grossière. Il suppose que les requêtes GET seront toutes sans effets secondaires. Dans une application Web bien conçue, cela devrait être le cas, espérons-le, mais dans la pratique, les concepteurs d'applications Web ne suivent parfois pas cette directive et implémentent des gestionnaires GET qui ont un effet secondaire (c'est une mauvaise idée, mais ce n'est pas rare) . C'est pourquoi je suggère une directive basée sur le fait que la demande aura un effet secondaire sur l'état de l'application Web ou non, au lieu de basée sur GET vs POST.

Je vois ... Je suppose que cela a du sens. La seule chose qui m'inquiète est de rendre les utilisateurs ennuyés par le fait que s'ils ont deux formulaires ouverts en même temps et qu'ils essaient de les publier, l'un d'eux échouera probablement à la validation :(
+1, niice. CSRF-twist sur la fixation de la vieille session ... Beau papier aussi, btw.
N'y a-t-il pas de solution à l'erreur reçue lorsque l'utilisateur se connecte à partir de deux onglets?
@AntonAnsgar, à l'aide d'un jeton CSRF ne signifie pas qu'il doit y avoir une erreur lorsque l'utilisateur se connecte à partir de deux onglets. Si vous obtenez une telle erreur, utilisez une meilleure implémentation de jeton CSRF.
Merci. L'utilisateur ouvre la page de connexion sur deux onglets. Se connecte à partir de l'un, va à l'autre et essaie de se reconnecter, l'application lève une exception. "System.Web.Mvc.HttpAntiForgeryException: Le jeton anti-contrefaçon fourni était destiné à l'utilisateur" ", mais l'utilisateur actuel est connecté@user" Ceci est dans asp.net mvc 4. J'utilise [ValidateAntiForgeryToken]
Ai-je raison de penser que le paramètre - AntiForgeryConfig.SuppressIdentityHeuristicChecks = true comme mentionné dans cet article http://stackoverflow.com/questions/14970102/anti-forgery-token-is-meant-for-user-but-the-current-user-is-username vous laisserait effectivement de nouveau ouvert à l'attaque de style evelyn?
@ChrisNevill, Je ne sais pas - on dirait que vous devriez poser une question distincte à ce sujet.
Quelqu'un peut-il expliquer ce que signifie cette phrase?"Quand est-il possible de supprimer le jeton anti-contrefaçon? En général, si la cible est une URL et que l'accès à cette URL n'a pas d'effets secondaires, vous n'avez pas besoin d'inclure le jeton anti-contrefaçon dans cette URL"
@Ned, peut-être pourriez-vous poser une nouvelle question en utilisant le bouton «Poser une question» en haut à droite?Vous pouvez créer un lien vers ce post pour le contexte.Je vous suggère de décrire les parties que vous comprenez et ce sur quoi vous êtes particulièrement confus, et de nous aider à comprendre votre niveau actuel de compréhension et pourquoi cela ne vous semble pas clair, dans votre question.
Merci d'avoir expliqué la bonne direction, @D.W.J'ai créé un nouveau message: https://security.stackexchange.com/questions/204041/when-is-it-okay-not-to-use-anti-forgery-token-in-login-page
#2
+2
Steve
2011-02-12 07:59:25 UTC
view on stackexchange narkive permalink

Là où il peut être nécessaire d'avoir le jeton sur une page de connexion, c'est lorsque vous devez empêcher quelqu'un de vous connecter de manière malveillante au site avec des informations d'identification particulières. Je peux voir que c'est le cas si quelqu'un est accusé de quelque chose qui nécessite une connexion avec un utilisateur particulier. Cela étant dit, c'est un peu un exemple artificiel.

Pas si artificiel ... Voir la réponse d'@D.W.


Ce Q&R a été automatiquement traduit de la langue anglaise.Le contenu original est disponible sur stackexchange, que nous remercions pour la licence cc by-sa 2.0 sous laquelle il est distribué.
Loading...