Mixing
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 yesterday
Jesse Sielaff
1032
asked 2 days ago
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 yesterday
Jesse Sielaff
1032
asked 2 days ago
David Grinberg
6661017
1
Sure, it only helps for resources served from different servers.
– Bergi
yesterday
@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
yesterday
@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
yesterday
@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
yesterday
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 yesterday
Jesse Sielaff
1032
asked 2 days ago
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 yesterday
Jesse Sielaff
1032
asked 2 days ago
David Grinberg
6661017
edited yesterday
Jesse Sielaff
1032
asked 2 days ago
David Grinberg
6661017
edited yesterday
Jesse Sielaff
1032
edited yesterday
Jesse Sielaff
1032
edited yesterday
Jesse Sielaff
1032
1032
asked 2 days ago
David Grinberg
6661017
asked 2 days ago
David Grinberg
6661017
asked 2 days ago
David Grinberg
6661017
6661017
1
Sure, it only helps for resources served from different servers.
– Bergi
yesterday
@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
yesterday
@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
yesterday
@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
yesterday
add a comment |Â
1
Sure, it only helps for resources served from different servers.
– Bergi
yesterday
@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
yesterday
@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
yesterday
@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
yesterday
1
1
Sure, it only helps for resources served from different servers.
– Bergi
yesterday
Sure, it only helps for resources served from different servers.
– Bergi
yesterday
@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
yesterday
@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
yesterday
@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
yesterday
@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
yesterday
@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
yesterday
@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
yesterday
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 2 days ago
Steffen Ullrich
105k10175243
Thanks. Do you know then how a client can be sure that the server it was talking to was not compromised?
– David Grinberg
2 days ago
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
2 days ago
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
yesterday
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 yesterday
Andrew Myers
1034
answered 2 days ago
ThoriumBR
16.7k44062
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
yesterday
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 2 days ago
Steffen Ullrich
105k10175243
Thanks. Do you know then how a client can be sure that the server it was talking to was not compromised?
– David Grinberg
2 days ago
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
2 days ago
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
yesterday
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 2 days ago
Steffen Ullrich
105k10175243
Thanks. Do you know then how a client can be sure that the server it was talking to was not compromised?
– David Grinberg
2 days ago
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
2 days ago
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
yesterday
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 2 days ago
Steffen Ullrich
105k10175243
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 2 days ago
Steffen Ullrich
105k10175243
answered 2 days ago
Steffen Ullrich
105k10175243
answered 2 days ago
Steffen Ullrich
105k10175243
answered 2 days ago
Steffen Ullrich
105k10175243
105k10175243
Thanks. Do you know then how a client can be sure that the server it was talking to was not compromised?
– David Grinberg
2 days ago
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
2 days ago
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
yesterday
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
2 days ago
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
2 days ago
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
yesterday
Thanks. Do you know then how a client can be sure that the server it was talking to was not compromised?
– David Grinberg
2 days ago
Thanks. Do you know then how a client can be sure that the server it was talking to was not compromised?
– David Grinberg
2 days ago
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
2 days ago
@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
2 days ago
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
yesterday
@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
yesterday
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 yesterday
Andrew Myers
1034
answered 2 days ago
ThoriumBR
16.7k44062
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
yesterday
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 yesterday
Andrew Myers
1034
answered 2 days ago
ThoriumBR
16.7k44062
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
yesterday
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 yesterday
Andrew Myers
1034
answered 2 days ago
ThoriumBR
16.7k44062
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 yesterday
Andrew Myers
1034
answered 2 days ago
ThoriumBR
16.7k44062
edited yesterday
Andrew Myers
1034
edited yesterday
Andrew Myers
1034
edited yesterday
Andrew Myers
1034
1034
answered 2 days ago
ThoriumBR
16.7k44062
answered 2 days ago
ThoriumBR
16.7k44062
answered 2 days ago
ThoriumBR
16.7k44062
16.7k44062
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
yesterday
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
yesterday
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
yesterday
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
yesterday
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
yesterday
@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
yesterday
@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
yesterday
@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
yesterday