RE: text/sandboxed-html


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

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

The semantics of the revised <sandbox> is to help a web site to safely include third-party scripts without giving them all of the site's privileges, but not to prevent a piece of untrusted content from being rendered with the privilege of an origin (as in the original MashupOS proposal). It is true that the new semantics is not as strong as the old one, but it is still very useful for constructing secure mashups and containing third party JavaScript. In the light of this discussion, I'd revise the design to deny the <sandbox> content to create new iframe elements at any time.

You are right that I am assuming that the user hasn't been attacked by visiting an attack page. I think all is pretty much lost if the user does that. Also, if a web server doesn't want the third party content that it is hosting to ever run with its privilege or interfere with other third party content, the web server could just host each third party content on a separate domain.

Helen

Received on Wednesday, 27 January 2010 00:56:42 UTC