31–40 of 78 posts
Earlier quoted context omitted.
How is that dangerous?
It leaks private user info -- a malicious server could include a JS file confirmed to be highly sensitive/top secret, and measure whether the client already has that cached. If so then the user is confirmed a sensitive target.
Earlier quoted context omitted.
Signatures are taken care of by connecting via TLS. If a hypothetical attack breaks TLS or you don't use it, you can just change the public key served.
This is to prevent files on a 3rd party CDN from being loaded if they've been replaced with malicious ones.
Thanks for the downmods.
Earlier quoted context omitted.
This is to prevent files on a 3rd party CDN from being loaded if they've been replaced with malicious ones.
A content hash is good enough. The trusted hash is sent over an already trusted channel (TLS). Thanks for the downmods.
Couldn't the great chinese firewall just intercept Github.com's HTML page as well and change the subresource integrity hashes? I thought that the Great Chinese Firewall already has the ability to penetrate SSL connections via some means.
The way that this fixes the issue is by ensuring that the file being loaded on those thousands of websites is the correct one, and not the malicious attack script that was injected by the Chinese government or other such actors, otherwise it's not run at all.
Could the Chinese government rewrite the HTML of all these thousands of websites to also change the hash? Theoretically yes, but practically it makes it much more difficult.
Edit : post below is right, nonces are only for inline scripts https://bugs.webkit.org/show_bug.cgi?id=89577 original: IIRC CSP already has hashes for resources, which also would handle this purpose. As a side note, there's at least one CDN already hosting fake copy of bootstrap - I've seen a mlicious extension loading it in my report-uri.io logs.
Earlier quoted context omitted.
A content hash is good enough. The trusted hash is sent over an already trusted channel (TLS). Thanks for the downmods.
The point is that with a signature you wouldn't have to change all the pages including the resource, but just sign the updated resource with the same key.
It would seem more desirable to be able to point to a specific version, instead of allowing a third party to be able to insert implicitly trusted code without acknowledgement.
Earlier quoted context omitted.
Signatures are taken care of by connecting via TLS. If a hypothetical attack breaks TLS or you don't use it, you can just change the public key served.
This is to prevent files on a 3rd party CDN from being loaded if they've been replaced with malicious ones.
Is there any security gain from doing that?
What about caching? If the HTML and the JS are both updated, but the browser receives the new version of one and the old version of another, this will break your page. (Since you'd now have to update the integrity attribute for every JS change, it means you run this risk every time you update your JS.) To be fair, running a mismatched version of the JS could already break things if the changes are big enough, but for…
Earlier quoted context omitted.
The point is that with a signature you wouldn't have to change all the pages including the resource, but just sign the updated resource with the same key.
It's just a semantic question. Does a URL point to a specific version of a resource or does it point to whatever the server considers to be the resource at a given time. It would seem more desirable to be able to point to a specific version, instead of allowing a third party to be able to insert implicitly trusted code without acknowledgement.