Login request validation token issue

Question

I have been going through the error logs of a development project and found the following error (name changed to protect the guilty innocent)-

The provided anti-forgery token was meant for user "", but the current user is "admin".

This was not an especially difficult issue to reproduce-

1. Open the application at the login page
2. Open a second window or tab in the same browser on the same computer to the login page before logging in
3. Login in the first window (or indeed second, the order doesn't matter)
4. Attempt to login in the remaining login window

The stack trace is-

System.Web.Mvc.HttpAntiForgeryException (0x80004005): The provided anti-forgery token was meant for user "", but the current user is "admin". at System.Web.Helpers.AntiXsrf.TokenValidator.ValidateTokens(HttpContextBase httpContext, IIdentity identity, AntiForgeryToken sessionToken, AntiForgeryToken fieldToken) at System.Web.Helpers.AntiXsrf.AntiForgeryWorker.Validate(HttpContextBase httpContext) at System.Web.Helpers.AntiForgery.Validate() at System.Web.Mvc.ValidateAntiForgeryTokenAttribute.OnAuthorization(AuthorizationContext filterContext) at System.Web.Mvc.ControllerActionInvoker.InvokeAuthorizationFilters(ControllerContext controllerContext, IList`1 filters, ActionDescriptor actionDescriptor) at System.Web.Mvc.Async.AsyncControllerActionInvoker.<>c__DisplayClass25.b__1e(AsyncCallback asyncCallback, Object asyncState)

The login method signature is-

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

This is exactly the same as the signature for the method in a internet "ASP.NET MVC 4 Web Application" templated project, which indicates that Microsoft either felt the ValidateAntiForgeryToken was necessary/best practice, or simply added the attribute here because it was used everywhere else.

Obviously there is nothing I can do to handle the problem within this method as it isn't reached, the ValidateAntiForgeryToken is a pre-request filter and it is blocking the request before it reaches the controller.

I could check if the user is authenticated via Ajax before submitting the form and attempt to redirect to them if so, or simply remove the attribute.

The question is this - I understand that the token is design to prevent requests from another site (CSRF) when the user is already authenticated against your site so on that basis is it an issue to remove it from a form which by definition will be used by unauthenticated users?

Presumably the attribute in this instance is designed to mitigate malicious actors providing fake login forms for your application (although by the time the exception is thrown presumably the user has already entered his or her details which will have been recorded - but it might alert them something is wrong). Otherwise submitting incorrect credentials to the form from an external site will result in exactly the same result as on the site itself surely? I am not relying on client validation/sanitation to clean up potentially unsafe input.

Have other devs come across this issue (or do we have unusually creative users) and if so how have you resolved/mitigated it?

Update: This issue still exists in MVC5, entirely intentionally, now with the error message "The provided anti-forgery token was meant for a different claims-based user than the current user." when using default template and Identity providers. There is a relevant question and interesting answer from Microsoft Developer Evangelist and Troy's fellow PluralSight author Adam Tuliper at Anti forgery token on login page which recommends simply removing the token.

Answer 1

I've just tested this pattern on ASafaWeb with the same result (it uses the same default implementation). Here's what I believe is happening

1. Both login forms load with the same __RequestVerificationToken cookie (it's just the same one set in the same DOM) and the same __RequestVerificationToken hidden field. These tokens are keyed to an anonymous user.
2. Login form A posts with the above tokens, validates them then returns an auth cookie which is now in the browser DOM
3. Login form B posts also with the above tokens but now it's also posting with the auth cookie set from login form A as well.

The problem is that the token isn't validating in step 3 because it's keyed to an anonymous user but it's being passed in the request by an authenticated user. This is why you're seeing the error: The provided anti-forgery token was meant for user "", but the current user is "admin"

You're only having this issue because form B loaded before form A posted therefore form B is expecting to be posted by an anonymous user.

Is it an issue to remove it from a form which by definition will be used by unauthenticated users?

The predominant underlying risk that anti-forgery tokens protect against is CSRF which usually takes advantage of authenticated users due to the fact that any requests their browser can be tricked into issuing will be automatically accompanied by an auth cookie hence the action will be performed on their behalf. This risk doesn't exist on the login form because usually the user isn't authenticated and the worst CSRF case here is that a login is forged and then fails; you're not exactly transferring money on the user's behalf!

There are other advantages to the anti-forgery token though: for example it prevents brute force attacks actually executing the method and hitting the DB. You need to decide if you're less worried about this and more worried about the scenario you're encountering in your question. Either that or you need to drop down into the request pipeline somewhere and take action if an auth cookie is already present in the request before the anti-forgery validation occurs.

Frankly though, I'm not sure I see the problem; to reproduce this issue the user has to have multiple login forms open at the same time and then try logging into each in succession - is this really going to happen enough to worry about? And when it does happen, does it really matter that the second login returns a custom error page (which of course you'd do in production)? IMHO, leave the default behaviour.