aspnetcore: Apparently Random Error: "Antiforgery token validation failed. The antiforgery cookie token and request token do not match."

We’ve been experiencing this problem for several years in a production application on ASP.NET MVC 5 (though similar anti-forgery mechanism to ASP.NET Core). Our application has a few components that are mini-single-page-applications. So, there’s a lot of requests via JavaScript that we do that include anti-forgery protection. We’ve been able to prevent anti-forgery errors by introducing a couple of changes:

1. Disable HTTP caching on HTML views that are returned to the browser - If the page was cached, the user could hit back and be served a page with a state form token that no longer matches the cookie. Our application is behind authentication and we do caching at many other levels (HTML fragments/views, data layers, etc) so full HTTP caching of a page doesn’t make sense for us anyways.
2. Detect logging in/out of multiple tabs and clearing cookies in the same browser session - If a user had a stale anti-forger token on a page but logged out with a separate tab, cleared their cookies, and logged back in with another tab, they had the possibility of using that old tab with the stale anti-forgery token. We prevented this from happening by allowing the tabs to communicate when loaded (e.g. via localStorage session events or using the Broadcast Channel API) and show a message on the “stale” tab. A lot of sites do this similar pattern (e.g. GitHub, AWS Console, etc). This reduced a large majority of our problems.
3. Prevent form submission double-clicking - This helped anti-forgery errors caused by double-form submissions on pages like our login if the anti-forgery token happened to be re-generated once logged in.

Although this fixed most of our problems, we still have had consistent anti-forgery problems from some of our users. We have a heartbeat-like request that sends useful information for aggregating/reporting later on in the user interface. This heartbeat-like request would continuously fail for certain users meaning that their data was lost and couldn’t be reported on. Thankfully, the anti-forgery error was transparent to them but it meant a discrepancy in data for reporting.

In a recent investigation back into this problem, I found some interesting revelation in our logs:

1. When the specific users were having problems some of their heartbeat-like requests were being accepted and validated by our servers but some were failing with anti-forgery mismatch exceptions.
2. When the users that experienced anti-forgery problems first started work in the day, our logs would show concurrent requests from them with the referrer empty.

Here’s what this is caused by:

1. The user logs into the application with an authentication cookie.
2. The user changes their browser setting to Open a specific page or set of pages on startup (e.g. in Chrome).
3. They set multiple pages of our application in that list (e.g. /apples and /bananas).
4. They’re done for the day and close their browser.
5. The __RequestVerificationToken cookie is cleared because it’s only alive for as long as the browser’s session.
6. The .ASPXAUTH cookie is not cleared because it has a default expiration of 1 year.
7. The next time the user launches their browser, /apples and /bananas are launched concurrently in our app. This could also be accomplished just by doing something like middle-clicking on a tab more than once, but the pattern seems to fit since this causes the referrer to be empty. Both of those pages render a form with the anti-forgery token (e.g. @Html.AntiForgeryToken()).
8. Both requests generate a new __RequestVerificationToken cookie and send it as part of the response because the request does not have a __RequestVerificationToken. When the form’s token is generated during the request, it’s for the unique cookie token per-request.
9. The browser chooses the last cookie to be saved, thus causing the first tab’s form token to be invalidated because it no longer matches the cookie when the tab was loaded. When our heartbeat-like requests are sent from the “bad” tab, anti-forgery exceptions are thrown server-side.

I have some ideas to work around this, though I haven’t fully thought them through:

1. Seed the cookie token based on the user’s current authentication context (e.g. in our case their internal user session id in our database). Anti-forgery (at least in MVC 5) doesn’t have a way to hook into this.
2. Change the anti-forgery token to be the length of the user’s authentication session when it’s first created. This would prevent it from being cleared in the first place. I’m not a security expert, so I’m not sure if this is a good idea.
3. Somehow detect the form anti-forgery token changes per-tab like we do with stale sessions. Obviously, the form tokens are always unique per-form… so I’m not sure how detecting a “change” could help here.
4. Use a mechanism outside of our web servers (e.g. Redis) to prevent generating the anti-forgery token more than once. This seems expensive because there’s no way to hook into when ASP.NET generates a new anti-forgery token.

Does anyone else have any ideas on how we could solve this problem? @wessleym I’m not entirely sure if any of this can help solve your problem but I hope it may be able to provide some insight.

If it’s worth something, iv’e been facing this issue since ASP.NET MVC 5. As it is described it happens 1 on 1000 times apparently random. No matter how hard I try, I still cannot reproduce this behaviour

We’re seeing the same strange behavior. Once in a while, a user will get a the exception: “Antiforgery token validation failed. The antiforgery cookie token and request token do not match.” when logging in to the website.

About the following question earlier:

Hi,

I’ve been looking at the issue you mentioned. There are a few things a user could do to cause this. So here are a few questions:

* Does the site allow HTTP and HTTPS traffic? (That will be one thing)

* Users can have a tab open, login with a user in another tab and then when they try to use the original tab antiforgery will fail (due to the cookie changing)

We support only HTTPS. For the given situation in bullet 2, a different error is thrown, so according to me, that’s an entirely different issue: “The provided antiforgery token was meant for a different claims-based user than the current user.” I think this is by design, and we accept that.

It seems to happen after a while after the user session and login have timed out, and the user tries to login again, although I’m unable to consistently reproduce the issue (the login/session timeout serverside doesn’t seem to be the only cause).

Regarding our solution We used the examples on https://docs.microsoft.com/en-us/aspnet/core/security/anti-request-forgery?view=aspnetcore-2.1 We use the header option in the AddAntiforgery call: services.AddAntiforgery(options => options.HeaderName = "X-CSRF-TOKEN");

We globally registered the AutoValidateAntiForgeryToken filter: services.AddMvc(options => options.Filters.Add(new AutoValidateAntiforgeryTokenAttribute()));

We also include an AntiForgeryToken in a cookie, according to the example in the webpage above:" context.Response.Cookies.Append("CSRF-TOKEN", tokens.RequestToken, new Microsoft.AspNetCore.Http.CookieOptions { HttpOnly = false, Secure = true });

This token is read by clientside javascript and used in AJAX requests by setting the X-CSRF-TOKEN header.

Hoping to at least find a root cause for when this happens (so something reproducable), since then, we can figure out how to prevent this from happening.

@mkArtakMSFT, I appreciate your time and your stance. But as my original post stated, this problem is not easily reproducible. It seems to happen randomly. I wish I could supply projects, but not only are the projects owned by my paying clients, but they also reliably work in my testing. It’s only in production, maybe every 1,000 requests, that they fail. So while this GitHub issue may be closed, the real-world issue continues. @javiercn, while I don’t think this my problem since I’m not generally seeing requests so close together and since my page load times are pretty low, would you be able to supply documentation about this? “Another situation where this might occur is when a user opens multiple tabs simultaneously (specially if the page takes time to load) where the requests go on simultaneously and the responses are sent concurrently (in which case the two cookies get set at the same time and one of that will cause one of them to fail) but eventually the browser will settle for the last cookie in the response. (Note that this is an unavoidable race condition that happens when there’s no cookie and the user opens multiple tabs simultaneously).”

Pfff. I’m investigating a maybe similar issue with this. At first it seemed random, later it seems it only happens when having Chrome DevTools open together with “Enable JavaScript source maps” enabled, INCLUDING a 404 generated by a ‘custom’ middleware.

I’ll try to explain it a clearly a possible what our situation is, as I THINK it is, but I’m not sure this situation is ‘fixable’ in ASP.NET Core, or that it has to be fixed by excluding .map files, or not sending cookie updates etc.

1. We have enabled AutoValidateAntiforgeryTokenAttribute:

services.AddMvc(options =>
{
	options.Filters.Add(new AutoValidateAntiforgeryTokenAttribute());
})

1. We use UseStatusCodePagesWithReExecute, nothing really special inside this ErrorController:

app.UseStatusCodePagesWithReExecute("/Error/InvalidRequestWithStatusCode", "?statusCode={0}");

But I guess because it is all processed through a real Controller it will alter the Cookie and messing up the expected and send Token.

1. We open a site with a form, which includes a .min.js file, with a source mapping (//# sourceMappingURL=jsfile.min.js.map) in it

2. Chrome WILL AUTOMATICALLY download this source mapping file, you WONT see it in the Network tab… But it WILL alter your cookie of the current page!! Which will ‘invalidate’ the expected one.

I really hope this is the problem you all might be having so that we have found the underlying vague issue and can move on 😃

I used Charles proxy, breakpoints and cURL to reproduce this issue. I downloaded a HTTP2 enabled cURL build for Windows: https://winampplugins.co.uk/curl/ (No idea why it is hosted on a winamp related site)

Path to reproduce:

1. Open site with form
2. Execute curl command like this (replace your URL and ASPSESSION, see browser cookies):

curl "https://localhost:44331/lib/parsley.js/parsley.min.js.map" -H "cache-control: no-cache" -H "user-agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/71.0.3578.10 Safari/537.36" -H "accept-encoding: gzip, deflate, br" -H "accept-language: en-US,en;q=0.9,nl;q=0.8" -H "cookie: ASPSESSIONID_COOKIE1=VALUE1" -H "cookie: ASPSESSIONID_COOKIE2=VALUE2" -H "cookie: ASPSESSIONID_COOKIE3=VALUE3" -H "cookie: ASPSESSIONID_COOKIE4=VALUE4" --insecure -H "Accept:" -IL

1. Replace token cookie value from the cURL output in browser (which is what Chrome will do without you knowing), see set-cookie: .AspNetCore.Antiforgery.PLlJ9KQhgiA=TAKETHISPART
2. Post form
3. Receive 400 error:
4. In log something like this:

2018-10-23 14:36:08.7609|1|INFO|Microsoft.AspNetCore.Hosting.Internal.WebHost|Request starting HTTP/1.1 POST http://localhost:44331/YourController/YourAction application/x-www-form-urlencoded 317 
2018-10-23 14:36:08.7775|1|INFO|Microsoft.AspNetCore.Mvc.Internal.ControllerActionInvoker|Route matched with {action = "YourAction", controller = "Your"}. Executing action YourApplication.Controllers.YourController.YourAction (YourApplication) 
2018-10-23 14:36:08.7775|1|INFO|Microsoft.AspNetCore.Authorization.DefaultAuthorizationService|Authorization was successful. 
2018-10-23 14:36:08.7905|1|INFO|Microsoft.AspNetCore.Mvc.ViewFeatures.Internal.AutoValidateAntiforgeryTokenAuthorizationFilter|Antiforgery token validation failed. The antiforgery cookie token and request token do not match. Microsoft.AspNetCore.Antiforgery.AntiforgeryValidationException: The antiforgery cookie token and request token do not match.
   at Microsoft.AspNetCore.Antiforgery.Internal.DefaultAntiforgery.ValidateTokens(HttpContext httpContext, AntiforgeryTokenSet antiforgeryTokenSet)
   at Microsoft.AspNetCore.Antiforgery.Internal.DefaultAntiforgery.ValidateRequestAsync(HttpContext httpContext)
   at Microsoft.AspNetCore.Mvc.ViewFeatures.Internal.ValidateAntiforgeryTokenAuthorizationFilter.OnAuthorizationAsync(AuthorizationFilterContext context)
2018-10-23 14:36:08.7905|3|INFO|Microsoft.AspNetCore.Mvc.Internal.ControllerActionInvoker|Authorization failed for the request at filter 'Microsoft.AspNetCore.Mvc.ViewFeatures.Internal.AutoValidateAntiforgeryTokenAuthorizationFilter'. 
2018-10-23 14:36:08.7905|1|INFO|Microsoft.AspNetCore.Mvc.StatusCodeResult|Executing HttpStatusCodeResult, setting HTTP status code 400 
2018-10-23 14:36:08.7905|2|INFO|Microsoft.AspNetCore.Mvc.Internal.ControllerActionInvoker|Executed action YourApplication.Controllers.YourController.YourAction (YourApplication) in 18.7502ms 
2018-10-23 14:36:08.8039|1|INFO|Microsoft.AspNetCore.Mvc.Internal.ControllerActionInvoker|Route matched with {action = "InvalidRequestWithStatusCode", controller = "Error"}. Executing action YourApplication.Controllers.ErrorController.InvalidRequestWithStatusCode (YourApplication) 
2018-10-23 14:36:08.8039|1|INFO|Microsoft.AspNetCore.Mvc.ViewFeatures.Internal.AutoValidateAntiforgeryTokenAuthorizationFilter|Antiforgery token validation failed. The antiforgery cookie token and request token do not match. Microsoft.AspNetCore.Antiforgery.AntiforgeryValidationException: The antiforgery cookie token and request token do not match.
   at Microsoft.AspNetCore.Antiforgery.Internal.DefaultAntiforgery.ValidateTokens(HttpContext httpContext, AntiforgeryTokenSet antiforgeryTokenSet)
   at Microsoft.AspNetCore.Antiforgery.Internal.DefaultAntiforgery.ValidateRequestAsync(HttpContext httpContext)
   at Microsoft.AspNetCore.Mvc.ViewFeatures.Internal.ValidateAntiforgeryTokenAuthorizationFilter.OnAuthorizationAsync(AuthorizationFilterContext context)
2018-10-23 14:36:08.8039|3|INFO|Microsoft.AspNetCore.Mvc.Internal.ControllerActionInvoker|Authorization failed for the request at filter 'Microsoft.AspNetCore.Mvc.ViewFeatures.Internal.AutoValidateAntiforgeryTokenAuthorizationFilter'. 
2018-10-23 14:36:08.8268|1|INFO|Microsoft.AspNetCore.Mvc.StatusCodeResult|Executing HttpStatusCodeResult, setting HTTP status code 400 
2018-10-23 14:36:08.8268|2|INFO|Microsoft.AspNetCore.Mvc.Internal.ControllerActionInvoker|Executed action YourApplication.Controllers.ErrorController.InvalidRequestWithStatusCode (YourApplication) in 20.3958ms 

Very small update. The screenshot on step 5 now ‘works’ (the right page/view is shown) because I added [IgnoreAntiforgeryToken] to the InvalidRequestWithStatusCode action… Ofcourse, when trying to access anything with a bad token it indeed does not work 😃

Hi,

I’ve been looking at the issue you mentioned. There are a few things a user could do to cause this. So here are a few questions:

• Does the site allow HTTP and HTTPS traffic? (That will be one thing)
• Users can have a tab open, login with a user in another tab and then when they try to use the original tab antiforgery will fail (due to the cookie changing)