标签: subresource-integrity

我正在实施子资源完整性检查。我想实现一个回退，以便 1) 浏览器从我的 CDN 加载，执行完整性检查并继续执行或 2) 在完整性检查失败的情况下，嵌入式脚本启动并从我的应用程序中检索所需的脚本服务器（我控制的资源）。

我有一个简单的 javascript 可以捕获 window.onerror 事件，但该脚本实际上正在检测未捕获的 ReferenceError（我的页面引用了外部资源中的脚本），而不是浏览器错误“无法找到有效的摘要...”。

有没有人找到检测完整性检查失败的方法，然后使用javascript从更受信任的位置拉取第三方托管资源？

我想知道是否有人知道使用 Angular-Cli 激活子资源完整性的可能方法。根据以下链接：GitHub Pull Request这将是一个功能（或未来的功能）。我希望激活它，但它似乎在当前版本上没有激活。是否有另一种方法可以在 Angular-Cli 中使用子资源完整性？

背景

我有一个使用谷歌分析的网站，比如

<script 
   src="https://www.google-analytics.com/analytics.js"/>

并使用 Mozilla Observatory 来测试它是否存在安全漏洞。

问题

我从 Mozilla 天文台收到以下问题：

未实现子资源完整性 (SRI)，但所有外部脚本均通过 HTTPS 加载

思念至今

似乎无法为其创建哈希，例如通过https://www.srihash.org/。我不想在本地创建哈希，因为如果发生analytics.js更改，它会破坏网站。

我可以使用 anonce但我不确定如何在每个请求中生成它。

我正在考虑下载analytics.js并在本地使用它。这样做有什么缺点吗？

提前致谢

我正在阅读子资源完整性，但我担心性能损失。这（必须在执行之前对每个文件进行哈希处理）如何减慢页面加载速度，尤其是在具有低级 CPU 的设备上？

客户想在其网站上的所有 CSS 和 JS 资产上使用 SRI，但他们在 Firefox 中遇到了一个非常奇怪的问题。他们的服务器是一个 apache2 实例，提供 HTML 内容。为整个虚拟主机启用 CORS，适用于任何 ( *) 源。没有缓存或 CDN。

有问题的两个文件是

• company.min.css 和
• company.min.js

为了生成 SRI 哈希，最初使用了SRI 哈希生成器。其输出有多种算法，如下所示：

<script src="https://example.com/static/company.min.js" integrity="sha256-aKuSpMxn15zqbFa0u0FVA7mAFOSVwIwU4gA3U7AZf5Y= sha384-WDAg+qGBjbEyE52SdQ5UHdTObTY+jYTL63m9Oy2IJcGZR8AFn0t9JNN7qdut6DBk sha512-bxmUFj1FVOVV74+zIYau/HSUcLq9cuneBKoMJyW9dAz//yKFi8eRhyyIezF++2vbGO7cR6Pzm1l9rvnPcrvIrg==" crossorigin="anonymous"></script>

CSS 文件类似。这些被插入到 HTML 中，并在几个不同的浏览器中对站点进行了测试，结果如下：

• 适用于 Chrome (/Canary)、Opera、Edge 甚至 IE
• 不会在Firefox（/日）的工作。

Firefox 只讨厌 CSS，说 SHA512 与资源不匹配。无论出于何种原因，它都能很好地处理 JS 文件。

我确认（使用 OpenSSL）上述工具生成的散列确实是正确的，而且它在除 Firefox 之外的几乎所有浏览器中都有效这一事实让我想到了。

因此，我尝试使用 Mozilla 自己的 SRI 工具srihash.org对资源进行哈希处理，这是 Mozilla 从他们关于 SRI的博客文章中推荐的。

现在它变得有点奇怪。

• 对于 CSS 文件，srihash.org 生成一个完全不同的哈希。
• 对于 JS …

如何将SRI用于.cssCDN中包含的文件所包含的资源.

例如,如果您在HTML中包含此内容:

<link href="https://maxcdn.bootstrapcdn.com/font-awesome/4.7.0/css/font-awesome.min.css" rel="stylesheet" integrity="sha384-wvfXpqpZZVQGK6TAh5PVlGOfQNHSoD2xbE+QkPxCAFlNEevoEH3Sl0sibVcOQVnN" crossorigin="anonymous">

这将加载通过CSS包含的字体,例如url('../fonts/fontawesome-webfont.woff2?v=4.7.0') 当然,这些字体可能被篡改,以利用一些不为人知的浏览器漏洞利用,因此强制执行散列检查也是有意义的.

如何告诉浏览器执行fontawesome-webfont.*通过.css？加载的文件的SRI-hash ？

注意:看起来不支持子子资源哈希,但我不确定这是否是最新的.

有谁遇到过Google Chrome和SRI Hash这个问题，它在控制台窗口中不断抛出相同的错误：

无法找到在“诚信”属性的有效消化资源“ https://fonts.googleapis.com/css?family=Indie+Flower ”与计算SHA-256诚信“yxJPuU / cJi0 / 8FoS + agssT / MtC4P3SGuU + JOzbTejqQ ='。资源已被阻止。

我正在从https://report-uri.io/home/sri_hash生成代码，并且还尝试过https://www.srihash.org/

根据这个网站https://glebbahmutov.com/blog/subresource-integrity/，作者有同样的问题，因此添加了多个散列<link rel="stylesheet" href="https://fonts.googleapis.com/css?family=Indie+Flower" integrity="sha256-CoGIUDlbZltnYk6u/wQKXOszdOOWImA1XzSERnNzHlc= sha384-vk+perBz0d5g0G+x7+4BxElvHeiaLNX7jegOI63Bg53TxNYaUzLGEsSQ4AmIwVr4 sha512-h+9Z3+9s3jtPJjXU9phAXFQwYYFSYhXlnkPwkuubLFf5kfeXWIRC32YkRdB08xmut/dJG/RjPoiR/r4DAtm3PQ==" crossorigin="anonymous">

我已阅读以下有关package-lock.json文件的内容：

\n

该文件旨在提交到源存储库中，并用于多种目的：

\n\n

\n
• 描述依赖关系树的单一表示，以便保证团队成员、部署和持续集成安装完全相同的依赖关系。
\n
• 为用户提供一种工具，可以将 \xe2\x80\x9ctime-travel\xe2\x80\x9d 恢复到 node_modules 的先前状态，而无需提交目录本身。
\n
• 通过可读的源代码控制差异来提高树更改的可见性。
\n
• 并通过允许 npm 跳过先前安装的软件包的重复元数据解析来优化安装过程。
\n

\n

请参阅NPMJS 文档 package-lock.json 描述。

但在同一链接的另一个片段中我看到：

\n

完整性\xc2\xa7

\n\n

这是该资源的标准子资源完整性。

\n\n

\n
• 对于捆绑的依赖项，无论来源如何，都不包括在内。
\n
• 对于注册表源，这是注册表提供的完整性，或者如果\xe2\x80\x99t 在 shasum 中提供了 SHA1。
\n
• 对于 git 源，这是我们克隆的特定提交哈希。
\n
• 对于远程 tarball 源，这是基于文件 SHA512 的完整性。
\n
• 对于本地 tarball 源：这是基于文件 SHA512 的完整性字段。
\n

\n

请参阅NPMJS 文档 package-lock.json 依赖项完整性。

通过标准子资源完整性 (SRI) 的链接，我发现了以下内容：

\n

1.1. 目标

\n\n …

我们使用puppeteer，有时还使用playwright来运行一些集成测试。我们模拟了一些目标页面的脚本依赖项，这会导致子资源完整性哈希不匹配。

无法使用计算的 SHA 在资源“http://localhost:3000/static/third-party/adobe-target/at-js/2.4.0-cname/at.js”的“integrity”属性中找到有效摘要-256 完整性'47DEQpj8HBSa+/TImW+5JCeuQeRkm5NMpJWZG3hSuFU='。资源已被封锁。”

有没有办法通过标志或配置属性禁用完整性哈希检查？

我最近发现了以下漂亮的小站点，用于为外部加载的资源生成SubResource Integrity（SRI）标签。例如，输入最新的jQuery URL（https://code.jquery.com/jquery-3.3.1.min.js），将获得以下<script>标记：

<script src="https://code.jquery.com/jquery-3.3.1.min.js" integrity="sha256-FgpCb/KJQlLNfOu91ta32o/NMZxltwRo8QtmkMRdAu8= sha384-tsQFqpEReu7ZLhBV2VZlAu7zcOV+rXbYlF2cqB8txI/8aZajjp4Bqd+V6D5IgvKT sha512-+NqPlbbtM1QqiK8ZAo4Yrj2c4lNQoGv8P79DPtKzj++l5jnN39rHA/xsqn8zE9l0uSoxaCdrOgFs6yjyfbBxSg==" crossorigin="anonymous"></script>

我了解SRI哈希的目的，并且我知道它们可以使用不同的哈希大小（256位，384位或512位），但是我以前从未见过像这样一次使用这三种哈希。深入研究MDN文档，我发现

完整性值可能包含多个由空格分隔的哈希。如果资源与那些哈希值之一匹配，将被加载。

但是，该匹配如何执行？在一个SO帖子中回答多个问题的时间...

1. 浏览器会尝试首先匹配最长的哈希（因为它比较安全），还是首先匹配最短的哈希（因为它更快）？
2. 真的有人会期望一个哈希能够匹配而不是三个都匹配吗（除了开发人员误将哈希哈希的琐事之外）？
3. 提供所有三个哈希值而不是仅提供一个哈希值有什么好处吗？
4. 与＃1类似，如果仅提供一个哈希值，应使用哪个值？我通常会看到站点（例如Bootstrap）在其示例代码中提供sha384值。是因为它在中间，不是太大，不是太小？
5. 出于好奇，可以integrity在<script>和旁边的任何标签上使用该属性<link>。我特别想知道像多媒体标签<img>，<source>等等。