As others have observed, if the attackers had wanted, they could have modified the hosted jQuery scripts and used them to attack other web sites. They don't seem to have done so, but this highlights how the practice of including scripts hosted by other parties is a security problem for the Internet as a whole.
But there's an easy way to fix it. Browsers should support a hash attribute for <script> tags, so instead of
The other benefit to this is that the browser can be confident that it's cached copy matches the requested file and we can now cache files that come from different hosts.
Example: User has jquery cached from googles CDN, jquery will not be loaded from microsofts cdn because it has the same hash.
> 3.2.1 Agility: the user agent will choose the strongest hash function in the list
Aside from the fact this contradicts the next section (Priority), it also would discourage browser vendors from adding better (slower) hashing functions as then they would be "forced" to utilise them.
Instead the standard should be: The "the fastest hash function which the browser finds secure." So if SHA-256 and SHA-512 were available, it would use SHA-256 until it was found insecure, then the browser would use SHA-512.
> Validation using unsupported hash functions always fails (see the “Does resource match metadataList” algorithm below). Authors are therefore encouraged to use strong hash functions, and to begin migrating to stronger hash functions as they become available.
No. Just no. If Chrome was the first to market with e.g. SHA-9999, I'd be unable to utilise that until literally every single browser on the market supported it (as it was fail by default).
Imagine if this standard existed in the IE6 days, today if you tried to use SHA-512 (which, let's assume, IE6 didn't support) the resources would fail to load every time (and you'd wind up having half a dozen different hashes just to hit something that was supported).
It should just ignore unknown hash functions, not fail. If the integrity attribute only had one hash function and it was unsupported then the entire attribute should be discarded.
Fail by default isn't even the HTML way. Ignore by default is.
> It should just ignore unknown hash functions, not fail. If the integrity attribute only had one hash function and it was unsupported then the entire attribute should be discarded.
Your proposal would make the hash attribute advisory. If I put a hash attribute on there, should I be able to count on it, and know that browsers won't load unless they can verify it? Or is it just advisory, and browsers may choose to ignore it, and I can't actually count on browsers only loading if hash matches?
Of course, I guess the fact that older browsers will always exist that ignore it (and that all browsers are essentially untrusted software, as far as the developer is concerned) may point to "you'd best consider it advisory only" anyway, I suppose.
Even without considering older browsers, the hash will be deliberately ignored by some clients for things like NoScript surrogates. Every tag and attribute is just advisory to the client; the client can always do what the user wants instead of what the server wants.
Even if we ignore the hash suggestion, you don't want to have some dev on the other side of the planet suddenly update one of your libraries on your live website.
That should never be a thing in the first place, so it won't be a problem.
The URL will change along with the version and hash number, unless you're using jquery-latest.min.js which is a bad idea in general and wouldn't make sense to use with the hash attribute anyways.
Yep, a lot of people have come up with this idea independently (I'm one of them). It's pretty obvious, after all.
But I don't think it will ever get much traction. Believe it or not, it's too far beyond the organizational and technical capacities of the people behind too many sites. The benefit, aside from slightly improved caching, will be minimal.
And if you're careful and meticulous you aren't doing braindead things like hotlinking javascript in the first place.
The thing which will give it traction[1] is performance: if a browser starts letting you host locally but say “Yes, this is the same jQuery you have in your cache” that'll be a big win for a number of sites, particularly on mobile where it could reduce expensive network traffic and reduce cache duplication.
You assume that such people wouldn't just copy/paste a code fragment. If that code fragment happened to already come with a hash/CRC, they likely won't remove it.
I guess, but it would have to download the script before hand,check the hash,then append the script somewhere. I dont see any other technique."document.write" is only efficient while the page itself is loading.
It's an interesting problem nevertheless, and could be extended to any link or src attributes in tags.
In case the hash and the file dont match,the browser wouldnt load that file.
I don't think a plugin could do it, but it's back- and forward-compatible enough that it makes sense to just go ahead and add it to a browser without waiting for standardization.
realistically you would want to use a merkle tree to hash the source, to make it more secure against a chosen plaintext collision, but aside from that this'd be a great addition.
... and it's impossible to know for sure that a hash is secure against collisions. For example, MD5 was the standard for hashing for quite some time but is considered broken today due to attacks that have since been discovered. By implementing the hashing using merkle trees, you increase the avalanche effect relative to the data, making it much harder to force a collision.
Obviously any compression function has collisions - this is a mathematical fact. What I mean with "no secure hash function has collisions" is that if you are using a secure hash function you shouldn't need extra defenses against collisions attacks as the "secure" in "secure hash function" implies those attacks are infeasible.
This is why everyone should have "Click To Play" turned on for all browser plugins.
It would have stopped the Java, Flash, and Silverlight drive-by attacks even if you had a vulnerable version installed.
The IE/browser based exploits can only be mitigated by keeping up to date or utilising something like EMET (although I don't really expect everyone to be running EMET).
PS - CVE-2013-0322 doesn't look like an IE10 issue.
I can't help but think this was a huge missed opportunity for the attackers. Instead of hosting malware on the site, they could have infected just the hosted jquery and attacked a ton of sites all at once.
Reading this news, I was wondering, whether from a security POV, including jQuery from Google's CDN rather than jQuery's own would be better.
My reasoning was that Google is bigger, therefore probably has better security. They also need very similar technology for securing the AdSense includes. Finally, if someone manages to compromise Google, there might be bigger problems than hosting a malware-d jQuery (although that would be pretty big).
It's not a very convincing reason, risk-wise, IMO. I'm assuming that jQuery should be pretty on top of the security of their CDN. Also that proposed new hash/integrity attribute for the SCRIPT tag seems way more promising.
You do however leak information to Google about your customers browsing behaviour. If you are using Google Analytics you obviously do that to an even greater degree anyway so there is no further harm for most users but it is more likely to be blocked by me and I always block Google Analytics.
Can anybody tell, if users with Linux systems can be affected?
It seems, that primary Windows PCs are targeted, but since also a Flash exploit is targeted, that also existed on Linux, it is not clear to me, if a Linux system could be infected.
I don't know, if I visited the site at this specific date, but I am rather sure, that if I was, I used a Linux system.
When a non-technical website is hacked, I expect a dumb press release like this. But when an attack targets the tech industry, I expect a deeper level of coverage. What malware is served? Does it work on OS X or linux?
Speaking as someone who whitelisted "jquery.com" in NoScript and RequestPolicy, I care. The various CDN-hosted libraries are very convenient, but to me they seem somewhat risky single points of failure. It's certainly possible that an attacker could parlay their access to the main JQuery web site into access to the the JQuery CDN (e.g., an admin uses the same password in both places). We're fortunate that (probably, hopefully) didn't happen in this case.
How many people Google a jquery function every day?
How many of those people were compromised (~6% conversion)?
How many machines were compromised and how many man hours will it take it re-secure?
In other words, plenty of people should care. You could argue that a modified version of jquery/jquery.min on CDNs would be more devastating, but both are bad news.
But there's an easy way to fix it. Browsers should support a hash attribute for <script> tags, so instead of
sites could instead say This would also significantly reduce the risks from use of http instead of https, and from weaknesses in https itself.