Subresource Integrity and raven.js

[shekyan]

Subresource Integrity is promising new technology that allows to verify the integrity of third-party resources included by the web page, and provides a backup mechanism to load the resources from trusted (but slow) sources. Backup mechanism is just an error event, that needs to be handled by the developer.

From what I understand, this flow does not align with the way raven.js should be deployed, e.g.

1. an SRI backup handler is loaded first
2. handler loads third party scripts
3. own scripts are loaded

Since SRI does not provide reporting mechanism, and there is no common way of getting notified when integrity violation happens. I'd be happy to use Sentry for that purpose, but there is chicken and egg problem in regards to what load first: raven.js without verifying it's integrity or SRI loader script without hooking raven.js into it.

How do you think this can be solved? May be I am overcomplicating things and there is some obvious way to use sentry to monitor SRI exceptions.

[shekyan]

An example SRI loading wrapper that we use on our website can be found here

[mattrobenolt]

I'm having a little bit of troubling understanding what exactly you're asking for, so lemme summarize what I understand about SRI:

A website could use SRI for a resource inside of it's script tag to validate it's integrity with a sha256 hash of the expected contents. (or another hash algorithm like sha512, etc). If the verification fails, the script does not get loaded. raven-js publishes a list of it's SRI hashes along with the dist bundle, see: https://github.com/getsentry/raven-js/blob/master/dist/sri.json and https://cdn.ravenjs.com/1.3.0/sri.json. We can't enforce this on the CDN, but a user would need to do this on their side.

So from my understanding, we could do a better job on promoting this on raven-js side for our own scripts, that'd work with our CDN.

BUT, I think you're asking about reporting these issues from other scripts via raven-js, not using SRI for raven-js itself, correct?

I think this is valid, but my concern is... what value does this report give to a developer? There are 2 major scenarios I think come into play here, and it's the same for the HPKP reporting:

• You massively mess up on your side and published resources with an invalid integrity hash, rendering everything broken.
• There's an attack going on that's targeting your users and someone is attempting to MITM and modify your resources.

If you flat our mess up, this would not be an isolated issue, and likely, it'd be 100% broken. So the reporting use case is limited.

And if there's an attack going on, and SRI is doing the right thing... would a report be useful to you? Could you use that information to counteract? It seems more like an FYI situation. I also wonder how many false positives would come from this due to proxies and ISPs trying to do sketchy things. All things that are not actionable.

Sorry if some of these are naiive, I'm just trying to figure out what we can do here and if it actually makes sense to be able to surface these things in Sentry. :) We try to make sure we're reporting useful things and not be noisy about things that are unactionable.

[mattrobenolt]

Also, looking at your script, it looks like you're using the fallback to serve the asset from your domain, instead of the public CDN.

Is this to protect against a compromised CDN? If there were an attack against the jQuery CDN, for example, falling back to your local copy is less likely to be compromised?

I guess I'm thinking about this more like your entire network being compromised (using a sketchy ISP) where it doesn't really matter which domain, they're always trying to intercept data. I've heard horror stories of airplane wifi doing this kind of stuff, for example.

[shekyan]

You pretty much got my points right. Here are some clarifications:

A website could use SRI for a resource inside of it's script tag to validate it's integrity with a sha256 hash of the expected contents. (or another hash algorithm like sha512, etc). If the verification fails, the script does not get loaded. raven-js publishes a list of it's SRI hashes along with the dist bundle, see: https://github.com/getsentry/raven-js/blob/master/dist/sri.json and https://cdn.ravenjs.com/1.3.0/sri.json. We can't enforce this on the CDN, but a user would need to do this on their side.

The point of SRI is to not trust anybody (e.g. blindly use the value provided by third-party) but, say, do security code review and if ok, calculate the SRI on your own and assume it's good to be used with .
openssl dgst -sha384 -binary file.js | openssl base64 -A

The backup source in our case, and I guess in most of the other cases is the local copy of the file that I reviewed already, but serving it from CDN should me much faster than from myself. So, if CDN is hacked, or a targeted attack is happening, or third-party developer pushed new change into the same resource (like bootswatch does), website still continues to work as expected, by maybe load is slower.
I, as the website maintainer, would have no reliable way of knowing when primary source of the resource failed integrity check, except either developing some kinda monitoring tool or stare at developer tools console and hit refresh every 5 seconds.

What I am asking is:

• since there is no unified way of collecting SRI violations, to consider having an SRI failure monitoring tool as part of Sentry toolset. Why separate tool? It has to be loaded before raven.js, because Joe doesn't trust nobody and wants to include only security audited, SRI enabled version of raven.js and other third-party scripts.
• because of chicken & egg problem here (who is gonna verify the integrity of that SRI tool), make it user-hosted only

  If you flat our mess up, this would not be an isolated issue, and likely, it'd be 100% broken. So the reporting use case is limited.

• this one is tricky, as you can be flooded with tons of similar reports. Perhaps something like special endpoint for SRI reports, that will collect first 100/1000 reports and then ignore everything else can be a solution? That will require new endpoint URL to be used for updated SRI config by the user. Impact is not much different from misconfigured CSP, or bug in the new version of browser, or tons of exception reports because of new version of jQuery is breaking your app.

[BYK]

Closing this issue due to staleness. Feel free to comment here if you think we should still work on this.