内容安全政策（CSP）-安全使用不安全评估吗？ [英] Content Security Policy (CSP) - safe usage of unsafe-eval?

问题描述

我们使用以下CSP标头：

We use the following CSP header:

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:

我们的安全团队的建议不是使用不安全评估。

The recommendation by our security team is not use unsafe-eval.

我的问题是：只要我们使用 sha256-[...] 来限制我们使用的任何脚本，还没有部署自己，仍然将 unsafe-eval 保留在CSP标头中的安全风险是什么？

My question is: as long as we are using sha256-[...] to restrict any script that we haven't deployed ourselves, what is the security risk of still keeping unsafe-eval in the CSP header? In what situation would this still expose us to cross-site attacks?

推荐答案

因为在什么情况下eval实际上是不安全的，因此在什么情况下这仍会使我们遭受跨站点攻击？每种语言中的Eval表示采用此字符串并执行它的代码。当然，您可能以半安全的方式使用eval，但是只要您完全允许，您就说允许任何人在给定入口点的情况下在我的应用程序中执行任意代码。

Because eval is literally unsafe. Eval in every language means "take this string and execute it code." Sure, you may be using eval in a semi-safe way, but as long as you allow it at all, you are saying "anyone is allowed to execute arbitrary code in my application given an entry point".

我的观点是没有理由使用eval。告诉我一种情况，在实际有用的代码中必需，我敢打赌我可以不用eval来重写代码，也可以将其声明为不可能的安全代码。

It is my opinion that there is no reason to use eval. Show me a case where eval is required in actual useful code and I'll bet that I can rewrite the code without using eval or declare it as impossibly secure code.

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

Disallowing Inline script is only half the battle, especially if you use jquery.

测验：该代码是否触发内联脚本冲突或评估冲突？

Quiz: does this code trigger an inline script violation or an eval violation?

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

您可能会感到惊讶。

剧透：

等于

it's eval

这篇关于内容安全政策（CSP）-安全使用不安全评估吗？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！