4

We are getting random "The anti-forgery cookie token and form field token do not match" errors showing up in the error log in with our site hosted in Azure. After realizing that we needed a static machine key, we added to that to the web.config with the validationKey and decryptionKey attributes, however, we still have the random error popping up.

Just to define my use of "random" here, out of every ~200-300 form submissions, this happens once or twice. It just feels like too much to have happen and it's a real interruption to our clients that trust our services.

One other thought that crossed my mind is whether this is happening on machines that don't have cookies enabled. I haven't been able to verify that one way or another, but I didn't know if cookies are a requirement for the ValidateAntiForgeryToken to work. If it does require cookies, then should we pop up a message to our users letting them know that cookies are required for proper use?

I could use help coming up with ways to diagnose this or other ideas of how to handle this.

Thank you in advance.

[UPDATE] I just heard from a user where I saw this error popup. It turns out that they loaded the page and walked away for a while causing the error. That's great news since that means that the validation is just doing its job and nothing crazy was happening...I just need to verify if that data point is indicative of the rest of the users. So given that, how do you all handle situations where the token expires? Do you notify the user in some clean way?

lostdeveloper
  • 73
  • 1
  • 6
  • Is someone trying to submit malicious form data, i.e. is the token doing it's job? – Liam Oct 26 '16 at 14:09
  • Really, who knows. Without recreation steps it could be many reasons – Liam Oct 26 '16 at 14:10
  • These are real users that are legitimately attempting to use our services, so I don't see a reason for them submitting malicious form data. There also the other form of malicious data like using Html or script tags but that generates a different type of error. – lostdeveloper Oct 26 '16 at 14:14
  • As for reproduction steps, that's the hard part in all of this since we can't replicate it ourselves. It's just an odd scenario all around. – lostdeveloper Oct 26 '16 at 14:14
  • Perhaps this will help: http://stackoverflow.com/questions/5767768/troubleshooting-anti-forgery-token-problems – Peter B Oct 26 '16 at 14:36
  • @PeterB, thank you for the link. What I see on that link that it is indeed cookie dependent so we can add a check for that. The original question on that link is for a consistent anti-forgery token issue whereas ours is very intermittent. – lostdeveloper Oct 26 '16 at 15:33
  • Turns out that this was a false alarm. I guess we are getting that many users that have expired tokens. Now we just need to find a good way to show them an error. – lostdeveloper Oct 31 '16 at 19:31

2 Answers2

0

Do you have a server farm ? i.e. do you have an App Service with auto-scaling enabled ? or a cloud service with several machines ?

If yes, check that all your machinekeys are defined with the same value in all your web.config files. The machinekey is used to generate AntiForgery tokens.

Toine Seiter
  • 437
  • 4
  • 20
  • I assume that since we are in Azure, we are automatically in a server farm of sorts. The machineKey is defined in the single web.config that has been deployed so I don't see an opportunity to have conflicting web.config files. – lostdeveloper Oct 26 '16 at 15:55
  • ok. the default cookie used by asp.net to manage AntiForgery token is **__RequestVerificationToken** – Toine Seiter Oct 26 '16 at 15:58
  • If you have an Azure App Service, you can go to portal.azure.com > App Services > _your app_ > App Service plan > Scale Out to check your autoscale policy and see how many instance do you have – Toine Seiter Oct 26 '16 at 16:06
  • I looked at the instance count. It is configured to "an instance count that I enter manually". That is currently set at 1. – lostdeveloper Oct 26 '16 at 20:48
  • ok, so you have only one server with a defined machinekey. Did you try to double click on the submit of the page that throws the error ? – Toine Seiter Oct 27 '16 at 08:24
  • Good suggestion. I tried clicking multiple times but I still can't make it break. – lostdeveloper Oct 27 '16 at 14:24
0

Could you log the headers of the failed requests ? You can add some code in your global.asax on Application_Error like :

foreach (string header in request.Headers)
{
     // header <== header name
     // request.Headers[header]) <== header value
 }
Toine Seiter
  • 437
  • 4
  • 20
  • First off, thank you again for your help on this. Much appreciated. As for logging the headers, what should I be looking for in there? Also, I'm posting an update to this question based on feedback I just received from a user. – lostdeveloper Oct 27 '16 at 17:32
  • You will be able to see if an anti-forgery token cookie is there and maybe some other interesting things. A POST without this cookie on an URL that should have it could be a hit from a crawler or a hacker. – Toine Seiter Oct 27 '16 at 19:51
  • 1
    If all headers seam OK, it could be a usage of your users. Let's consider the following use cases : 1) Your form is on cached page (cache on client side). An Anti-forgery token `A` is generated 2) the user validates the form 3) then hit the back button of his browser 4) the user re-validate the form (with the old `A`token) 5) asp.net waits for a anti-forgery token `B` and get the `A`. so it throws an exception. To void this, client cache should be disabled on URL with form containing antiforgery. – Toine Seiter Oct 27 '16 at 19:51