Intermittent error thrown, "A required anti-forgery token was not supplied or was invalid."

Question

I'm occasionally getting this error during normal use, and I've not found a way to stop it without removing the attribute that requires the token, which I'd rather not do.

I've gotten this bug during my own testing (but seemingly randomly) and I know from my logging that actual logged-in users are getting it as well.

Does anyone know what would cause the antiforgerytoken system to break (other than a real attack), and how I could fix this without opening up a security hole in my forms?

Thanks!

Incus

Not familiar with MVC2, but if it's a rare occurrence, I would suspect that the token is expiring between the time the user loads the page, and submits the form. – Decrepit

mark - i think that really could be it. you should post that as an answer in case that turns out to be the answer. it's not a solution - but it could be the problem. how could I handle an expiring token? how long does it take to expire? – Incus

The RequestVerificationToken_Lw cookie expires at the end of the session when tested using MVC3 and Firefox. I'd like to find a way to force a page reload to refresh the cookie rather than kicking out an error. – Ladd

Answer 1

Here's a portion of my answer to a similar question:

Machine Key and Cookies: this issue is ugly, easy to spot (causes exceptions), but not very intuitive. The validation cookies and tokens are encoded and decoded using a unique "machine key". This means that if you have a server farm, or change your server, your cookie will no longer be valid. Closing your browser fixes the issue (because the cookie is a session cookie). However, some people leave their browser windows open in the background for a long time!
The solution is to set a "machine key" in your config file. This will tell MVC to use the same key on all servers, ensuring that the cookie will be decryptable everywhere.

Please note: if a user keeps any browser window open, even AFTER you change your machine key, they will continue to get these error messages! They MUST close the window (to clear the session-cookie) in order to access your website again.

Hardworking

This is the same scenario that I have, but I'm already using the machine key in my web.config. The other thought I have, is that the user has a cookie for the "Remember Me" feature that is non-expiring. Is it possible that this non-expiring cookie is kind of tied to the anti-forgery token/requestverification cookie, when that one IS expiring, thus being different from the "Remember Me" cookie? – Mentalism

I only have a single machine and I get this error every few tries – Stitching

Answer 2

One thing to make sure is to have the same machine key token for all requests. If you don't have this and your application pool recycles, subsequent POSTs with old cookies cause this error.

Another cause is when somebody has the privacy settings way high and thus blocking cookies. For example, in Internet Explorer from the Privacy tab if the settings are set to High or Block All Cookies you would get this error.

Turbofan

Was getting the issue in Firefox. Couldn't work out why - turns out all cookies were disabled for some reason. My theory is that I had them disabled in Firebug (which I then uninstalled), and this setting remained. – Nealson

Answer 3

Read the section here on limitations

prevent cross site request forgery

Cuprum

No it's all set up correctly. The error happens rarely, once a week or so and occasionally during heavy testing. – Incus

the only think i saw in there that's any different from what i've implemented is, they show this: <% using(Html.Form("UserProfile", "SubmitUpdate")) { %> <%= Html.AntiForgeryToken() %> <!-- rest of form goes here --> <% } %> while i commonly implemented this: <% using(Html.Form("UserProfile", "SubmitUpdate")) { %> <!-- rest of form goes here --> <%= Html.AntiForgeryToken() %> <% } %> since this is a form post, i didn't think it would matter, and i still don't. but at this point i'll change anything to make it work. – Incus

stackoverflow should allow code blocks in comments - anyway the point is that i had the token field at the end instead of at the beginning of the form. now it's at the beginning. – Incus

Answer 4

Not sure if this will help but I found that when using Internet Explorer I would get this error whenever there was an underscore '_' inside the subdomain... however not on Firefox.

Still looking for a solution or reasoning.

Bevbevan

Thank you ioSamurai! I'd never have thought underscores to be the culprit. – Lineal

Answer 5

Make sure that your ~/Web.config has a <machineKey> section and that you're setting the key from within that section. The anti-XSRF system requires this to be present.

Bollworm

I've already done this during my last attempt to fix this problem. It didn't help, but theoretically this was a necessary step. Thanks – Incus

If you have access to your machine's event log, can you check it for any entries that are occurring at around the same time as the anti-XSRF invalid exception? For example, do these happen immediately after an AppDomain restart, etc.? – Bollworm

I'll look into this Levi, another interesting thought. Not sure if it's session expiration or appdomain restart at this point - both suggestions seem plausible. thanks again! – Incus

Answer 6

As mpen said in the comment on the answer I see this all the time when users leave the page sitting there for more than 20 minutes (the default session time) and the token expires.

You can trigger or force this error (if you're trying to test catching it) by opening your browser's developer tools and deleting the __RequestVerificationToken hidden field:

<input name="__RequestVerificationToken" type="hidden" value="AqJL/+e9tGCSCXdurrXDRefVL/TAdOAG9Hjrx0oMPg6sVZY3xv099OSYlH1qI8uZyu4x2xFj9eiNVSH2BGsSfJCQAqzxfQtIKoHXNkkW2FJTkxzsNRkwZo1SJUzYGvcEJ/OJ0AouiUWh98qyIzgN2ZkKP7k=">

Protamine