A good friend of mine, lets call him Mikey G, shared this article via Google Reader the other day and it’s probably the first time I’ve gotten interested in the work going on in the HTML spec, as far as security is concerned. The feature in particular is the “sandbox” attribute for the
The sandbox attribute, when specified, enables a set of extra restrictions on any content hosted by the iframe.
When the attribute is set, the content is treated as being from a unique origin, forms and scripts are disabled, links are prevented from targeting other browsing contexts, and plugins are disabled.
The article lists these privileges as being reduced for “sandboxed” iframes:
- They cannot access the DOM of the parent page
- They cannot run scripts
- They cannot embed their own forms, or manipulate forms via scripts
- They cannot read or write cookies, local storage or local SQL databases
- This functionality will have to be implemented by browser manufacturers (I believe latest dev versions of Chrome already implement this functionality) and people who are falling victim to these attacks today are more than likely running out-of-date version of browsers (*cough* IE6 *cough*) so this won’t help them anyway
- The parent page can provide options to over-ride the controls, in case the 3rd party ad-provider requires scripts, which of course they all will
The blog makes it clear that this attribute, when it finally gets implemented*, is not the only thing your developers will have to do to provide areas for untrusted content. They will have to continue doing all the existing security “stuff” they’re doing now. I’m relieved to know that on top of all the pretty new features they’re putting into the new HTML specs (audio, video, ria, local storage, bling bling) that they are also looking to make inroads into making peoples browsing experience safer too.
*NB: This includes implementing the sandbox attribute, the text/html-sandboxed MIME type, and the srcdoc attribute – which could be quite a long way away.