CDN用于传递jQuery的安全性如何? [英] How secure are CDNs for delivering jQuery?

问题描述

我们构建的站点具有公共(非安全)区域和安全(通过HTTPS交付)区域，并且我们使用jQuery库.

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

最近我建议我们使用Google CDN进行jQuery交付.我的一些同事对这种提供JavaScript库的方式在安全性方面表示担忧.

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.

例如，他们提到有人可能劫持DNS服务器，然后注入经过恶意修改的库的情况，这为不同的安全攻击打开了大门. 现在，如果黑客可以通过Google CDN注入恶意代码，那么如果从站点本身提供jQuery，他可能也可以这样做，对吗?

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?

似乎Google CDN支持通过SSL提供库.

It seems that google CDN supports serving libraries over SSL.

从CDN提供jQuery是否真的比从服务器本身提供jQuery安全性低?这种威胁有多严重?

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

推荐答案

减轻风险的一种方法是对从Google获得的文件运行校验和，并将其与您已经拥有的已知有效的校验和进行比较.

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.

针对有关Google是否以任何方式更改这些文件的问题，Google员工 Ben Lisbakken建议将Google提供的文件的MD5校验和与从其维护者的主站点获得的同一文件的规范版本进行比较.阅读链接网站上的注释八以获取上下文.

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.

如果您担心DNS劫持，那么从原始"站点获得的文件当然也会受到同样的关注.您也可能不想在每次请求时都对jQuery文件运行校验和带来速度上的损失-除非您极度偏执.当然，这样做会消除使用CDN的所有优势.

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:

• 确保您引用的是Google的jQuery文件的唯一且特定的版本.例如，执行以下操作:

• 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

不是这个:

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

后面的版本可能现在返回1.4.2，但是明天将返回1.4.3.如果您将http和https需求结合在一起，则可以使用相对协议的URL，如下所示:

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.

您当然可以以编程方式执行此操作.您决定什么间隔有意义.每一分钟?每五个?现在，您将拥有自动终止开关的功能，可以根据自己的喜好调整其灵敏度.当然，监视"例程不必在要保护的应用程序中同步运行；也许您只是为此目的而在同一台服务器上运行一个小型实用程序.

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.

测试非常容易:只需更改存储的哈希即可.由于您引用的是特定文件版本，因此每次次要版本更新都不会按下紧急按钮.当您确实要转移到新版本的jQuery时，请在您的网站上更改AJAX API URL并存储新的哈希值.

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.

这篇关于CDN用于传递jQuery的安全性如何?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！