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: Maciej Stachowiak <mjs@apple.com>
Date: Tue, 19 Jan 2010 17:45:28 -0800
Cc: Adam Barth <w3c@adambarth.com>, "public-html@w3.org" <public-html@w3.org>
Message-id: <9D31E7FF-51AE-46AB-9469-33D239676FCE@apple.com>
To: Ian Hickson <ian@hixie.ch>

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

Regards,
Maciej
Received on Wednesday, 20 January 2010 01:46:01 UTC

This archive was generated by hypermail 2.3.1 : Monday, 29 September 2014 09:39:12 UTC