什么时候JavaScript的eval()不是邪恶的?

我正在编写一些JavaScript代码来解析用户输入的函数(用于类似电子表格的功能)。解析完公式后，我可以将其转换为JavaScript并在其上运行eval()以产生结果。

然而，我总是避免使用eval()，因为它是邪恶的(而且，无论正确与否，我一直认为它在JavaScript中更邪恶，因为要计算的代码可能会被用户更改)。

那么，什么时候可以使用它呢?

当前回答

至于客户端脚本，我认为安全性问题是一个有争议的问题。加载到浏览器中的所有内容都受到操作的影响，因此应该这样对待。当有更简单的方法来执行JavaScript代码和/或操作DOM中的对象(例如浏览器中的URL栏)时，使用eval()语句的风险为零。

javascript:alert("hello");

如果有人想操纵他们的DOM，我说swing away。防止任何类型的攻击的安全性应该始终是服务器应用程序的责任。

从实用主义的角度来看，在可以用其他方法完成任务的情况下，使用eval()没有任何好处。但是，在某些特定的情况下应该使用eval。当这样做时，它绝对可以在没有任何破坏页面的风险的情况下完成。

<html>
    <body>
        <textarea id="output"></textarea><br/>
        <input type="text" id="input" />
        <button id="button" onclick="execute()">eval</button>

        <script type="text/javascript">
            var execute = function(){
                var inputEl = document.getElementById('input');
                var toEval = inputEl.value;
                var outputEl = document.getElementById('output');
                var output = "";

                try {
                    output = eval(toEval);
                }
                catch(err){
                    for(var key in err){
                        output += key + ": " + err[key] + "\r\n";
                    }
                }
                outputEl.value = output;
            }
        </script>
    <body>
</html>

2009-07-29 16:52:55

其他回答

底线

如果你创建或净化了你评估的代码，它永远不会是邪恶的。

略为详细

如果在服务器上使用不是由开发人员创建或未经过开发人员处理的客户端提交的输入运行Eval是邪恶的。

如果在客户端上运行Eval，即使使用客户端制作的未经处理的输入，它也不是邪恶的。

显然，您应该始终清理输入，以便对代码使用的内容有一定的控制。

推理

客户端可以运行任何他们想要的代码，即使开发人员没有编写这些代码;这不仅适用于被求值的对象，而且适用于对eval本身的调用。

2019-08-13 19:59:40

我想花点时间谈谈你的问题的前提——eval()是“邪恶的”。“邪恶”这个词，在编程语言的使用者中，通常意味着“危险”，或者更准确地说，“能够用一个看起来简单的命令造成很多伤害”。那么，什么时候可以使用危险的东西呢?当你知道危险是什么，并采取适当的预防措施时。

首先，让我们看看使用eval()的危险。就像其他事情一样，可能有许多小的隐患，但是两个大的风险——eval()被认为是邪恶的原因——是性能和代码注入。

Performance - eval() runs the interpreter/compiler. If your code is compiled, then this is a big hit, because you need to call a possibly-heavy compiler in the middle of run-time. However, JavaScript is still mostly an interpreted language, which means that calling eval() is not a big performance hit in the general case (but see my specific remarks below). Code injection - eval() potentially runs a string of code under elevated privileges. For example, a program running as administrator/root would never want to eval() user input, because that input could potentially be "rm -rf /etc/important-file" or worse. Again, JavaScript in a browser doesn't have that problem, because the program is running in the user's own account anyway. Server-side JavaScript could have that problem.

说到你的具体情况。根据我的理解，您自己生成字符串，所以假设您小心地不允许生成像“rm -rf something-important”这样的字符串，就没有代码注入风险(但请记住，在一般情况下很难确保这一点)。此外，如果你在浏览器中运行，那么我相信代码注入的风险是相当小的。

至于性能，您必须将其与编码的便捷性进行权衡。我的观点是，如果要解析公式，不妨在解析期间计算结果，而不是运行另一个解析器(eval()内的解析器)。但是使用eval()编码可能更容易，而且性能上的影响可能不太明显。在这种情况下，看起来eval()并不比任何其他可能为您节省时间的函数更邪恶。

2008-10-13 15:40:39

我倾向于遵循Crockford关于eval()的建议，并完全避免使用它。即使是看起来需要它的方法也不需要。例如，setTimeout()允许您传递一个函数而不是eval。

setTimeout(function() {
  alert('hi');
}, 1000);

即使它是一个可信的源，我也不会使用它，因为JSON返回的代码可能是乱码，最好的情况下可能会产生一些不稳定的东西，最坏的情况下可能会暴露一些不好的东西。

2008-10-13 14:36:50

由于还没有人提到它，让我补充一下eval对于Webassembly-Javascript互操作非常有用。虽然在您的页面中包含WASM代码可以直接调用的预先制作的脚本当然是理想的，但有时这是不可行的，您需要从Webassembly语言(如c#)传入动态Javascript来真正完成您需要做的事情。

在这种情况下，它也是安全的，因为您可以完全控制传入的内容。好吧，我应该说，这并不比使用c#编写SQL语句更安全，也就是说，无论何时使用用户提供的数据来生成脚本，都需要谨慎地执行(正确转义字符串等)。但在这种情况下，它在互操作场景中有一个明确的位置，远非“邪恶”。

2022-01-21 21:04:40

唯一需要使用eval()的情况是需要动态地运行JS。我说的是你从服务器异步下载的JS…

.．.10次中的9次你都可以通过重构来避免这种情况。

2008-10-13 14:35:22

什么时候JavaScript的eval()不是邪恶的?

推荐文章

最新文章

标签