{"action":"created","issue":{"url":"https://api.github.com/repos/w3c/webappsec-csp/issues/119","repository_url":"https://api.github.com/repos/w3c/webappsec-csp","labels_url":"https://api.github.com/repos/w3c/webappsec-csp/issues/119/labels{/name}","comments_url":"https://api.github.com/repos/w3c/webappsec-csp/issues/119/comments","events_url":"https://api.github.com/repos/w3c/webappsec-csp/issues/119/events","html_url":"https://github.com/w3c/webappsec-csp/issues/119","id":179078142,"number":119,"title":"Allow \"inline\" violation reports to contain the text of offending scripts","user":{"login":"arturjanc","id":665379,"avatar_url":"https://avatars.githubusercontent.com/u/665379?v=3","gravatar_id":"","url":"https://api.github.com/users/arturjanc","html_url":"https://github.com/arturjanc","followers_url":"https://api.github.com/users/arturjanc/followers","following_url":"https://api.github.com/users/arturjanc/following{/other_user}","gists_url":"https://api.github.com/users/arturjanc/gists{/gist_id}","starred_url":"https://api.github.com/users/arturjanc/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/arturjanc/subscriptions","organizations_url":"https://api.github.com/users/arturjanc/orgs","repos_url":"https://api.github.com/users/arturjanc/repos","events_url":"https://api.github.com/users/arturjanc/events{/privacy}","received_events_url":"https://api.github.com/users/arturjanc/received_events","type":"User","site_admin":false},"labels":[],"state":"open","locked":false,"assignee":null,"assignees":[],"milestone":null,"comments":2,"created_at":"2016-09-25T09:56:49Z","updated_at":"2016-09-25T23:56:21Z","closed_at":null,"body":"One of the biggest problems with CSP violation reports is the large number of false positives. Popular applications, even if they are compatible with their CSP, can generate hundreds of QPS of violation reports, usually due to markup injected by browser extensions. The amount of noise makes it very difficult to find breakage caused by deploying CSP in a production environment.\r\n\r\nIdeally, this would be solved by recognizing all modifications to the page introduced by extensions, and have these modifications exempt from CSP; in practice, this seems like an intractable -- or at least very difficult -- problem for user agents. There are probably ways to indicate to authors that one of their pages violates its CSP without having to solve the extension-injected markup issue...\r\n\r\nCSP3 currently requires violations caused by inline markup to have a blocked-uri of \"inline\". This is better than in the past, but it leads to a lot of `\"inline\"` violations without any identifying information. For nonce-based policies with `'strict-dynamic'` this is by far the most common violation type. The blocked resource is `\"inline\"` for event handlers, javascript: URIs, and inline scripts without a nonce; the only exception are external scripts without a nonce, but they are easy to identify by the `blocked-uri`.\r\n\r\n**Proposal**: For \"inline\" violations, the UA could include additional information in the report to identify the offending inline markup and help developers distinguish site problems from extension-generated violations. It could be enabled via a new keyword in the `report-uri` directive, e.g. `include-inline-script-details` (as usual, terrible name).\r\n\r\nThere are several approaches that might work:\r\n- Include the entire offending script (e.g. `<b onclick=\"foo('bar')\">` and `<script>foo('bar')</script>` would both return `foo('bar')`.\r\n- Include a fixed-length prefix of the script (10 bytes? 50 bytes?). This sounds awkward, but in practice it should allow developers to search their codebase for the given string and/or build databases of common false extension-generated false positives.\r\n- Perform more elaborate processing of the script text, e.g. replace string/integer values with placeholders, find the first named function and return its name, etc. These are even more awkward and probably non-starters, but in principle there's nothing that would prohibit the UA from doing some processing on the script text to reduce the amount of information it sends but still make the report useful to the developer.\r\n\r\nI can think of two things that we'd need to be careful about:\r\n- Disclosing script contents shouldn't allow CSP to be used as a mechanism to leak data across origins. I think the proposal is okay since it's limited to inline scripts, and the document can already inspect all its inline markup, but we should think carefully about this.\r\n- Sending full script contents to third-party collector infrastructure could leak sensitive data. The opt-in keyword in report-uri should solve this concern.\r\n\r\nOverall, this is something where the simplicity of implementation in user agents might trump other concerns, i.e. even a non-ideal mechanism that gives *some* information to developers to help them decide if a violation report is legitimate would still be quite helpful.\r\n\r\n"},"comment":{"url":"https://api.github.com/repos/w3c/webappsec-csp/issues/comments/249454972","html_url":"https://github.com/w3c/webappsec-csp/issues/119#issuecomment-249454972","issue_url":"https://api.github.com/repos/w3c/webappsec-csp/issues/119","id":249454972,"user":{"login":"arturjanc","id":665379,"avatar_url":"https://avatars.githubusercontent.com/u/665379?v=3","gravatar_id":"","url":"https://api.github.com/users/arturjanc","html_url":"https://github.com/arturjanc","followers_url":"https://api.github.com/users/arturjanc/followers","following_url":"https://api.github.com/users/arturjanc/following{/other_user}","gists_url":"https://api.github.com/users/arturjanc/gists{/gist_id}","starred_url":"https://api.github.com/users/arturjanc/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/arturjanc/subscriptions","organizations_url":"https://api.github.com/users/arturjanc/orgs","repos_url":"https://api.github.com/users/arturjanc/repos","events_url":"https://api.github.com/users/arturjanc/events{/privacy}","received_events_url":"https://api.github.com/users/arturjanc/received_events","type":"User","site_admin":false},"created_at":"2016-09-25T23:56:20Z","updated_at":"2016-09-25T23:56:20Z","body":"@devd helpfully pointed out that something like this already exists in Firefox (!) -- it's the 'script-sample' field: \r\nhttps://www.tollmanz.com/content-security-policy-report-samples/\r\nhttps://github.com/w3c/webappsec-csp/issues/81\r\n\r\nA main missing piece of the FF implementation is that while 'script-sample' sends contents of inline scripts, it doesn't do the same for event handlers or javascript: URIs; for event handlers, the value is something like \"script-sample\":\"onmouseover attribute on H1 element\", and for javascript: URIs there is no \"script-sample\" at all. But if \"script-sample\" also included the contents of the event handler, it would probably be good enough...\r\n\r\nAlso, since FF has already included script snippets in violation reports, this probably removes the need for an additional keyword to enable this change ;-)"}}
{"actor":{"display_login":"arturjanc"}}