当前位置：文江博客话题详情

CDN 交付 jQuery 的安全性如何？

发布于 2024-09-14 14:37:40 字数 347 浏览 7 评论 0原文

我们构建的网站具有公共（非安全）区域和安全（通过 HTTPS 交付）区域，并且我们使用 jQuery 库。

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

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

谷歌 CDN 似乎支持通过 SSL 提供库服务。

从 CDN 提供 jQuery 真的不如从服务器本身提供服务安全吗？这种威胁有多严重？

原文

分享到QQ

分享到微博

如果你对这篇内容有疑问，欢迎到本站社区发帖提问参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。

发布评论

需要登录才能够评论，你可以免费注册一个本站的账号。

别挽留 2024-09-21 14:37:40

降低风险的一种方法是对从 Google 获得的文件运行校验和，并将其与您已经拥有的已知良好的校验和进行比较。

在回答有关 Google 是否以任何方式更改这些文件的问题时，Google 员工 Ben Lisbakken建议将 Google 提供的文件的 MD5 校验和与从其维护者主页获取的同一文件的规范版本进行比较。请阅读链接网站上的评论八了解上下文。

如果您担心 DNS 劫持，那么从“原始”站点获取的文件当然也会出现同样的问题。您可能也不想因为在每个请求上对 jQuery 文件运行校验和而导致速度损失——除非您非常偏执。当然，这样做会消除使用 CDN 的所有优势。

但假设您只是有点偏执，您可以尝试这样的操作：

确保您引用的是来自 Google 的 jQuery 文件的唯一且特定的版本。例如，执行以下操作：
```
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，如下所示：
```
<代码>//ajax.googleapis.com/ajax/libs/jquery/1.4.2/jquery.min.js
```
最初为此文件生成并存储您自己的校验和。
定期重复该过程，并确保新的校验和与旧的校验和匹配。如果没有，请鸣响喇叭。

当然，您可以通过编程来完成此操作。您决定什么间隔才有意义。每分钟？每五个？您现在已经具备了自动终止开关的条件，您可以根据自己的喜好调整其灵敏度。 “监视”例程当然不必在您希望保护的应用程序中同步运行；也许您只是出于此目的在同一服务器上运行一个小型实用程序应用程序。

测试起来很容易：只需更改存储的哈希值即可。由于您引用的是特定文件版本，因此每次次要版本更新时都不会按下紧急按钮。当您确实想要迁移到新版本的 jQuery 时，请更改站点上的 AJAX API URL 并存储新的哈希值。

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.

回复收藏 0 原文

泡沫很甜 2024-09-21 14:37:40

从 CDN 提供 jQuery 真的不如从服务器本身提供 jQuery 安全吗？

是的。如果它是外部资源，那么它总是不太安全。如果您不拥有源代码，您如何确定您知道客户真正得到什么？如果您不熟悉 CloudBleed，您可能需要在继续之前先阅读一下。

如果出于性能原因您确实需要从外部 CDN 加载 jQuery，请确保您使用子源完整性。有关 SRI 的更多信息可以在 MDN 上找到。

最后，如果由于网站性能和单点故障的创建而导致通过 CDN 安全加载 jQuery 成为一个问题（如果您完全熟悉Steve Souders），从安全和性能的角度来看，您几乎肯定会更好地在内部移动所有脚本并使用获取注入。请确保，如果您这样做，您正在积极地进行浏览器缓存。如果您为全球受众提供服务，请确保对这些资产进行边缘缓存。