为什么 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
指令,如 this mdn 文档,我期待为 script-src
也用于 script-src-elem
指令.但是,我看到违规被报告为 "viloated-directive":"script-src-elem"blocked-uri":https://www.gstatic.com/blah/blah"
.
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:
- 内容安全政策执行预请求检查 用于包含在页面上的 JavaScript(例如 gstatic.com 或 google-analytics.com).请求前检查通过,因为策略中允许使用主机名.
- 浏览器发起资源请求
- PrivacyBadger 通过浏览器的 onBeforeRequest API 拦截请求(参见 PrivacyBadger 源 和 Chrome 文档)
- ProvacyBadger 返回一个为资产.它这样做是为了确保依赖于真实 javascript(例如
window.ga
)的代码不会中断. - 浏览器然后执行请求后检查针对返回的 base64 blob
- 请求后检查失败 - 因为策略不允许
data:
用于script-src
- 浏览器发送被阻止资产的 CSP 报告.
- 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.
- The browser initiates a request for the resource
- PrivacyBadger intercepts the request via the browser's onBeforeRequest API (see PrivacyBadger source and Chrome documentation)
- 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. - The browser then performs a post-request check against the returned base64 blob
- The post-request check fails - because the policy does not allow
data:
forscript-src
- The browser sends a CSP report for the blocked asset.
这似乎是浏览器的错误 - 因为报告反映了原始资产的第三方主机名;而被阻止的内容实际上是通过拦截请求返回的 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屋!