Clever Geek Handbook

Ideas for Implementing XSRF Security in ASP.NET MVC Using Double Send Files

I decided to try and use the double-sent cookie method to try and prevent XSRF attacks on the site I'm working on. So, the way I wrote it down here is all actions that actually do anything other than the GET information will be messages. So, there will be ... uh ... GET. Second, every form that posts posts will have a key / cookie combination.

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

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

Currently my controllers all inherit from the base controller, so my first thought was to override the OnActionExecuted method to check for the presence of the required form field, and from there, if it finds it, check it against the cookie and either allow the write to continue or remove it to the error page.

For the form part, I was thinking about creating my own html extension methods like ... Html.BeginSecureForm (), which overloads all the same methods as BeginForm (in case I need them), but automatically generates a pseudo-random key and file cookie and automatically places the cookie and the form field inside the form (IF ITS POST!).

Sorry if this is a little confused, I have notes scattered across these pages and I'm trying to organize them. Part of this is to figure out my design for this XSRF security thing.

+1


source to share


3 answers


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



+2


source


The built-in ASP.NET MVC XSRF security has one drawback: it sends another cookie to the client.

At the same time Html.AntiForgeryToken()

will provide the visitor with a cookie named __RequestVerificationToken with the same value as the random hidden value shown above.

I would rather not send a bunch of cookies to the client, so when you have a unique server tracker for each user (like a table of sessions in a database ..) you can use that instead. One less cookie - just send a unique hash of something in the user's table.



But then there are anonymous users who do not have a user account and therefore no server side tracking. In this case, I'm wondering if there is some way to hijack the existing ASP.NET_SessionId cookie (when sessions are enabled) that has already been sent to every user .. instead of creating another Cookie.

Possible? Or I don't think about it through.?

0


source


One way to get traction is through an encrypted token template implemented by the ARMOR platform. The premise here is that you don't need a session or cookie to maintain CSRF protection. The encrypted token template uses a Rijndael encrypted token whose integrity is maintained by the SHA256 hashing algorithm.

The ARMOR platform is easy to implement in MVC and Web API applications. Full description here .

0


source






More articles:


All Articles