RE: Comparison between <sandbox> and @sandbox

Sorry, folks, that I wasn't clear with my terminologies.
"provider" = "hosting site", which is the site that hosts and serves the content.

For example: http://integrator.com/index.htm may contain an element <sandbox src="http://provider.com/possibly3rdPartyScript.js">

Hope this clarifies some things,

Helen

-----Original Message-----
From: Helen Wang (MSR) 
Sent: Thursday, January 28, 2010 6:02 PM
To: 'Adam Barth'; HTML WG
Cc: Collin Jackson
Subject: RE: Comparison between <sandbox> and @sandbox

Thanks, Adam, for the methodical and detailed analysis!  Please see my comments and additional analysis inline.

> == Use Cases ==
>
> I think part of the reason there is such a diversity of opinion on
> sandboxing content in HTML is that there are a wide variety of use
> cases we could hope to address.  In particular, Helen's <sandbox>
> proposal appears targets at mashups in which the integrator and the
> gadget which to interact extensively (e.g., via JavaScript calls such
> as aSandbox.map.setCenter).  However, @sandbox is optimized for adding
> defense-in-depth to current mashup designs that either have little
> interaction or use a message-passing API built with postMessage.

I'd say <sandbox> is optimized for mashing up untrusted scripts while @sandbox is for mashing up same-domain-hosted untrusted iframes. I'd say the former has been very common and the latter is becoming common with the advent of PostMessage.

> Low-interaction use cases:
> 
> 1) Advertising.  A publisher wishes to embed a third-part
> advertisement but wishes to limit the privileges of the advertisement.

Advertising is not necessarily low interaction since there are JavaScript-based ads that interact intimately with its host page.

>  For example, the publisher might be concerned about Flash-based
> malware and might want to prevent the advertisement from instantiated
> a Flash movie.

Neither sandbox proposals allow inclusion of plugin content.

> == Design Space ==
> 
> The design space seems to break down as follows:
>
> A) How does the sandboxed content run in legacy browsers?  There are
> two options here: legacy-open and legacy-closed.  In the legacy-open
> model, the content renders in legacy browsers in some security
> context.  In the legacy-closed model, the content does not render in
> legacy browsers.

<sandbox> is trying to sandbox existing scripts out there.  A script runs with the context of its includer in legacy browsers when included as <script>, and may run as its origin when included as <iframe> due to MIME sniffing.

> B) Do we expect authors to host untrusted content on-domain or
> off-domain?  In the on-domain model, we expect authors to host
> untrusted resources by somehow shield them from receiving the origin's
> full privileges.  In the off-domain model, authors host untrusted
> content on a "throw away" domain (such as gmodules.com) and we expect
> that content to obtain the (somewhat uninteresting) privileges of that
> origin.

The goal of <sandbox> is not to protect the hosting site, but the integrator.
Of course, it is the best for a hosting site to host untrusted scripts on a throwaway domain to protect its own domain.

In contrast, @sandbox is to protect a hosting site from the third-party content hosted on the same domain. 

We should add this dimension in our analysis: goal of protection, integrator or hosting site.

> C) How (and to what extent) do we expect the hosting site to interact
> with the sandboxed content?  To optimize for high-interaction use
> cases, we want to make this interaction as easy as possible (while
> maintaining security).  However, the low-interaction use cases can be
> satisfied with little or no interaction with sandboxed content.

Hosting a script allows high interaction no matter which domain the script is hosted. 
For low-interaction use cases, why don't a hosting site simply host the content in a throwaway domain, which seems almost as simple as doing @sandbox; what do people think about this?

> == Proposals ==
> 
> Rather than get tied up in the details of the syntax of the various
> proposals, I think it might be helpful to look at how they fall into
> this design space:
> 

> * @sandbox is a legacy-open, off-domain mechanism that is optimized
> for low-interaction use cases.

Without MIME type specification, @sandbox does not achieve its goal of protecting the hosting site.
However, as we discussed, MIME-sniffing in legacy browsers also defeats MIME type specification.  (This is exactly what led me to revise the original MashupOS sandbox proposal.)

> * <sandbox> is a legacy-closed, on-domain mechanism that is optimized
> for high-interaction use cases.

<sandbox> is not exactly legacy-closed since "script" content can run in legacy browser (and an integrator can express alternative way of rendering that content when <sandbox> is not available).  "on-domain" or "off-domain" is irrelevant for <sandbox> since <sandbox> is for the integrator who wants to protect itself. And yes, <sandbox> is definitely for high-interaction use cases (just as <script> is).


> == Relative Merits ==
> 
> === Legacy Open or Closed ===
> 
> Legacy-open is useful for authors who want to add defense-in-depth to
> already existing security mechanisms.  For example, instead of forcing
> advertisers to re-write their advertisements, a publisher might want
> to restrict their privileges in newer browsers that support
> sandboxing.

I am kind of worried about such a legacy-open scenario. What security goal does it really achieve? Are the publishers protected or not from potentially malicious ads? The answer is "sometimes, depending on the browser version of a request". Will publishers be really happy with this? I suspect not. 

> Legacy-closed is better for folks who want more assurance that the
> untrusted code will run only under the sandboxed conditions.  Note
> that even if the API is legacy-closed, we still need some way to
> prevent the content from being rendered in legacy browsers if the
> attacker directs the user's browser directly to the untrusted content.

Here, we need to divide the responsibility. Integrator and provider (hosting site) should each have responsibilities protecting themselves. Integrators can use <sandbox>, and provider can choose to host untrusted content on throwaway domains.

> At a higher-level, authors can transform a legacy-open API into a
> legacy-closed API using browser feature detection.  Similarly, authors
> can perform the opposite transformation if the legacy-closed
> environment matches a programming environment that exists in legacy
> browsers.  For <sandbox>, in particular, I'm not sure how an author
> would create a legacy-open system because the programming environment
> is novel.


For <sandbox>, the integrators need to be explicit on what to do when <sandbox> is not supported. It is up to the integrators to decide whether legacy and new browsers will render the content with the same behavior or not.

> === On or Off Domain ===
> 
> The main advantage of hosting the untrusted content on-domain is that
> we can allow richer interaction with the untrusted content than we can
> if the content is hosted off-domain because we can be assured that the
> untrusted content wishes to interact with hosting page.  Therefore,
> hosting the untrusted content on-domain is more attractive when
> optimizing for high-interaction use cases.
> 
> The main risk of hosting the untrusted content on-domain is we need a
> secure way of preventing legacy (and supporting!) browsers from
> rendering the content with the full privileges of the origin.  HTML5
> currently suggests using the media type text/html-sandboxed to prevent
> legacy browsers from rendering on-domain untrusted content (although
> there seem to be some subtleties related to file extensions in IE6 and
> to Flash).  The <sandbox> API encourages on-domain hosting, but I'm
> not sure what mechanism it uses to prevent legacy user agents from
> rendering the content as fully privileged HTML.
>
>	
> Hosting the untrusted content off-domain limits its privileges to the
> default set of privileges afforded arbitrary web sites.  The security
> argument here is that if the attacker can convince the user's browser
> to render the throw-away domain outside of the sandbox, the attacker
> can probably convince the user's browser to render attacker.com
> outside of the sandbox.

I hope I have made convincing arguments that hosting on or off domain does not matter to integrators's safety, but only that of providers' (hosting sites).   <Sandbox> cares only about integrators.
In contrast, @sandbox cares only about providers (hosting domains); therefore, on-domain, off-domain matters and affects high/low interaction as well.

> === High or Low Interaction ===
>
> To some extent, whether we'd prefer to have a high or low interaction
> sandboxing mechanism depends on which use cases we're interested in
> targeting.  However, there are some technical considerations that
> apply to both cases.
> 
> The <sandbox> API combines two things: (1) a way to render content
> with reduced privileges and (2) a way to interact with that content.
> HTML5, as currently specced, separates those concerns.  Reducing
> privileges is handled by @sandbox and interaction is handled by
> postMessage.  These can be combined to both provide privilege
> reduction and interaction simultaneously.

<sandbox> is very analogous to <script>, except to reduce the privilege of the script. In fact, it is probably possible to implement <sandbox>'s high interaction part with PostMessage (this is like RPC implemented with IPC.), though I don't think it is necessary to go with such an inefficient implementation (my original specification gave an implementation guideline based on our prototype experience.)


> For high-interaction use cases, the direct JavaScript interaction
> model of <sandbox> is easier to author than the message-passing
> interaction model of postMessage.  Helen and I have a somewhat
> long-standing disagreement about whether direct interaction between
> trusted and untrusted JavaScript objects provides robust security for
> authors.  Collin Jackson, William Li, and I have written a paper
> recently presenting our arguments on this point:
> 
> http://www.adambarth.com/papers/2009/barth-jackson-li.pdf

Yup, I am not convinced by the arguments in this paper.  I feel optimistic from our prototyping experience that a reliable reference monitor is possible between rendered engine and JavaScript engine to realize the asymmetric access of <sandbox>. 


> == Summary ==
> 
> The @sandbox mechanism seems to be better optimized for
> low-interaction use cases.  Using postMessage, @sandbox can cover the
> interactive maps use case with some amount of author effort.  The
> <sandbox> mechanism appears optimized for high interaction use cases,
> such as defensively secure systems.
> 
> Based on my current understanding, there are three open challenges
> with <sandbox>:
>
> 1) How can authors construct a legacy-open systems using code written
>for the <sandbox> programming environment?
>
> 2) How can authors host untrusted content on-domain for <sandbox>
> without granting that content the full privileges of their origin in
> legacy browsers?
> 
> 3) Can user agent implements and web authors secure direct JavaScript
> references (as used by <sandbox>) between mutually distrusting
> principals with reasonable assurance?


To sum up my inline responses:
1) integrators need to explicitly deal with legacy browser.
2) it is up to providers (hosting sites) to protect themselves by hosting untrusted content on throwaway domain.
3) I believe so!

A key difference between <sandbox> and @sandbox is that <sandbox> is for integrators to protect themselves while @sandbox is for providers to protect themselves. 

Two key concerns for @sandbox after much discussion so far:
- MIME sniffing defeats @sandbox's protection for providers on legacy browsers
- if @sandbox is for low-interaction applications, why don't providers host untrusted content on throwaway domains?

Cheers,

Helen

P.S., I have really enjoyed all the great discussions on this list!

Received on Friday, 29 January 2010 03:56:15 UTC