Connexion de validation de la demande de jeton de problème

Question

J'ai été en passant par les journaux d'erreur d'un projet de développement et a trouvé le message d'erreur suivant (le nom a été changé pour protéger le coupable innocent)-

La lutte contre la falsification de jeton a été conçu pour l'utilisateur "", mais le courant l'utilisateur est "admin".

Ce n'était pas particulièrement difficile à reproduire-

1. Ouvrez l'application sur la page de connexion
2. Ouvrir une deuxième fenêtre ou un onglet dans le même navigateur sur le même ordinateur à la page de connexion avant de vous connecter
3. De connexion dans la première fenêtre (ou le deuxième, l'ordre n'a pas d'importance)
4. Tentative de connexion dans le reste de la fenêtre de connexion

La trace de la pile est-

Système.Web.Mvc.HttpAntiForgeryException (0x80004005): La condition anti-faux jeton a été conçu pour l'utilisateur "", mais l'utilisateur actuel est "admin". au Système.Web.Les aides.AntiXsrf.TokenValidator.ValidateTokens(HttpContextBase httpContext, l'Identité de l'identité, AntiForgeryToken sessionToken, AntiForgeryToken fieldToken) à Système.Web.Les aides.AntiXsrf.AntiForgeryWorker.Valider(HttpContextBase httpContext) au Système.Web.Les aides.AntiForgery.Valider() à Système.Web.Mvc.ValidateAntiForgeryTokenAttribute.OnAuthorization(AuthorizationContext filterContext) à Système.Web.Mvc.ControllerActionInvoker.InvokeAuthorizationFilters(ControllerContext controllerContext, IList`1 filtres, ActionDescriptor actionDescriptor) au Système.Web.Mvc.Async.AsyncControllerActionInvoker.<>c_DisplayClass25.b_1e(AsyncCallback asyncCallback, Objet asyncState)

Le login de la signature de la méthode est-

[HttpPost]
[AllowAnonymous]
[ValidateAntiForgeryToken]
public ActionResult Login(LoginModel model, string returnUrl)
{
...
}

C'est exactement la même que la signature de la méthode dans un internet "ASP.NET MVC 4 Web Application" basé sur un modèle de projet, ce qui indique que Microsoft soit senti le ValidateAntiForgeryToken était nécessaire/le meilleur de la pratique, ou simplement ajouté l'attribut ici, car il était utilisé partout ailleurs.

Évidemment, il n'y a rien que je peux faire pour traiter le problème dans cette méthode car elle n'est pas atteint, le ValidateAntiForgeryToken est un pré-filtre de requête et c'est le blocage de la demande avant qu'il n'atteigne le contrôleur.

J'ai pu vérifier si l'utilisateur est authentifié via Ajax avant de soumettre le formulaire et de tenter de le rediriger vers eux, si oui, ou tout simplement de supprimer l'attribut.

La question est-ce - que je comprends que le jeton est conçu pour empêcher les demandes à partir d'un autre site (CSRF) lorsque l'utilisateur est déjà authentifié sur votre site alors, sur cette base est-il un problème pour l'enlever à partir d'un formulaire qui, par définition, sera utilisé par des utilisateurs non authentifiés?

Sans doute l'attribut dans ce cas est conçu pour atténuer les acteurs malveillants fournissant de faux formulaires de connexion pour votre application (même si, à l'époque de l'exception est levée, vraisemblablement, l'utilisateur est déjà entré dans ses détails qui ont été enregistrés, mais il peut alerter de quelque chose qui est faux). Soumettez des informations d'identification incorrectes à la forme d'un site externe résultat sera exactement le même résultat que sur le site lui-même, dites-vous? Je ne suis pas en s'appuyant sur la validation du client/de l'assainissement pour nettoyer potentiellement dangereux d'entrée.

Avoir d'autres devs rencontré ce problème (ou ne nous ont exceptionnellement les utilisateurs créatifs) et si oui, comment avez-vous résolu/atténués il?

Mise à jour: Ce problème existe toujours dans MVC5, entièrement intentionnellement, maintenant avec le message d'erreur "La lutte contre la falsification de jeton a été conçu pour une autre basée sur les revendications de l'utilisateur que l'utilisateur actuel." lors de l'utilisation de ce modèle par défaut et de l'Identité des fournisseurs. Il y a une question pertinente et intéressante réponse de Microsoft Developer Evangelist et Troy autres PluralSight l'auteur Adam Tuliper à Anti faux jeton sur la page de login qui recommande simplement de retirer le jeton.

Answer 1

Je viens de testé ce modèle sur ASafaWeb avec le même résultat (il utilise le même défaut de mise en œuvre). Voici ce que je crois qui se passe

1. Les deux formulaires de connexion de la charge avec la même __RequestVerificationToken cookie (c'est tout de même un jeu dans le même DOM) et la même __RequestVerificationToken champ caché. Ces jetons sont conçus pour un utilisateur anonyme.
2. Formulaire de connexion à l'Un des postes ci-dessus, les jetons, valide, puis renvoie un auth cookie, qui est maintenant dans le navigateur DOM
3. Formulaire de connexion B postes aussi avec les jetons, mais maintenant, c'est également l'affichage avec l'auth cookie défini à partir d'Un formulaire de connexion ainsi.

Le problème est que le jeton n'est pas la validation de l'étape 3 car elle est associée à un utilisateur anonyme, mais il est transmis dans la requête par un utilisateur authentifié. C'est pourquoi vous voyez l'erreur: La lutte contre la falsification de jeton a été conçu pour l'utilisateur "", mais le courant d'utilisateur est "admin"

Vous êtes seul à avoir ce problème car la forme B chargé avant de former Une posté, par conséquent, le formulaire B s'attendait à être posté par un utilisateur anonyme.

Est-ce un problème pour l'enlever à partir d'un formulaire qui, par définition, sera utilisé par des utilisateurs non authentifiés?

Le principal risque sous-jacents de la lutte anti-contrefaçon des jetons de protéger contre les CSRF est qui habituellement prend avantage des utilisateurs authentifiés en raison du fait que les demandes de leur navigateur peut être dupé dans l'émission seront automatiquement accompagnés par un auth cookie d'où l'action sera réalisée en leur nom. Ce risque n'existe pas sur le formulaire de connexion parce que généralement, l'utilisateur n'est pas authentifié et le pire CSRF cas la c'est que la connexion est forgé et ne parvient pas, vous n'êtes pas exactement transférer de l'argent sur le compte de l'utilisateur!

Il ya d'autres avantages à la lutte contre le faux jeton de bien: par exemple, il empêche les attaques par force brute en fait de l'exécution de la méthode et de frapper la DB. Vous devez décider si vous êtes moins inquiet à ce sujet et plus préoccupés par le scénario que vous avez rencontré dans votre question. Soit ça, ou vous avez besoin de descendre dans le pipeline demande quelque part et prendre des mesures si un auth cookie est déjà présent dans la requête avant de l'anti-contrefaçon de validation se produit.

Franchement si je ne suis pas sûr que je vois le problème; pour reproduire ce problème, l'utilisateur doit avoir plusieurs formulaires de login ouvrir en même temps et puis essayez de vous connecter à chacun dans la succession, est - ce vraiment va arriver assez de soucis? Et quand ça arrive, est-il vraiment important que le deuxième connexion renvoie une page d'erreur personnalisée (qui, bien sûr, vous feriez dans la production)? À mon humble avis, laissez le comportement par défaut.

Answer 2

J'ai eu le même problème, je l'ai résolu en ajoutant machineKey à système.web>

<machineKey validationKey="your machine key numbers" 
decryptionKey="Your description key nuumbers" validation="SHA1" decryption="AES" />

Voici un site qui génèrent unique Machnie Clés http://www.developerfusion.com/tools/generatemachinekey/

Fonctionne très bien, je comprends que la lutte contre la Contrefaçon peut ne pas être nécessaire dans une page de Connexion, mais si quelqu'un est déterminé à pirater le site, il réconfortant de savoir que [ValidateAntiForgeryToken] est là pour contrecarrer les off.