为什么 script-src-elem 不使用 script-src 中的值作为后备？答案

【问题标题】：Why is script-src-elem not using values from script-src as a fallback?为什么 script-src-elem 不使用 script-src 中的值作为后备？
【发布时间】：2021-01-27 00:52:25
【问题描述】：

在实施 csp-header 时，我已将我的策略指定为： default-src 'self'; script-src www.gstatic.com; 由于我没有在我的 csp 策略中声明 script-src-elem 指令，如 this mdn 文档中所述，我期望为 script-src 定义的策略也可用于 script-src-elem 指令。但是，我看到违规行为被报告为"viloated-directive":"script-src-elem" "blocked-uri":"https://www.gstatic.com/blah/blah"。

知道为什么会发生这种行为吗？

【问题讨论】：

您知道您在哪些特定浏览器（和版本）上看到过这种情况吗？我一直在试图追查这个完全相同的问题，我想知道是否可能是浏览器缺陷导致了它。就我而言，我的script-src 白名单中有https://www.google-analytics.com，我看到script-src-elem 报告针对该uri 进入。我没有script-src-elem 指令，所以它应该退回到允许该uri 的script-src。据我所知，它根本不应该被阻止或报告。
@MattMetzger - 我们的日志没有包含在违规报告中的浏览器信息。我还没有时间探索 doublesharp 在下面的答案中给出的理论，即这些违规行为可能会发生，因为脚本是基于 js 事件注入的，但这对我来说听起来很有趣。
@anish：你是如何解决这个问题的？我们在应用程序中面临同样的问题。即使我们提到了 connect-src self 和 script-src self，我们仍然会看到来自同一 orign/host 的一些 CSP 违规报告。如果您让我们知道您是如何解决这个问题的，将会非常有帮助。
@YathishManjunath - 我们从未解决它。这是我们收到的违规报告的一小部分，所以我们正在处理这个问题，我们仍然在阻止它们。它只是不经常发生，而且我们的客户都没有抱怨过任何事情，所以......你有没有看过 doublesharp 不得不说什么？ javascript 事件可能会注入一些关于脚本的内容
我在Mozilla/5.0 (Windows NT 6.1; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/88.0.4324.104 Safari/537.36 上看到了同样的问题，我认为这是 Windows 7 上的 Chrome 88.0。

标签： web browser content-security-policy

【解决方案1】：

在我的一些应用程序中看到了完全相同的模式后，我终于找到了问题的根源！

我们看到的奇怪之处在于 CSP 报告中的主机名肯定在 script-src 指令中；我们知道script-src-elem 应该回退到这些指令。从这个角度来看，这些报告应该是不可能发生的。

以下是我们发现的情况：这些报告来自的用户正在使用 PrivacyBadger 浏览器扩展程序，这导致它阻止的主机 (Google) 出现误报 CSP 报告。我没有深入研究它，但这是我关于如何发生的理论：

内容安全策略对页面上包含的 JavaScript 执行 pre-request check（例如 gstatic.com 或 google-analytics.com）。请求前检查通过，因为策略中允许使用主机名。
浏览器发起资源请求
PrivacyBadger 通过浏览器的 onBeforeRequest API 拦截请求（参见PrivacyBadger source 和Chrome documentation）
ProvacyBadger 为资产返回 surrogate data blob。这样做是为了确保依赖于真正 javascript（例如window.ga）的代码不会中断。
然后浏览器对返回的 base64 blob 执行post-request check
请求后检查失败 - 因为策略不允许 data: 用于 script-src
浏览器为被阻止的资产发送 CSP 报告。

这似乎是一个浏览器错误 - 因为 report 反映了原始资产的第三方主机名；而被拦截的内容实际上是通过拦截请求返回的data: blob。

【讨论】：

我想你可能在这里有所收获。我看到 track.adform.net 的行为相同，尽管我的 CSP 允许 *.adform.net 和 data:。我只看到来自 Windows 上某些 Chrome 实例的报告。没有其他浏览器，也没有其他操作系统。
相关错误报告：bugs.chromium.org/p/chromium/issues/detail?id=880816
@Span ：我们在我们的应用程序中面临同样的问题。即使我们提到了 connect-src 'self' 和 script-src 'self'，我们仍然会看到来自同一 orign/host 的 connect-src 和 script-src-elem 的一些 CSP 违规报告。我们现在被阻止以强制模式推出。我检查了您在评论中提到的链接。我在错误报告中没有看到与此问题相关的任何内容。
我觉得有趣的是，PrivacyBadger 会导致额外的跟踪信息以 CSP 违规报告的形式发送。
是否有人能够重现 PrivacyBadger 的问题？我试图追查同样的问题，并尝试了几个广告拦截和隐私扩展，但它们似乎都在不触发 CSP 违规的情况下阻止了这些资源。

【解决方案2】：

来自您链接到的文档：https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Content-Security-Policy/script-src-elem

HTTP Content-Security-Policy (CSP) script-src-elem 指令指定 JavaScript 元素的有效来源，但不指定 onclick 等内联脚本事件处理程序。

在没有看到其余代码的情况下，可以安全地假设您看到此错误是内联事件处理程序的结果，并且需要在您的 CSP 策略中定义 script-src-elem。

【讨论】：

这是有道理的。谢谢双锋。让我来验证一下。
那行不通。虽然 script-src-elem 不适用于内联脚本，但 script-src 指令适用。由于我在我的 csp 策略中声明了 script-src 指令，因此获取 script-src-elem 的允许来源的违规报告仍然没有意义......
您是说添加script-src-elem 会导致同样的错误吗？你能包括触发它的代码吗？ Google 脚本经常更新 dom，因此错误的来源可能并不明显。
不，我不是那个意思。我的 csp-policy 中根本没有定义 script-src-elem 指令。我只有 script-src 指令，其中包含允许的来源列表。根据 mdn 文档，如果我允许 script-src 中的源并且没有定义 script-src-elem，则 script-src-elem 应该允许 script-src 允许的源。我没有看到这种行为。我无法发布实际代码，但我已经发布了我在问题中看到的 csp 政策和违规报告的缩影版本。
@anish 我认为文档是这样说的，除非脚本是由 javascript 事件添加的，我认为这就是您的情况。错误中的完整 URL 是什么？

【解决方案3】：

script-src-elem 在 Chromium 引擎上的浏览器中肯定会回退到 script-src。检查 Chrome 控制台，警告将如下所示： ...请注意，'script-src-elem' 没有明确设置，因此 'script-src' 用作备用。

Gecko-browsers 不支持script-src-elem，直接使用script-src。

违规报告中的 CSP2 浏览器会发送一个违规指令，导致毕竟后备链。但是 CSP3 浏览器会发送一个“理论上”违反的指令，如果指令被省略，than 会执行回退。这会带来一些混乱。

script-src-elem 与 onClick() 之类的内联事件处理程序无关 - 这在 MDN 文档中有所说明。 script-src-elem 仅控制 <script>...</script> 和 <script src='...'> elements（和 javascript-navigation）。 "blocked-uri":"https://www.gstatic.com/blah/blah" 表示 https://www.gstatic.com 主机源被阻止，而不是内联事件处理程序。

内联事件处理程序确实锁定了script-src-attr 指令，并且报告看起来像"blocked-uri":"inline"。

看起来您编辑了一个副本 CSP，但服务器默认发出另一个。请查看报告 JSON 中提交的“原始政策”。它包含你真正的 CSP 还是一些默认的？

PS：要详细分析发生了什么，需要查看完整的违规报告和完整的 CSP（浏览器控制台消息的打印屏幕将非常有帮助）。因为script-src www.gstatic.com; 完全足以让 CSP3 浏览器允许来自“https://www.gstatic.com”的任何资源。（CSP2 浏览器需要更多规则，但您显示了 CSP3 浏览器发送的违规报告）。

【讨论】：

您能否指出 CSP2 和 CSP3 文档，以了解您提到的“违反报告的 CSP2 浏览器在所有后备链之后发送了一个违反指令。但是 CSP3 浏览器发送一个“理论上”违反指令，然后执行回退”。
violated-directive in CSP2 如果后备。在 CSP3 中，信息分散在整个规范中，但 violated-directive = effective-directive in CSP3。您可以在 Firefox 和 Chrome 中查看live demo。 FF 确实发送了一个真正违反的指令，但如果该指令将在策略中显示，Chrome 会在应该发生违规的地方发送有效指令。