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

Question

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

我们使用以下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:

Run Code Online (Sandbox Code Playgroud)

我们的安全团队的建议不是使用unsafe-eval.

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

Answer 1

ore*_*ake 20

因为eval实际上是不安全的.每种语言中的Eval表示"接受此字符串并执行代码".当然,您可能以半安全的方式使用eval,但只要您允许它,您就会说"任何人都可以在给定入口点的应用程序中执行任意代码".

我认为没有理由使用eval.给我看一个实际有用的代码中需要 eval的情况,我敢打赌,我可以在不使用eval的情况下重写代码或将其声明为不可靠的安全代码.

禁止使用内联脚本只是成功的一半,特别是如果你使用jquery.

测验:此代码是否触发内联脚本违规或eval违规？

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

Run Code Online (Sandbox Code Playgroud)

你可能会感到惊讶.

扰流板:

这是评价

有一个原因：性能。构建与编译代码一样快的解释器几乎是不可能的。在代码依赖于某些运行时数据的情况下，使用 `eval()` 可以实现更快的代码。对于更具体的用例，请考虑一个站点，其中用户提供数据的 URL，以及对该数据的任意表达式。该表达式需要评估数百万次。以解释方式执行（例如，表达式“abc”被转换为数组 ['a','b','c']，并且循环访问子对象的子对象的子对象）显然比 x=eval(' (a) => abc') 并调用 x(a)。 (8认同)
@yurik 是的，性能绝对是一个原因。我没有任何数据来支持它，但我觉得在很多情况下性能提升没有意义。人们过去常常评估 JSON 而不是解析它，但对许多人来说，这种权衡并不值得。 (2认同)
给我看一个需要 eval 的情况，我敢打赌我可以在不使用 eval 的情况下重写代码或将其声明为不可能安全的代码： function check() { try { eval("class = {}"); } catch (e) { return false; 返回真；} (2认同)

Answer 2

Sil*_*Fox 5

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

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

有关攻击者如何注入代码的（人为的）示例，请参见此处。当然，这是否可以对您的站点进行很大程度上取决于您的代码。

结果是几乎总有一种替代方法可以使用eval.

我可以打给你吗，我们使用 KendoUI，它在模板中使用了 eval() (2认同)

归档时间：	9 年，7 月前
查看次数：	17923 次
最近记录：	6 年，10 月前