Exploiting JavaScript's eval() method

Jared Nielsen picture Jared Nielsen · Aug 12, 2013 · Viewed 24.1k times · Source

Many developers believe that JavaScript's eval() method should be avoided. This idea makes sense from a design perspective. It is often used as an ugly workaround when a simpler, better option is available.

However, I do not understand the concerns about security vulnerabilities. Certainly, running eval() gives the hacker the ability to run any JavaScript code that you can run.

But can't they do this anyway? In Chrome, at least, the Developer Tools allow the end-user to run their own JavaScript. How is eval() more dangerous than the Developer Tools?

Answer

SilverlightFox picture SilverlightFox · Aug 13, 2013

As B-Con mentioned, the attacker is not the one sitting at the computer so could be using the eval() already in your script as a means to pass malicious code to your site in order to exploit the current user's session in someway (e.g. a user following a malicious link).

The danger of eval() is when it is executed on unsanitised values, and can lead to a DOM Based XSS vulnerability.

e.g. consider the following code in your HTML (rather contrived, but it demonstrates the issue I hope)

<script>

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

</script>

Now if the query string is ?foo you simply get an alert dialog stating the following: Your query string was ?foo

But what this code will allow a user to do is redirect users from their site to a URL such as http://www.example.com/page.htm?hello%22);alert(document.cookie+%22, where www.example.com is your website.

This modifies the code that is executed by eval() to

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

(New lines added by me for clarity). Now this could be doing something more malicious than showing the current cookie value, as the required code is simply passed on the query string by the attacker's link in encoded form. For example, it could be sending the cookie to the attacker's domain in a resource request, enabling the authentication session to be hijacked.

This applies to any value from user/external input that is unsanitised and executed directly in the eval(), not just the query string as shown here.