Safari 11.0.3无法识别内容安全策略哈希 [英] Content Security Policy hash not recognized by Safari 11.0.3
问题描述
我有一个带有以下指令的元标记：
< meta http-equiv = Content- Security-Policy content = base-uri'self'; script-src'self''sha256-s5EeESrvuQPpk2bpz5I3zn / R8Au2DYB1Z + YUH9p0fUE =''sha256-PYYfGnkbZ44B9ZBpgv8NbP3MXT560LMfrDSas2'
然后我在页面的下方有2个内联脚本，每个脚本都应与其中生成的阴影匹配
在Chrome和Firefox中，我没有抱怨，脚本也按预期运行。
在Safari版本11.0.3（13604.5.6），出现以下错误：
拒绝执行脚本，因为脚本的哈希值，其随机数或 unsafe-inline不会出现在内容安全策略
而且我对为什么感到困惑！
不幸的是，我无法生成其中包含问题的最小可复制回购协议-较小的示例对我来说是有效的，因此它使我相信这与我的应用程序中的特定功能有关，可能与我在下面尝试过的第二件事有关。
任何帮助将不胜感激！
我尝试过的事情：
是否支持哈希？
根据
在Safari渲染角色之后，以下内容（甚至在代码的源中）：
奇怪的是，Chrome和Firefox都没有此问题，因此它必须是Safari在呈现字符后将其标准化，或者在浏览器之间计算 sha256 哈希值时的差异。
解决方案是关闭UglifyJS中的字符压缩，以使字符保持为 \uF900 而不是压缩为单个字符在上面的图片中。
我在webpack.config.js文件中使用以下选项实现了此目的：
new UglifyJsPlugin（{
uglifyOptions：{
output：{
//必须停止将逸出的unicode序列最小化为它们的实际字符。
//某些Unicode破坏了野生动物园中的CSP检查
ascii_only：true，
}，
}，
}），
我已向苹果公司报告了此事，以查看他们是否会考虑解决此问题。
I have a meta tag with the following directive inside of it:
<meta http-equiv="Content-Security-Policy" content="base-uri 'self'; script-src 'self' 'sha256-s5EeESrvuQPpk2bpz5I3zn/R8Au2DYB1Z+YUH9p0fUE=' 'sha256-PYYfGnkbZ44B9ZBpgv8NbP3MXT560LMfrDSas2BveJo=';">
I then have 2 inline scripts further down the page, each which should match one of the generated shas in the policy.
In Chrome and Firefox, I get no complaints and my scripts run as expected.
In Safari Version 11.0.3 (13604.5.6), I get the following error:
Refused to execute a script because its hash, its nonce, or 'unsafe-inline' does not appear in the script-src directive of the Content Security Policy
and I am confused as to why!
Unfortunately, I am unable to produce a minimum reproducible repo with the issue inside of it - smaller examples work in Safari for me, so it leads me to believe it's to do with something specific in my app, possibly related to the second thing I have tried below.
Any help would be much appreciated!
Things I have tried:
Are hashes supported?
According to this Stack Overflow post and the Safari release notes, CSP 2.0 which supports hashes was implemented in Safari 10
Correct charset?
Previously, I was seeing issues because I was calculating the hashes based on a UTF-8 charset, but was outputting the JS to the browser without a charset meta tag in place. Special characters in my JS were being mangled and were causing differences in the shas when the browser tried calculating them.
I don't believe this is affecting me now since Chrome and Firefox see no issues, but maybe I'm wrong here?
unsafe-inline for Safari, and then allow hashes to override that in Chrome and Firefox?
According to the CSP spec, unsafe-inline is ignored if a hash or nonce is present. Safari 11 also adheres to this, so adding the unsafe-inline keyword has no effect
Turns out this was a charset issue.
I managed to get a minimal reproducible issue (after some trial and error, and a lot of luck!) and found that one of my characters had a different sha before and after it was rendered in Safari.
Before it was rendered in Safari, the character was the following:
After Safari had rendered the character, it was the following (even in the source of the code):
Strangely, Chrome and Firefox both don't have this issue, so it either must be Safari normalizing the character after it has rendered, or a difference in when the sha256 hashes are calculated between the browsers.
The solution was to turn off character compression in UglifyJS so that the character stays as \uF900 instead of being compressed to the single character in the picture above.
I achieved this with the following option in my webpack.config.js file:
new UglifyJsPlugin({
uglifyOptions: {
output: {
// necessary to stop the minification of escaped unicode sequences into their actual chars.
// some unicode breaks CSP checks in safari
ascii_only: true,
},
},
}),
I have reported this to Apple to see if they will consider fixing this.
这篇关于Safari 11.0.3无法识别内容安全策略哈希的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
