Cutting edge web applications push the boundaries of the web development model. In the security space, this raises an interesting question – who owns security for a web application built on a complex platform hierarchy? Is it the application at the top of the stack, the intermediate platform component, or the browser itself?
We believe that web application security is a shared responsibility between the browser client, web platform components (such as ASP.Net), and web applications themselves. Any shared security responsibility can potentially lead to finger-pointing whenever a vulnerability is encountered. This is why we endorse the application of declarative security features that clearly assign responsibilities at design-time.
An Example
A recent paper by UC Berkeley researchers demonstrates some very interesting flaws affecting highly complex new web platforms. One of these issues involved the use of the postMessage API supported in IE8 to post a cross-domain message with the use of a wildcard targetOrigin parameter. A targetOrigin parameter configured as a wildcard allows the message being passed to leak out to any target, without validation. This potential information disclosure threat is why the developers of the specification required targetOrigin to be explicitly set by the caller:
Finally, the HTML 5.0 draft also mandates that the targetOrigin parameter for the postMessage method now be made a required parameter, as opposed to an optional one. This will make it difficult for developers to make errors by requiring an explicit acknowledgement of the target destination of the message by specifying the origin <URL> or wildcard <*>.
From: http://blogs.msdn.com/ie/archive/2008/10/06/updates-for-ajax-in-ie8-beta-2.aspx
One reason Microsoft helped participate in the working group developing the HTML5 Web Messaging specification was to ensure that the result could be implemented “secure-by-default” in products such as Internet Explorer.
We have updated our postMessage API documentation to better reflect the security implications of the targetOrigin parameter.
In this example the browser provides a primitive that, if used correctly, enables a secure platform feature. A more pointed observation is that the techniques predating the postMessage API just do not provide a reliable way to ensure messages are delivered securely.
How Declarative Security Guarantees Help
Used appropriately, declarative security features in the browser enable new scenarios while allowing web application developers to avoid potentially unreliable application-level hacks. These features ultimately help reduce some of the uncertainty and complexity around securing web applications. Rather than relying on incidental browser behavior to achieve a security objective, the browser itself explicitly provides a solution.
There are numerous declarative security features offered in modern browsers. Here is a list of a just a few:
|
Feature |
IE Versions |
Description |
|
The X-FRAME-OPTIONS header |
IE8 and up |
Prevents a page from being framed, mitigating ClickJacking attacks |
|
The “secure” bit on cookies |
All supported versions of IE |
Prevents cookie leakage to non-secure sites, mitigating man-in-the-middle cookie disclosure attacks |
|
HTTP-Only cookies |
IE6 and up |
Prevents direct theft of cookie-based session IDs in the event of a cross-site scripting vulnerability |
|
toStaticHTML |
IE8 and up |
Enables web apps to strip potentially malicious script from HTML on the client-side |
|
SECURITY=RESTRICTED frames |
IE6 and up |
Disables script execution in a frame, allowing safer hosting of external content |
To summarize, it is important to take full advantage of the declarative security features that the browser provides. Proper configuration of the targetOrigin parameter when using postMessage is one example. As you create and threat model web applications, rely on underlying platform technology as much as possible to help mitigate threats. Just take care in using these technologies to ensure that your security goals are ultimately met.
David Ross
Principal Security Software Engineer
Microsoft Security Response Center