5 ms·

IMO this highlights the need for hash-verified script tags: <script src="https://jquery.com/whatever.js" hash="sha256,deadbeef..."> The browser would refuse

by jlebar 12y ago

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.

Kortaggio 12y ago
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?
- ryan-c 12y ago
  It's a proposal. I made this thing: https://github.com/ryancdotorg/VerifyJS https://github.com/ryancdotorg/VerifyJS but it requires CORS headers from the CDN and isn't well tested.
nthitz 12y ago
Looks like it was committed to Chromium today https://codereview.chromium.org/566083003/ https://codereview.chromium.org/566083003/ as per this spec http://www.w3.org/TR/SRI/ http://www.w3.org/TR/SRI/
- jlebar 12y ago
  Huh! That looks awesome. :)
- rudilee 12y ago
  and instead of 'hash' it use 'integrity' attribute
  - jlebar 12y ago
    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".
  - franze 12y ago
    why does the "integrity" attribute use this strange fake-URL? ni:/// why 3 slashes? any clue?
    - Someone 12y ago
      Could be ni: // <empty field> / file:: URIs can have it, too (http://superuser.com/questions/352133/what-is-the-reason-that-file-urls-start-with-three-slashes-file-etc http://superuser.com/questions/352133/what-is-the-reason-tha...)
    - kam 12y ago
      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 http://tools.ietf.org/html/rfc6920#section-3
    - deleted 12y ago
      [deleted]
    - the_mitsuhiko 12y ago
      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).
chc 12y ago
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.
- jlebar 12y ago
  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.
huskyr 12y ago
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.
- DougBTX 12y ago
  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/ 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.)
- _ikke_ 12y ago
  If the jquery version changed, their site could break anyway due to changes in how the library worked.
  - huskyr 12y ago
    Could, yes. But in practice this happens very rarely. Breaking the site because a new version is released with an old hash will happen.
    - aaronm67 12y ago
      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.
      - joshuacc 12y ago
        Unfortunately, it's the people least qualified to assess the safety of using an always-changing version who are most likely to do so.
Skywing 12y ago
If somebody has the ability to change the script file, what's to stop them from changing that hash, too?
- adamtj 12y ago
  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.
  - Skywing 12y ago
    Good point. I was taking the parent's post literally, where jquery.com was used.
- 14113 12y ago
  It's a solution for loading scripts from third party servers (e.g. jQuery), not from servers you control.
annnnd 12y ago
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.
- edandersen 12y ago
  If someone could create a SHA256 collision just for that, we'd have bigger problems.
  - jlebar 12y ago
    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.
- dchest 12y ago
  (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/#risks-1 https://w3c.github.io/webappsec/specs/subresourceintegrity/#...
vlunkr 12y ago
> 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.

by jlebar 12y ago

Kortaggio 12y ago

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?

ryan-c 12y ago
It's a proposal. I made this thing: https://github.com/ryancdotorg/VerifyJS https://github.com/ryancdotorg/VerifyJS but it requires CORS headers from the CDN and isn't well tested.

nthitz 12y ago

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

jlebar 12y ago
Huh! That looks awesome. :)
rudilee 12y ago
and instead of 'hash' it use 'integrity' attribute
- jlebar 12y ago
  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".
- franze 12y ago
  why does the "integrity" attribute use this strange fake-URL? ni:/// why 3 slashes? any clue?
  - Someone 12y ago
    Could be ni: // <empty field> / file:: URIs can have it, too (http://superuser.com/questions/352133/what-is-the-reason-that-file-urls-start-with-three-slashes-file-etc http://superuser.com/questions/352133/what-is-the-reason-tha...)
  - kam 12y ago
    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 http://tools.ietf.org/html/rfc6920#section-3
  - deleted 12y ago
    [deleted]
  - the_mitsuhiko 12y ago
    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).

chc 12y ago

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.

jlebar 12y ago
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.

huskyr 12y ago

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.

DougBTX 12y ago
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/ 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.)
_ikke_ 12y ago
If the jquery version changed, their site could break anyway due to changes in how the library worked.
- huskyr 12y ago
  Could, yes. But in practice this happens very rarely. Breaking the site because a new version is released with an old hash will happen.
  - aaronm67 12y ago
    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.
    - joshuacc 12y ago
      Unfortunately, it's the people least qualified to assess the safety of using an always-changing version who are most likely to do so.

Skywing 12y ago

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

adamtj 12y ago
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.
- Skywing 12y ago
  Good point. I was taking the parent's post literally, where jquery.com was used.
14113 12y ago
It's a solution for loading scripts from third party servers (e.g. jQuery), not from servers you control.

annnnd 12y ago

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.

edandersen 12y ago
If someone could create a SHA256 collision just for that, we'd have bigger problems.
- jlebar 12y ago
  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.
dchest 12y ago
(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/#risks-1 https://w3c.github.io/webappsec/specs/subresourceintegrity/#...

vlunkr 12y ago

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