Rely on Declarative Security Features in the Browser
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: https://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 |
IE8 and up |
Prevents a page from being framed, mitigating ClickJacking attacks |
|
All supported versions of IE |
Prevents cookie leakage to non-secure sites, mitigating man-in-the-middle cookie disclosure attacks |
|
IE6 and up |
Prevents direct theft of cookie-based session IDs in the event of a cross-site scripting vulnerability |
|
IE8 and up |
Enables web apps to strip potentially malicious script from HTML on the client-side |
|
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
Comments
Anonymous
June 14, 2010
Is there a column for what the other browsers support?Anonymous
June 14, 2010
@Curious: The "Secure" bit and HTTPOnly are supported by all modern browsers. X-Frame-Options is everywhere except Firefox (blogs.msdn.com/.../combating-clickjacking-with-x-frame-options.aspx). I believe toStaticHTML has yet to be implemented by others. Non-IE browsers don't have a "Restricted" Sites zone, so they don't offer the SECURITY=restricted attribute (HTML5 frame sandboxing is the closest analog, but it has significant differences).Anonymous
June 14, 2010
Why are you still using old stable Google Chrome 4.1 on Windows Internet Explorer Testing Center? Newest 5.0.375.70 version have been available for a long time now.Anonymous
June 14, 2010
The comment has been removedAnonymous
June 14, 2010
It makes me feel safer knowing that when I view lolcats I won't get hacked.Anonymous
June 14, 2010
The comment has been removedAnonymous
June 15, 2010
The comment has been removedAnonymous
June 15, 2010
The HTTP-Only implementation of Firefox is better than the one of IE: bugzilla.mozilla.org/show_bug.cgiAnonymous
June 15, 2010
The comment has been removedAnonymous
June 15, 2010
The comment has been removedAnonymous
June 15, 2010
@Wurst: I'm not sure I understand your statement? If you're saying that you can use XHR to retrieve a Set-Cookie2 header, that is true, however IE doesn't support Set-Cookie2 (I don't even know that FF does either) and hence almost no sites ever send that header. The HTTPOnly token was never defined for the Set-Cookie2 grammar in RFC2965, so complaining that a browser that doesn't support Set-Cookie2 also doesn't restrict access to that header based on a token not even defined for that header seems a bit silly.Anonymous
June 16, 2010
@EricLaw: It's not specifically about Set-Cookie2, IE allows the retrieval of cookies marked as HTTP-Only through certain Javascript functions.Anonymous
June 16, 2010
And to which "certain Javascript functions" do you refer? (Mozilla's bug database isn't always a good source of reliable information about IE.)Anonymous
June 16, 2010
IE is like the BP oil spill of the internetAnonymous
June 21, 2010
@Eric - "Mozilla's bug database isn't always a good source of reliable information about IE" Nice one :-)