One of the most common attack scenarios concerns exploitation of the display of unfiltered user input—coming in via GET, POST, COOKIE, or other client-to-server messages that the user can influence manually or with a tool. In this scenario, an attacker has to check where his input is being reflected and which characters the Web application filter is allowing. Sometimes there is no filter at all; sometimes the filter just encodes or strips certain characters or strings; and sometimes the filter uses a complex validation mechanism that has knowledge about the context in which the input is being reflected and then executed. The term context is important in this discussion. It is easy to harden a Web application against user input that could result in markup injections or cross-site scripting and JavaScript execution. A developer would just have to make sure each incoming string is encoded to an HTML entity before being reflected. This approach would work perfectly—as long as the attacker does not have the ability to inject input into the HTML element, because the browser accepts HTML entities at this location (as we learned in Chapter 2). However, a complex Web application cannot just rigorously encode any incoming data to entities. Sometimes, the Web site owner wishes to allow users to use HTML for text formatting; other times an abstraction layer for creating HTML text, such as BBCode (www.bbcode.org/) or similar markdown dialects, are being used.

In this situation, a developer is faced with a dilemma: Either the user can submit HTML, and thus the whole Web application will be rendered vulnerable to cross-site scripting or worse; or the requirement cannot be fulfilled, resulting in sad users and Web site owners. What is necessary in this case is an easy-to-describe but difficult-to-build layer between the Web application and the user-generated data. A tool with this capability would know all about HTML, browsers, and rendering quirks. It would be able to decide whether the submitted HTML is harmless or potentially dangerous; even fragments of dangerous HTML could be detected and, in the best case, removed. Chapter 2 should have taught you that this feat is quite challenging. Still, many developers have faced this challenge and attempted to create “aware” filtering tools. Google uses such a filter, and from what we, the authors, could see during our research, it is pretty tight and almost invincible. Microsoft also has a solution, called Safe HTML, which works quite well too. Meanwhile, PHP developers should investigate the HTML Purifier (http://htmlpurifier.org/) and Java folks should look into the OWASP AntiSamy project (www.owasp.org/index.php/Category: OWASP_AntiSamy_Project).

In essence, each of these tools parses the user-submitted markup and checks for tag-attribute combinations that could execute JavaScript code, interfere with client-side layout rendering such as base or meta tags, or embed arbitrary sources via object, applet, iframe, and embed.

Many of these tools are also capable of parsing CSS to make sure no evil styles can be smuggled into the submitted markup. The tools do this via whitelisting. In essence, the tools contain a list of known good; anything that is not on this list is stripped or manipulated to prevent any negative effects. (By the way, blacklists would fail at this task, since there are endless combinations of invalid or unknown tags and XML dialects for generating code executing JavaScript or worse.) HTML Purifier even completely rebuilds the user-submitted markup after analysis to make sure an attacker cannot use encoding tricks and other behavior to inject bad code, as we discussed in Chapters 2, 3 and 5. Nevertheless, bypasses sometimes do exist because user agents do not follow the defined standards for working markup. A recently discovered bypass that works against HTML Purifier and Internet Explorer 8 looks like this:

In the preceding code, the vector abused a parser bug in IE8 and earlier that is connected to the exclamation mark in the middle of the vector. HTML Purifier did everything correctly, but had no knowledge of the parser bug. This immediately rendered many Web applications vulnerable to cross-site scripting, and even bypassed PHPIDS attack detection in some scenarios since it relies on HTML Purifier too.

This problem was partially resolved in HTML Purifier 4.1.0 and fully resolved in HTML Purifier 4.1.1. So, as you can see, the task of cleaning markup of bad input is difficult to almost impossible. Too many layers are included in the process of submitting, reflecting, and processing user-generated markup. And not only must the filtering solution be equipped with knowledge regarding what HTML is capable of but also it is important to know about bugs, glitches, and proprietary features in the user agents rendering the resultant markup.

But, of course, there is more to Web application security and code injection than just client-side reflected code via bad server-side filters. Let us look at some of the protection mechanisms that are available to protect server runtimes such as PHP and the database.

There are dozens of techniques and even more attack scenarios and vulnerability patterns when it comes to executing code on the server via vulnerabilities in a Web application. In this section, we revisit those we discussed in Chapters 6 and 7.

The Web has evolved since we, the authors, conducted that test, and the brilliant SOP is now outdated. The policy now states that different domains should not be able to access the content unless both domains match. This worked great for Web applications in the 1990s and early 2000s, but as Web applications have evolved, the restrictions of SOP have become apparent. Web sites are no longer restricted to their own domains; they are combined to form mashups, in which data from one site can be used by another site to create a new application. Even user-created applications can be accepted on some Web sites such as Facebook. This presents a problem for SOP, because if we are accepting untrusted code, how can we be sure a user is not doing something malicious with it?

To solve this problem, companies such as Google, Microsoft, and Facebook have started to develop their own sandboxes, such as Caja (http://code.google.com/p/google-caja/) and the Microsoft Web Sandbox (http://websandbox.livelabs.com/). These are designed to allow Web sites to include untrusted code and execute the code in their own environment, choosing what the code should be allowed to do.

Although this sounds great, the footprint is high, and sometimes involves a server layer or plug-in to parse the code safely. We thought this could be done with less code and just the client.

Gareth (one of the authors of this book) decided to create a regular expression sandboxing system based entirely in JavaScript. This journey started when he was writing a simple JavaScript parser that could accept untrusted code. After around 100 lines of code, he realized that instead of writing multiple if or switch statements, he could use a regular expression as a shortcut to define more than one instance or range of characters. He soon realized that it would make sense to simply match the code and rewrite it as necessary, and then let the browser execute the rewritten code. From this, JSReg was born.

One of the challenges of sandboxing JavaScript is the square bracket notion. Literally, any statement can be placed within a pair of square brackets and the result is used to determine which object property to access. For example, the property __parent__ would return the window object on Firefox. We cannot allow access to window as we would then have access to the various methods and the ability to create global variables. Another challenge is that the square bracket notation shares the same syntax as an array literal. We want to detect both, as we will do different rewrites depending on whether the script we are detecting is an array or an object accessor.

Let us see how an array literal and object accessor compare.

As you can see in the preceding code, they are very similar; the object accessor looks like an array, even though it only returns the result of the comma operator. The last statement, meanwhile, is always returned by the object accessor. We could, in effect, rewrite the preceding code sample as obj[‘a’] as the string ‘b’ is redundant.

Once a sandbox is in place, the next step is to proxy existing functions that we want to allow access to. When proxying functions you need to consider object leakage and any calls to the DOM. An issue in Firefox to look out for is native objects leaking window; this issue could be applied to other browsers in the future, so it is worth applying a proxy function in every browser. A closure is a good choice when creating a proxy function, as you can supply any global objects a function has access to without exposing the window object. The variables passed to the closure are sent before the proxied function is defined. The following code shows a function proxy:

In this instance, the extendWindow method allows you to add methods to a sandboxed window object that is really named $window$ and that follows our prefix and suffix. Notice that we name our function $alert$ and that the eval'd code is alert. As we discussed in the “Code Replacement” section earlier, all code supplied to the sandbox is replaced with the prefix and suffix, so alert becomes $alert$. We use the closure to send the native function alert to our proxy function where we can call the native whenever we like and perform any checks before the actual native is run. In a real-world situation, we might limit the number of alerts that can be called to prevent a client-side denial of service. We can do this within the scope of our proxy function.

Proxying assignments is quite difficult if you want to maintain compatibility with older browsers as the technique requires some form of setter syntax. Getters and setters are supported in Firefox, IE8, Chrome, Opera, and Safari, but not in earlier versions of Internet Explorer, or at least not in a standard form. From a sandboxing point of view, you might want to intercept assignments such as document.body.innerHTML in Firefox, Chrome, Opera, or Safari. You can use __defineSetter__ syntax in JavaScript (https://developer.mozilla.org/en/JavaScript/Reference/Global_Objects/Object/defineSetter). This function takes two arguments: the name of the property that you want the setter to be called on and the function that will be called. The setter function will be passed one argument of whatever has been assigned. ECMAScript 5 introduced a new way to perform setter assignments using the defineProperty function (http://msdn.microsoft.com/en-us/library/dd229916%28VS.85%29.aspx). This method is far more powerful than the nonstandard __defineSetter__ syntax. One reason for this concerns control over the object. Instead of supplying two arguments, you provide a property descriptor. This allows you to define a setter, a getter, and how the properties can be used (e.g., making nonenumerable properties).

To be compatible with earlier versions of Internet Explorer such as IE7, we can use nonstandard functionality that can be used to emulate setters. The onpropertychange event (http://msdn.microsoft.com/en-us/library/ms536956%28VS.85%29.aspx) calls a function when a DOM object, usually an HTML element, has an attribute modified. Putting all this together, we can create setter emulation which works in the majority of browsers. Gareth (one of the authors of this book) created a sandboxed DOM API which combines all of these techniques to successfully intercept DOM assignments. The following URL shows how to use feature detection and fallbacks to provide the most compatible way to listen for these assignments:

The most recent feature is detected first, so if the browser supports Object.defineProperty this test will be passed first; then Object.__defineSetter__ is checked, and as a fallback, it is assumed that onpropertychange will be supported. If this actual code fails, it will fail gracefully as it will simply be ignored by browsers that don't support it. There is an interesting problem in IE8's support of the defineProperty syntax; it only supports DOM elements and not literal JavaScript objects. This presents a problem for sandboxed code because, for example, if a sandboxed object was checking for styles being assigned to a style property, as our previous code sample shows, it would not be called. Unfortunately, the hack around this is quite ugly; you have to create an empty tag and use that object to check assignments:

The onpropertychange event suffers the same problem. This element can be used in both instances to provide a reliable setter assignment and cross-browser compatibility. The next code sample shows how to use these pieces together and form your cross-browser setters independently of the DOM API. We will create an object, assign it a styles property, and then intercept any assignments.

The code sample shows how to intercept the assignment styles.color to the obj we created. Styles is created using a span and is assigned as a property of our object obj. We then test for defineProperty; if it is available, we assign a sandboxed $styles$ property to the span element we created. Then we create a setter using the “fake” styles (the span element); the setter looks for $color$. Normally, the setter would be created multiple times for the various different values. The setter function then has one argument, val, which contains the result of the assignment. Next, we check for __defineSetter__. If the browser does not have Object.defineProperty, this process is simpler, as we can just create a setter on our object that mirrors the defineProperty setter. Lastly, the fallback is assuming that the browser is earlier than IE8; here we have to add our span element to the DOM for the onpropertychange event to fire, then assign this reference to our object obj. The syntax is quite different from the previous two examples, as these are actual events that are called. We must check that the assignment is actually our target property $color$, which we do using event.propertyName, and we obtain the value being assigned using event.srcElement[event.propertyName]. The good thing about the fallback is that onpropertychange will not be fired if the browser does not support it, so in the worst-case scenario, the assignment will not occur and the sandboxed property will just be added with no effect on the DOM. Then we add our object to the sandboxed window using extendWindow, which will intercept any assignment to the $color$ property in pretty much every browser, including those earlier than IE7.