How secure are CDNs for delivering jQuery?
Asked Answered
R

4

24

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?

Reggi answered 15/8, 2010 at 21:26 Comment(8)
There's a privacy issue involved as well, since Google would be able to know which users that goes to your site.Corinthians
@Gert - They would possibly know, the more sites your user visits that also pull the same file from the CDN, the less likely they hit google via your site.Oxbridge
@Nick - As long as the user isn't refreshing the page (e.g. via the refresh button, CTRL-R or CTRL-F5).Corinthians
Actually, I think the browser is not allowed to cache HTTPS requests (if I remember correctly).Infer
@Infer https can be cached client side with the header cache-control set to public w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.9.1Hardigg
@JustinHamade so are the cdns setting it to public?Reggi
@Reggi its pretty easy to check, but yes they are.Hardigg
One way to cryptographically verify web page requisites is to use Subresource Integrity.Benildis
A
7

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.

Autotruck answered 21/8, 2010 at 0:27 Comment(6)
Protocol relative URLs aren't good to use due to bugs in IE where it will download the relatively referenced file twice: stevesouders.com/blog/2010/02/10/…Shamus
Ah, IE, as always a breath of fresh air. However, that problem seems only to extend to stylesheets. From the referenced page: "It turns out this only happens with stylesheets. The Missing schema, double download test page I created contains a stylesheet, an image, and a script that all have protocol relative URLs...The stylesheet is downloaded twice, but the image and script are only downloaded once."Autotruck
This is a form of Subresource Integrity checking. More information on a standard way to perform SRI available on MDN.Espadrille
@JoshH What's disappointing is that it's been seven years since this roll-your-own-integrity-checking answer was written, and subresource integrity as a browser feature is still not supported in all modern browsers (and apparently unlikely to be anytime soon). caniuse.com/#feat=subresource-integrityAutotruck
@KenRedler I haven't checked on status with the other browsers, but there are likely other priorities that take precedence, despite how important SRI may seem. Like SVG favicons! :)~Espadrille
I think this website is safe: code.jquery.com I compared hashes of the 3.4.1 version with the googleapis one and they do match.Stir
E
3

Is serving jQuery from CDN really less secure then serving it from the server itself?

Yes. If it's an external resource it's always less secure. How could you possibly be sure you know what your customers are really getting if you don't own the source code? And if you're not familiar with CloudBleed, you may want to read up before you continue.

If you do need to load jQuery from an external CDN for performance reasons, please ensure you're using Subsesource Integrity. More information on SRI can be located on MDN.

Lastly, if loading jQuery securely via CDN is a concern due to website performance and the creation of a Single-Point of Failure (and it should be a concern if you're at all familiar with the work of Steve Souders), you're almost certainly better off from a security and performance perspective moving all of your scripts in-house and loading them asynchronously in parallel using Fetch Injection. Just be sure, if you do, you're aggressively browser caching. And if you serve a global audience, make sure you're edge caching those assets.

Espadrille answered 15/4, 2017 at 11:54 Comment(0)
R
2

As your colleagues point out, hijacking a DNS server would be an issue here. It wouldn't be if you served the library from the same host as your site. However, if one uses HTTPS, it is unlikely that the attacker would have a valid certificate on the spoofed site. I do not know how browsers would react to this, but I suspect they would flag the site as unsafe (since some part of it can't be trusted) and act accordingly.

So in short; if the CDN is also accessed using HTTPS, there shouldn't be any large risks.

Edit: Also consider the privacy issue mentioned by Gert G.

Randolph answered 15/8, 2010 at 21:39 Comment(3)
you say it wouldn't be the issue if library is served from the same server as the site. But, if he can hijack DNS, than he can play Man in the Middle with the rest of the site as well.Reggi
But if he's hijacked your DNS record, the whole site is untrustworthy, regardless of where you get your jQuery library. The issue is then no longer related to the CDN.Randolph
well, exactly my point. If he hijacked DNS server, he can hijack my DNS record. In the end, CDN or not CDN, the security is the same.Reggi
C
-3

If trust exists online then Google is the most trustworthy...

There is no doubt that Google CDN is secure, but problems always always come from user's/server's Internet connection quality.

By the way, if you include the jQuery library with Google API loader script, Google adds some small stat tracking code to it's CDN available JavaScript libraries (about +4kb, see in Firebug) that makes 20kb minified and compressed jQuery library a bit heavy, plus foresee SSL speed.

Anyway minifying/compressing/caching jQuery isn't a problem these days, I suggest make your own...

Comeaux answered 23/8, 2010 at 15:2 Comment(3)
Google CDN version of JavaScript libraries contain no tracking code. The jQuery version from the official site is exactly the same file as the one Google hosts from CDN.Peripheral
If you include jQuery library with Google API loader script it will... <script type="text/javascript" src="google.com/jsapi?key=INSERT-YOUR-KEY"></script> then google.load('jquery', '1.4.2');Comeaux
I put in a suggestion to edit this answer to make it clearer to others users that tracking only happens with Google API loader, as per original author's own note in the comments below. Can this definitely be confirmed as happening though? Does Google really track when using its loader?Damalas

© 2022 - 2024 — McMap. All rights reserved.