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

Brian Smith <brian@briansmith.org> wrote:
> The spec says "When generating a violation report for a frame-ancestors
> violation, the user agent MUST NOT include the value of the embedding
> ancestor as a blocked-uri value unless it is same-origin with the protected
> resource, as disclosing the value of cross-origin ancestors is a violation
> of the Same-Origin Policy."
>
> However, there is no text that says that a violation reports are to be sent
> for frame-ancestors violations. Are violation reports for frame-ancestors to
> be sent or not? This should be fixed, because it has non-obvious
> ramifications.

Mike West fixed this here:
https://github.com/w3c/webappsec/commit/dc83d2eab9f07e782d6ad8fd20aef6b519a1dc70

I agree with Mike's fix. More clarifications below.

> If frame-ancestor violation reports are to be sent: For almost all CSP
> directives, a violation indicates a serious security vulnerability in the
> web application (modulo violations caused by addons). So, usually an
> attacker cannot force a violation report unless there is already serious
> vulnerability in the web application. However, frame-ancestors is different.
> Any page can frame a page with a frame-ancestors constraint, which means any
> page can force a frame-ancestors violation. But causing a violation on many
> pages loaded by many users, the attacker's DoS abilities on the reporting
> server are easily amplified to create a huge DoS on the reporting server.
> This seems totally unnecessary.
>
> Because of this DoS potential, I believe that frame-ancestors violations
> should never be reported. Regardless, this issue should be mentioned in the
> security considerations of the document, at a minimum.

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.

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.

> The spec says "The frame-ancestors directive obsoletes the X-Frame-Options
> header."
>
> If violation reports are to be generated for frame-ancestors policy
> violations, then it is not true that frame-ancestors obsoletes
> X-Frame-Options, because X-Frame-Options does not cause violation reports to
> be generated.

I was just wrong about this. I agree frame-ancestors will eventually
be a fine replacement for X-Frame-Options.

> 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.

Cheers,
Brian

Received on Wednesday, 12 November 2014 00:15:57 UTC