Ideas for XSRF Security implementation in ASP.NET MVC using Double Submitted Cookies

Question

I've decided to attempt using the double submitted cookies technique to attempt to prevent XSRF attacks on the site I'm working on. So the way I have it written down here is, all actions that actually DO something other than GET information, will be posts. Gets will be...uh...GETs. Secondly, every form that posts will have the key/cookie combo.

My question is, what would be the easiest way to implement this in an ASP.NET MVC web application?

Not to answer my own question, but here are my initial thoughts:

Right now my controllers all inherit from a base controller, so my first thought was to override the OnActionExecuted method to check for the existence of the required form field, and from there if it finds it, verify it against the cookie and either allow the post to continue or kick it to some error page.

For the form portion I was thinking of generating my own html extension methods like... Html.BeginSecureForm() that overloads all of the same methods as BeginForm (In case i need them) but auto generates the Pseudorandom key and cookie and places the cookie and the form field inside the form (IF ITS A POST!) automagically.

Sorry, if this is kind of jumbled up, I have notes scattered throughout these pages and I'm trying to organize them. Part of that is to figure out my design for this XSRF security thing.

Answer 1

Use the built-in support for this in ASP.NET MVC.

Answer 2

The built in ASP.NET MVC XSRF protection has one downside: it sends down yet another cookie to the client.

At the same time, Html.AntiForgeryToken() will give the visitor a cookie called __RequestVerificationToken, with the same value as the random hidden value shown above.

I'd prefer not to send down a ton of cookies to the client, so when you have a unique server-side tracker for each user (like, say a session table in the database..) you can use that, instead. One less cookie -- just send down a unique hash of something in the user table.

But then there are anonymous users who do not hold a user account and thus have no server-side tracking. In that case, I'm wondering if you could somehow grab the existing ASP.NET_SessionId cookie (when sessions are enabled) that's being already sent to every user.. rather than creating Yet Another Cookie.

Possible? Or am I not thinking this through..?