Comparison between <sandbox> and @sandbox

Apologies for the length of this email.  If you're not interested in
sandboxing, you can safely skip it.

== Executive Summary ==

<sandbox> and @sandbox address different use cases.

== 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.

Low-interaction use cases:

1) Advertising.  A publisher wishes to embed a third-part
advertisement but wishes to limit the privileges of the advertisement.
 For example, the publisher might be concerned about Flash-based
malware and might want to prevent the advertisement from instantiated
a Flash movie.

2) Image search.  Image search sites often embed an iframe to the
search results to show the image in the context of the rest of the
page.  However, the page can trick the user by navigating the top
frame to a malicious site that masquerades as the image search site.
The image search site might wish to prevent that from happening.

3) Blog comments.  Many blogs let user supply comments.  These
comments are displayed on the blog's page but the blogger does not
wish the comments to run with the same privileges as the blog itself.
Currently, most blogs limit user comments to plain text (possibly with
some formatting), but some advanced sites, such as MySpace, have
sophisticated filters that allow for richer comments.  These richer
media comments are difficult to secure with server-based filtering.

High-interaction use cases:

1) Interactive maps.  Sites like Yelp wish to integrate mapping
services from a third party (including the ability to scroll and add
restaurant markers to the map.  However, Yelp wishes to limit ability
for the map to take over the rest of the Yelp page.

2) Defensively secure systems.  One approach to building a complex web
application is to compose the web application from a set of mutually
distrusting software components.  These components need to interact to
create the application's user experience, but these components
distrust each other to prevent the compromise of one component from
leading to the compromise of the entire system.

== 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.

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.

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.

== 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.

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

== 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.

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.

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.

=== 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.

=== 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.

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

== 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?

Adam

Received on Thursday, 28 January 2010 23:52:08 UTC