为什么script-src-elem不使用script-src中的值作为后备? [英] Why is script-src-elem not using values from script-src as a fallback?

问题描述

在实现csp-header时，我将策略指定为: default-src'self';script-src www.gstatic.com; 由于未在我的csp策略中声明 script-src-elem 指令，如.

When implementing csp-header, I have specified my policy as: default-src 'self'; script-src www.gstatic.com; Since I have not declared script-src-elem directive in my csp policy, as stated in this mdn documentation, I was expecting policy defined for script-src to be used for script-src-elem directive as well. However, I see violation being reported as "viloated-directive":"script-src-elem" "blocked-uri":"https://www.gstatic.com/blah/blah".

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

Any idea why this behavior is happening?

推荐答案

在我的一些应用程序中看到了完全相同的模式之后，我终于明白了这一点！

After seeing this exact same pattern in some of my applications, I finally got to the root of this!

我们看到的奇怪之处在于，CSP报告的主机名是 script-src 指令中的绝对.而且我们知道 script-src-elem 应该属于这些指令.从这个角度来看，这些报告实际上是不可能发生的.

The weirdness we were seeing was that CSP reports were coming in for a hostname which was definitely in the script-src directive; and we know that script-src-elem is supposed to fall back to those directives. From that perspective, it should have been literally impossible for these reports to happen.

我们找到的是:这些报告来自的用户正在使用 PrivacyBadger 浏览器扩展，这导致了对于它阻止的主机(Google)，CSP报告为误报.我并没有深入研究它，但是这是我的理论:

Here's what we found: the users these reports were coming from were using the PrivacyBadger browser extension, which was leading to false positive CSP reports for the hosts (Google) that it blocked. I didn't dig too far into it, but here's my theory on how that happens:

1. 内容安全政策执行请求前检查 JavaScript包含在页面上(例如gstatic.com或google-analytics.com).请求前检查通过，因为策略中允许使用主机名.
2. 浏览器启动对资源的请求
3. PrivacyBadger通过浏览器的onBeforeRequest API拦截请求(请参见 PrivacyBadger来源和 Chrome文档)
4. ProvacyBadger返回代理数据块资产.这样做是为了确保依赖真实javascript的代码(例如 window.ga )不会中断.
5. 然后浏览器执行请求后检查针对返回的base64 blob
6. 请求后检查失败-因为该策略不允许 script-src
使用 data:
7. 浏览器发送有关被冻结资产的CSP报告.

1. The Content Security Policy performs a pre-request check for the JavaScript include on the page (eg. gstatic.com or google-analytics.com). The pre-request check passes, because the hostname is allowed in the policy.
2. The browser initiates a request for the resource
3. PrivacyBadger intercepts the request via the browser's onBeforeRequest API (see PrivacyBadger source and Chrome documentation)
4. ProvacyBadger returns a surrogate data blob for the asset. It does this to ensure that code which relies on the real javascript (eg. window.ga) won't break.
5. The browser then performs a post-request check against the returned base64 blob
6. The post-request check fails - because the policy does not allow data: for script-src
7. The browser sends a CSP report for the blocked asset.

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

This seems like it might be a browser bug - because the report reflects the original asset's third party hostname; while the blocked content is actually a data: blob that was returned via the intercepted request.

这篇关于为什么script-src-elem不使用script-src中的值作为后备?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！