在我的站点中实现了 CSP，但第 3 方库使用内联 javascript。我可以选择性地允许“不安全内联”吗？

Question

出于安全目的，我在我的公共站点中实现了 CSP 标头，并重构了代码以删除任何内联 javascript 实例，如 onclick=foo()和<a href='javascript: bar()'。

我们最近与将代码注入页面的第 3 方集成。每个面向公众的页面都需要这样做。问题是他们的代码包含大量内联 javascript（与上面提到的相同）并且违反了我们禁止内联脚本的 CSP 标头。

我的理解是，如果您必须'unsafe-inline'为脚本添加内容，那么由于存在剩余的安全风险，您还不如根本不实施 CSP。

我们能够更改每页的 CSP 标头，但由于每个页面都需要代码，因此似乎要么全部要么全无。

看起来您不能'unsafe-inline'只允许页面的特定部分，或者我们可以只允许该部分。

是我允许'unsafe-inline'和打败 CSP 的唯一选择吗？

Answer 1

\n
我唯一的选择就是允许\'unsafe-inline\'并挫败 CSP 的全部意义吗？
\n

\n\n

最有可能的是，是的。对不起。但可能有办法解决这个问题。

\n\n

如果您确切知道第三方脚本将向您的站点注入哪些代码，您可以通过其哈希值在 CSP 中将该代码列入白名单。例如，如果您知道将注入以下脚本：

\n\n

<script>alert("hello world");</script>\n

你可以计算

\n\n

> Base64(SHA256(\'alert("hello world");\'))\n"1tD3lYbOBFeMLrXs+T9Tv9xEgcMsVs032rlMyrYSa0c="\n

并将以下内容添加到您的 CSP：

\n\n

script-src \'sha256-1tD3lYbOBFeMLrXs+T9Tv9xEgcMsVs032rlMyrYSa0c=\'\n

当然，如果涉及多个内联脚本，这将极大地增加您的策略的大小，并且除非这些脚本的内容绝对恒定，否则它根本不起作用。因此，这是否可行将在很大程度上取决于您的应用程序以及您试图保持兼容性的脚本。（它甚至可能会随着供应商\xe2\x80\xa6 更新该脚本而改变）

\n

还应该注意的是，并非所有浏览器都支持哈希方法，因此您通常必须包含 unsafe-inline 和 sha256 哈希。这听起来可能毫无意义，但那些支持内联脚本哈希的浏览器通常会明确忽略策略的不安全内联部分（如果包含哈希）。而那些不这样做的浏览器可以继续使用不安全内联。虽然 Firefox 确实有一个错误，它们无法正确计算哈希值，但忽略了不安全内联部分:-( 现在已修复，但在使用 CSP 哈希等新功能时，您可能会看到这样的奇怪现象。 (2认同)