The browser would refuse to load the script if its hash didn't match.
This would be far safer than what we currently do.
It would also allow the browser to more aggressively cache scripts -- if it already has a script in the cache from another URI whose hash matches, e.g. because someone else included jquery from Google's CDN, it can substitute it in.
This has an easy legacy story, too; old browsers will just ignore the "hash" tag and behave as they currently do.
To be clear, I was totally making up this proposal; I wasn't aware that there was a spec. Nothing should be read into the fact that I used "hash" and they use "integrity".
Because the ni scheme is separate from this proposal and it supports having a server there if you retrieve named information from somewhere else (implementation defined i think).
Given the number of websites that rely on jQuery and other hosted JavaScript libraries, I can't believe there isn't yet a well-publicized way of verifying external scripts before loading them. If someone managed to compromise a jQuery CDN, we're looking at a Heartbleed-level vulnerability in terms of scale and impact.
I've never seen the hash attr before. Is this an experimental feature that is already available on live browsers, or only a proposal?
For the most-common use case (people using code.jquery.com/jquery.js), this won't work. That URL always links to the latest version, which updates with every new release, hence invalidating the hash (and the developer's website).
You could argue that a well-educated developer should know that and only use this for tagged releases though.
Very rarely being every single release? You should not be using a changing library in any production code, you're just asking for problems.
If all you're using jQuery for is a document.querySelectorAll polyfill + the most primitive event handling, you're possibly safe, as those don't change terribly often...but at that point, you should probably be using a different library or a custom build of jQuery.
Aggressive caching might not be such a good idea - if someone figured out how to create a collision, he could replace all those ga.js / jquery.js / ... calls with his own scripts. The attacker doesn't even have to be "man in the middle", he just needs to get victims to his site.
(Note: technically, this is not a collision attack: if you goal is to find a second input which results in the same hash for the given input, this is called a second-preimage attack. A collision attack is the one when you can create two inputs which result in the same hash. For example, even though collision resistance of MD5 is broken, AFAIK, there's no second-preimage attacks known for it, so even if this integrity checking used MD5, you probably wouldn't be able to create evil.js such that md5(evil.js) == md5(jquery.js) if you didn't control the contents of jquery.js.)
To be specific, if you can create an arbitrary primage for sha256, you could pwn all digital signatures that sign a sha256 of the message. So in particular, you'd own all TLS connections and certs that use sha256.
The existence of a hash attribute wouldn't do anything at all for the supposed compromise in question, so I don't understand how a possibly nonexistent breach is supposed to highlight a feature that wouldn't help to prevent this or similar breaches in the future.
The issue is that, if jquery.org can plausibly be hacked, then jquery's CDN can presumably also plausibly be hacked. This would allow an attacker to serve whatever she wanted to any page which used this CDN, even pages protected with TLS.
For jquery, the page is often on your server and the script is on a CDN. The worry is that if an attacker compromises the jquery source on the CDN, they can exploit thousands or millions of sites on as many different servers. If each of those servers were serving pages with hashes, the modified jquery on the CDN would be rejected.
So let's say that the jquery.com server was not compromised... What else could have caused RiskIQ to see the injected script tag at the end of the body element?
Could there have been an injection at the ISP? Was it a DNS heist? Or another BGP compromise?
I must admit I'm quite intrigued and looking forward to seeing what the investigation uncovers.
This implies that the script tag injection was indeed served to a wide audience. Although I guess there is no way to know that these requests came from the jquery.com site.
Fair enough, but what about stuff like google analytics or other legit third-party scripts, or ads god forbid? Seems like the problem of pulling third-party code may be bigger than laziness.
"mostly". It's not unusual to deliver an easy to detect and obvious malware and your real payload to catch those convinced that they got it all.
This is the reason why being equipped for automatic reimaging of a server and quick rotation of keys and passwords should be standard practice nowadays.
You have now revealed that if somebody were to get access to one of your servers, they just need to drop some script kiddie trash at the very front, and then put their heavy stuff deep into the system.
You'll clean up the script kiddie trash, and call it a day.
At the moment jquery.com loads with the following content:
<body>I'm looking for a new job, I'm so sorry for this experiment with iframe, no one was injured, all files was permanently deleted. Greetz: Umputun, Bobuk, Gray, Ksenks @ radio-t.com My PGP public key is:
<key>
</body>
Normally I hate glib citations of Betteridge's law[0], but in this case they really ought to unequivocally state right in the headline "No, jquery.com was not compromised". Anything else seems like they're hiding something.
Quite a silly response, considering the content and how easy it is to view just the text
Earlier today, RiskIQ published a blog post stating that the jQuery.com web servers were compromised and serving the RIG exploit kit for a short period of time on the afternoon of September 18th. Our internal investigation into our servers and logs have not yet found the RIG exploit kit or evidence that there was in fact a compromise.
RiskIQ was able to make contact with the jQuery Infrastructure team on September 18th, at which point with members of the RiskIQ team tried to find evidence of compromise. So far the investigation has been unable to reproduce or confirm that our servers were compromised. We have not been notified by any other security firm or users of jquery.com confirming a compromise. Normally, when we have issues with jQuery infrastructure, we hear reports within minutes on Twitter, via IRC, etc.
At no time have the hosted jQuery libraries been compromised.
Currently the only potential system compromised is the web software or server that runs jquery.com. We have asked RiskIQ to help us look through our server logs and systems to help identify when and how a compromise happened. Please check this blog post for updates on the situation.
Even though we don’t have immediate evidence of compromise, we have taken the proper precautions to ensure our servers are secure and clean. If you happened to visit any of the our sites on September 18th and are afraid of your system being compromised you can follow the advice RiskIQ recommends:
Immediately re-image system
Reset passwords for user accounts that have been used on the system
See if any suspicious activity has originated from the offending system
Are there any consequences for the hosting AS? Would they know who registered the domains and hosted the kit? If not, why are they still getting peers?
This would be far safer than what we currently do.
It would also allow the browser to more aggressively cache scripts -- if it already has a script in the cache from another URI whose hash matches, e.g. because someone else included jquery from Google's CDN, it can substitute it in.
This has an easy legacy story, too; old browsers will just ignore the "hash" tag and behave as they currently do.