waysact / webpack-subresource-integrity

Webpack plugin for enabling Subresource Integrity.
MIT License
357 stars 46 forks source link

Firefox integrity hash + csp issue #182

Closed joergbaier closed 2 years ago

joergbaier commented 2 years ago

While this is not necessarily an issue with webpack-subresource-integrity, people here may be the most helpful with our issue.


When using the Angular subresource-integrity build option, several script tags are injected into the index.html like the one below:

<script
  src="runtime.cdc6837cf654de44.js"
  type="module"
  crossorigin="anonymous"
  integrity="sha384-j08qqMVBPQfnDReJt/ZuczYwLvqwGLUwwv0io0dY7d3UpIKruGIPPxT5U55s0t8K"
></script>

Our S3+CloudFront hosted Angular application will initialize in Chrome and Safari, but not Firefox due to the following error:

None of the “sha384” hashes in the integrity attribute match the content of the subresource.

The generated sha384 from https://www.srihash.org/ matches. The downloaded script by Firefox has identical contents to other browsers and curl. Caching doesn't seem to be an issue either, I've tried private windows and clearing all cached data.

I downloaded the remote index.html, replaced src="runtime.cdc6837cf654de44.js" with src="https://_our_domain_/runtime.cdc6837cf654de44.js" and then opened this local file in Firefox, which works, the application will initialize. This makes me think that Firefox handles "same-origin" differently.

Any ideas why Firefox errors out?


Why are we using subresource-integrity?

We are trying to add a strict csp policy that uses strict-dynamic. Using hashes greatly reduces the complications of hosting our SPA vs being nonce based.

script-src 'strict-dynamic' 'sha384-j08qqMVBPQfnDReJt/ZuczYwLvqwGLUwwv0io0dY7d3UpIKruGIPPxT5U55s0t8K' ...;
jscheid commented 2 years ago

The most likely explanation, based on your description, is that index.html gets cached and is stale. Have you had a look at it yet (using the DOM inspector in FF) to see if the hash on the script tag is what you'd expect?

jscheid commented 2 years ago

Or it could be an extension. If you have any installed, make sure they're all disabled.

joergbaier commented 2 years ago

The index.html is fresh (we are sending cache-control: no-store) and can see that a full network request is occurring to fetch that file. The script source and integrity are up to date.

I've disabled extensions and getting the same error.

jscheid commented 2 years ago

Curious. If you can absolutely rule out caching, proxies, extensions, service workers, (malicious actors 😄) -- anything that could mess with the responses/contents -- (maybe try a fresh install on a different machine just to be sure) then you may have hit a bug? Perhaps one that only gets triggered in certain edge cases, possibly to do with the CSP and/or your use of modules? It's not inconceivable, years ago Chrome had a bug in their SRI handling for example (to do with charset encodings, if memory serves.)

You could try an older FF version, or consider installing it from source to see if you can get any debug output out of it.

joergbaier commented 2 years ago

Thanks for the leads, I'll try a few more CSP/no-CSP & ServiceWorker/no-ServiceWorker combinations and report back in a day or two ... last resort I'll try the FF from source 😅

joergbaier commented 2 years ago

I believe the issue is narrowed down to this combination: