The Web is better when developers can build safer experiences in their sites. With each release of Internet Explorer, we’ve led the way with improvements to the browser to help ensure a safe and secure browsing
experience. Now IE10 Platform Preview 2 includes full support for
HTML5 Sandbox technology that allows developers to further lockdown mash-up content on their sites.
HTML5 Sandbox allows developers to further reduce the privileges of portions of their pages. To use it, it’s as simple as
adding the sandbox attribute to an iframe element:
<iframe src="untrusted.html" sandbox></iframe>
With the sandbox attribute, the framed content is no longer allowed to:
- Instantiate plugins
- Execute script
- Open popup windows
- Submit forms
- Access storage (HTML5 localStorage, sessionStorage, cookies, etc.)
- Send XMLHttpRequests
- Access the parent window’s DOM
- Use HTCs, binary behaviors, or data binding
These restrictions greatly reduce the capabilities of the framed content. If these restrictions are too much for your site,
you can allow-list certain capabilities back to the content using tokens in the attribute’s value. For example, this markup
would have all of the above restrictions except would be allowed to submit forms and execute script:
<iframe src="untrusted.html" sandbox="allow-forms allow-scripts"></iframe>
Try out the HTML5 Sandbox Test Drive demo to see all of the
allow tokens in action. Read the IE10 Developer’s Guide for more details on what is blocked inside sandboxed iframes.
The mash-up security problem isn’t new to the Web; developers had to deal with how to safely host content such as ads,
widgets, forums, comment posts, etc. on their sites for years. This content can be dangerous to the hosting site as a vector
for Cross-Site Scripting attacks (XSS), information disclosure, user-experience hijacking, and more. Sites employ a number of mitigations, such as:
- Server and client side content validation, filtering, and encoding
- JavaScript libraries to override access to undesirable APIs
- Hosting content from an separate domain to rely on existing cross-origin policies
- Using IE’s legacy security=”restricted” attribute
Detecting support for sandbox
We encourage developers to target IE10 Standards Mode for their sites. But to ensure users can’t accidentally remove the sandbox by clicking the Compatibility View button, IE10 supports the attribute in all document modes.
You may have content which you only wish to display if the user’s browser supports sandbox. As always, we encourage the use of feature detection for this purpose. HTML5 Sandbox can be detected using the following JavaScript:
if ("sandbox" in document.createElement("iframe")) {
window.alert("HTML5 Sandbox is supported!");
}
Graceful and secure fallback
In browsers which do not support HTML5 Sandbox, the attribute will be ignored. This means your content
will be rendered without the additional security restrictions. HTML5 Sandbox is a defense-in-depth technology—meaning, you
should use this on top of other mash-up security techniques like those I mentioned above.
Improving the standard
While implementing this feature, we identified a few areas in the specification to improve.
First, by default browsers block popups inside the sandbox. However, there are times where it might be desirable to allow them.
For example, in the sandbox Test Drive demo the site puts a Bing Maps widget in a sandboxed iframe but allows popups to facilitate the larger
map, directions, and Bird’s Eye popup links. IE10 supports allowing popups for such valid cases via the ms-allow-popups
token. We’ve given this feedback to the HTML Working Group. When the specification is updated and stabilized, we’ll remove the vendor prefix.
Second, it’s important for the server to also be able to sandbox content. The sandbox attribute restricts content only when within an iframe. If the sandboxed content is able to convince the user to browse to it directly, then the untrusted content would no longer be within the sandboxed iframe and none of the security restrictions would apply.
While no browser implements it, HTML5 suggests
the server could send the untrusted content with a text/html-sandboxed MIME type. There are a number of issues with this approach—notably, you can’t specify the necessary
allow tokens via a MIME type. After the discussion generated by proposing to remove this from HTML5, we’ve put our support
behind the sandbox directive of the X-Content-Security-Policy HTTP header. Here’s an example header you can send to sandbox
the content but allow form submission and script execution:
X-Content-Security-Policy: sandboxed allow-forms allow-scripts;
Finally, we developed 26 test cases for HTML5 Sandbox, which we’ll submit to the W3C.
We welcome your feedback on HTML5 Sandbox in IE10. Download
IE10 Platform Preview 2 and report and bugs you find via Connect.
—Jacob Rossi, Program Manager, Internet Explorer