6 ms·

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 see

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 <script src="https://code.jquery.com/jquery-2.1.1.min.js"> sites could instead say <script src="https://code.jquery.com/jquery-2.1.1.min.js" hash="sha256:874706b2b1311a0719b5267f7d1cf803057e367e94ae1ff7bf78c5450d30f5d4"> This would also significantly reduce the risks from use of http instead of https, and from weaknesses in https itself.

teraflop 12y ago
This was suggested on the WHATWG mailing list last December, but AFAIK no action has been taken yet: http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2013-December/211148.html http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2013-Dec...
krapp 12y ago
I really like this idea. Is this something browser plugins would be able to do?
- jimrandomh 12y ago
  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.
- aikah 12y ago
  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.
Igglyboo 12y ago
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.
thirsteh 12y ago
And what happens when it's patched to fix a real issue? Your site will just break. Just don't trust so many third parties with your site's security: Host jQuery (and other things) yourself.
- johnduhart 12y ago
  >And what happens when it's patched to fix a real issue? Your site will just break. No, they will release a new version with a new URL.
- 0x0 12y ago
  Then you update the version number and the hash, just like you have to update the version number today already :)
- Drakim 12y ago
  Nah, the new version is hosted at a new url. 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.
- Igglyboo 12y ago
  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.
robertduncan 12y ago
This proposal already exists: Subresource Integrity http://www.w3.org/TR/SRI/ http://www.w3.org/TR/SRI/ http://www.chromestatus.com/features/6183089948590080 http://www.chromestatus.com/features/6183089948590080 http://status.modern.ie/subresourceintegrity http://status.modern.ie/subresourceintegrity
- Someone1234 12y ago
  I have a few issues with this proposal e.g. > 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.
  - jrochkind1 12y ago
    > 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.
maw 12y ago
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.
- acdha 12y ago
  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. http://www.w3.org/TR/SRI/ http://www.w3.org/TR/SRI/
- Someone1234 12y ago
  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.
- thomasfromcdnjs 12y ago
  Thomas chiming in from cdnjs.com here. We are responsible for quite a lot of copy and paste script includes these days and could potentially push people in this direction. If anyone is serious about investigating hash'ed includes shoot me an email with your thoughts, my email can be found on my HN profile.
alexjeffrey 12y ago
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.
- nightcracker 12y ago
  No secure hash function has collisions, so it's not necessary.
  - TheCoelacanth 12y ago
    Every hash function has collisions. It's just nearly impossible to find them if the hash function is secure.
    - alexjeffrey 12y ago
      ... 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.
    - nightcracker 12y ago
      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.
kpatrick 12y ago
IBM also has a patent pending on this.

teraflop 12y ago

This was suggested on the WHATWG mailing list last December, but AFAIK no action has been taken yet: http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2013-December/211148.html http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2013-Dec...

krapp 12y ago

I really like this idea. Is this something browser plugins would be able to do?

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

Igglyboo 12y ago

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.

thirsteh 12y ago

And what happens when it's patched to fix a real issue? Your site will just break. Just don't trust so many third parties with your site's security: Host jQuery (and other things) yourself.

johnduhart 12y ago
>And what happens when it's patched to fix a real issue? Your site will just break. No, they will release a new version with a new URL.
0x0 12y ago
Then you update the version number and the hash, just like you have to update the version number today already :)
Drakim 12y ago
Nah, the new version is hosted at a new url. 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.
Igglyboo 12y ago
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.

robertduncan 12y ago

This proposal already exists: Subresource Integrity http://www.w3.org/TR/SRI/ http://www.w3.org/TR/SRI/ http://www.chromestatus.com/features/6183089948590080 http://www.chromestatus.com/features/6183089948590080 http://status.modern.ie/subresourceintegrity http://status.modern.ie/subresourceintegrity

Someone1234 12y ago
I have a few issues with this proposal e.g. > 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.
- jrochkind1 12y ago
  > 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.

maw 12y ago

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.

acdha 12y ago
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. http://www.w3.org/TR/SRI/ http://www.w3.org/TR/SRI/
Someone1234 12y ago
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.
thomasfromcdnjs 12y ago
Thomas chiming in from cdnjs.com here. We are responsible for quite a lot of copy and paste script includes these days and could potentially push people in this direction. If anyone is serious about investigating hash'ed includes shoot me an email with your thoughts, my email can be found on my HN profile.

alexjeffrey 12y ago

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.

nightcracker 12y ago
No secure hash function has collisions, so it's not necessary.
- TheCoelacanth 12y ago
  Every hash function has collisions. It's just nearly impossible to find them if the hash function is secure.
  - alexjeffrey 12y ago
    ... 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.
  - nightcracker 12y ago
    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.

kpatrick 12y ago

IBM also has a patent pending on this.