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

On Tue, Jan 19, 2010 at 5:45 PM, Maciej Stachowiak <mjs@apple.com> 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...

There is also "social-engineering" redirect. I.e. put a giant <a
href="...">CLICK ME</a> on the page with the desired redirection uri.

/ Jonas

Received on Wednesday, 20 January 2010 01:53:05 UTC