4

I'm developing an ASP.NET MVC application and I'm planing to protect each non GET request (POST, PUT, DELETE, etc...) with AntiForegeryToken.

I've implemented an extension of the classical AntiForgery verification based on the [__RequestVerificationToken] sent in the header. This because most of my calls are async ($.ajax()) and it turns out easier for me to send the hidden field value that way.

Does it make sense to put one single @Html.AntiForgeryToken() in the _Layout.cshtml (template for all pages) and always refer to that one only ?

I've tryed to understand what wolud be different beteen this option and putting it in each form (that I don't use much since my requests are pretty much all async), but I haven't.

Can anyone clear this to me ?

Thanks

Lorenzo

Gabor Lengyel
  • 14,129
  • 4
  • 32
  • 59
l.raimondi
  • 389
  • 2
  • 14

1 Answers1

1

You can put it in your _Layout.cshtml and generate a single token when the page is rendered, that's fine.

While there is a very slight security benefit of using a different token for every request, if your token has enough entropy (and the standard token generated by @Html.AntiForgeryToken() does), then it is practically infeasible for an attacker to guess the token even during the time of a user session. So one token per user session is still considered secure in most cases.

Actually, trying to use a new token for each request leads to all kinds of bugs in a Javascript heavy application, because the browser needs a non-neglectible time to actually change things like a cookie value or to send a request, and frequent ajax requests will lead to a race condition and you will have hard to debug bugs around token mismatches.

ASP.NET MVC still focuses on traditional form-based applications in this regard, and while you can use it to prevent CSRF in modern Javascript-heavy apps with some tweaks (like a custom attribute to actually verify a token sent in request headers), you do have to write some custom code to do that. Hopefully Microsoft will add built in support in future versions.

UPDATE

After implementing the solution with @Html.AntiForgeryToken() directly in Template page (_Layout.cshtml) I found out a possible problem bound to the use of custom Claims. The problem happens during re-validation of UserIdentity. As a reference I'll leave the link to another post in which I've been dealing with that and added there the wotrkaround for those who choose the same implementation. Custom Claims lost on Identity re validation

Hope it helps !

Community
  • 1
  • 1
Gabor Lengyel
  • 14,129
  • 4
  • 32
  • 59
  • So, if I understood correctly: security wise it's ok, but might cause token verification mismatch (and thus bugs !) because it takes some time for the browser to set up the all environment (hidden field + cookie) and my requeests might start before everythig is settled. Did I understand right ? – l.raimondi Nov 15 '16 at 13:42
  • Sorry for the confusion. Having one token in your layout and using that some one in Javascript requests is fine and probably the best you can do. Having it somewhere else like separate tokens for separate forms or even a new token for each request would lead to difficulties. Hope this clears it up. :) – Gabor Lengyel Nov 15 '16 at 13:45
  • So is there an issue with Custom Claims or nothing to worry about if we add it at layout level ? – love2code Oct 16 '19 at 16:43