What are the implementation details and rationale of ASP.NET MVC3's AntiForgeryToken?

Question

The AntiForgeryToken is used to prevent CSRF attacks, however the links on MSDN don't give me much insight to what exactly the AntiForgeryToken does, or how it works, or why things are done the way they are.

From what I gather, it creates a hash inside a web page and a cookie. One or both of them use the hashed IPrincipal.Name, and use symmetric encryption.

Can anyone shed light as to:

1. How the AntiForgeryToken works internally
2. What should it be used to protect
3. What should it NOT be used to protect
4. What is the reasoning behind the implementation choices for #1 above?
   • Example:
     • is the implementation safe from "DoubleSubmit" cookies and other common vulnerability
     • Are there implementation issues if the user opens multiple tabs
     • What makes MSFT's implementation different from the one available at SANS

Answer 1

Okay, here is my best shot.

1) Internally, mvc uses RNG crypto methods to create a 128 bit string to act as the XSRF token. This string is stored in a cookie as well as in a hidden field somewhere on the form. The cookie name seems to be in the form of __RequestVerificationToken + a base 64 encoded version of the application path(server side). The html part of this uses the AntiForgeryDataSerializer to serialize the following pieces of data - salt - value(the token string) - the ticks of the creation date - the username (seems like Context.User)

The validate method basically deserializes the values out of the cookie and that of the form and compares them based on the values (salt/value/ticks/username).

2/3) I would think this discussion is more for when to use XSRF tokens and when not to. In my mind, you should use this on every form (I mean why not). The only thing I can think of that this doesn't protect is if you have actually hit the form in question or not. Knowing the base64 encoding of the app name will allow the attacker to be able to view the cookie during the XSRF attack. Maybe my interpretation of that is incorrect.

4) Not sure exactly what you are looking for here? I guess I would have built a mechanism where I would try and store the XSRF token in the session (if one was already available) and if not, then try the cookie approach. As for type of crypto used, I found this SO artcile. Pros and cons of RNGCryptoServiceProvider