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

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:
https://github.com/w3c/webappsec/commit/2406569ef9d8511197c5bfe6003b4b87a5aeba56


> > 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:
https://github.com/w3c/webappsec/commit/f2f6ec23dfc8cedbc523b4ead5a2eab39ce82c79.
WDYT?

-mike

--
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
Flores
(Sorry; I'm legally required to add this exciting detail to emails. Bleh.)