Use SRI to Detect More Libraries

[chris-barry]

Mozilla recently put in SRI support into Firefox. If a script tag has a SRI attached, and it matches the hash of a known, then it can be assumed there is no need to download the resource.

Edit: To be clear, this would allow the same library hosted anywhere to be caught. I don't know the current usage of SRI, but hopefully it grows.

[austinhartzheim]

@chris-barry Just to clarify, are you suggesting that this be used to detect common libraries that are self-hosted?

If so, I think it is a good idea overall. However, some users might want to disable this functionality as it is a fingerprintable trait. That is, the fact that this add-on is installed could be detected by a web page you visit due to the behavior you describe.

[chris-barry]

Yes, that's exactly what I am suggesting. And I completely agree about the fingerprintability. It should be opt-in, maybe under an "aggressive" mode, or similar.

[Synzvato]

@chris-barry @austinhartzheim

Currently, Decentraleyes doesn't get along well with integrity and crossorigin. In fact, all pages that implement these new attributes will not be able to load any resources unless they're whitelisted.

The issue, as described in #16, is quite hard to tackle as it seems that there's no way to tell if these attributes are present in the DOM when looking at an intercepted HTTP request. Also, the corresponding page is still mostly unparsed when the requests are sent out. So we'll need to find another way.

Once the related issue is solved (there has to be a way to detect the presence of these attributes on request interception), we can indeed use the resulting information to power this feature. Thanks for the suggestion! Any further suggestions would, of course, be greatly appreciated.

[mozfreddyb]

This is a really neat idea! But allow me to briefly explain a security problem that comes with using an SRI hash for caching:

Assume somone has a very secure website, supersecure.example, protected by Content Security Policy (CSP). This high-security policy disallows scripts to be loaded from any domain other than supersecure.example. Given the defaults of CSP, there is no inline JavaScript on supersecure.example (e.g., <script>…code here…</script>), nor is it allowed.

Now, let's also assume there is a trivial XSS vulnerability at supersecure.example/hello.php, which will reflect whatever content you put in the name GET variable. The CSP prevents this bug from being exploitable (no new inline scripts, no remote script loads from somewhere other from supersecure.example.

Here come's a way to attack this with a cache poisoning attack:

An attacker can inject something that includes <script src="supersecure.example/does-not-even-exist.js" integrity=foo>, where integrity matches the hash of a known-vulnerable file. It is, for example, known that you can bypass CSP and cause XSS with an outdated angular-js version. The browser (extension) would happily include the old library, even though the file does not exist on supersecure.example. This bypasses the CSP restriction and makes the previously secure web page vulnerable.
I'm afraid there is no way to verify that the script was meant to be included and actually exists on said domain until you do the request (which, of course, you want to avoid).

NB: Using SRI for caching is a neat idea and we're still looking at how to do so securely. Possibly via opt-in :/ Read more about that on the w3c SRI issue tracker. If you have feedback, please provide your comments on the mailing list and not in the github issue)

[stewie]

Please consider preserving an option to "fuggadabout SRI and (just) facilitate caching".

[stewie]

Will the "integrity" SRI attribute cause the browser to reject our permacached copy of a script when the "inject a comment denoting locally injected file" option is active?

[mozfreddyb]

If you modify the file, it will have a different hash. Even if it's just a comment. So, yes, it will be bocked.