许多开发人员认为应该避免使用JavaScript的eval()
方法。从设计角度来看,这个想法很有意义。当一个更简单,更好的选择可用时,它经常被用作一种丑陋的解决方法。
但是,我不了解安全漏洞的担忧。当然,运行eval()
使黑客能够运行您可以运行的任何JavaScript代码。
但他们不能这样做吗?至少在Chrome中,开发人员工具允许最终用户运行自己的JavaScript。 eval()
如何比开发人员工具更危险?
答案 0 :(得分:11)
正如B-Con所提到的,攻击者不是坐在计算机上的人,因此可能正在使用脚本中的eval()
作为将恶意代码传递到您的站点以利用当前用户的方法在某种程度上会话(例如,用户关注恶意链接)。
eval()
的危险在于它是在未使用的值上执行的,并且可能导致DOM Based XSS漏洞。
e.g。考虑HTML中的以下代码(相当人为,但它表明了我希望的问题)
<script>
eval('alert("Your query string was ' + unescape(document.location.search) + '");');
</script>
现在,如果查询字符串为?foo
,您只需显示一个警告对话框,说明以下内容:Your query string was ?foo
但是,此代码允许用户执行的操作是将用户从其网站重定向到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()
中执行的用户/外部输入的任何值,而不仅仅是此处显示的查询字符串。
答案 1 :(得分:3)
攻击者无法访问用户浏览器的开发人员工具。攻击者很可能不是坐在电脑前的用户。
eval()
的危险在于攻击者可能能够以其他方式操纵最终通过eval()
运行的数据。如果eval()
'字符串来自HTTP连接,则攻击者可能会执行MITM攻击并修改字符串。如果字符串来自外部存储,则攻击者可能已操纵该存储位置中的数据。等