利用 JavaScript 的 eval() 方法答案

【问题标题】：Exploiting JavaScript's eval() method利用 JavaScript 的 eval() 方法
【发布时间】：2013-08-12 14:24:04
【问题描述】：

许多开发人员认为应该避免使用 JavaScript 的 eval() 方法。从设计的角度来看，这个想法是有道理的。当有更简单、更好的选择时，它通常被用作丑陋的解决方法。

但是，我不理解对安全漏洞的担忧。当然，运行eval() 使黑客能够运行您可以运行的任何 JavaScript 代码。

但他们就不能这样做吗？至少在 Chrome 中，开发者工具允许最终用户运行他们自己的 JavaScript。 eval() 比开发者工具更危险吗？

【问题讨论】：

这不是“共同共识”。许多经验丰富的开发人员对eval 的 FUD 感到恼火。 “eval is evil” 今天可能从未被有经验的程序员说过。如果你很愚蠢，那可能很危险。但通常它只是缓慢、丑陋并导致代码难以进化。
@DenysSéguret 我认为 mozilla 开发人员可以认为是经验丰富的。 article 建议避免使用 eval 并改用 Function ，他们声称这样更快、更安全，因为它只能访问全局范围。
@N4ppeL 当然，大多数情况下，eval 有更好的替代品。我告诉了它（将我的评论读到最后）。我的观点是 “eval is evil” 可能是一个有趣的口号，但不是一个有用的口号。顺便说一句，可以说 JS 自 2013 年以来确实发生了一些变化，因此尝试恢复和辩论旧对话可能最好留给历史学家。
我强烈不同意最后一部分，因为人们最终还是会在这里寻求建议，因此绝对应该让辩论保持最新。这也是为什么我想指出一个潜在的替代方案，当然Function 也应该谨慎使用。如果可能，应使用 JSON 解析器或类似的工具。还有a more recent thread 讨论这个话题，任何人都可能会感兴趣。

【解决方案1】：

正如 B-Con 所提到的，攻击者不是坐在计算机旁的人，因此可能会使用您脚本中已经存在的 eval() 作为将恶意代码传递到您的站点的一种手段，以利用当前用户的会话以某种方式（例如，用户点击了恶意链接）。

eval() 的危险在于它在未经处理的值上执行，并可能导致DOM Based XSS 漏洞。

例如在您的 HTML 中考虑以下代码（相当做作，但它说明了我希望的问题）

<script>

eval('alert("Your query string was ' + unescape(document.location.search) + '");');

</script>

现在，如果查询字符串是 ?foo，您只会得到一个警告对话框，说明以下内容：Your query string was ?foo

但此代码将允许用户将用户从他们的网站重定向到一个 URL，例如 http://www.example.com/page.htm?hello%22);alert(document.cookie+%22，其中 www.example.com 是您的网站。

这会将eval()执行的代码修改为

alert("Your query string was hello");
alert(document.cookie+"");

（为清楚起见，我添加了新行）。现在，这可能比显示当前的 cookie 值更恶意，因为所需的代码只是通过攻击者的链接以编码形式传递到查询字符串上。例如，它可能在资源请求中将 cookie 发送到攻击者的域，从而使身份验证会话被劫持。

这适用于来自用户/外部输入的任何未经处理并直接在 eval() 中执行的值，而不仅仅是此处显示的查询字符串。

【讨论】：

【解决方案2】：

攻击者无权访问用户浏览器的开发者工具。攻击者可能不是坐在电脑前的用户。

eval() 的危险在于攻击者可能能够以其他方式操纵最终通过eval() 运行的数据。如果eval()'d 字符串来自 HTTP 连接，则攻击者可能会执行 MITM 攻击并修改字符串。如果字符串来自外部存储，则攻击者可能已经操纵了该存储位置中的数据。等等。

【讨论】：

真正的问题是来自用户提供的任何来源的字符串。无论eval，MITM 攻击始终是个问题。如果他们在做 MITM，他们可以很容易地修改常规的非评估 JS 有效负载。
另一个经典例子是evaling GET 变量是打开 XSS 漏洞的简单方法。等等。