W3C home > Mailing lists > Public > public-web-security@w3.org > March 2011

Re: text/html-sandboxed should just be a sandboxed MIME type attribute

From: gaz Heyes <gazheyes@gmail.com>
Date: Tue, 29 Mar 2011 10:11:45 +0100
Message-ID: <BANLkTinwMKSqACGvZAf7RbvWjqY9qDnsfA@mail.gmail.com>
To: Jacob Rossi <jrossi@microsoft.com>
Cc: "public-web-security@w3.org" <public-web-security@w3.org>, "public-html@w3.org" <public-html@w3.org>, Adrian Bateman <adrianba@microsoft.com>
On 29 March 2011 07:33, Jacob Rossi <jrossi@microsoft.com> wrote:

>  (Including public-web-security for their feedback on this as well.)
> The iframe sandbox attribute is a self-described defense in-depth security
> feature. As such, there's no need to use a full MIME type to protect against
> non-supporting browsers (
> http://dev.w3.org/html5/spec/Overview.html#text-html-sandboxed). The spec
> text under "Security Considerations" makes it sound like text/html-sandboxed
> is the resolution to the sandbox attribute being defense in-depth, which is
> untrue. Furthermore, if web sites view this feature as "just send this mime
> type to be safer," then users of non-supporting browsers will experience
> file downloads or (in the case where another program/browser has registered
> to handle the type)the launch of part of the website in another
> program/browser. That's just a bad user experience IMO.
> What about other existing MIME types that might need to be sandboxed
> (image/svg+xml, application/xhtml+xml, etc.)? Do we really want to add new
> sandboxed MIME types for each of these? Really, these aren’t new types.
> Rather, they’re existing types with the caveat of a flag being set. A better
> option would be to use a MIME type attribute to indicate the content should
> be relegated to a unique domain (text/html;sandboxed or
> application/xhtml+xml;sandboxed). This would allow any existing (or future)
> type to be sandboxed. Additionally, it avoids the false impression that
> text/html-sandboxed is a definitive method of restricting the content from
> accessing the rest of the site.

There are two problems:
1) Any untrusted sandboxed content will be rendered for non-supporting
browsers or when the content is directly loaded without a iframe.
2) The mime type ensures that the content itself was intended to be

If the content is directly rendered when navigating to it then we would have
a XSS hole, I'd say in addition the no-sniff header needs to be served when
using sandboxed content. The mime type is a really crappy defence but what
would be better?

If we don't have a mime type then any content can be sandboxed which is bad
as it would allow an attacker to have fine grain control over the content of
the page.
Received on Tuesday, 29 March 2011 09:12:20 UTC

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