15

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?

Jared Nielsen
  • 3,669
  • 9
  • 25
  • 36
  • 2
    That's not *"the common consensus"*. Many experienced developers are annoyed by the FUD about `eval`. The *"eval is evil"* is probably never said today by experienced coders. If you're stupid, it may be dangerous. But usually it's just slow, ugly and leading to hard to evolve code. – Denys Séguret Aug 12 '13 at 14:26
  • @DenysSéguret I think mozilla devs can be considered experienced. This [article](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/eval#never_use_eval!) suggests to avoid eval and use Function instead, which they claim is faster and also safer since it can only access the global scope. – N4ppeL Oct 19 '21 at 09:26
  • @N4ppeL Of course most usually there are better alternatives to `eval`. I told it (read my comment to the end). My point is that *"eval is evil"* might be a fun slogan but isn't a useful take. BTW it could be argued that JS did change a little since 2013 so trying to revive and debate an old conversation is probably best left to historians. – Denys Séguret Oct 19 '21 at 09:42
  • 1
    I strongly disagree with that last part, since people still end up here looking for advice, so the debate should absolutely be kept up to date. Which is also why I wanted to point to a potential alternative, although of course also `Function` should only be used with care as well. If possible, a JSON-parser or similar should be used instead. There is also [a more recent thread](https://stackoverflow.com/questions/197769/when-is-javascripts-eval-not-evil) discussing this topic that might be of interest for anyone ending up here. – N4ppeL Oct 19 '21 at 09:59

2 Answers2

21

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.

SilverlightFox
  • 32,436
  • 11
  • 76
  • 145
6

An attacker doesn't have access to the user's browser's Developer Tools. The attacker is likely not the user sitting at the computer.

The danger of eval() is that an attacker may be able to manipulate data that is eventually run through eval() in other ways. If the eval()'d string comes from an HTTP connection, the attacker may perform a MITM attack and modify the string. If the string comes from external storage, the attacker may have manipulated the data in that storage location. Etc.

B-Con
  • 454
  • 6
  • 15
  • 2
    The real problem is the string coming from any source that is user supplied. MITM attack will always be a problem, regardles of `eval`. If they are doing MITM, they can modify the regular non-evaled JS payload just as easily. – Matt Aug 12 '13 at 14:59
  • 1
    Another classic example is `eval`ing GET variables is an easy way to open XSS holes. Etc. – B-Con Aug 12 '13 at 15:25