W3C home > Mailing lists > Public > public-html@w3.org > January 2010

Re: Disallow plug-ins in text/html-sandboxed? (was: Re: text/sandboxed-html)

From: Ian Hickson <ian@hixie.ch>
Date: Wed, 20 Jan 2010 01:50:13 +0000 (UTC)
To: Maciej Stachowiak <mjs@apple.com>
Cc: Adam Barth <w3c@adambarth.com>, "public-html@w3.org" <public-html@w3.org>
Message-ID: <Pine.LNX.4.64.1001200146190.3759@ps20323.dreamhostps.com>
On Tue, 19 Jan 2010, Maciej Stachowiak wrote:
> On Jan 19, 2010, at 5:35 PM, Ian Hickson wrote:
> > On Wed, 13 Jan 2010, Adam Barth wrote:
> >> 
> >> There are actually two things going on here, and we should be careful 
> >> to make sure each works correctly:
> >> 
> >> 1) Content loaded in an iframe with the @sandbox attribute.  Here,
> >> Maciej is correct that plug-ins are disabled.
> >> 2) Content loaded with the media type text/html-sandboxed.  Here, as
> >> described by Ian in his email, I think plug-ins are still allowed.
> >> 
> >> We probably should disallow plug-ins in case (2) for the same reason 
> >> we disallow them in case (1): Existing plug-ins likely won't respect 
> >> the unique origin of the document.  For example, I bet Gears would 
> >> let a "text/html-sandboxed" document access the database for it's 
> >> normal origin.
> > 
> > Wouldn't it be trivial to get around this restriction in case #2 by 
> > just making the page redirect to the plugin full-page?
> That presumes the attacker has a plugin-full page at the victim origin 
> being served as text/html. In which case they have already violated the 
> intent of sandboxing, presumably.
> Also, what kind of redirect?
> - Script-based redirects presumably don't work without allow-script
> - HTTP redirects imply that attacker controls the headers, in which case they could just use Content-Type: text/html
> - Meta refresh seems like a way any sandboxed content could redirect, and maybe shouldn't be allowed...

I guess I don't understand the attack scenario you are concerned with. 
Could you elaborate on what the attack scenario is which would be 
protected by making a text/html-sandboxed page prevent plugins?

Note that such a page doesn't prevent scripts, forms, page navigation, or 
anything else that sandbox="" does currently -- it only forces the origin 
into a unique origin, blocking the ability for the attacker to direct a 
user to that page directly to sidestep the sandbox protections. There's no 
point blocking the other things as far as I can tell, since the attacker 
could then just direct the user to the same page on their site.

Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'
Received on Wednesday, 20 January 2010 01:50:42 UTC

This archive was generated by hypermail 2.3.1 : Thursday, 29 October 2015 10:15:57 UTC