W3C home > Mailing lists > Public > public-webappsec@w3.org > January 2015

Re: [CSP] How to interpret 'self' in a sandboxed iframe

From: Anne van Kesteren <annevk@annevk.nl>
Date: Mon, 12 Jan 2015 10:37:55 +0100
Message-ID: <CADnb78je6gbo53A-BS-o4Bt9WXaVppHrB3EZvvkXn51pbKh_Gw@mail.gmail.com>
To: Daniel Veditz <dveditz@mozilla.com>
Cc: Joel Weinberger <jww@chromium.org>, "public-webappsec@w3.org" <public-webappsec@w3.org>
On Mon, Jan 12, 2015 at 8:50 AM, Daniel Veditz <dveditz@mozilla.com> wrote:
> We have a similar confusion with frame-ancestors and sandboxed frames.
> If your content is put into a sandbox with a unique origin does that
> mean that all sub-documents that use a CSP with frame-ancestors will be
> blocked because no one can match a unique origin? From one very narrow
> view you could say that the parent content was sandboxed because it
> wasn't fully trusted and therefore if frame-ancestors is a list of
> trusted framers then blocking is the right result. But mostly we'll get
> very sad broken pages and ultimately less use of frame-ancestors and/or
> sandboxed frames. Keep in mind that content can be sandboxed against its
> will if that helps an attacker.

Creating a third type of origin however should not be done lightly
either. Already with "effective script origin" and "origin" it turns
out that often the wrong one is used for security checks. Making this
even more complicated in the case of sandboxing sounds problematic.

Received on Monday, 12 January 2015 09:38:22 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 18:54:44 UTC