- From: Jonas Sicking <jonas@sicking.cc>
- Date: Tue, 19 Jan 2010 17:52:12 -0800
- To: Maciej Stachowiak <mjs@apple.com>
- Cc: Ian Hickson <ian@hixie.ch>, Adam Barth <w3c@adambarth.com>, "public-html@w3.org" <public-html@w3.org>
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