Hacker News Reader

Comment by jlebar | Hacker News Reader

IMO this highlights the need for hash-verified script tags:

  <script src="https://jquery.com/whatever.js" hash="sha256,deadbeef...">

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.

View on HN

Looks like it was committed to Chromium today https://codereview.chromium.org/566083003/ as per this spec http://www.w3.org/TR/SRI/

Huh! That looks awesome. :)

and instead of 'hash' it use 'integrity' attribute

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".

why does the "integrity" attribute use this strange fake-URL?

ni:///

why 3 slashes? any clue?

Could be

  ni:
  //
  <empty field>
  /

file:: URIs can have it, too (http://superuser.com/questions/352133/what-is-the-reason-tha...)

They cite RFC6920 [1], which uses the "host" portion of the URL as an optional "authority" field.

[1] http://tools.ietf.org/html/rfc6920#section-3

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?

It's a proposal.

I made this thing: https://github.com/ryancdotorg/VerifyJS

but it requires CORS headers from the CDN and isn't well tested.

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.

That file is probably going to stay at v1.11.1 forever now: http://blog.jquery.com/2014/07/03/dont-use-jquery-latest-js/

(The blog post talks about /jquery-latest.js, but I'd imagine the same goes for all the version-number-free urls.)

If the jquery version changed, their site could break anyway due to changes in how the library worked.

Could, yes. But in practice this happens very rarely. Breaking the site because a new version is released with an old hash will happen.

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.

Unfortunately, it's the people least qualified to assess the safety of using an always-changing version who are most likely to do so.

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.

If someone could create a SHA256 collision just for that, we'd have bigger problems.

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.

(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.)

In the standard draft, there's a discussion of caching risks: https://w3c.github.io/webappsec/specs/subresourceintegrity/#...

> At no time have the hosted jQuery libraries been compromised.

The problem isn't with the CDN. It was supposedly on jquery.com, so you would have had to visit that url directly.

That said, I don't disagree with the hash ID in case something there was a problem with the CDN.

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.

If somebody has the ability to change the script file, what's to stop them from changing that hash, too?

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.

Good point. I was taking the parent's post literally, where jquery.com was used.

It's a solution for loading scripts from third party servers (e.g. jQuery), not from servers you control.

Reply on news.ycombinator.com