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: Adam Barth <w3c@adambarth.com>
Date: Tue, 19 Jan 2010 17:52:18 -0800
Message-ID: <7789133a1001191752t629a2c0fn646d1646b1e20545@mail.gmail.com>
To: Ian Hickson <ian@hixie.ch>
Cc: Maciej Stachowiak <mjs@apple.com>, "public-html@w3.org" <public-html@w3.org>
On Tue, Jan 19, 2010 at 5:50 PM, Ian Hickson <ian@hixie.ch> wrote:
> 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?

Consider the case of Google Gears.  Gears provides access to databases
based on the origin of the embedding page.  Unfortunately, Gears
doesn't understand text/html-sandboxed and so would grant the
sandboxed content access to the origin's databases.

Adam
Received on Wednesday, 20 January 2010 01:53:11 UTC

This archive was generated by hypermail 2.4.0 : Saturday, 9 October 2021 18:45:08 UTC