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

Re: [CSP] Problems with frame-ancestors; X-Frame-Options not obsolete?

From: Mike West <mkwst@google.com>
Date: Thu, 15 Jan 2015 15:34:45 +0100
Message-ID: <CAKXHy=cuMVKW_QnOTuif0J7Nd_gUoe=aMwdjuhQ5_GGZg8FWOQ@mail.gmail.com>
To: Brian Smith <brian@briansmith.org>
Cc: "public-webappsec@w3.org" <public-webappsec@w3.org>
On Wed, Nov 12, 2014 at 1:15 AM, Brian Smith <brian@briansmith.org> wrote:

> To correct myself: I still think this is worth adding to the security
> considerations, but I now understand that I was wrong to suggest that
> the CSP spec should say "frame-ancestors violations should never be
> reported." Instead, CSP policy authors can (and probably should) write
> their policies in such a way that they prevent frame-ancestors
> violation reports are not sent:
> Content-Security-Policy: frame-ancestors 'self', script-src 'self';
> report-uri=http://violations.example.com
> My understanding is that this policy will result in violations being
> sent for everything EXCEPT frame-ancestors violations.

That's correct. Since it took me a minute to understand why: the ',' means
that the header's value is split during processing into multiple headers,
and each is parsed separately.

> Note that this is one of the reasons why I think the statement "To
> enforce multiple policies, the administrator SHOULD combine the policy
> into a single header." is wrong.

Added a note:

> > NIT: The text says "Steps 2.2 and 2.3 ensure that the blocked frame
> appears
> > to be a normal cross-origin document’s load. If these steps are ignored,
> > leakage of a document’s policy state is possible." s/2.2/3.2.2/ and
> > s/2.3/3.2.3/.
> >
> > NIT: The text says "The user agent MAY implement these steps by instead
> > redirecting the user to friendly error page in a unique origin which
> > provides the option of opening the blocked page in a new top-level
> browsing
> > context." This contradicts the text that says "To enforce the
> > frame-ancestors directive [...] the user agent MUST perform the following
> > steps: [...]" In particular, a MAY cannot override a MUST. Instead,
> either
> > one way of doing things should be specified (preferred), or the MUST text
> > should be rewritten to specify both alternatives as options (less
> > preferred).
> I think these suggestions are still right though.

Poked at both in:


Mike West <mkwst@google.com>, @mikewest

Google Germany GmbH, Dienerstrasse 12, 80331 München,
Germany, Registergericht und -nummer: Hamburg, HRB 86891, Sitz der
Gesellschaft: Hamburg, Geschäftsführer: Graham Law, Christine Elizabeth
(Sorry; I'm legally required to add this exciting detail to emails. Bleh.)
Received on Thursday, 15 January 2015 14:35:38 UTC

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