Better IFrames Better Sandboxing

From RuntimeWiki

Jump to: navigation, search

Contents

Title

Better IFrames Better Sandboxing

Detailed write-up

Description

IFRAMEs are an essential tool for secure mashup todays because the feature represents pretty much the only mechanism for isolating untrusted content within a web page. Most commercial or Enterprise mashup tools today, such as Google Gadgets, put gadgets into an IFRAME (using a different domain or subdomain) so that the gadget cannot interact with the DOM or JavaScript objects outside of that IFRAME.

However, IFRAMEs lack important flexibility and represent a heavyweight answer to features that could benefit from a lightweight solution. Depending on the use case, sometimes IFRAMEs are too restrictive, and in other cases they are too loose.

Too restrictive:

  • Sometimes, the same-domain implementation gets in the way unnecessarily, and the developer wants an IFRAME from a different domain or subdomain to have the ability to bridge into the parent frame's DOM and JavaScript
  • In some cases, it would be nice if the content for the IFRAME could be inline instead of referenced
  • Sometimes the developer would like events to bubble up from the IFRAME into the main document in the same manner as would happen if the content had been placed inline inside of a DIV
  • Sometimes the developer would like CSS stylesheets to bubble down from the main document into the IFRAME in the same manner as would happen if the content had been placed inline inside of a DIV
  • Sometimes the developer would like the IFRAME to auto-size (like a DIV) based on the size of the content within the IFRAME

Too loose:

  • In some mashup scenarios, 3rd party content is delivered via a proxy server that is in the same domain as the main web page. In this case, the browser does not sandbox the IFRAME. It would be advantageous if the browser had an option to sandbox an IFRAME even if it came from the same domain.
  • Also, would be nice to prevent selected IFRAMEs from moving or resizing, or blocking communicating with other iframes even if from the same domain

Too slow and heavyweight:

  • IFRAMEs are implemented in a heavyweight manner, which is understandable since the model is that it represents a whole new web page, but for secure mashup scalability, it would be great if there were mechanisms to allow for lighterweight sandboxing

Why Is This Important?

See above.

Possible Solutions

Adding a "hash" attribute to all elements that has "href" or "src" attribute

This came up during the OpenAjax F2F discussion at NYC on March 27th 2008. It looks like a very sensible approach to enhance security in general (such as cross site scripting, iframe sandbox) as well as web performance (by enabling more effective caching).

Ajaxian.com reported this proposal here - Not sure whether Douglas Crockford has some writeup on this or not. Citing from Ajaxian.com report from Douglas:

Any HTML tag that accepts a src= or href= attribute should also be allowed to take a hash= attribute. The value of a hash attribute would be the base 32 encoding of the SHA of the object that would be retrieved. This does a couple of useful things.

First, it gives us confidence that the file that we receive is the one that we asked for, that it was not replaced or tampered with in transit.

Second, browsers can cache by hash code. If the cache contains a file that matches the requested hash=, then there is no need to go to the network regardless of the url. This would improve the performance of Ajax libraries because you would only have to download the library once for all of the sites you visit, even if every site links to its own copy.


'sandbox' attribute on IFRAME and DIV

One part of the solution could be a 'sandbox' attribute on an IFRAME and DIV, with values auto, true and false. auto would result in today's browser behavior. true would force the IFRAME or DIV into a sandbox (even if the IFRAME were from the same domain as the parent web page). false would allow an IFRAME to bridge into the parent web page even if the IFRAME were from a different domain/subdomain.

(Note: DIV would need an attribute to identify its domain for when sandbox=true)

<module> tag and/or a revamped DOM and JavaScript

Doug Crockford has given keynotes lately where he calls for a more fundamental attack on security vulnerabilities, including major overhauls of how DOM and JavaScript work.

He has proposed the <module> tag (http://json.org/module.html) to associate a particular domain with a particular snippet of HTML and results in sandboxing that snippet from the rest of the document (i.e., DOM and JavaScript).

Doug has also proposed a safe subset of ECMAScript (someone, please insert a link).

Add Capabilities to iframes

This is based on some ideas from Dimitri Glazkov around cross-domain workers in Gears. What if when you create an iframe you could say what Capabilities it has? Capabilities is an idea from the security field where instead of saying all or nothing you can give something access to particular capabilities, with everything off by default. Some of these capabilities could be full DOM access, limited DOM access (just to say particular IDs or classes), script access, XHR access, etc. Not sure of what the syntax might look like, but perhaps something like the following:

<iframe capabilities="limited-DOM DOM-read-only X-XHR" access-to=".hcard">

This would create an iframe that has limited DOM access but which can run cross-domain XHR. The 'access-to' element says that the iframe can only access elements that have the class '.hcard', possibly useful for an iframe to glean all of the microformat data on the page that are hcards. The DOM-read-only says that the iframe can only read the DOM, not modify it.

Background material that request this feature

Discussion

In this section, the contributors should express their opinions about this feature request, such as providing particular technical analysis or describing in prose why this feature is important (or not). It is recommended that each contributor create his own level-3 sub-section (e.g., === Jon Ferraiolo Comments ===).

It is OK for others to insert comments within other people's sections, but as a courtesy please make sure that it is clear which part of the section is original and which section are annotative comments. For example, perhaps annotative comments would be colorized (e.g., enclosed by <span style="color:red">JON: Here is what I think about what you are saying.</span>).

Brad Neuberg's Comments

I'm surprised there aren't more comments here yet. I've been seeing what Google Gadgets has been doing with iframes to act as a containment mechanism and I've been impressed (disclosure: I work for Google). iframes have the potential to be a good containment mechanism. With a little iteration they could also be a light-weight component mechanism, which is essentially how others have been using them.

To get to this, we need more of a capabilities based model with them (I propose something like this above), plus solve some of the pragmatic issues they have around sizing. Getting an iframe's height to size to the surrounding content can be a challenge on some browsers. Also, it would be nice if a document can create an iframe and do a document.open into it, but actually specify the MIME type of what you are writing in so you can write XML into an iframe (document.open support setting the MIME type, see here http://developer.mozilla.org/en/docs/DOM:document.open , but not all browsers support it).

Mike Wilson's Comments

Recently there has been additions to the HTML5 draft related to this: http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2008-May/014874.html

Phase I Voting - Vote for Your Top 5 Features

NOTE: PHASE I VOTING IS NOW OPEN. (2008-04-01) We have now changed the voting procedure. Instead of putting votes on each separate wiki page, we are asking people to cast their Phase I Votes on the following wiki page:


Phase II Voting

More about this later.

Personal tools