Add hashes to external scripts (CSP3)

[Kage-Yami]

Description

According to Mozilla's documentation, CSP3 allows for the <hash-algorithm>-<base64-value> attribute of script-src to be applied for external scripts.

As I understand it (based on reading #35 and trying out the plugin myself), hashes are not generated and included for external scripts, only inline scripts.

It'd be nice if they could be included for external scripts too. (Maybe via a default-false configuration option?)

What type of issue is this?

• bug
• enhancement (feature request)
• question
• documentation related
• testing related
• discussion

Requirements

• I've read and understood the Contributing guidelines and have done my best effort to follow them.
• I've read and agree to the Code of Conduct.
• I've searched for any related issues and avoided creating a duplicate issue.

[AnujRNair]

Hi @Kage-Yami

The src value of a script tag could be set to any external script, so gives us a lot of vectors to cover here:

• ✅ For a script which is linked from the same webpack build, we could inline the hash
• ⚠️ For a script which is a true external script, outside of the current webpack build, or hosted on a different server, we would have to download this script to be able to calculate the hash for it.
  • This could potentially create a security risk, if the external host has been compromised, or there is a proxy between the request and response. This would circumvent what CSP is trying to accomplish

We have a few options when it comes to supporting external scripts in CSP 3.0:

• Ask the developer to inline the csp hash themselves
  • This is probably the most secure, but least automatic way to do things. Developers can already do this today by adding hashes manually to their script-src config
• Only add hashes for external scripts which are in the same webpack build
  • This would be inconsistent behaviour when compared to true external scripts, and could be confusing to developers as to why this is happening
• Download all external scripts, and add their hashes to the policy. Would definitely be behind a flag to enable this
  • This could open up security concerns as described above.

At the moment, I am leaning towards the first option, although I am unsure as to how frequently developers would want to use this feature.

To anyone reading this: Maybe add a 🎉 to this comment if you'd like to stick with the 1st option, 👍 if you would like to see the 2nd or 😄 if you'd like to see the 3rd.
This should give us a better sense of developer needs, and then I will accept pull requests!

[Kage-Yami]

Hmm, fair points. Definitely agree that (3) is right out.

I'd vote for a (2b): default to (1), but have a config setting to enable (2) - idea being that if a dev is enabling it, they likely should've read the doco outlining the limitations; config setting can be verbose (e.g. hashLocalExternal) to give devs enough pause to look up what it means if they encounter it enabled first.

I'm assuming that "Local-External" here is anything bundled (e.g. node_modules imported into entry scripts), and "Web-External" is any explicitly specified <script> blocks - though I can't think of where those might exist outside of a template (which I assume are not touched by csp-html-webpack-plugin), so where would the risk be coming from?

[AnujRNair]

I think we're on the same page here :)

If we're only including hashes from assets which are added as 'local-external' script srcs, then there is no risk there. Implementation steps here would be to:

• Calculate hashes for these files as they are emitted by webpack
• Scan the html file for all script src's and filter to leave only assets emitted by webpack
• Add the hashes to the csp meta tag

The potential risk would be introduced if we were looking to add hashes for 'web-external' scripts too. Since we wouldn't be able to calculate the hashes for these assets as webpack emits them, the only way to add them to the csp policy would be to manually calculate them and add them to the policy, or download the files during webpack compilation and calculate the hashes then.

If you're open to opening a PR with what we've discussed here, I would be happy to review!

[lweichselbaum]

Unfortunately, hashing of external scripts is currently only supported in Chromium-based browsers (see web-platform-tests).
This means that while hashed external scripts would load e.g. in Chrome and Edge, they'd get blocked in Firefox and Safari. Right now I'm not aware of any fallbacks you could use to make sure that these scripts still load in browsers not supporting hashes of external scripts.

[Nantris]

We'd really like to use hashes for "external" scripts - ie our Webpack generated scripts. The only environment that matters to us is Chromium-based (Electron) and we have no truly external scripts.

Is there any way to get this to work currently? I guess no?

---

At the moment, I am leaning towards the first option, although I am unsure as to how frequently developers would want to use this feature.

Please don't require developers to manually assign hashes. They'll never do it.

The second option may be confusing to developers initially, but would provide far more security since it would actually get used.

The third option sounds like a significant security risk.

Users always have the option to use nonce instead of hashes, so I think that covering every use case of hashes is less important than covering the most standard use case - which is wanting hashes for the Webpack generated assets.

(Though I should note that we can't get __webpack_nonce__ working, so nonce doesn't provide as much security as one would hope. If we could get that working it would be a good alternative to hashing.)

[sersorrel]

I spent an hour or so trying to implement this earlier today, and whilst I'm totally unfamiliar with Webpack, I couldn't work out a way to do it – you need the final content of each JS file in order to hash it, but you then need to modify the HTML in order to insert the hashes.

• if you use the assetEmitted hook to calculate file hashes, you're too late to output the hashes anywhere
• if you use html-webpack-plugin's beforeEmit hook to modify the HTML, you don't yet know the contents of the JS files to produce the hashes

On the other hand, webpack-subresource-integrity seems like it does a similar kind of thing, so I suspect I'm just trying to use the wrong hooks.

[Nantris]

Any movement on this? Few single issues could do as much to enhance security across a wide range of projects as this one.

@AnujRNair any thoughts on a path forward?

[Nantris]

I hate to be a pain bumping this thread again, but I have to ask since I think this would be such a big deal for so many projects, any update on this? The status on the issue is both "In Review" and "In Development". Is this actually under development? Planned? Still under review?

[melloware]

I thought this PR has been out there for almost a year: #87

We would really like to see this feature implemented.

[SteffenBlake]

Hashes are supported on script-src because it applies to both inline and elem scripts generically.

Hashes for elem scripts is not currently supported by CSP lv 3, which is what most browsers are currently at. Hashes currently only work for inline scripts and styling according to W3C specs.

https://www.w3.org/TR/CSP3/