[whatwg] The <iframe> element and sandboxing ideas

(Please pick one mailing list when replying, so as to reduce 
cross-posting.)

On Thu, 22 May 2008, Boris Zbarsky wrote:
> Ian Hickson wrote:
> >      - by default, content in sandboxed browsing contexts, and any
> >        browsing contexts nested in them
> 
> How do those nested browsing contexts come about, given that later you say:
> 
> >     - content in those browsing contexts cannot create new browsing
> >       contexts or open modal dialogs or alerts
> 
> ?

My summary was under-precise, my apologies. The spec itself seems to be 
unambiguous here, though let me know if I missed anything.


> >        have a unique origin
> >        (independent of the origin of their URI); this can be overriden
> >        using the "allow-same-origin" keyword
> 
> So the parent page cannot script the contents of the iframe by default, right?

Correct.


> >      - by default, script in those browsing contexts cannot run; this can
> >        be overriden using the "allow-scripts" keyword
> 
> What happens if the parent page sets window.location to a javascript: URI on
> the sandbox iframe?  Does the script run?  If so, in which browsing context?

If the "allow-same-origin" flag is not set, the javascript: doesn't run, 
as cross-orgin javascript: execution is blocked.

If the "allow-scripts" flag is not set, uh, *fixes error in the spec*.

Ok, if the "allow-scripts" flag is not set, then javascript: doesn't run, 
as javascript execution is blocked in sandboxed browsing contexts.


> >    causes the iframe to size vertically to the bounding box
> >    of the contents, and horizontally to the width of the container
> 
> I assume that the bounding box is computed after setting the width?

No need to assume. :-)

The spec text is at:

   http://www.whatwg.org/specs/web-apps/current-work/#attr-iframe-seamless

Please do let me know if that is suboptimal.


> >    and the style sheets that apply to the <iframe>
> >    must also apply to the contents.
> 
> But the ' ' and '>' combinators don't cross the iframe boundary, right?

It's as if the style sheets were imported directly by the inner frame.


> > This is all HIGHLY EXPERIMENTAL. I am looking for feedback on the 
> > general approaches taken.
> 
> As someone else pointed out, this doesn't seem like it would be usable 
> without some UA sniffing or something, as things stand.

Indeed. If someone can come up with a way of making this work in legacy 
UAs, I'd certainly be happy to change the spec to do that.


> > There are various things that this doesn't address yet; e.g. there's 
> > no way to force (or even allow) a non-seamless iframe to open links in 
> > the parent window.
> 
> This could be an @sandbox keyword value.

Indeed.


> > This attribute would take a string which would then be interpreted as 
> > the source document markup of an HTML document, much like the above
> 
> This seems very prone to security issues (injection of the closing quote 
> in the content) to me...  The base64 approach is nice in that you can't 
> shoot yourself in the foot with it.

You would only have to escape two characters (" and &, and in fact only 
the " is needed to be safe). Base64 would indeed be safer. (Right now it's 
the only option, as I haven't introduced doc='' yet.) But escaping just 
one character seems like a pretty low bar.

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'

Received on Friday, 13 February 2009 15:06:25 UTC