CSRF Prevention with MVC.NET

There's plenty of information on the inter-tube on the Cross Site Request Forgery Hack (CSRF, also known as XSRF and Confused Deputy - go on just Google those acronyms) so I'm only going to give a general overview of the exploit but know that it is a problem that has been around pretty much since the birth of of the internet, that browsers cannot prevent it (and have in the past aided it), and pretty much relies on a User's Trust / Stupidity.


The hack in general

The hack itself is 'blind'; it's automated.  There's nobody sat at there desk actively attacking an application.  There's no pretty colours on a screen and flying between virtual file structures on some remote server... as much as I like the film Hackers (1995), it just isn't that cool.  The hacker instead a web page or HTML email is set-up that could contain as little as a single HTML element or a Script tag.  As long as that element or script forces a victims browser to performs a remote request, possibly by  setting a 'src' attribute on a HTML element, or invoking an AJAX call then it can be potentially dangerous, because websites will simply perform such remote requests as they, unless programmed to do so, will assume that it is a legitimate user request. CSRF exploits the trust that a site has for a user.

What makes CSRF particularly dangerous though is that such attacks are not limited to browsers, they can also be embedded in many other formats including Flash, Word documents, movies, RSS web feed, anything that allows scripting.

Limitations of CSRF

The success of a CSRF attack relies on intelligence of the target site. The attacker must know;

• of a form submission action url that the target site performs
• the correct values that a form holds or the arguments on an action url takes
• a site where on POST request it does not check the HTTP referrer header (Common as this can be controlled by the browser and is often switched off)
• of a victim with a browser (or browser plugin) that allows referrer spoofing. (Uncommon)

The hacker must lure their victim to activate their exploit in what ever form it takes and then the success of the CSRF relies on one last thing; on whether the user is logged in to the target website at that time.  This is the reason we provide logout buttons; to delete cookies and sessions.

CSRF has a high ratio of failure, but the potential for damage on success according to authorities is unlimited.

General Prevention

To prevent CSRF attacks you can

• Limit the lifetime of session cookies.
• Check the HTTP referrer header
• Require authentication data in HTTP Requests that perform operations which have security implications.
• Require user specific tokens in form submissions.  Unless logged in as that user, a hacker would have difficulty recreating the algorithm to create that token.

.NET Specific Prevention - Anti-Forgery Tokens

.NET provides an inbuilt means of CSRF prevention using this last form of prevention, automatically generating user-specific tokens; it's called the Anti-forgery token.  It's easy to implement, and easy to use.  In each form that your application contains add the following helper method.

@using (Html.BeginForm()) {

    @Html.AntiForgeryToken()

    ...

}

For each POST method in your controller (Not GET methods because you shouldn't be providing GET methods with arguments that have implications on the application, and anti-forgery tokens do not work on GET methods) add the method attribute ValidateAntiForgeryToken like so.

[HttpPost]

[ValidateAntiForgeryToken]

public ActionResult Create(Dinner dinner)

...

Thats it folks!.  

You'll also notice that the anti-forgery method and attribute takes a parameter of 'Salt'.  This is used to lessen the non-zero likelihood of a Encryption collision during requests.  Seed it as you like just remember to add the Salt to both the form method and the attribute for it to work; I leave the implementation to you.  I suggest that a hard-coded static Application GUID would probably be best. I wouldn't generate a new GUID for every request and save it to the session, because all your doing is more work whilst exposing more data to the session which could potentially be caught by a malicious person. So until someone gives me a seriously good reason to auto-generate the salt for every request I'm sticking to this argument.  I've traversed Google up and down and as yet no one has convinced me of the need to do this, and since the .NET's AntiForgeryToken implementation uses OWASPS Synchronizer Token Pattern, I'm going to allow Microsoft do the work for me on this one and say, for the moment at least, this is good as it is.