RE: text/sandboxed-html


> In any case, the text/html-sandbox defense is requirement for hosting
> untrusted content on the same server as ordinary web content,
> regardless of what tags or attributes are used to include the
> untrusted content by the victim. That's because an attacker's web site
> can try to load the untrusted content in a non-sandboxed iframe; this
> is a problem on both legacy browsers and future browsers. Hence, the
> text/html-sandboxed defense is required for both the <sandbox> tag and
> the @sandbox attribute of the <iframe> tag.

>
> Making <sandbox> a separate tag instead of an attribute of <iframe>
> doesn't eliminate the need to indicate the untrusted content with
> text/html-sandboxed, because of the problem of an attacker loading the
> content in a non-sandboxed iframe. The main difference between the
> <sandbox> tag and the @sandbox attribute is that they have slightly
> different syntax to handle the legacy fallback case; however both fail
> safely once the text/html-sandboxed defense is employed.


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.

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.

Looking from another angle, this <sandbox> proposal is very similar to <script> except the sandboxed script has no privileges.

Helen

Received on Wednesday, 27 January 2010 00:18:44 UTC