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

Add support for subresource integrity #76

Open
wants to merge 1 commit into
base: main
Choose a base branch
from

Conversation

mrmonday
Copy link

@mrmonday mrmonday commented Apr 27, 2020

Add support for generating subresource integrity hashes at build time

  • Add an sri feature, which depends on the ssri crate
  • Generate sha256, sha384, and sha512 SRI hashes for statics
  • Update examples to use SRI

 * Add an `sri` feature, which depends on the `ssri` crate
 * Generate sha256, sha384, and sha512 SRI hashes for statics
 * Update examples to use SRI
@kaj
Copy link
Owner

kaj commented Apr 27, 2020

Hi! Thanks for this contribution! It seems like a good thing overall, I'll try to take good look at the details tomorrow (I'm a bit too tired today).

Copy link
Owner

@kaj kaj left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Now I've taken a better look at this. Sorry it took closer to a week than a day ... I have mainly one question:

Should a template author have to specify which kind integrity hash should be used for each place a resource is linked? Seems to me a project would probably like to decide on one hash size / algorithm, and if / when the time to change it comes, it would be nicer to change it in one place in the project, rather than in every link or script tag in every template.

So, instead of including three separate fields with diffent integrity hashes, I think it would be better to only have one field (named integrity without suffix) containing one of the hashes. We could choose any of the hash algorithms as a default, and add a method to be called from the build script that can change the hash algorithm (that addition could be either as part of this PR, or left as room for future improvement after just hardcoding one of the hashes in this PR).

@mrmonday
Copy link
Author

mrmonday commented May 1, 2020

If this ends up as a single method, it needs to be possible to specify multiple hash algorithms, as well as just one (eg. integrity="<hash1> <hash2> <hash3>" is valid).

I opted to go the old fashioned route of serving static resources from the file system for what I'm working on, so probably won't do any more work on this PR - feel free to push against the branch if you want to continue work on it.

@vbrandl
Copy link
Contributor

vbrandl commented Oct 7, 2022

I might be willing to pick this one up, rebase and make the used hash algorithm globally configurable in build.rs.

But before doing that: Does subresource integrity really make sense when everything is served from the same server? I know it makes sense when using external resources to prevent a CDN/external hosting provider from maliciously changing the file. But for resources that are served from the same server as the file that uses the resource, if an attacker has access to the server, they can change both the resource and the SRI hash. What's the attack vector, SRI for local resources protects from?

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

Successfully merging this pull request may close these issues.

3 participants