- From: Collin Jackson <collin@collinjackson.com>
- Date: Tue, 26 Jan 2010 13:52:39 -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 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 UTC