许多开发人员认为eval()应该避免使用 JavaScript 的方法。从设计的角度来看，这个想法是有道理的。当有更简单、更好的选择时，它通常被用作丑陋的解决方法。
但是，我不理解对安全漏洞的担忧。当然，运行eval()使黑客能够运行您可以运行的任何 JavaScript 代码。
但是他们就不能这样做吗？至少在 Chrome 中，开发者工具允许最终用户运行他们自己的 JavaScript。怎么eval()比开发者工具更危险？
问问题
31800 次
2 回答
21
正如 B-Con 所提到的，攻击者不是坐在计算机旁的人，因此可能会使用eval()脚本中已经存在的内容作为将恶意代码传递到您的站点的一种手段，以便以某种方式利用当前用户的会话（例如，用户跟随恶意链接）。
的危险eval()是当它在未经处理的值上执行时，可能会导致基于 DOM 的 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()to执行的代码
alert("Your query string was hello");
alert(document.cookie+"");
（为清楚起见，我添加了新行）。现在，这可能比显示当前的 cookie 值更恶意，因为所需的代码只是通过攻击者的链接以编码形式传递到查询字符串上。例如，它可能在资源请求中将 cookie 发送到攻击者的域，从而使身份验证会话被劫持。
这适用于来自用户/外部输入的任何未经处理并直接在 中执行的值eval()，而不仅仅是此处显示的查询字符串。
于 2013-08-13T11:35:39.763 回答
6
攻击者无权访问用户浏览器的开发者工具。攻击者可能不是坐在计算机前的用户。
危险eval()在于攻击者可能能够操纵最终eval()以其他方式运行的数据。如果eval()'d 字符串来自 HTTP 连接，则攻击者可能会执行 MITM 攻击并修改该字符串。如果字符串来自外部存储，则攻击者可能已经操纵了该存储位置中的数据。等等。
于 2013-08-12T14:30:18.580 回答