4

We've just had some Penetration Testing carried out on an application we've built using ASP.NET MVC, and one of the recommendations that came back was that the value of the AntiForgeryToken in the Form could be resubmitted multiple times and did not expire after a single use.

According to the OWASP recommendations around the Synchronizer Token Pattern:

"In general, developers need only generate this token once for the current session."

Which is how I think the ASP.NET MVC AntiForgeryToken works.

In case we have to fight the battle, is it possible to cause the AntiForgeryToken to regenerate a new value after each validation?

jmcd
  • 4,269
  • 5
  • 36
  • 36
  • I'm not sure that you'd want it to, especially as many sites need to make multiple AJAX calls from a single page. The _Synchronizer Token Pattern_ means that you're not just checking a token that's unique to the user for their session (which is what `AntiForgeryToken` does) but that you also check a token that's specific to the page that you expect the request to have come from. `ViewState` did just that in WebForms pages but it's messier in MVC. – Keith Apr 26 '12 at 12:14

2 Answers2

8

The anti-forgery token is just an anti-XSRF token. In particular, it is not a single-use nonce. If you need a single-use nonce for your application, you cannot use the anti-forgery token for this purpose. There is no built-in functionality for this.

Levi
  • 32,628
  • 3
  • 87
  • 88
-1

Maybe you can use the AntiForgeryToken using the three parameters constructor.

Using a salt is always recommended but also limiting the token by domain and path will make your token more secure and per-page unique.

If you don't have XSS vulnerabilities this problem is not going to be a big mess in your web site :) // Did I write this? Surely I didn't read well the problem.

Cheers!

Pedro Laguna
  • 465
  • 2
  • 5
  • 20
  • Thanks, but that doesn't really address the issue of per-request token values. – jmcd Feb 09 '10 at 09:44
  • Sorry, but -1 for _"If you don't have XSS vulnerabilities this problem is not going to be a big mess in your web site"_ as that's just plain wrong. CSRF attacks can be completely external to your application, they just need the user to still have a valid authentication cookie. – Keith Apr 26 '12 at 12:11