交付 jQuery 的 CDN 有多安全？答案

【问题标题】：How secure are CDNs for delivering jQuery?交付 jQuery 的 CDN 有多安全？
【发布时间】：2011-03-30 04:41:02
【问题描述】：

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

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

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

google CDN 似乎支持通过 SSL 提供库。

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

【问题讨论】：

还有一个隐私问题，因为 Google 能够知道哪些用户访问了您的网站。
@Gert - 他们可能知道，您的用户访问的同时从 CDN 提取相同文件的网站越多，他们通过您的网站访问 google 的可能性就越小。
@Nick - 只要用户不刷新页面（例如，通过刷新按钮、CTRL-R 或 CTRL-F5）。
其实我觉得浏览器是不允许缓存HTTPS请求的（如果我没记错的话）。
@Dan 很容易检查，但是是的。

标签： jquery security cdn

【解决方案1】：

正如您的同事所指出的，劫持 DNS 服务器将是一个问题。如果您从与您的站点相同的主机提供库，则不会。但是，如果使用 HTTPS，攻击者不太可能在欺骗站点上拥有有效证书。我不知道浏览器对此有何反应，但我怀疑他们会将网站标记为不安全（因为其中的某些部分不可信）并采取相应措施。

简而言之；如果 CDN 也是使用 HTTPS 访问的，应该不会有什么大的风险。

编辑：还要考虑 Gert G 提到的隐私问题。

【讨论】：

您说如果库是从与站点相同的服务器提供的，那将不是问题。但是，如果他可以劫持 DNS，那么他也可以与站点的其他部分一起玩中间人。
但是如果他劫持了你的 DNS 记录，那么无论你从哪里得到你的jQuery 库，整个站点都是不可信的。该问题不再与 CDN 相关。
嗯，正是我的意思。如果他劫持了 DNS 服务器，他就可以劫持我的 DNS 记录。最后，CDN还是不CDN，安全性是一样的。

【解决方案2】：

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

在回答有关 Google 是否以任何方式更改这些文件的问题时，Google 员工 Ben Lisbakken suggested comparing MD5 checksums 将 Google 提供的文件转换为从其维护者的主页获得的同一文件的规范版本。阅读链接网站上的评论八了解上下文。

如果您担心 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 并存储新的哈希值。

【讨论】：

协议相对 URL 不适合使用，因为 IE 中的错误会下载相对引用的文件两次：stevesouders.com/blog/2010/02/10/…
啊，IE，一如既往地呼吸新鲜空气。然而，这个问题似乎只扩展到样式表。从引用的页面：“事实证明，这只发生在样式表中。我创建的缺失模式、双重下载测试页面包含一个样式表、一个图像和一个脚本，它们都具有协议相对 URL...样式表是下载了两次，但是图片和脚本只下载了一次。”
这是子资源完整性检查的一种形式。有关执行 SRI 的标准方法的更多信息available on MDN。
@JoshH 令人失望的是，自编写此滚动您自己的完整性检查答案已经七年了，并且所有现代浏览器仍然不支持作为浏览器功能的子资源完整性（以及显然不太可能很快出现）。 caniuse.com/#feat=subresource-integrity
@KenRedler 我还没有检查其他浏览器的状态，但可能有其他优先事项优先，尽管 SRI 看起来多么重要。就像 SVG 图标一样！ :)~

【解决方案3】：

如果网上存在信任，那么 Google 是最值得信赖的......

毫无疑问，Google CDN 是安全的，但问题总是来自用户/服务器的互联网连接质量。

顺便说一句，如果您在 Google API 加载器脚本中包含 jQuery 库，Google 会在其 CDN 可用的 JavaScript 库中添加一些小的统计跟踪代码（大约 +4kb，请参阅 Firebug） 20kb 缩小和压缩的 jQuery 库有点重，再加上预见 SSL 速度。

无论如何，这些天缩小/压缩/缓存 jQuery 都不是问题，我建议自己制作...

【讨论】：

Google CDN 版本的 JavaScript 库不包含跟踪代码。来自官方网站的 jQuery 版本与 Google 从 CDN 托管的文件完全相同。
如果你在 Google API 加载器脚本中包含 jQuery 库，它将...
我建议编辑此答案，以便其他用户更清楚地知道，跟踪只发生在 Google API 加载程序中，根据原始作者自己在下面的 cmets 中的注释。可以肯定地确认这正在发生吗？谷歌在使用它的加载器时真的会跟踪吗？

【解决方案4】：

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

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

如果您出于性能原因确实需要从外部 CDN 加载 jQuery，请确保您使用的是 Subsesource Integrity。更多关于 SRI can be located MDN 的信息。

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

【讨论】：