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

Question

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

然而，如果可以避免的话，我总是回避使用 eval() 因为它是邪恶的（而且，无论正确与否，我一直认为它在 JavaScript 中更加邪恶，因为要评估的代码可能会被用户更改）。

那么，什么时候可以使用呢？

Answer 1

我想花点时间来解决您问题的前提 - eval() 是“邪恶”。 编程语言人员使用的“邪恶”一词通常意味着“危险”，或更准确地说“能够通过看似简单的命令造成很多伤害”。 那么，什么时候可以使用危险的东西呢？ 当您知道危险是什么并且采取适当的预防措施时。

言归正传，我们来看看使用eval()的危险性。 就像其他事情一样，可能存在许多小隐患，但两大风险 - eval() 被认为是邪恶的原因 - 是性能和代码注入。

• 性能 - eval() 运行解释器/编译器。 如果您的代码已编译，那么这将是一个很大的打击，因为您需要在运行时中间调用可能很重的编译器。 然而，JavaScript 仍然主要是一种解释性语言，这意味着在一般情况下调用 eval() 不会对性能造成太大影响（但请参阅下面我的具体评论）。
• 代码注入 - eval() 可能会在提升的权限下运行一串代码。 例如，以管理员/root 身份运行的程序永远不会想要 eval() 用户输入，因为该输入可能是“rm -rf /etc/important-file”或更糟。 同样，浏览器中的 JavaScript 不存在这个问题，因为该程序无论如何都在用户自己的帐户中运行。 服务器端 JavaScript 可能存在这个问题。

根据您的具体情况。 据我了解，您自己生成字符串，因此假设您小心不要生成像“rm -rf Something-important”这样的字符串，则不存在代码注入风险（但请记住，它是 在一般情况下很难确保这一点）。 另外，我相信，如果您在浏览器中运行，那么代码注入的风险相当小。

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

Answer 2

eval() 并不是邪恶的。 或者，如果是的话，它是邪恶的，就像反射、文件/网络 I/O、线程和 IPC 在其他语言中是“邪恶的”一样。

如果，为了您的目的，eval()比手动解释更快，或者使您的代码更简单或更清晰......那么您应该使用它。 如果两者都不是，那么你就不应该。 就那么简单。

Answer 3

当你信任来源时。

对于 JSON，篡改源或多或少是困难的，因为它来自您控制的 Web 服务器。 只要 JSON 本身不包含用户上传的数据，使用 eval 就没有什么大的缺点。

在所有其他情况下，我会竭尽全力确保用户提供的数据符合我的规则，然后再将其提供给 eval()。

Answer 4

让我们来真正的人：

1. 现在每个主要浏览器都有一个内置控制台，您的潜在黑客可以充分使用它来调用具有任何值的任何函数 - 为什么他们会费心使用 eval 语句 - 即使他们可以 ？

2. 如果编译 2000 行 JavaScript 需要 0.2 秒，那么如果我评估四行 JSON

甚至克罗克福德对“评估是邪恶的”的解释也是站不住脚的。

eval 是邪恶的，eval 函数是最常被滥用的功能
JavaScript。 避免它

正如克罗克福德本人可能会说的那样“这种说法往往会产生非理性的神经症。不要相信它。”

理解 eval 并知道它何时可能有用更为重要。 例如，eval 是一个用于评估软件生成的服务器响应的实用工具。

顺便说一句：Prototype.js 直接调用 eval 五次（包括在 evalJSON() 和 evalResponse() 中）。 jQuery 在 parseJSON 中使用它（通过函数构造函数）。

Answer 5

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

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

即使它是一个可信源，我也不会使用它，因为 JSON 返回的代码可能是乱码，这充其量可能会做出一些奇怪的事情，最坏的情况是暴露出一些不好的东西。

Answer 6

Eval 是对用于模板化代码的编译的补充。 我所说的模板化是指您编写一个简化的模板生成器，它可以生成有用的模板代码，从而提高开发速度。

我编写了一个框架，开发人员不使用 EVAL，但他们使用我们的框架，而该框架又必须使用 EVAL 来生成模板。

使用以下方法可以提高 EVAL 的性能； 您必须返回一个函数，而不是执行脚本。

var a = eval("3 + 5");

应该组织成

var f = eval("(function(a,b) { return a + b; })");

var a = f(3,5);

Caching f肯定会提高速度。

Chrome 还允许非常轻松地调试此类功能。

关于安全性，使用或不使用eval几乎没有什么区别，

1. 首先，浏览器在沙箱中调用整个脚本。
2. 任何在 EVAL 中是邪恶的代码，在浏览器本身中也是邪恶的。 攻击者或任何人都可以轻松地在 DOM 中注入脚本节点并执行任何操作（如果他/她可以评估任何内容）。 不使用 EVAL 不会产生任何影响。
3. 有害的主要是服务器端安全性差。 服务器上不良的 cookie 验证或不良的 ACL 实施会导致大多数攻击。
4. 最近，Java 的本机代码中存在 Java 漏洞等。 JavaScript 过去和现在都被设计为在沙箱中运行，而小程序被设计为在带有证书等的沙箱外运行，这会导致漏洞和许多其他问题。
5. 编写模仿浏览器的代码并不困难。 您所要做的就是使用您最喜欢的用户代理字符串向服务器发出 HTTP 请求。 无论如何，所有测试工具都会模拟浏览器； 如果攻击者想要伤害您，EVAL 是他们的最后手段。 他们有许多其他方法来处理服务器端安全。
6. 浏览器 DOM 无法访问文件，也无法访问用户名。 事实上，机器上没有任何东西可供 eval 访问。

如果您的服务器端安全性足够可靠，任何人都可以从任何地方进行攻击，那么您不必担心 EVAL。 正如我提到的，如果 EVAL 不存在，攻击者就有很多工具可以侵入您的服务器，无论您的浏览器的 EVAL 功能如何。

Eval 仅适用于生成一些模板，以根据未使用的内容进行复杂的字符串处理提前。 例如，我更喜欢

"FirstName + ' ' + LastName"

As 而不是

"LastName + ' ' + FirstName"

As 我的显示名称，它可以来自数据库并且不是硬编码的。

Answer 7

底线

如果您创建或清理了您评估的代码，那么它绝不会邪恶。

稍微更详细一点，

如果在服务器上运行时使用客户端提交的输入运行，则eval是邪恶，而该客户端不是由开发人员创建的或者是 >未经开发商清理。

如果在客户端上运行，eval 是不是邪恶的，即使使用客户端制作的未经净化的输入。

显然，您应该始终清理输入，以便对代码消耗的内容进行一定的控制。

推理

客户端可以运行他们想要的任何任意代码，即使开发人员没有编码； 这不仅适用于评估的内容，也适用于对 eval 本身的调用。

Answer 8

在 Chrome (v28.0.1500.72) 中调试时，我发现如果变量未在生成闭包的嵌套函数中使用，则它们不会绑定到闭包。 我想，这是 JavaScript 引擎的优化。

BUT：当在导致闭包的函数内部使用 eval() 时，所有外部函数的变量都会绑定到闭包，甚至如果根本不使用它们。 如果有人有时间测试是否会产生内存泄漏，请在下面给我留言。

这是我的测试代码：

(function () {
    var eval = function (arg) {
    };

    function evalTest() {
        var used = "used";
        var unused = "not used";

        (function () {
            used.toString();   // Variable "unused" is visible in debugger
            eval("1");
        })();
    }

    evalTest();
})();

(function () {
    var eval = function (arg) {
    };

    function evalTest() {
        var used = "used";
        var unused = "not used";

        (function () {
            used.toString();   // Variable "unused" is NOT visible in debugger
            var noval = eval;
            noval("1");
        })();
    }

    evalTest();
})();

(function () {
    var noval = function (arg) {
    };

    function evalTest() {
        var used = "used";
        var unused = "not used";

        (function () {
            used.toString();    // Variable "unused" is NOT visible in debugger
            noval("1");
        })();
    }

    evalTest();
})();

我想在这里指出的是，eval() 不一定引用本机 eval() 函数。 这完全取决于函数的名称。 因此，当使用别名调用本机 eval() 时（比如 var noval = eval;），然后在内部函数 noval(expression); 中， >) 那么当表达式引用了应该是闭包一部分但实际上不是闭包一部分的变量时，它的求值可能会失败。

Answer 9

我看到人们提倡不要使用 eval，因为它是邪恶的，但我看到同样的人动态地使用 Function 和 setTimeout，所以他们在幕后使用 eval :D

BTW，如果您的沙箱不够确定（例如，如果您正在允许代码注入的网站上工作），则 eval 是您的最后一个问题。 安全的基本规则是所有输入都是邪恶的，但是对于 JavaScript 甚至 JavaScript 本身也可能是邪恶的，因为在 JavaScript 中你可以覆盖任何函数并且你可以不确定您使用的是真实的，因此，如果恶意代码在您之前启动，您就不能信任任何 JavaScript 内置函数 :D

现在这篇文章的尾声是：

如果您真的< /strong> 需要它（80% 的时间不需要 eval）并且你确定自己在做什么，只需使用 eval （或更好的 Function ;) ）、闭包和 OOP 覆盖80/90% 的情况 eval 可以使用另一种逻辑替换，其余的是动态生成的代码（例如，如果您正在编写解释器），并且正如您已经说过的评估 JSON（在这里您可以使用Crockford 安全评估 ;) )

Answer 10

唯一应该使用 eval() 的情况是当您需要动态运行动态 JS 时。 我说的是从服务器异步下载的 JS...

...10 次中有 9 次你可以通过重构轻松避免这样做。

Answer 11

eval 很少是正确的选择。 虽然在许多情况下，您可以通过将脚本连接在一起并即时运行来完成您需要完成的任务，但您通常可以使用更强大且可维护的技术：关联数组表示法（obj[ "prop"] 与 obj.prop 相同）、闭包、面向对象技术、函数式技术 - 请改用它们。

Answer 12

在服务器端，eval 在处理外部脚本（例如 sql、influxdb 或 mongo）时非常有用。 可以在运行时进行自定义验证，而无需重新部署服务。

例如具有以下元数据的成就服务

{
  "568ff113-abcd-f123-84c5-871fe2007cf0": {
    "msg_enum": "quest/registration",
    "timely": "all_times",
    "scope": [
      "quest/daily-active"
    ],
    "query": "`SELECT COUNT(point) AS valid from \"${userId}/dump/quest/daily-active\" LIMIT 1`",
    "validator": "valid > 0",
    "reward_external": "ewallet",
    "reward_external_payload": "`{\"token\": \"${token}\", \"userId\": \"${userId}\", \"amountIn\": 1, \"conversionType\": \"quest/registration:silver\", \"exchangeProvider\":\"provider/achievement\",\"exchangeType\":\"payment/quest/registration\"}`"
  },
  "efdfb506-1234-abcd-9d4a-7d624c564332": {
    "msg_enum": "quest/daily-active",
    "timely": "daily",
    "scope": [
      "quest/daily-active"
    ],
    "query": "`SELECT COUNT(point) AS valid from \"${userId}/dump/quest/daily-active\" WHERE time >= '${today}' ${ENV.DAILY_OFFSET} LIMIT 1`",
    "validator": "valid > 0",
    "reward_external": "ewallet",
    "reward_external_payload": "`{\"token\": \"${token}\", \"userId\": \"${userId}\", \"amountIn\": 1, \"conversionType\": \"quest/daily-active:silver\", \"exchangeProvider\":\"provider/achievement\",\"exchangeType\":\"payment/quest/daily-active\"}`"
  }
}

然后允许，

• 通过 json 中的文字字符串直接注入对象/值，对于模板化文本很有用

  通过

• 可以用作比较器，假设我们制定规则如何验证 CMS 中的任务或事件

缺点：

• 可能会出现错误如果没有经过充分测试，代码中可能会出现错误，并且会破坏服务中的事物。

  如果没有

• 如果黑客可以在您的系统上编写脚本，那么您就完蛋了。

• 验证脚本的一种方法是将脚本的哈希值保存在安全的地方，以便您可以在运行之前检查它们。

  验证脚本的一种方法是将

Answer 13

Eval 并不是邪恶的，只是被滥用了。

如果您创建了进入其中的代码或者可以信任它，那就没问题。
人们一直在谈论用户输入对于 eval 来说并不重要。 好吧~

如果有用户输入发送到服务器，然后返回客户端，并且该代码将在 eval 中使用而不经过清理。 恭喜，您已经打开了潘多拉魔盒，用户数据可以发送给任何人。

根据评估的位置，许多网站都使用 SPA，并且评估可以使用户更轻松地访问应用程序内部，否则这并不容易。 现在，他们可以制作一个伪造的浏览器扩展，可以将其粘贴到该评估中并再次窃取数据。

只需弄清楚您使用 eval 的意义是什么。 当您可以简单地创建方法来执行此类操作、使用对象等时，生成代码并不是非常理想。

现在是一个使用 eval 的很好的例子。
您的服务器正在读取您创建的 swagger 文件。 许多 URL 参数都是以 {myParam} 格式创建的。 因此，您希望读取 URL，然后将它们转换为模板字符串，而无需进行复杂的替换，因为您有许多端点。 所以你可以做这样的事情。
请注意，这是一个非常简单的示例。

const params = { id: 5 };

const route = '/api/user/{id}';
route.replace(/{/g, '${params.');

// use eval(route); to do something

Answer 14

由于还没有人提到它，让我补充一下 eval 对于 Webassemble-Javascript 互操作非常有用。 虽然在页面中包含可供 WASM 代码直接调用的预制脚本当然是理想的选择，但有时这是不切实际的，您需要从 C# 等 WebAssembly 语言传入动态 Javascript 才能真正完成您需要做的事情。

在这种情况下它也是安全的，因为您可以完全控制传入的内容。嗯，我应该说，它并不比使用 C# 编写 SQL 语句安全，也就是说，它需要小心完成（正确转义字符串等） .) 每当使用用户提供的数据来生成脚本时。 但有了这个警告，它在互操作情况下就有了明确的地位，并且远非“邪恶”。

Answer 15

就客户端脚本而言，我认为安全问题是一个有争议的问题。 加载到浏览器中的所有内容都可以进行操作，并且应该如此对待。 当有更简单的方法来执行 JavaScript 代码和/或操作 DOM 中的对象（例如浏览器中的 URL 栏）时，使用 eval() 语句的风险为零。

javascript:alert("hello");

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

从实用的角度来看，在可以用其他方式完成事情的情况下使用 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>

Answer 16

代码生成。 我最近编写了一个名为 Hyperbars 的库，它弥补了 virtual-dom 和 车把。 它通过解析车把模板并将其转换为 hyperscript 来实现此目的。 超脚本首先作为字符串生成，在返回它之前，使用 eval() 将其转换为可执行代码。 我发现在这种特殊情况下，eval()与邪恶完全相反。

基本上，在这种情况下

<div>
    {{#each names}}
        <span>{{this}}</span>
    {{/each}}
</div>

，

(function (state) {
    var Runtime = Hyperbars.Runtime;
    var context = state;
    return h('div', {}, [Runtime.each(context['names'], context, function (context, parent, options) {
        return [h('span', {}, [options['@index'], context])]
    })])
}.bind({}))

eval() 的性能也不是问题，因为您只需要解释生成的字符串一次，然后多次重复使用可执行输出。

如果您好奇，您可以看到代码生成是如何实现的 在这里。

Answer 17

当您没有宏时，Eval 对于代码生成很有用。

举个（愚蠢的）例子，如果你正在编写一个 Brainfuck 编译器，你可能会想要构造一个以字符串形式执行指令序列的函数，并对其进行评估以返回一个函数。

Answer 18

我认为任何评估合理的案例都是罕见的。 您更有可能认为它是合理的而使用它，而不是在它实际上合理时才使用它。

安全问题是最为人所知的。 但也要注意 JavaScript 使用 JIT 编译，这对于 eval 来说效果很差。 Eval 对于编译器来说有点像黑匣子，JavaScript 需要能够（在某种程度上）提前预测代码，以便安全、正确地应用性能优化和范围界定。 在某些情况下，性能影响甚至会影响 eval 之外的其他代码。

如果您想了解更多：
https: //github.com/getify/You-Dont-Know-JS/blob/master/scope%20%26%20closures/ch2.md#eval

Answer 19

如果您可以完全控制传递给 eval 函数的代码，则可以使用它。

Answer 20

如果可能的话，仅在测试期间。 另请注意，eval() 比其他专用 JSON 等评估器慢得多。

Answer 21

只要您可以确定代码的来源来自您或实际用户，就没有理由不使用 eval()。 尽管他可以操纵发送到 eval() 函数的内容，但这不是安全问题，因为他能够操纵网站的源代码，因此可以更改 JavaScript 代码本身。

那么...什么时候不使用 eval() ？ 仅当第三方有可能更改 Eval() 时，才不应使用 Eval()。 就像拦截客户端和服务器之间的连接一样（但如果这是一个问题，请使用 HTTPS）。 您不应该使用 eval() 来解析其他人（例如在论坛中）编写的代码。

Answer 22

如果确实需要 eval 并不是邪恶的。 但是我偶然发现的 99.9% 的 eval 用法都是不需要的（不包括 setTimeout 的东西）。

对我来说，邪恶不是性能问题，甚至不是安全问题（好吧，间接地两者都是）。 所有这些不必要的 eval 使用都会增加维护难度。 重构工具被抛弃了。 搜索代码很困难。 这些评估带来的意想不到的影响是巨大的。

Answer 23

我相信 eval 对于客户端 Web 应用程序来说是一个非常强大的函数，并且安全......与 JavaScript 一样安全，但事实并非如此。 :-) 安全问题本质上是服务器端问题，因为现在，使用 Firebug 这样的工具，您可以攻击任何 JavaScript 应用程序。

Answer 24

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

我总是试图阻止使用 eval。 几乎总是有更干净、更可维护的解决方案可用。 即使 JSON 解析也不需要 Eval 。 Eval 增加了维护地狱。 道格拉斯·克罗克福德（Douglas Crockford）等大师对它不屑一顾，这并非没有道理。

但我发现了一个应该使用它的示例：

当您需要传递表达式时。

例如，我有一个构造通用 google.maps.ImageMapType 对我来说对象，但我需要告诉它秘诀，它应该如何从 zoom 和 coord 参数构建图块 URL：

my_func({
    name: "OSM",
    tileURLexpr: '"http://tile.openstreetmap.org/"+b+"/"+a.x+"/"+a.y+".png"',
    ...
});

function my_func(opts)
{
    return new google.maps.ImageMapType({
        getTileUrl: function (coord, zoom) {
            var b = zoom;
            var a = coord;
            return eval(opts.tileURLexpr);
        },
        ....
    });
}

Answer 25

我使用eval的示例：导入。

通常是如何完成的。

var components = require('components');
var Button = components.Button;
var ComboBox = components.ComboBox;
var CheckBox = components.CheckBox;
...
// That quickly gets very boring

但在 eval 和一些辅助函数的帮助下，它看起来更好了：

var components = require('components');
eval(importable('components', 'Button', 'ComboBox', 'CheckBox', ...));

importable 可能看起来像（这个版本不支持导入具体成员）。

function importable(path) {
    var name;
    var pkg = eval(path);
    var result = '\n';

    for (name in pkg) {
        result += 'if (name !== undefined) throw "import error: name already exists";\n'.replace(/name/g, name);
    }

    for (name in pkg) {
        result += 'var name = path.name;\n'.replace(/name/g, name).replace('path', path);
    }
    return result;
}

Answer 26

尽管在许多情况下，您可以通过将脚本连接在一起并即时运行来完成您需要完成的任务，但您通常可以使用更强大且可维护的技术。 eval 很少是正确的选择。：关联数组表示法（obj["prop"] 与 obj.prop 相同）、闭包、面向对象技术、函数技术 - 请改用它们。

Answer 27

当您使用解析函数（例如 jQuery.parseJSON）解析 JSON 结构时，它期望 JSON 文件具有完美的结构（每个属性名称都用双引号引起来）。 然而，JavaScript 更灵活。 因此，您可以使用 eval() 来避免它。