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 action=”whatever.page” method=”POST”>
…
<input type=”hidden” name=”CSRFToken” value=”SomeSecretValue” />
<input type=”Submit” value=”Click Me”/>
</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.
