[whatwg] some thoughts on sandboxed IFRAMEs

[Adam Barth]

On Sun, Dec 13, 2009 at 2:13 PM, Michal Zalewski <lcamtuf at coredump.cx> wrote:
>> How do I use the <jail> tag to sandbox advertisements?
>
> Huh? But that's not the point I am making... I am not arguing that
> iframe sandbox should be abandoned as a bad idea - quite the opposite.
>
> I was merely suggesting that we *expand* the same logic, and the same
> excellent security control granularity, to span and div; this seems
> like it would not increase the implementation complexity in any
> significant way.

Implementation complexity is not the gating factor.  Implementing
<canvas> is orders of magnitude more complex than any of the proposals
we've seen so far.  The gating factor is discovering simple, robust
mechanisms that provide security for the key use cases.

> We could then allow these to be populated with secure
> contents in three ways:
>
> 1) Guarded closing tag - this is simple and bullet-proof; but may
> conflict with XML serializations, and hence require some hacks,
>
> 2) CDATA or @doc-like approaches. Less secure because it does not
> enforce a security control, but less contentious, and already being
> considered for IFRAMEs.
>
> 3) .innerHTML, which would be then safe by default, without the need
> for .innerSafeHTML (and the associated ambiguities) or explicit
> .toStaticHTML calls.
>
> This allows people to utilize the mechanism for so many more
> additional use cases without the performance and usability cost of
> IFRAMEs, and does not subvert the original ad / gadget use case in any
> way.
>
> *This* is what I find greatly preferred to having separate, completely
> disjointed APIs with different semantics for ads / gadgets and other
> "full page" contents, for small snippets of JS-inserted HTML, and for
> server-returned data.

It sounds like you think we should proceed with @sandbox and also do
something with inline HTML.  Ian has already asked browser vendors to
experiment in these areas and try to gain some implementation
experience.  I'd encourage you to write up your thoughts in a brief
spec along the lines of the "DOM-based HTML Sanitizer" document I sent
to this list a while back.

I'm very interested in a solution that works for the following use cases:

1) A web page wants to display untrusted (i.e., restricted) HTML
received via cross-site XMLHttpRequest or postMessage.

2) A blog wishes to display many comments containing untrusted (i.e.,
restricted) HTML.

I'm certainly not married to my proposal.  In fact, I'm planning to
update it based on the feedback I've received here an elsewhere.

>> The sandbox tag is great at addressing that use case.  I don't see why
>> we should delay it in the hopes that the <jail> tag comes back to
>> life.
>
> I am not suggesting this at all; extending the spec to cover, or at
> least hint these cases would be a good idea. This is not to say the
> functionality as currently speced out should be scraped. My points
> were:
>
> 1) If we want to keep it limited to the ads / gadget case, we should
> make it clear in the spec, reconsider the applicability of
> allow-same-origin in this context,

allow-same-origin is useful if the advertisement wishes to retrieve
additional information from its origin, e.g via XMLHttpRequest or the
<video> tag.  For example, the ad might want to show a video from its
origin and be able to interact with the video without the cross-origin
restrictions.

> and definitely revise the as of now unsafe getusercontent example, etc.

I agree what we should revise that example.

> I am not entirely sold that this
> is a beneficial strategy in the long run, but as long as the
> alternatives were considered, so be it.
>
> 2) If we want to make the implementation useful for other scenarios as
> well, and avoid the proliferation of HTML-sandboxing APIs with
> different security controls, we should still keep the spec mostly as
> is, and I have no objection to implementations incorporating it; BUT
> it would be beneficial to allow it to be extended as outlined above,
> or in a similar general way, specifically making it easy to sandbox
> inline HTML, and to place thousands of sandboxed containers on a page
> without making the renderer implode.

These concerns seem to be with the implementation and not the spec.
We certainly can expand the web platform after HTML5.  I must be
misunderstanding something.

On Sun, Dec 13, 2009 at 2:31 PM, Michal Zalewski <lcamtuf at coredump.cx> wrote:
> And Adam - as you know, I have deep respect for your expertise and
> contributions in this area, so please do not take this personally...
> but this really strikes me as throwing random ideas at the wall, and
> seeing which ones stick.
>
> This is sometimes beneficial - but we are dealing with possibly
> revolutionary security mechanisms in the browser, meant to counter one
> of the most significant unsolved security challenges on the web.

I'm not sure its that revolutionary, but I'm glad you think it's important work.

> And this mode of  engineering is probably why we have a different
> same-origin policies for XMLHttpRequest, DOM  access, cookies,
> third-party cookie setting, Flash, Java, Silverlight... plus assorted
> ideas such as MSIE zones on top of it. It's the reason why their sum
> is less secure than each of the mechanisms individually.

I'm not sure I see the connection here.  Nothing we write in the spec
is going to help Flash, Java, Sliverlight, or
proprietary-technology-of-the-week from making up their own security
model.  Documenting the browser security policy in HTML5 might help,
but we can't stop these folks from making up their own rules.

> Still, this is not an attempt to dismiss the hard work: implementing
> sandboxed IFRAMEs as-is and calling it a day *will* make the Internet
> a safer place.

I'm not sure why you think we're calling it a day.  @sandbox doesn't
address all the use cases I think are important, but it does address
the one that I think is the most important.

> But a collection of walled off, incompatible APIs with
> different security switches and knobs, all of  them to perform a
> common task, does strike me as suboptimal - and I do think it's
> avoidable. Especially since, I am guessing, some of the pragmatic
> objections to guarded tags were probably due to implementation
> complexity or dubious usability, all of which are probably moot with
> @sandbox in place.

You've already said that <jail> doesn't address the most important use
case.  Until we have another way of addressing that use case, I don't
think we should wait around for the grand unified browser security
mechanism.

> Furthermore, in this particular case, I am really concerned that the
> spec is at odds with itself - you mention certain specific use cases,
> but the spec seems to be after a broader goal: sandboxing
> user-supplied content in general. In doing so, it gives some bad
> advice (again, the user content example is exploitable, at least until
> the arrival of some out-of-scope security mechanism to prevent it).

I agree that we should revise that example.

Adam