Comments (10)
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
- 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
- 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!
from csp-html-webpack-plugin.
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.)
from csp-html-webpack-plugin.
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.
from csp-html-webpack-plugin.
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?
from csp-html-webpack-plugin.
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?
from csp-html-webpack-plugin.
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!
from csp-html-webpack-plugin.
I thought this PR has been out there for almost a year: #87
We would really like to see this feature implemented.
from csp-html-webpack-plugin.
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?
from csp-html-webpack-plugin.
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.
from csp-html-webpack-plugin.
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.
from csp-html-webpack-plugin.
Related Issues (20)
- Angular 8+ ready HOT 4
- No nonce values are showing up in the CSP string
- Wrong inline script hash when the file EOL is CRLF HOT 1
- Elements within <noscript> are not hashed HOT 2
- Peer Dependency for WebPack v5 HOT 2
- Lodash 4.17.20 HOT 1
- Cheerio 1.0.0-rc.4 HOT 1
- Consider adding documentation for automatic webpack server restart HOT 1
- Documentation tweaks HOT 3
- Problem in setting nonce when using a custom processFn HOT 2
- Regression in 5.0.1 HOT 5
- [Security] Nonce reuse HOT 12
- Yarn 2 support HOT 2
- Add nonce also for preloaded scripts
- Example of using with Helm and multiple environment/values files HOT 1
- Adding nonces to inline styles in <head> HOT 1
- deprecated @types/[email protected]: This is a stub types definition. anymatch provides its own type definitions
- CSP Plugin doesn't put the nonce value into CSP meta tag on Windows HOT 2
- Generates wrong hashes
- Allow `nonceEnabled` to take a single boolean value HOT 2
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from csp-html-webpack-plugin.