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