Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Feature request: W3C SubResource Integrity support #284

Open
jayaddison opened this issue Jan 18, 2024 · 3 comments
Open

Feature request: W3C SubResource Integrity support #284

jayaddison opened this issue Jan 18, 2024 · 3 comments

Comments

@jayaddison
Copy link

SubResource Integrity (acronym SRI) is a W3C recommendation that provides web publishers with a way to add the hash checksums of content referenced from their HTML pages, by adding an integrity attribute to the relevant HTML elements.

The attribute value contains one or more hyphen-joined conjunctions of a hash algorithm (such as sha256) and a base64-encoded hash of the content of the linked resource.

When multiple of these algorithm-and-hash conjunctions are present, then a space is used to separate each atomic conjunct.

Furthermore, there is logic in the specification that says that stronger algorithms take precedence over weaker algorithms - but it is up to the user agent to provide the ranking. So if we have an integrity attribute with value sha256-x sha256-y sha384-z, then -- assuming that sha384 is stronger than sha256 -- we should ignore the x and y hash values entirely and only validate fetched content against the sha384 hash.

However, within equal-strength algorithms, the logic is that any of the equal-strength hashes are permitted. So if we removed sha384-z from the previous example, then either x or y are valid base64-encoded SHA256 values for the referenced content.

The specification is relatively strict in that it suggests that integrity check failures should prevent the referenced resource from being loaded by the user agent.

There are no doubt other relevant details in the W3C specification; this is my attempt to summarize what I understand to be the most important aspects of the feature from my understanding of it so far.

@rkd77
Copy link
Owner

rkd77 commented Feb 13, 2024

It should not be to hard to implement, but first need to have some js code which works.
Code which modifies DOM tree or calls document.write does not work well yet, so it is too early to add such features like this one.

rkd77 added a commit that referenced this issue Sep 24, 2024
Now only for Spidermonkey and OpenSSL.
SHA512, SHA384 or SHA256 were added.
URIs are stored in map, which is not cleared yet.
rkd77 added a commit that referenced this issue Sep 24, 2024
rkd77 added a commit that referenced this issue Sep 24, 2024
For ecmascript it is '^integrity\0url'.
Weak points:
Bad script is not executed, but is stored in cache, so next requests will take it from cache, not from network.
Checksum is calculated everytime script is loaded (it can be many times per second).
Scripting pre_format_hook can modify the body of script and cause a wrong checksum.
Error message is written to stderr.
@rkd77
Copy link
Owner

rkd77 commented Sep 24, 2024

Yes, it is possible to add integrity checks, but is not so easy.
Added test cases jqfind_ok.html, jqfind_bad.html. It worked for mozjs.
openssl must be enabled (1.1 or newer)).

@jayaddison
Copy link
Author

Thanks @rkd77 for considering this and enabling initial support for it. I notice the config option in some more recent commits.

I'm particularly interested in some aspects of how sufficiently-strong integrity hashes can -- to some extent -- be used as cache keys. However I would also mention that there are some privacy and cross-site security issues that go along with that.

I had hoped to find more time to read into the details and then respond here with useful feedback; instead I'm closing out and unsubscribing from a bunch of threads so that I can refocus/recuperate -- but I do want to mention that w3c/webappsec-subresource-integrity#22 could be worth a read.

Thanks again,
James

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants