KeepItLocked.net : ASP.NET, Software Security

SoCalCodeCamp Presentation - "Top Ten Tips for Tenacious Defense for ASP.NET Application"

Alex — Tue, 27 Jan 2009 20:37:00 GMT

I think it was a good talk - too bad I only got through three tips :)

View more presentations or upload your own.

You can download the slides here if you have a Slideshare account, or just send me an email.

@SoCalCodeCamp, Speaking

Alex — Fri, 23 Jan 2009 19:35:00 GMT

I'll be at SoCalCodeCamp this weekend (January 24-25, 2009), attending sessions and hanging out. I'll also be speaking on Sunday, January 25, at 9:00AM in UH 250, giving a presentation entitled "Top Ten Tips for Tenacious Defense in ASP.NET".

I like SoCalCodeCamp. It's in my backyard (growing up a Fullertonite) and it's free for all participants. Also, somehow Rock n' Roll is involved. Looking forward to it.

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.

Developing ASP.NET in Partial Trust

Alex — Fri, 11 Apr 2008 22:20:00 GMT

Recently I developed a lab for our Writing Secure Code – ASP.NET training course where students modify Hacme Bank to run in Partial Trust rather than Full Trust.

A lot has been written about Partial Trust. It's not going to solve every security problem, but it's a smart thing to do. I wanted to show students that it was easy to take an existing application and get it to run with only the privileges it needed.

Turns out, there is more than one way to skin a cat. And, depending on your architecture, you may be spinning your wheels needlessly, as I learned the hard way.

Hacme Bank is based on the older .asmx web service architecture, with the web front-end calling a service layer, which calls the database.

If we configure the site to run in the default Medium Trust level, it does not have access to the Hacme Bank web service (a WebPermission error is thrown).

After a few hours of tinkering, reading, debugging, and throwing my innocent wireless mouse across the room (my preferred method of stress management), I discovered a couple of different methods that I could use to get this working. Thanks to Dominick Baier and Rudolph Araujo for seeding the clouds of this brainstorm.

The four options are:

Set the originUrl attribute in the trust element of the web.config file
Create a new custom trust level
Partition the privileged code into an assembly and install in the Global Assembly Cache
Partition the privileged code into an assembly and create a new custom trust level

And, for those of you who aren't into reading longish blog posts, here's a summary of what I found:

Approach

Pros

Cons

Set the originUrl attribute in the trust element of the web.config file

Really easy

Only works for web permissions (like calling a web service)

Create a new custom trust level

Only necessary permissions are granted

All code runs with the extra permissions

Partition the privileged code into an assembly and install in the Global Assembly Cache

Only a small amount of code gets elevated privileges

The code that gets elevated privileges runs in Full Trust

Partition the privileged code into an assembly and create a new custom trust level

Only necessary permissions are granted and only a small amount of code gets elevated privileges

Difficult

Now for some background:

1. Set the originUrl attribute in the trust element of the web.config file.

originUrl is an optional attribute that punches a hole in medium trust, allowing web connections to hosts defined by a regular expression. This is used to facilitate exactly what we need – connecting to a web service at an arbitrary location.

This is implemented by an entry in the web_mediumtrust.config file:

</ConnectAccess>

</IPermission>

Besides making this lab a little too easy, the originUrl attribute is limited to web permissions and is not useful for different permission elevation scenarios such as accessing the registry or using reflection.

2. Create a new custom trust level.

A more flexible approach is to create a new trust level. Usually this is done by copying over one of the policy files and adding the necessary permission. A good description is available at the Patterns and Practices site here.

While this approach gives us the tools to add arbitrary permissions to the code base, it doesn't exactly follow the principal of least privilege, because all of the code in the web site is granted the permissions, rather than just the code that requires them.

3. Partition the privileged code into an assembly and install in the Global Assembly Cache.

In order to segregate duties and reduce the overall privileges granted, we can rip out the code that needs permissions and throw it in to a new assembly. This is also known as sandboxing. All code that can run with low privileges is in a very low privilege environment, and is given limited access to higher privilege functionality. This approach has some similarity with the Silverlight security model and the security safe critical attribute – I'll blog about this later.

Once we have our privileged code in a separate assembly, we need to configure our environment so that the privileged code can be accessed safely. First, the privileged assembly should be decorated with the AllowPartiallyTrustedCallersAttribtue, strong nam signed, and (in this case) installed in the GAC. To protect the code from being accessed by other classes, we can add a Code Access Security demand that will prevent access by all but the required classes. We have a few options here:

Use a StrongNameIdentityPermission. If we strong name the ASP.NET application (running with partial trust), we can verify the strong name in the privileged assembly. This, unfortunately, isn't as easy as you might think. It's not supported in Visual Web Developer Express 2008, and so it wouldn't work for my lab. In the full version of Visual Studio, we can strong name the assembly by adding a compiler option however this means that we need to create a new trust level. This is because modifying compiler options requires unmanaged code permissions. The suggestion is to use this modified trust level while debugging, then to deploy the assembly as a pre-compiled, strongly named assembly, with the unmodified trust level. I feel that this is probably a bad design choice – there should be a simple option for the Visual Studio built-in web server to perform strong naming on the ASP.NET code to support this type of scenario in medium trust. One note - Dominick points out that strong naming doesn't scale particularly well, since more than one strong name cannot be demand (this will result in an AND condition).
Use the UrlIdentityPermission. I wasn't able to get this working, but theoretically you could restrict the caller's file location to the URL file://c:\directorytowebapp\*. Not sure if anyone has tried this successfully, but if you could, you may get around some of the difficulties around strong naming.
Use a custom permission. This may be the most natural way to express the demand and justify the extra effort in creating a new permission, which isn't trivial.

Note that these permissions do not prevent Full Trust callers from accessing the assembly. See this blog post for a description of why "Full Trust Means Full Trust"

One major problem here is that the assembly will run in the GAC with Full Trust. This is a fairly significant privilege escalation, even for a very small piece of code. However, we can do better.

4. Partition the privileged code into an assembly and create a new custom trust level.

In this approach, we will combine approaches 2 and 3 to get the best of both worlds. We partition the code into a privileged assembly and the low privileged web site, taking into account the precautions discussed in the previous step. Then, rather than installing the code in the GAC, we create a custom policy file (as described in approach 2) and add a new code group which refers to our privileged assembly, and assign that code group a permission set that has only the requisite permissions. This approach is described in the hyperbolically-titled but otherwise helpful article "Never Write an Insecure ASP.NET Application Ever Again" and in Dominick's book (pages 330-332). One thing to note here is that you don't use the .NET Framework Configuration tool to set the security policy for the privileged assembly – you want to use the ASP.NET policies in the .config file. Boy, I wish I had known that a few days ago.

This approach gives us the best shot at least privilege, and is extremely flexible. However, it's probably not appropriate for the couple of hours that the students have to complete the lab. Hopefully in the future we'll get an easy way to a) secure a privileged assembly with a simple permission demand and b) create a new trust level based off medium trust and c) create a new code group in the custom trust level based on the strong name of the privileged assembly.