61–70 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.
This matters: If someone wants to hack my company, they're not going to do it by hacking Github's CDN. They're going to do it by targeting particular employees -- probably focusing on those who have the least security experience. To reduce risk, I need to give each team member the least authority they need to do their job. Github is making it really hard for me to do that; I tend to have to give "admin" rights to everyone. :(
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 Great Firewall would probably have copies of private keys issued by CNNIC, and there's a bunch of attacks to get private keys via heartbleed, and a bunch of Debian easily guessable private keys, but there's no general purpose 'penetrate SSL' attack that we know of right now.
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…
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…
> 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. Only if your page requires JavaScript to function and doesn't gracefully degrade. None of us would ever write that sort of page, would we?
For example the tag works that way.
<script src="..." is very dangerous. At best, you can vet the src and check to see if it's benign or not. Often times, that vendor and their "1-line of javascript to get our whiz-bang service" in turn loads other javascript files. I don't see how cryptographically signing the bootloader solves anything in this case. Compromised analytics or vendor javascript will still lead to total site pwnage if I'm reading this ri…
This protects you from providers that go rogue or are compromised after you enable their JS. It also lets you use CloudFront as a CDN for your own JS without having to trust them to serve the content as you described it, if you calculate your hashes based on the scripts you sent them.
Earlier quoted context omitted.
No, it was a very good point. Not everyone adds hashes to filenames, and to me it seems that you're right in that weird caching can break pages that way. If indeed this is the case, subresource integrity needs a big warning sign about that. For me, your comment was that warning sign, so please keep posting while you're not awake yet.
Why would it need a warning? If the HTML provides a new integrity="" hash, then any cached version obviously wouldn't pass. Subresource integrity makes it easier to determine if a cached file has expired. The file can be permanently cached for any HTML that requests the same hash value(s).
1) Load the resource specified in src (from network or cache)
2) If there's an integrity attribute, verify its hash
Widespread adoption of Subresource Integrity could
have largely prevented the Great Cannon attack
earlier this year.
In the attack on GitHub and GreatFire.org, the GC
intercepted traffic sent to Baidu infrastructure
servers that host commonly used analytics, social,
or advertising scripts. If the GC saw a request
for certain Javascript files on one of these servers,
it appeared to probabilistically take one of two
actions: it either passed the request onto Baidu’s
servers unmolested (roughly 98.25% of the time),
or it dropped the request before it reached Baidu
and instead sent a malicious script back to the
requesting user (roughly 1.75% of the time). In
this case, the requesting user is an individual
outside China browsing a website making use of a
Baidu infrastructure server (e.g., a website with
ads served by Baidu’s ad network). The malicious
script enlisted the requesting user as an unwitting
participant in the DDoS attack against GreatFire.org
and GitHub.
To prevent this sort of attack with SRI you would need to change your page to look like:
SRI is useful in the case where the entity producing the html is referencing js that they've uploaded to a third party CDN or js where they choose what version to run, but not in the normal "include a snippet and we'll do stuff to your page" model.
(To block the Great Cannon there, what would have worked would be moving the js serving to HTTPS.)
I really wish browsers could leverage this for caching across origins. If my copy of jQuery has the same SHA256 as another file the user has already downloaded, there's no need to load it again
There's subtle, dangerous ways this can be exploited. (Short version: It'd make SRI usable as an oracle to confirm or deny guesses for the content of a cross-domain resource.)
Earlier quoted context omitted.
If you include content produced by a third party (e.g. JQuery) off a CDN, right now you can use the hash-based SRI mechanism to make sure that only the exact file you specified can be included, otherwise the CDN could suddenly send any compromised code. The file can't be changed, because otherwise the hash wouldn't match. With a signature, you could specify "include cdn.com/jquery-X if signed by the JQuery project",…
This is more convenient but less secure than a straight-up hash. If an attacker compromises the JQuery signing key, they could still serve malicious files. With a hash, the authenticity is ONLY dependant on the TLS connection to the main website, e.g. github. TL;DR: * hash: need to compromise the main website, that supplies (and authenticates) the hash * signature by CDN: attacker can either compromise the main websi…