KeepItLocked.net : Software Security, CSRF

More ASP.NET CSRF Protection Options

Alex — Tue, 16 Dec 2008 21:39:00 GMT

Barry Dorrans created a filter for CSRF protection in ASP.NET. It's inspired by the ASP.NET MVC CSRF token approach. It's a simple and effective protection mechanism when you can't use the ViewStateUserKey because you've disabled ViewState. It doesn't rely on sessions either. Now if I could only get him to support GET requests on an opt-in basis! Check out his blog post and the code on Codeplex.

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.

ViewStateUserKey Doesn’t Prevent Cross-Site Request Forgery

Alex — Thu, 29 May 2008 21:30:00 GMT

ViewStateUserKey is not a completely effective mitigation against Cross-Site Request Forgery. It doesn't work for non post-backs (I.e. GET requests), and it doesn't work if the ViewState MAC is turned off.

In several different places, we see a piece of advice repeated - use the ViewStateUserKey property to prevent One-Click Attacks. Often, this piece of advice is accompanied by the following code:

void Page_Init(object sender, EventArgs e)

{

ViewStateUserKey = Session.SessionID;

}

What exactly does this code do? To understand it, we first need to look at the ViewState mechanism itself. The ViewState is an ASP.NET mechanism used to persist the value of web controls between post-backs. This allows a lot of the drag and drop, UI-driven ASP.NET architecture to function "auto-magically" by serializing and de-serializing data automatically on the fly.

The ViewState is encoded and stored as a hidden field. This introduces security issues, because the value is under the control of the client. There may be a value stored in a field that you do not want someone to see and modify, like an admin-only control with the visible property set to false.

ASP.NET helps us out by introducing two mechanisms to help protect the ViewState. ViewState MAC prevents tampering with the ViewState by introducing a separate Message Authentication Code that is verified when the ViewState is submitted. ViewState Encryption protects the ViewState confidentially by encrypting the ViewState value. By default, the ViewState MAC is enabled, and ViewState Encryption is not.

The ViewStateUserKey property is an optional addition to the data used in ViewState MAC calculation. If that value changes between post-backs, the ViewState MAC calculation will fail and the page will cause an error.

When we set the value of ViewStateUserKey to something associated with a particular user (like a Session ID or a Username), we are making sure that the ViewState is valid only for that user.

Back to One-Click Attacks. One-Click Attack is sometimes incorrectly referred to as Microsoft's name for Cross-Site Request Forgery. However, this is not entirely correct.

One-Click Attacks refer to CSRF attacks that use a malicious ViewState to perform the request. Because web forms developed with ASP.NET use ViewState for post-backs, the attacker can perform the post-back they want the user to perform unknowingly, and record the ViewState. Due to the way that ASP.NET ignores HTTP verbs when using Request.Params versus Request.Form, and in web controls, this request can often be made via GET.

Example:

http://site/Default.aspx?__VIEWSTATE=%2FwEPDwULLTExOTcyMDExODNkZAShpi32DKvqCd4uvHuQ%2FmmnBcdY&TextBox1=<MALICIOUS_CONTROL_DATA_GOES_HERE>&Button1=Button&__EVENTVALIDATION=%2FwEWAwKEyYGZBwLs0bLrBgKM54rG3sCHijug9ibUUfHX808cCvcppg1i

This link can be used in a CSRF attack. It is then known as a one-click attack, because it uses the ViewState. This, however, is not:

http://site/DeleteUser.aspx?user_id=123456789

If the page is not a post-back (as in the case of a direct link), the ViewState MAC is never checked. Several ASP.NET applications allow you to modify data without submitting a form. Consider ASP.NET MVC - it doesn't even use post-backs.

Furthermore, the ViewState MAC can be disabled at the page level:

<%@ Page Language="C#" EnableViewStateMac="false"%>

or in web.config.:

</pages>

ViewState MAC is often disabled for (perceived) performance reason, or (more likely) if there is some functionality in the application that causes the ViewState MAC to cause error.

This reminds of problems with Request Validation is ASP.NET - the mechanism works, sometimes. This can be dangerous, because people rely on it and can get burned. The solution is to write something similar to CSRFGuard from OWASP in .NET. I have a feeling that the newly resurgent OWASP .NET project will add this to their to-do list.