Defense in Depth: Locking Down Mash-Ups with HTML5 Sandbox
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: sandbox 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
August 1, 2011: Corrected error in X-Content-Security-Policy HTTP header example. —Ed.
Comments
Anonymous
July 14, 2011
In all document modes? Even quirks mode?Anonymous
July 14, 2011
I don't quite get the second point. The HTTP header instructs the browser to do what? To prevent the user from accessing the framed content directly?Anonymous
July 14, 2011
As far as your first point, I hope you are not asserting that because a page expresses a desire to allow the sandbox to have pop ups it would overwrite when a user has specifically chosen to deny pop ups.Anonymous
July 14, 2011
@Björn - We need to support the security restrictions in all modes (including Quirks) so that forcing legacy doc modes is not a vector to escape the sandbox. We reduce the compatibility impact on existing sites by not having the attribute be enumerable in the DOM prototype in legacy modes (the above feature detection method fails in modes <10). Put another way: we will enforce the restrictions in all modes to help maximimize your site's security; but your site using sandbox should target IE10 Standards Mode for maximum functionality. @dTrupee - The HTTP header instructs the browser to sandbox the content (just like the sandbox attribute on a hosting iframe). In the case where the user accesses the framed content directly, the HTTP header is still there to instruct the browser to sandbox it. Think of it as yet another layer in your defense-in-depth strategy. If you must serve the untrusted content from your own server, the recommended best practice is to serve it inside an iframe with the sandbox attribute and serve it with a matching X-Content-Security-Policy HTTP header. That way, the content is always sandboxed by a supporting browser whether served as intended inside the iframe or if navigated to directly by the user.Anonymous
July 14, 2011
@Jacob Rossi: Ah OK, now I get it, it's an HTTP header for the framed the content not the parent site. But the won't protect against content from a server I don't control that might "convince the user to browse to it directly".Anonymous
July 14, 2011
@Lance - In a full version of IE10, the popup blocker and your popup settings will still apply. However, the popup blocker is not included in Platform Previews.Anonymous
July 14, 2011
i would love to see a more in depth break down of script access through iframes using these settings to see how ie is handling local content security.Anonymous
July 14, 2011
The comment has been removedAnonymous
July 14, 2011
The comment has been removedAnonymous
July 14, 2011
I confirm, in the nontroppo.org/.../Hixie_DOM.html test that Marko mentions, IE9, IE10PP2 are about 100 times slower than Chrome (80ms vs 9700).Anonymous
July 14, 2011
Indeed and firefox is the worst. It freezes off and on while the test runs but gets even worse.. It freezes completely after the test finishes. :(Anonymous
July 14, 2011
The comment has been removedAnonymous
July 14, 2011
Why would you prevent xhr's if you can still include script tags? What's the point? With the prevention of form submits, you'd mostly stop POST requests. I'd suggest xhr and, if you'd want it that way, only allow GETs. Maybe disallow CORS and be done with it. Just saying, xhr is used often in these mashups and removing them forces people back to 1999 methodologies of including script tags or images to communicate with the server. Do we really want that?Anonymous
July 14, 2011
The comment has been removedAnonymous
July 15, 2011
Correct usage of boolean attributes in HTML is as follows, not what you posted in your example: <iframe src="untrusted.html" sandbox="sandbox"></iframe> All thy attributes shall have a quoted value. IE HTML tag soup is NO LONGER SUPPORTED!Anonymous
July 15, 2011
@Joel You're not right. See www.whatwg.org/.../syntax.htmlAnonymous
July 15, 2011
Good article .I just found your site and wanted to say that I have really enjoyed browsing your posts. In any case I'll be subscribing to your blog and I hope you post again soonAnonymous
July 15, 2011
The comment has been removedAnonymous
July 15, 2011
Hello, I am facing a issue with Canvas and IE9, I posted same on Stackoverflow.com, can you please take a look. Sorry for using this forum to raise the issue. stackoverflow.com/.../655085Anonymous
July 15, 2011
@Elvation of privileges Okay, but still a .XML file to store favorites would be better then just Internet Shortcut files in the Favorites folder on Windows 7.Anonymous
July 15, 2011
so does allow-scripts allows framebuster scripts? If that's the case, then the sandbox mode with allow-scripts token would be quite useless...Anonymous
July 16, 2011
@Mario Whats so bad about shortcuts?Anonymous
July 16, 2011
About the favorites, in my opinion, if they provide a service on SkyDrive to manage (add/edit/remove) your favorite and then implement a functionality in IE to sync the list with the SkyDrive (for the given Live id account) that would make it pervasive and user can use their favorites on other platforms like WP7 and for other browsers, same feature can be implemented in BingBar (this way users might have any reason to use BingBar! :P ) ~WinWin IE team!Anonymous
July 16, 2011
BTW, that concept about favorite is not new. If you are G-bar user then you must have tried that favorites-on-the-cloud feature.. MSIE team, its a simple dual-faceted CRUD app (with categories and "SEARCH!!!" in it), interfacing SkyDrive as a web-app and IE/BingBar as a web-service and see the benefit your old 1990-style favorites section would be connected to the sky! Moreover, if its feasible for you guys, please upgrade the UI for favorites, settings menu, internet properties and please please implement "search" in favorites like FF! (obviously if you develop that SkyDrive-driven app, there would definitely be a search feature for its web version!) P.S. This is a feature request, & I posted this request on connect in Feb, which was unfortunately closed by design, I hope in IE10 this feature would be taken into consideration by the IETeam. For those who think this feature would help them in their daily routine, like if you want to use some URL in future (or on other system like iPad for an instance) rather than emailing the link to yourself or save it in your fone u just sync it with your SkyDrive (Live/Hotmail) account which can further accessed from anywhere anytime, please vote-up or press I can too button at: connect.microsoft.com/.../sync-favorites-with-skydrive-an-idea-to-enhance-personalization-experience . FWIW, I am going to reopen this feature-request now. IETeam I hope you are listening!Anonymous
July 16, 2011
@Prior Semblance Favorites making shortcuts in the favorites folder in windows 7 makes me just get bad feeling about IE it makes me think IE5 or IE6 :|Anonymous
July 16, 2011
Why web browsers don't have jQuery built in?Anonymous
July 17, 2011
Syncing favorites across computers was possible years ago using the Windows Live Toolbar which could also sync your favorites to Skydrive. Currently the product is called Windows Live Mesh and it comes with Live Essentials, like Live Messenger. It can even sync your Office settings, like your Word templates and Outlook signatures and of course your IE favorites. And yet nobody knows about it. It is strange since WL Messenger is used by 360 million people. It seems that these people never look in their Start menu.Anonymous
July 17, 2011
Saving favorites as shortcuts is very good. It means that I can use Windows Explorer to re-arrange them into folders and copy and paste them where ever I like, even on removeable media and take them with me. And I don't need to copy all of them but only the folders I want. Favorites can be moved around and edited like Start menu shortcuts. I hope you don't want your Start menu shortcuts to be place in yet another XML file? Having favorites as shortcuts in ordinary folders also means that I can create scripts to easily create and move them into any folder I like since they are just ordinary files. I can also access them from a toolbar which can display any files.Anonymous
July 17, 2011
Why would you include jQuery in a browser? jQuery is just a framework, one out of many. Why special treatment?Anonymous
July 17, 2011
@Mario That explanation doesn't make any sense =/Anonymous
July 17, 2011
@JM - Real Web Application developers properly quote all their attributes. If you want to take shortcuts, and watch things fall apart when you generate attributes and values go for it. The rest of us will continue to strive for quality standards based code.Anonymous
July 18, 2011
@Marcus: JM pointed to the relevant portion of the WhatWG spec. Here's the relevant part of the W3C HTML5 spec:dev.w3.org/.../Overview.html Using an empty attribute IS standards based. If you feel strongly that empty attributes should be prohibited, please feel free to work with the W3C to get them to remove them.Anonymous
July 18, 2011
Too bad we can't put this in an envelope and mail it back to 2001 where it would have a done a lot of good and saved a lot of time and money, but security wasn't important to MS back then.Anonymous
July 18, 2011
@hh281 The whole world was a more naive place back then. We wanted images, we wanted the blink tag. We wanted all the cool stuff to make our web-pages go bling-bling. Had microsoft said: "we don't do all that eye-candy stuff, but our browser is the most secure" then Netscape would be rolling on the floor, laughing. In retrospect, yes, things could have been handled differently (better) back then. But not only Microsoft, the whole world wasn't ready for that debate yet.Anonymous
July 18, 2011
I know this blog isn't exactly the right place to post this but when IE's Information Bar asks "This website wants to run the following add-on: 'npctrl.dll' from 'Microsoft Corporation'. [...]". Isn't it about time someone in the Silverlight team could update it so this reads 'Silverlight' from 'Microsoft Corporation'. It is rather odd it's gone so long without a more sensible name.Anonymous
July 19, 2011
The comment has been removedAnonymous
July 19, 2011
The comment has been removedAnonymous
July 19, 2011
Not cool. It’s not what YOU think is a standard. It comes from the published material by standard maintaining authorities. And if your aim is just to curse the product with the hypothetical and folly reasons then you are failed! Your claim is totally wrong. You have no point. Very Bad..Anonymous
July 19, 2011
And to add to @Marcus' comment: A standard maintaining body are e.g.: the W3C, ISO NOT a standard maintaining body are e.g.:
- www.whatwg.org ("The WHATWG was founded by individuals of Apple, the Mozilla Foundation, and Opera Software in 2004, after a W3C workshop." from their WiKi)
- WebGL (Khronos Group und Mozilla) Harry
Anonymous
July 19, 2011
Did you happen to consider reading Larry Osterman's comment? Here is the W3 link that @Marcus is talking about: dev.w3.org/.../Overview.htmlAnonymous
July 20, 2011
@ @Harry Richter Yes, I did! He is - correctly - speaking of a spec. and not a standard in regards to whatwg and points to the relevant STANDARD by the W3C. What is wrong with that? I did not - as you probably wrongly assume - comment on anything regarding attributes! HarryAnonymous
July 20, 2011
This system eats my comments. The sandbox could make a lot of existing anti-clickjacking JS ineffective. Should attempts to sandbox another site's content fail unless the other site "consents" to it by sending a matching X-Content-Security-Policy?Anonymous
July 20, 2011
@Randall +1 for "This system eats my comments" & this happened to me many times on IE9 and FF4,5,6. I am sure everyone can reproduce this unknown bug without a hassle. So, to secure my comment (from getting digest by this buggy-app), I write it in WordPad. The funny part is, I have reported this issue so many times via "Email Blog Author" but it never get resolved... Its being years now... :'( @ieblog, something to do with (200yrs old) Webform's Postback & validations? How about diagnosing this irritating issue/bug/whatnot once forever! Or redevelop the newer version with your very own next-generation .NET4MVC3 RAZOR! P.S. Microsoft please listen to the real people. Microsoft please listen to the real people. Microsoft please listen to the real people. Microsoft please listen to the real people. Microsoft please listen to the real people. Microsoft please listen to the real people.Anonymous
July 21, 2011
To make my comment above a bit clearer, I'm talking about making cross-site sandboxed iframes fail to load at all unless the framed site "consents" with a matching X-Content-Security-Policy header, since not loading is a safe failure mode for both sites. I'm aware of X-Frame-Options as a JS-free anti-clickjack mechanism, but sites like Facebook don't use it despite obvious clickjacking concerns. Facebook, on at least one page, has JS that reports the clickjack attempt to their servers, which you can't do with X-Frame-Options.Anonymous
July 21, 2011
@the_dees, about the DOM manipulation test (nontroppo.org/.../Hixie_DOM.html), I have submitted the bug-report on Connect and the bug# is 680378 (connect.microsoft.com/.../a-dom-manipulation-test-ie-performance). @ieblog, please show us the significant performance improvement when dealing with these essential DOM operations (such as; append, prepend, index, insert and remove) in next platform preview of IE10. ~ Keep up the good work guys!Anonymous
July 21, 2011
@ DanglingPointer No, I don't think that they should change anything! This gives "tests" like html5test, kraken and similar a chance to "prove" that IE is an inferior browser while their supported browsers are blown away in real world scenarios. HarryAnonymous
July 22, 2011
The comment has been removedAnonymous
July 23, 2011
IE is IE10 going to be a little bit faster then IE9? I hope so lets keep letting IE get faster and faster!Anonymous
July 24, 2011
@ DanglingPointer I was trying some tongue-in-cheek humor but obviuosly failed with English not being my native language. HarryAnonymous
July 25, 2011
@Harry Richter I thought it was funny... <gd&r>