An introduction to code sandboxing

One of the latest buzz words surrounding application development is "sandboxing", and it's becoming a buzz word for a reason. Incase you haven't heard much about sandboxing your code, take a few minutes to get up to snuff.

Overview

Code Sandboxing is the idea that you can keep all application resources contained within one build. Look at it like this... if you don't sandbox your code, and if you share a web server for a variety of web applications, if one application is compromised, all are compromised... and beyond that, your server as well!

The idea behind sandboxing is that you can isolate the security permissions behind each build, so if there is a security leak behind one application, the rest of your server is still off limits. And incase you haven't figured it out, it's as if you put each application in its own.. say it with me.. sandbox.

How do I Sandbox?

Sandboxing is as simple as adding a value to your web config. In your web.config, add the following key:

<trust level="Medium" originurl="" processrequestinapplicationtrust="true" />

There are 5 Out-Of-The-Box values for the level, Full, High, Medium, Low, and Minimal.

Now, you have 2 choices here, sandboxing a new application, or an existing application. As you might have guessed, a new application is easier, and so we will start there. Therefore, go ahead and develop your project. What the key above does is only give you access to any processes that are configured for "Medium" trust. So, as you are developing, you will receive security permission errors if you go outside of your Medium trust. For example, with Medium trust, you have no File IO Permissions. So attempt to perform File IO, and you'll receive an error. In this instance, you have two options, remove your File IO Code and find a different method.. or add File IO to the security permissions (more on that later).

The tricky part is sandboxing an existing application. The whole idea behind sandboxing is giving your app partial-trust. So if you build an app on top of partial-trust, anytime you stumble upon a security issue, you can fix it accordingly. Therefore, when dealing with an existing app, you need to identify any area's that go outside the normal boundaries. How do you do that? Well, you can hire yourself about 10 interns and feed them coffee and peanuts until they identify/fix every issue... or you can use permcalc.

Permcalc is a Microsoft tool that analyzes an assembly of your application, and generates an XML document stating all the methods that need any type of security access. To use it, open up the Visual Studio Command Prompt, navigate to your applications bin directory, and perform the following command:

permcalc -show

A new browser window will load with each method that is used within the assembly, along with showing what security features are needed.

How do I resolve my security issues?

OK, so at this point you took my advice above and added a trust key to your web.config, but you get to a certain line of code and an error is thrown. Just because you receive a security issue doesn't mean that you give your application a higher privelage! You have two options, create a security policy that contains all of the access that you need (recommended), or grant temporary access (NOT recommended).

Remember up above when you assigned the level of trust to "Medium"? That references a policy file on the server that grants access to the different permissions. So you can copy/paste the existing Medium File, rename it, and reference the new file (yes, you can just update the Medium trust policy file... but c'mon.. lets not cut corners here).

So, to get started, navigate to the .Net Framework's config location (try C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\CONFIG) and look for the config files. Namely, you'll be looking for web_mediumtrust.config. Copy/paste it, and rename it. Then, add the permission set you need. Next, in your global web.config, create a reference to your new policy file by adding an entry within the securityPolicy section, such as:

<trustlevel name="MyPolicy" policyfile="MyPolicy.config"/>

Finally, in your app's web.config, set the trust level to "MyPolicy", and now your code has access, while still running at partial-trust.

Above was just an overview of sandboxing, but hopefully it provides you enough of an idea so you know how to do it, and the importance of sandboxing. For more information, I strongly recommend that you read about Partial-Trust - http://msdn2.microsoft.com/en-us/library/ms998326.aspx. And if that doesn't give you enough information to quench your thirst, check out Dominick Baier's book - Developing More-Secure Microsoft ASP.NET 2.0 Applications - http://www.amazon.com/Developing-More-Secure-Microsoft%C2%AE-Applications-Developer/dp/0735623317. Chapter 8 is devoted to this topic. Finally, the most recent cover story of Redmond Developer News was dedicated to sand boxing, and provides a nice overview.. probably better than mine was ;) http://reddevnews.com/features/article.aspx?editorialsid=2386

ASP .NET Security - Stopping scripting attaXSS in their traXSS

As of May 2007, the top security vulnerability on the web is Cross Site Scriping (XSS) attacks. And why shouldn't they be? Theyre extremely easy to use and potentially lethal to the credibility of your site, fortunately the kind people at Microsoft made it simple to prevent these attacks.

The culprit

Here's the situation: You have a web form where the user can post data for others to see. For example, you're writing a custom blog application and you want users to write comments. On your site, you have a textbox that allows users to post comments, lets call this textbox "txtUserComments".

When your user clicks your submit button on the form, your code will look something like this:

If Page.IsPostBack

'Some Code Up Here

Dim UserComment as String = txtUserComments.Text

'Some More Code Here

End If

Yep, thats all it takes to have an XSS Vulnerability. If input validation is turned off on your page/site, an end user can post some bad stuff, and all future users will be affected.

For example, if <script>alert('ha')</script> is posted, all future users will enter the page and see the alert box. I'll let your imagination run wild with the other possiblities here...

The fix

So, what's the fix to this solution? Well for one, you probably noticed that I said above that "If input validation is turned off", which is turned on by default. So... don't turn off validation! But there's much more to this post than that. What about query string values, HTTP Header Information, or other Form POST data?

The nice people at Microsoft developed an Anti XSS library... and it's cake to use. You can get the library here.

To use it, download and install the library. In your web project, add a new project reference, and get your dll from your program files\Microsoft Corporation\Anti-Cross Site Scripting Library V1.5\Library\.Net 1.1 | .Net 2.0. That's right folks, the library is available for both 1.1 and 2.0!

Now that you added your reference, import the namespace into your page:

Imports Microsoft.Security.Application

Finally, make use of the library! For example, remember our example above with the textbox input? Well, now we would use the following code:

Dim UserComment as String = AntiXss.HtmlEncode(txtUserComments.Text)

The magic behind it all

Some of the best things in life are simple, and this is no variation of that rule. The HtmlEncode function takes the input characters and encodes them for HTML output. For example, the '<' in a script tag is converted to a '&lt;'.

The library has multiple functions available, so you can use the best encoding for your application. There is "JavaScriptEncode" for any JavaScript input, or even "UrlEncode" for passing values via querystring.

Hopefully this blog post gave you some insight into how easy it can be to compromise your site with an XSS attack, but more importantly you also saw how easy it can be to fix such attacks.

References

• Microsoft Anti-Cross Site Scripting Library v1.5 Download


• MSDN Anti-Cross Site Scripting Article - Kevin Lam - November 2006


• OWASP Top-10 Security Vulnerabilities

In IE 7, the window.open function isn't what it used to be

So here's the scenario. You have a website with a link that opens a new window. When opening this new window, you use the javascript:window.open() function, and you specifically state "location=no, statusbar=no" within the open function. When you test it locally, it works wonderfully. Then, you make your push to production, and users see the location and statusbar in the new window. What's the deal!?

IE 7, Firefox, and Safari have all preached user security for quite some time, so it may not be much of a shock to you to hear that the address and status bars are always visible, no matter what parameters you feed it via window.open(). Granted, the address bar in the above scenario cannot be used for navigation as it is "greyed out", but these toolbars are always visible to ensure that user's aren't sent to Phishing sites, etc.

So why did my window.open() function work when I tested it?

Simple, when testing on your development PC, or internal network, you're withing your "Intranet" group according to your browser. The Intranet group has lower level security permissions that allow such functions to work. However, when you make your push to production, the site is now in the "Internet" group, which obviously has higher level security.

This FAQ here states how IE 7, Firefox, and Safari take to the window.open() parameters.

This post, albeit brief, hopefully saves you some time and energy on not only troubleshooting the scenario above, but also saves you in development time as you can no longer rely on this technique to open new windows with total control over their look and feel.