Any reason not to trust ASP.NET AntiForgeryToken?

Question

I know that Stack Exchange sites do not use the ASP.NET MVC built-in @Html.AntiForgeryToken() for the prevention of XSRF/CSRF attacks. Instead of creating a hidden input named __RequestVerificationToken with a really long value based on the machineKey section of the web.config, the Stack Exchange method creates an input named fkey with a MUCH more succinct value. This is apparently a Guid, and based on evidence from the Stack Exchange Data Explorer project on Google Code, this value is tied to each individual user, remaining fairly constant until you log in or out.

Also, the Stack Exchange value is constant on a page, and is made available to client script, so that Ajax posts for voting and things like that also use the token. By contrast

So why does Stack Exchange march to its own drummer?

• Is there a reason not to trust AntiForgeryToken?
• Does the AntiForgeryToken have some limitations that the Stack Exchange team was unwilling to accept? If so what were they?
• Or maybe AntiForgeryToken just wasn't around (it started life in the MVC Futures project) when Stack Overflow was started, and if they had it to do over from scratch today they would use AntiForgeryToken?

I've been unable to find any blog posts from Jeff or others on the Stack Exchange team to explain the guiding principles behind how the XSRF-prevention policy on the SE network. It would be really nice if one of them could do a write-up, assuming of course that it could be done in general terms without creating a vulnerability. It would be really valuable information for those of us that want to make our websites secure, but aren't entirely comfortable just blindly trusting Microsoft to do it for us.

Heathenism

option 3: it was not around when we were constructing SO in 2008-2009. I can't comment on the pros and cons of the built in method, because I've never used it. – Bakemeier

Another consideration is that any security mechanism we put into MVC or ASP.NET has to be general-purpose. We can hit the 95% case, but there will always be some set of customers who have extraordinary requirements that a general-purpose built-in mechanism could never hope to satisfy. For example, the existing anti-XSRF implementation is unfriendly to sites that make heavy use of JSON or claims-based identities, and in those cases the developer ends up rolling his own solution much of the time. – Azriel

Answer 1

The one limitation we ran into with the default implementation was the lack of out-of-the-box support for AJAX calls. The hidden field approach works for sites that primarily deal with traditional form POSTs; but, not quite for AJAX heavy sites like SO.

We implemented the approach outlined in this CodeThinked blog post and we couldn't be happier. It looks like Phil Haack also supports this approach, based on his oct 2011 blog post

Couple of (unsolicited, I know!) pointers:

1. if you are running a web-farm, you should, of course use a static machinekey in your Web.config
2. Make sure all your servers have this KB installed. Otherwise, you may run into machinekey validation issues

Athalie