W3C home > Mailing lists > Public > public-web-security@w3.org > January 2010

Re: text/sandboxed-html

From: Collin Jackson <collin@collinjackson.com>
Date: Tue, 26 Jan 2010 14:44:48 -0800
Message-ID: <986207e71001261444v43960680q6774e13acd5d1cb4@mail.gmail.com>
To: "Helen Wang (MSR)" <helenw@microsoft.com>
Cc: "public-web-security@w3.org" <public-web-security@w3.org>
On Tue, Jan 26, 2010 at 2:23 PM, Helen Wang (MSR) <helenw@microsoft.com> wrote:
> This <sandbox>'s semantics differs from that of the original MashupOS sandbox.
> The only goal of the revised <sandbox> is to allow a host page to restrict a public
> script.  The original MashupOS sandbox proposal additionally wants to allow a web
> server to indicate that some hosted content is untrustworthy and shouldn't be
> rendered with any origin' privilege. This latter semantics is lost in the revised
> proposal in exchange for the elimination of setting the MIME type for easy deploy-ability.

Since the attackers control the untrusted content intended for the
<sandbox>, they are free to make it script-like or document-like or
SWF-like. We still need to consider the scenario where the attacker
points an <iframe> or <object> tag at the untrusted content, even
though this wouldn't make sense in a non-attack scenario.

> Please note that <sandbox>'s "src" can *only* be a script, but not any other type
> of content. This together with its intended semantics make it fine without setting
> MIME type.

Since there is no mechanism preventing the attacker from making an
iframe that points at the <sandbox>'s "src" attribute, the site needs
some way of preventing the content from rendering as HTML, even though
it will normally be script in non-attack scenarios. Serving up content
with the mime type text/javascript (or application/x-javascript) works
about as well as text/html-sandboxed (same IE6 and Flash caveats).

Collin Jackson
Received on Tuesday, 26 January 2010 22:48:06 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:26:17 UTC