W3C home > Mailing lists > Public > public-webappsec@w3.org > November 2014

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

From: Brian Smith <brian@briansmith.org>
Date: Wed, 5 Nov 2014 22:39:13 -0800
Message-ID: <CAFewVt4CBiqULj6qEAJde4+KW1DS=Cg7hqm7sXw531FCvfK2ZA@mail.gmail.com>
To: "public-webappsec@w3.org" <public-webappsec@w3.org>
Hi,

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.

If frame-ancestor violation reports are NOT to be sent, then the above text
should be deleted, and the fact that violation reports are not sent should
be explicitly stated in a clarifying note.

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.

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 would actually recommend people use X-Frame-Options over
CSP frame-ancestors (assuming that Firefox fixes its X-Frame-Options
behavior), for this reason, unless it is clarified that frame-ancestors
violation reports are not to be sent.

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

Cheers,
Brian
Received on Thursday, 6 November 2014 06:39:40 UTC

This archive was generated by hypermail 2.3.1 : Monday, 23 October 2017 14:54:07 UTC