内容安全策略 (CSP) - unsafe-eval 的安全使用？答案

【问题标题】：Content Security Policy (CSP) - safe usage of unsafe-eval?内容安全策略 (CSP) - unsafe-eval 的安全使用？
【发布时间】：2016-05-11 06:59:25
【问题描述】：

我们使用以下 CSP 标头：

default-src 'self' *.ourdomain.com; script-src 'self' *.ourdomain.com 'sha256-[...]' 'unsafe-eval'; 
connect-src 'self' *.ourdomain.com; 
style-src 'unsafe-inline' * 'self' data:; font-src *; 
img-src * 'self' data:

我们的安全团队建议不要使用 unsafe-eval。

我的问题是：只要我们使用 sha256-[...] 来限制我们自己没有部署的任何脚本，仍然保留 的安全风险是什么？ CSP 标头中的 unsafe-eval？在什么情况下，这仍会使我们面临跨站点攻击？

【问题讨论】：

标签： content-security-policy

【解决方案1】：

因为 eval 实际上是不安全的。每种语言中的 eval 意味着“获取这个字符串并执行它的代码”。当然，您可能会以一种半安全的方式使用 eval，但只要您完全允许它，您就是在说“任何人都可以在我的应用程序中执行任意代码”。

我的观点认为没有理由使用 eval。向我展示一个在实际有用的代码中需要 eval 的情况，我敢打赌我可以在不使用 eval 的情况下重写代码，或者将其声明为不可能安全的代码。

禁止内联脚本只是成功的一半，尤其是如果您使用 jquery。

测验：此代码会触发内联脚本违规还是 eval 违规？

$('body').html('<script>alert(1)</script>')

你可能会感到惊讶。

剧透：

它是 eval （在撰写本文时）

【讨论】：

有一个原因：性能。几乎不可能构建一个与编译代码一样快的解释器。在代码依赖于某些运行时数据的情况下，使用eval() 可以加快代码速度。对于更具体的用例，请考虑用户提供数据 URL 的站点，以及该数据的任意表达式。该表达式需要被评估数百万次。解释性地执行它（例如，表达式“abc”被转换为数组 ['a','b','c']，并循环访问子对象的子对象的子对象）显然比 x=eval(' (a) => abc') 并调用 x(a)。
@yurik 是的，性能绝对是一个原因。我没有任何数据来支持它，但我觉得在很多情况下性能提升没有意义。人们过去常常评估 JSON 而不是解析它，但这种权衡对许多人来说并不值得。
很公平。最初的 JS 实现是解释器，但后来它们变成了将 JS 编译为原生 CPU 指令的编译器。这让他们更安全了吗？可能不是，但它显然在性能上有所提高。我们都需要快速的 JS，尽管内部浏览器基本上在 JS 代码上使用“eval”来使其成为原生代码。因此，他们进行了大量仔细检查，并使用 CPU 功能进行沙盒化，以同时获得速度和安全性。
向我展示一个需要 eval 的情况，我敢打赌我可以在不使用 eval 的情况下重写代码或将其声明为不可能安全的代码：function check() { try { eval("class= {}"); } 捕捉 (e) { 返回假； } 返回真； }
无论我在我们的脚本、jquery 和我们使用的其他 3rd 方库上击败了多少，仍然会以某种方式不断触发被 CSP 阻止的eval。如果不重写某人的 ELSES 代码（违背使用上述库的目的）......我们只是不知所措，举起手来并在我们的定义中添加 unsafe-eval。

【解决方案2】：

安全风险在于它无法保护您自己的任何可能易受攻击的代码，因为使用了eval。

如果您在自己的代码中使用eval，您应该质疑原因。有没有更安全的替代方案可以代替？

See here 提供了一个（人为的）攻击者如何注入代码的示例。当然，这是否可以对您的站点进行很大程度上取决于您的代码。

结果是几乎总是有替代使用eval。

【讨论】：

我可以打电话给你打赌吗，我们使用在模板中使用 eval() 的 KendoUI