-
Notifications
You must be signed in to change notification settings - Fork 38
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
Comments
It should not be to hard to implement, but first need to have some js code which works. |
Now only for Spidermonkey and OpenSSL. SHA512, SHA384 or SHA256 were added. URIs are stored in map, which is not cleared yet.
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.
Yes, it is possible to add integrity checks, but is not so easy. |
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, |
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 thatsha384
is stronger thansha256
-- we should ignore thex
andy
hash values entirely and only validate fetched content against thesha384
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 eitherx
ory
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.
The text was updated successfully, but these errors were encountered: