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 13:52:39 -0800
Message-ID: <986207e71001261352y4f84d4bib6b57f46b9381a12@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 5:08 AM, Helen Wang (MSR) <helenw@microsoft.com> wrote:
> Letting web servers indicate the MIME type definitely improves the current
> sandbox design as long as MIME sniffing is not in the way. That is a legacy
> UA does not recognize the sandbox MIME type and then it sniffs and renders
> the content as text/html, elevating the privilege of the sandboxed content
> as a result.

I have been unable to find any existing browsers that are willing to
sniff text/html-sandboxed as HTML. I have tried various versions of
IE, Firefox, Google Chrome, Safari, and Opera. Most browsers try to
download the content as a file or show a warning; Safari renders it as
plain text.

> Also, the deployment hurdle is that web servers must correctly mark the MIME
> type for sandboxed content. This could be a tall order.

It is fair to call this a tall order. One potential mitigation is that
browsers could show a warning when developers try to include
non-text/html-sandbox content in a sandbox iframe.

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.

> I wrote a revision to our original MashupOS sandbox proposal [1] to retain
> the basic sandbox semantics while eliminating web servers setting the
> sandbox MIME types. I am attaching my writeup below. We use a "SANDBOX" tag
> rather than a "sandbox" attribute of an iframe so that legacy UAs will not
> be able to render the content with higher privileges. Must we piggy-back 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.

Collin Jackson
Received on Tuesday, 26 January 2010 21:54:15 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Sunday, 19 December 2010 00:16:02 GMT