【问题标题】:Subresource integrity for images and other media?图像和其他媒体的子资源完整性?
【发布时间】:2016-05-03 18:10:53
【问题描述】:

Subresource integrity 似乎是一个很棒的权宜之计,允许以安全的方式使用第三方控制的 HTTP 提供的资源。

但是 the spec 只考虑 HTMLLinkElementHTMLScriptElement 接口:

注意

本规范的未来修订版可能包括对所有可能的子资源的完整性支持,即aaudioembediframeimglinkobjectscriptsourcetrackvideo 元素。

我知道scriptlink 元素引用的内容更“活跃”,但浏览器删除了绿色挂锁,以便通过纯 HTTP 获取甚至相对无害的图像,而规范选择忽略它们?对我来说,这似乎是一个严重缺乏远见的问题。

这背后的原因是什么?如果有的话,我们什么时候可以期待“未来的修订”?

【问题讨论】:

  • 这个问题可以通过使用 javascript 函数来解决,该函数从提供受信任校验和的同一服务器提供,以验证来自不受信任服务器的下载的完整性。请参阅meixler-tech.com/aivwd 了解更多信息。

标签: html image https w3c subresource-integrity


【解决方案1】:

SRI 为您提供了一些保证,即您请求的资源未被更改。例如,如果您从 CDN 加载 JQuery,那么您希望确保没有人修改它以包含恶意代码(从另一个站点加载代码的主要缺点之一 - 您隐含地信任该站点的安全性)。 SRI 为您提供这样的保证。

SRI 对它的加载方式无话可说。您可以通过 http 轻松下载 JQuery 并获得不安全的内容警报,尽管它已通过 SRI 验证。

不安全的内容不好有很多原因,包括:

  1. 不保证内容没有在网络上被更改(SRI 解决了一些问题)。
  2. cookie 泄漏(除非受 Secure 属性保护)。
  3. 隐私泄露(窥探者知道您已请求该资源)。

SRI 仅解决第一个问题。即使这样,它也只会在它被更改时停止加载,并且不会减少它被更改的机会(就像 https 一样)。

如果您想解决不安全的内容问题,那么您可以查看内容安全策略,或者明确阻止这些问题,或者使用 upgrade-insecure-requests 指令自动升级它们(对于支持此功能的浏览器)。

【讨论】:

  • 我知道 SRI 的缺点。当资源不受您的直接控制时,无能为力。问题是为什么规范中的差异化处理(元素方面)以及是否有任何朝着扩展/改进它的方向发展。
  • 在规范作者处可能会得到更好的解决。正如您所说,首先解决了更关键的问题,他们自己在规范中说他们已经考虑过这一点,未来的修订可能会包括这一点。所以不确定你还在寻找什么。我的回答更多是为了解决您对绿色挂锁的评论 - SRI 不会尝试解决这个问题。
  • 我正在寻找的是对我最后一个问题的实际答案。大概来自“规范作者”或“了解”规范构思时与此相关的任何讨论的其他人
  • 嗯,规范上有很多联系方式,所以建议最好在这个地方问这个问题。除非从事此工作的人碰巧在这里看到了您的问题,否则我们其他人所能做的最好的事情就是猜测。我建议在链接到那里的 GitHub 页面中提出一个问题,以便在那里提出这个问题。找到答案后,最好在此处添加答案。
猜你喜欢
  • 2017-10-18
  • 2016-07-05
  • 1970-01-01
  • 2016-11-02
  • 1970-01-01
  • 2017-12-22
  • 1970-01-01
  • 2023-02-14
  • 2016-02-22
相关资源
最近更新 更多