- From: Collin Jackson <collin@collinjackson.com>
- Date: Tue, 26 Jan 2010 14:44:48 -0800
- 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