Preventing CSRF with CsrfGuard

Alex — Fri, 17 Oct 2008 22:00:00 GMT

Edit: I realized I didn't mention the multitude of other ways to discourage CSRF including re-authentication, CAPTCHA, referrer checking, etc. This article deals only with the "secret token" approach to stopping CSRF.

CSRF (Cross-Site Request Forgery) attacks occur when an attacker forces a victim to perform an action unintentionally - "forging" a request from the victim, usually by using <img> tags (GET) or self-submitting forms (POST) in an attacker-controlled page the victim views.

CSRF attacks work because the browser likes to "auto-authenticate" to sites. Session IDs in cookies, HTTP, and NTLM authentication tokens are all automatically sent by the browser when it makes a request to a site. Thus, when the victim makes a request to site unintentionally, they do so with their full privileges.

A simple solution is to include an additional, unguessable token as a request argument. The application verifies this CSRF token against a server-side copy (or a cookie). If there's a mismatch, then a CSRF exception should be raised. This would prevent the attacker from forging the request because they can't set up a valid form without this secret value.

…

</form>

This type of solution is suggested by some reputable sources in application security. In some cases, the CSRF token is the session ID.

There are problems with this solution. The salient issue is the difference between GET and POST. According to RFC 2616, GET requests should be idempotent, meaning that they should not cause observable state-change on the server-side. If there was an RFC for CSRF, it would prohibit CSRF attacks against GET targets for this reason – there would is no reason to forge idempotent request. However, this is simply not the way GET is used in the real-world – it is used directly (the application has non-idempotent hyperlinks) or indirectly (the application accepts GET arguments just like they were POST arguments).

So, GET requests need to be protected, too. Easy enough:

http://www.keepitlocked.net/whatever.page?CSRFToken=SomeSecretValue

This works, but it's inelegant. It ruins bookmarking. Furthermore, if the CSRF token is the session ID, then placing it into a GET argument will cause it to be stored in server and proxy logs and browser history, which makes the session identifier secret more difficult to keep.

So, a full-featured CSRF solution is more difficult than it seems.

The CsrfGuard project is a fairly compelling solution – it overwrites all forms (POST) with an additional CSRF token argument, and it also overwrites links (GET). But, there are cases where links do not get a token:

The link doesn't have any arguments (in which case it's likely idempotent).
The link is to a .gif or other whitelisted extension.
The link is in a configurable whitelist of URLs (for pages which are known to be idempotent).

I like this approach because it offers the maximum amount of protection, not simply relying on developers to follow the standard and penalizing them with vulnerabilities if they don't.

That's why I'm integrating the .NET CsrfGuard project into OWASP .NET ESAPI. It will require some tweaking, but it's the most comprehensive functionality preventing CSRF I've seen.

One tweak is that the CSRF token should not be the session ID, because it increases the risk of exposure. Instead, I'll use the hash(Session ID + Salt). This is all easily configurable with CsrfGuard.

Oh yeah, what about ViewStateUserKey? Well, it's still there, with the weaknesses I've written about before. To me, it's like ValidateRequest – use it, but don't rely on it.

OWASP ESAPI.NET

Alex — Wed, 12 Mar 2008 02:04:00 GMT

Sent via OWASP ESAPI mailing list:

The ESAPI.NET project is now available on Google code (http://code.google.com/p/owasp-esapi-dotnet/).

The ESAPI.NET project is an implementation of the original ESAPI code base (http://code.google.com/p/owasp-esapi-java/) in C#, using the .NET platform.

Some notes on the implementation:

1) The code uses nUnit for unit testing. Currently, all unit tests pass and there is >80% code coverage.

2) The code uses the built-in .NET documentation format. Sandcastle (http://blogs.msdn.com/sandcastle/) will be used to compile the documentation.

3) The code follows the .NET/C# coding conventions discussed here: http://www.irritatedvowel.com/Programming/Standards.aspx.

4) For unit testing purposes, the code uses the HTTP Interfaces and Duck Typing library described here: http://haacked.com/archive/2007/09/09/ihttpcontext-and-other-interfaces-for-your-duck-typing-benefit.aspx. Hopefully we can use Microsoft code in a future release, as I believe that the ASP.NET MVC framework will use similar constructs (the author of the blog above is the project manager for ASP.NET MVC).

5) In general, the code is more of a direct translation of the Java implementation than a re-write from scratch for the .NET framework. Future work may include more .NET specific security functionality as well as implementations leveraging existing .NET security mechanisms.

6) The code passes its unit tests, but probably has some kinks to work out based on actually applying the library to an ASP.NET application. The next step will be to build a sample ASP.NET application that uses the ESAPI features.

Please feel free to provide feedback. Thanks in advance!

Alex

KeepItLocked.net : .NET ESAPI, OWASP

Preventing CSRF with CsrfGuard

OWASP ESAPI.NET