Question

We build sites that have a public (non-secured) area and secured (delivered over HTTPS) area and we use jQuery library.

Recently I suggested we use Google CDN for jQuery delivery. Some of my colleagues expressed concerns in regards to security aspect of this way of delivering JavaScript libraries.

For example, they mention the scenario where someone might hijack DNS server and then inject maliciously modified library, opening the door for different security attacks.
Now, if hacker can inject malicious code through Google CDN, then he can probably do the same if jQuery is served from the site itself, right?

It seems that google CDN supports serving libraries over SSL.

Is serving jQuery from CDN really less secure then serving it from the server itself? How serious is this threat?

Answer 1

One way to mitigate the risk is to run a checksum against the file obtained from Google, and compare that to a known-good checksum already in your possession.

In response to a question about whether Google alters these files in any way, Google employee Ben Lisbakken suggested comparing MD5 checksums of a file provided by Google to the canonical version of that same file as obtained from its maintainers’ home site. Read comment eight on the linked site for context.

If you’re concerned about DNS hijacking, then of course the same concerns would apply to the file as obtained from the “original” site. You also probably don’t want to incur the speed penalty of running a checksum against the jQuery file on every request — unless you’re incredibly paranoid. And of course, doing so would remove all advantages of using a CDN.

But assuming you’re only somewhat paranoid, you could try something like this:

• Make sure you’re referencing a unique and specific version of the jQuery file from Google. For example, do this:

  http://ajax.googleapis.com/ajax/libs/jquery/1.4.2/jquery.min.js
  

  and not this:

  http://ajax.googleapis.com/ajax/libs/jquery/1.4/jquery.min.js
  

  The latter version may return 1.4.2 now, but 1.4.3 tomorrow. If you have a combination of http and https needs, you can use protocol-relative URLs, like this:

  //ajax.googleapis.com/ajax/libs/jquery/1.4.2/jquery.min.js
  

• Initially generate and store your own checksum for this file.

• Periodically repeat the process, and make sure the new checksum matches the old one. If it doesn’t, sound the klaxons.

You can do this programmatically, of course. You decide what interval makes sense. Every minute? Every five? You now have the makings of an automatic kill-switch whose sensitivity you can adjust to your preference. The “monitor” routine certainly doesn’t have to run synchronously within the application you’re looking to secure; perhaps you run a small utility application on the same server just for this purpose.

It’s easy enough to test: just alter the stored hash. Since you’re referencing a specific file version, the panic button won’t be pressed with every minor version update. When you do want to move to a new version of jQuery, change the AJAX API URL on your site and store the new hash.