How does subresource integrity actually help?
Clash Royale CLAN TAG#URR8PPP
.everyoneloves__top-leaderboard:empty,.everyoneloves__mid-leaderboard:empty margin-bottom:0;
up vote
31
down vote
favorite
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?
web-browser integrity validation sub-resource-integrity
edited Sep 11 at 18:56
user22a6db72d7249
1032
asked Sep 10 at 20:22
David Grinberg
6661017
add a comment |Â
up vote
31
down vote
favorite
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?
web-browser integrity validation sub-resource-integrity
edited Sep 11 at 18:56
user22a6db72d7249
1032
asked Sep 10 at 20:22
David Grinberg
6661017
1
Sure, it only helps for resources served from different servers.
– Bergi
Sep 11 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.
– Michael Kjörling
Sep 11 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 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.
– Michael Kjörling
Sep 11 at 11:49
add a comment |Â
up vote
31
down vote
favorite
up vote
31
down vote
favorite
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?
web-browser integrity validation sub-resource-integrity
edited Sep 11 at 18:56
user22a6db72d7249
1032
asked Sep 10 at 20:22
David Grinberg
6661017
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?
web-browser integrity validation sub-resource-integrity
web-browser integrity validation sub-resource-integrity
edited Sep 11 at 18:56
user22a6db72d7249
1032
asked Sep 10 at 20:22
David Grinberg
6661017
edited Sep 11 at 18:56
user22a6db72d7249
1032
asked Sep 10 at 20:22
David Grinberg
6661017
edited Sep 11 at 18:56
user22a6db72d7249
1032
edited Sep 11 at 18:56
user22a6db72d7249
1032
edited Sep 11 at 18:56
user22a6db72d7249
1032
1032
asked Sep 10 at 20:22
David Grinberg
6661017
asked Sep 10 at 20:22
David Grinberg
6661017
asked Sep 10 at 20:22
David Grinberg
6661017
6661017
1
Sure, it only helps for resources served from different servers.
– Bergi
Sep 11 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.
– Michael Kjörling
Sep 11 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 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.
– Michael Kjörling
Sep 11 at 11:49
add a comment |Â
1
Sure, it only helps for resources served from different servers.
– Bergi
Sep 11 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.
– Michael Kjörling
Sep 11 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 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.
– Michael Kjörling
Sep 11 at 11:49
1
1
Sure, it only helps for resources served from different servers.
– Bergi
Sep 11 at 10:20
Sure, it only helps for resources served from different servers.
– Bergi
Sep 11 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.
– Michael Kjörling
Sep 11 at 11:34
@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.
– Michael Kjörling
Sep 11 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 at 11:47
@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 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.
– Michael Kjörling
Sep 11 at 11:49
@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.
– Michael Kjörling
Sep 11 at 11:49
add a comment |Â
2 Answers
2
active
oldest
votes
up vote
40
down vote
accepted
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).
answered Sep 10 at 20:34
Steffen Ullrich
107k12182247
Thanks. Do you know then how a client can be sure that the server it was talking to was not compromised?
– David Grinberg
Sep 10 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 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 at 14:27
add a comment |Â
up vote
23
down vote
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.
edited Sep 11 at 12:43
Andrew Myers
1035
answered Sep 10 at 21:19
ThoriumBR
18.4k44565
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 at 21:02
add a comment |Â
2 Answers
2
active
oldest
votes
2 Answers
2
active
oldest
votes
active
oldest
votes
active
oldest
votes
up vote
40
down vote
accepted
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).
answered Sep 10 at 20:34
Steffen Ullrich
107k12182247
Thanks. Do you know then how a client can be sure that the server it was talking to was not compromised?
– David Grinberg
Sep 10 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 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 at 14:27
add a comment |Â
up vote
40
down vote
accepted
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).
answered Sep 10 at 20:34
Steffen Ullrich
107k12182247
Thanks. Do you know then how a client can be sure that the server it was talking to was not compromised?
– David Grinberg
Sep 10 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 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 at 14:27
add a comment |Â
up vote
40
down vote
accepted
up vote
40
down vote
accepted
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).
answered Sep 10 at 20:34
Steffen Ullrich
107k12182247
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).
answered Sep 10 at 20:34
Steffen Ullrich
107k12182247
answered Sep 10 at 20:34
Steffen Ullrich
107k12182247
answered Sep 10 at 20:34
Steffen Ullrich
107k12182247
answered Sep 10 at 20:34
Steffen Ullrich
107k12182247
107k12182247
Thanks. Do you know then how a client can be sure that the server it was talking to was not compromised?
– David Grinberg
Sep 10 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 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 at 14:27
add a comment |Â
Thanks. Do you know then how a client can be sure that the server it was talking to was not compromised?
– David Grinberg
Sep 10 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 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 at 14:27
Thanks. Do you know then how a client can be sure that the server it was talking to was not compromised?
– David Grinberg
Sep 10 at 20:45
Thanks. Do you know then how a client can be sure that the server it was talking to was not compromised?
– David Grinberg
Sep 10 at 20:45
2
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 at 21:14
@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 at 21:14
10
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 at 14:27
@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 at 14:27
add a comment |Â
up vote
23
down vote
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.
edited Sep 11 at 12:43
Andrew Myers
1035
answered Sep 10 at 21:19
ThoriumBR
18.4k44565
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 at 21:02
add a comment |Â
up vote
23
down vote
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.
edited Sep 11 at 12:43
Andrew Myers
1035
answered Sep 10 at 21:19
ThoriumBR
18.4k44565
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 at 21:02
add a comment |Â
up vote
23
down vote
up vote
23
down vote
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.
edited Sep 11 at 12:43
Andrew Myers
1035
answered Sep 10 at 21:19
ThoriumBR
18.4k44565
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.
edited Sep 11 at 12:43
Andrew Myers
1035
answered Sep 10 at 21:19
ThoriumBR
18.4k44565
edited Sep 11 at 12:43
Andrew Myers
1035
edited Sep 11 at 12:43
Andrew Myers
1035
edited Sep 11 at 12:43
Andrew Myers
1035
1035
answered Sep 10 at 21:19
ThoriumBR
18.4k44565
answered Sep 10 at 21:19
ThoriumBR
18.4k44565
answered Sep 10 at 21:19
ThoriumBR
18.4k44565
18.4k44565
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 at 21:02
add a comment |Â
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 at 21:02
4
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 at 21:02
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 at 21:02
add a comment |Â
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
StackExchange.ready(
function ()
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fsecurity.stackexchange.com%2fquestions%2f193429%2fhow-does-subresource-integrity-actually-help%23new-answer', 'question_page');
);
Post as a guest
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
1
Sure, it only helps for resources served from different servers.
– Bergi
Sep 11 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.
– Michael Kjörling
Sep 11 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 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.
– Michael Kjörling
Sep 11 at 11:49