Strangely long article for what amounts to: server runs eval on user input, security problems follow.

It's funny how we've been taught for years not to use eval for "security reasons" and I always thought "eh, how much harm can someone do in their own browser? But I won't use eval anyway."

...then Node came along and I vowed to never consider eval even an option. I mean, that's a HUGE risk if you eval any user input on the server side. In fact, the only valid use I've seen for eval is template engines like Jade, but they don't touch user input.

What if one of the libraries you call into use it?

Perl has taint mode, which treats user input as unsafe before validation.

Does node provide anything similar?

It's interesting to see SQL injection techniques reworked to attack Mongo, but not really surprising. Not following good coding practices is going to cause problems regardless the language. Nosql, SSJS and the like won't protect you from yourself if you don't sanitize user input.

This is all bad code practices. Why use eval since we have a fast JSON parser.

Why use map/reduce for user interaction queries. Since we have mongo's JSON based querying.

Btw. Mongo can also vurnable to JSON queries with taking query JSON directly from the user.

Makes me wonder if 'eval' still serves a legit purpose

It can be nice for quick and dirty things like this:

function sum(numericArray){return eval(numericArray.join('+'))}

Of course, that assumes you're smart enough not to use it on arrays that might contain user input, or you'll end up being susceptible to things like sum(['alert("pwned")']).

That code takes a terrible detour. To do a simple reduction, you build a STRING, hand it over to the parser, which creates an expression, which is converted to bytecode and then it can be interpreted/JIT-ed.

I can't imagine it actually being faster than normal array functions, and if it's the case it yet again proved what an abysmal language JS is :-)

But seriously, don't use eval this way. The array may not seem to contain user input on first glance, but it's very fragile: a small bug, a change to the code (for example, by another programmer, or by you when you're not paying attention) can easily cause it to be.

You're never "smart enough" to go around basic security guidelines to gain some (questionable) speed.

I think it's a good question by the grandparent what eval is good for. Arguably it allows for some powerful paradigms such as generating code at run time, but similar things can be done with function closures and eval is just too often abused for parsing (wasn't there window.JSON.parse for that?)

All I'm saying is that if I'm putting together a quick demo or proof of concept or reduced test case, I'm always going to favor "easy" over "secure". And sometimes using eval is easier.

By the way, the performance of evaling an array that way is abysmal: http://jsperf.com/array-summing-loop-vs-eval

Yes, eval is evil. And remember folks, eval is just as evil in PHP where use defined data is nearby.

it would take some next level negligence to write a server you could exploit like this.