search

w3c / webappsec-csp

WebAppSec Content Security Policy
https://w3c.github.io/webappsec-csp/
Other
210 stars 78 forks source link

Include script hash in CSP report when 'report-sample' is set #378

Open april opened 5 years ago

april commented 5 years ago

When 'report-sample' is set, it would be nice if the sha256 hashsum were included along with the report sample. This has a couple use cases:

1) creating signatures for things like noisy browser extensions, when the first 40 characters may not suffice; for example, you may know that it's the React Devtools, but you don't necessarily have a way to determine which version (since 3.4.2 and 3.4.3 start with the same 40 characters), and 2) helping tools that process CSP reports to generate policies, such as the Mozilla Laboratory

In the case of 2, how Laboratory works is by injecting this CSP-RO policy:

default-src 'none';
  form-action 'none';
  connect-src 'none';
  font-src 'none';
  frame-src 'none';
  img-src 'none';
  manifest-src 'none';
  media-src 'none';
  object-src 'none';
  prefetch-src 'none';
  script-src 'none';
  style-src 'none';
  worker-src 'none';
  report-uri /laboratory-fake-csp-report',

And then processing the CSP reports that come in to generate policies. When it detects inline scripts, the only option it has is to add 'unsafe-inline' and include a warning about how dangerous it is. It would be nice to allow script hashes as an alternative to 'unsafe-inline', but there is currently no clean way to go from a sample to a hash.

Anyways, this proposal is for the report to look like this:

csp-report:
  blocked-uri: "inline"
  document-uri: "https://f.bar/foo"
  effective-directive: "script-src"
  script-hash: "sha256-1b2383b324c8520974ee097e46301d5ca4e076de387c02886f1c6b1503671586"
  script-sample: "try {window.AG_onload =function(func)..."

The downsides of this would be: 1) The CSP report would be larger by 71 bytes 2) If there was secret information in the script sample that was not in the first 40 characters, it would be possible (if unlikely) for someone in control of the CSP reporting endpoint to work out what that information is. This is weird, but I wanted to mention it regardless.

Note that browsers already include this information in the CSP reports that they make to the console log.

zero-24 commented 4 years ago

Together with @snipersister I'm working on an CSP Implementation for Joomla and we use the CSP reports to suggest policies to our users. There we face the exact issue reported here that we are forced to suggest 'unsafe-inline' in the case one inline report comes in.

I personally would not bind the script-hash information to the flag 'report-sample' as in the browser this is generated anyway and for me this would be a generally information that can be usable on any inline csp report.

At the CMS Security summit 2020 we also talked with @mikewest about this and agreed to report it to this repo and I'm happy to see that others in this case @april also had that idea before us.

So a big 👍 from us on that proposal as that would help us to avoid unsafe-inline even more :)

mikewest commented 4 years ago

I'm sorry I missed April's earlier suggestion. :(

As we discussed yesterday, I don't think this is a terrible idea, and I agree with April's risk analysis above.

SniperSister commented 4 years ago

/cc @ohader

freddieleeman commented 4 years ago

I love this. Would love to see this as it would make CSP management a lot easier.

gabinkbl commented 2 years ago

Great suggestion. It will definitely allow to generate more secure policies. Is there a plan to incorporate this in the standard?