Tell me more ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.
up vote 8 down vote favorite
1

Eval is a notoriously controversial language feature. Douglas Crockford flat out rejects it. I'm wondering what specific risks Eval brings about. According to this question, Improper use of eval opens up your code for injection attacks.

What are some improper uses of the Eval command, and what security holes do they open up?

share|improve this question

3 Answers

up vote 0 down vote

I've seen it used well once or twice, but in general if there is any other possible way to do what you are doing, use that method!

share|improve this answer
up vote 11 down vote

Back when I was implementing the JScript engine I advocated having EVAL IS EVIL shirts printed up but sadly we never got around to it.

My biggest problem with eval is not the obvious malicious code injection attack, though that is certainly of enormous concern. My biggest problem with it is that people tend to use it as a Really Big Hammer to solve really small problems. Most of the real-world usages I saw of "eval" in the wild when I was on the JScript team could have been trivially solved by using a lookup table; and since every object in JScript already is a lookup table it's not like that was an onerous burden. Eval starts the compiler again and completely destroys the ability of the compiler to optimize your code.

For some more thoughts in this vein see my articles from 2003 on the subject:

General evilness:

http://blogs.msdn.com/b/ericlippert/archive/2003/11/01/53329.aspx

Injection attack evilness:

http://blogs.msdn.com/b/ericlippert/archive/2003/11/04/53335.aspx

share|improve this answer
What are your thoughts on evaling large chunks of code the way that applications like JSPacker like to? JSPacker + gzip usually results in smaller file sizes than either solution on its own, but as you rightly point out it is essentially firing up a compiler twice on the same piece of code, plus some overhead to do string replacements. – Matthew Scharley Mar 22 '11 at 9:06
1  
@Matthew: There is often a tradeoff between space and time, and taking advantage of that tradeoff can sometimes be a big win. If the purpose of the technique is to improve performance then my opinion is that if careful measurement shows that it is a significant win in realistic scenarios without introducing security holes, great, do that. But I don't know enough about the specific technique to criticize its details. – Eric Lippert Mar 22 '11 at 14:02
I wish one of the answers I had seen either here or on SO itself would have stated what your second link states: that eval() is not a security risk on client (browser) code. – sq33G Dec 25 '11 at 11:50
up vote 3 down vote

Most of the security holes are the same sort of holes as with SQL injection, namely concatenating user input into JavaScript code. The difference being that while there are ways to ensure this doesn't happen with SQL, there's not much you can do with JavaScript.

As a trivial and useless example, a simplistic JavaScript calculator:

textbox1.value = eval(textbox2.value);

One correct usage examples are some of the JavaScript packers that compress JavaScript by pulling out common words and replacing them with short 1-2 character replacements. The packer then outputs all this along with string replacement code based on the dictionary generated then evals the result.

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.