32

Subresource integrity basically lets me know that a resource I'm about to download is valid, because the hash of its contents matches what I expect.

But this assumes that I'm already running on some trusted and verified code. If a hacker has compromised the server serving resources, then they could easily just replace the root resource with hashes of their own malicious code (or just bypass integrity checks altogether).

So how do subresource integrity checks help at all? And how would a client go about verifying the root resource?

user22a6db72d7249
  • 103
  • 2
David says Reinstate Monica
  • 1,108
  • 1
  • 15
  • 20
  • 1
    Sure, it only helps for resources served from different servers. – Bergi Sep 11 '18 at 10:20
  • @Bergi I wouldn't say that. It seems more correct to say that it helps for resources served from *other administrative domains*. (That's not necessarily "domains" as in "DNS domain names", by the way, but DNS domain name can be one way to segregate administrative domains.) If entity X controls the main web site, and entity Y controls a resource used by the main web site, then entity Y can effectively alter the content of the main web site without the consent of entity X. *SRI effectively gives entity X the ability to state which content entity Y is allowed to offer.* – user Sep 11 '18 at 11:34
  • @MichaelKjörling Ah, thanks, didn't know the technical term. I commented based on the OPs assumption that complete "servers" would be compromised or not - of course that's a simplification, you are right. – Bergi Sep 11 '18 at 11:47
  • @Bergi Trivial example of a single server serving multiple administrative domains: your typical shared hosting setup. A potentially large number of customers store content on the same server, and each customer has login details that allows access to their portion of the storage and, ideally, nothing else. In this case, you don't need the entire server to be compromised for one of the customers' files to be compromised. – user Sep 11 '18 at 11:49

2 Answers2

40

Subresource integrity is not about protecting your own code of the web application against modification. What SRI is intended to do can be seen from the description of the goals:

Compromise of a third-party service should not automatically mean compromise of every site which includes its scripts.

Thus, it is about protecting your use of resources located at sites which are not under your control. SRI gives back some control even if code from a third party site is included. It does not offer availability but it offers integrity, i.e. protection against unwanted modifications by the third party (or some hacker which took over this party).

Steffen Ullrich
  • 184,332
  • 29
  • 363
  • 424
  • Thanks. Do you know then how a client can be sure that the server it was talking to was not compromised? – David says Reinstate Monica Sep 10 '18 at 20:45
  • 2
    @DavidGrinberg: This is a different question and should better not be asked in a comment. Also, it is impossible unless the client has some prior knowledge about the server. If the client has this the client could at least check if the relevant files match the expectations - but there is no standard for this and the question would also be where the client gets this prior knowledge from in the first place. – Steffen Ullrich Sep 10 '18 at 21:14
  • 10
    @DavidGrinberg To clarify, SRI isn't about client and server; it's about server A and server B. As a client, when I ask server A (who I trust) for a page, and it says I should also get content from server B (who I have no reason to trust), I have to implicitly trust B. What SRI does is ensure that a malicious entity who gains control of B can't serve malicious content and have me trust it because A said so; the content must match what A thought it was. If A is compromised (or malicious), then SRI doesn't help. Other mechanisms are used there, and you should ask about those separately. – anaximander Sep 11 '18 at 14:27
23

Let's say you have a site built around jQuery. You don't download jQuery and use your copy, but you use a version from a CDN, making use of the caching on client's browsers. That works because if one site uses the CDN version, it will be cached and every site that uses the same version will benefit, not having to download an identical file every time.

One day, someone hacks into the CDN servers and replaces the JavaScript files with altered versions that submit every keystroke to the attacker's servers somewhere. And every single site that uses that script is affected, your site included.

Here enters Subresource Integrity - SRI. It prevents a third party from altering external resources undetected. If you have SRI enabled on your external resources, a client browser will not load resources with hash mismatches.

then they could easily just replace the root resource with hashes of their own malicious code

Not really. SRI protects your site (code you control) from changes on a third party script, which you don't control. An attack on your code is not protected by SRI, because if an attacker changes a third party script and your site, he can do the same changing only your site with way less trouble. After all, attacking your site is easier than attacking Akamai, CloudFlare, Google, or Microsoft.

Fire Quacker
  • 2,432
  • 1
  • 19
  • 29
ThoriumBR
  • 50,648
  • 13
  • 127
  • 142
  • 4
    Note the weak point of jquery isn't the Akamai or CloudFlare that serves it, but the couple of maintainers who have the right to release new versions. And due to the potential impact, stealing those is worth more resources than attacking your site even if the later might be easier in the end. – Jan Hudec Sep 11 '18 at 21:02