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.

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.

KeepItLocked.net : ASP.NET, CSRF

More ASP.NET CSRF Protection Options

ViewStateUserKey Doesn’t Prevent Cross-Site Request Forgery