RE: [webappsec] Including URI fragment in CSP reports (ACTION-43)

Doing an obnoxious top-post because I'm using Outlook :(

The one case I can think of that might be especially relevant was the "universal XSS" against Reader, in which the XSS payload was in a fragment but only used by the client.  Could this happen for DOM-XSS as well and be relevant?  If so, we should at least consider it.   Each content author should know whether they are generating pages with fragment identifiers, and whether those are private, and can control their policy appropriately.  I don't know of any cases where we expect the client to use fragment identifiers that are "secret" as it relates to the Origin that "authored" the content....  Though I admit terminology is rough here and my apologies if I'm mangling definitions too much.

- Andy

From: Hill, Brad [mailto:bhill@paypal-inc.com]
Sent: Monday, January 30, 2012 4:25 PM
To: public-webappsec@w3.org
Subject: [webappsec] Including URI fragment in CSP reports (ACTION-43)

On our last WG call, we raised the issue of URI fragments in CSP reports.   Currently, the specification calls for the "HTTP request line of the protected resource whose policy was violated including method, URI and HTTP version".  This would exclude URI fragments as they are not sent with the request, but processed locally in the User-Agent.  This appears to be correct behavior, as fragments are sometimes used for private context and should not leak, especially in non-same-origin reports.

I would like to propose that the spec be amended to explicitly forbid the sending of URI fragments as a clarification.  Are we aware of any cases where this prohibition would negatively impact the usefulness of the reports?




Brad Hill