
Server-Side JavaScript Injection - wglb
https://media.blackhat.com/bh-us-11/Sullivan/BH_US_11_Sullivan_Server_Side_WP.pdf
======
kzahel
Strangely long article for what amounts to: server runs eval on user input,
security problems follow.

~~~
firefoxman1
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.

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

------
justjohn
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.

------
arunoda
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.

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

~~~
kevincennis
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")']).

~~~
wladimir
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?)

~~~
kevincennis
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>

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

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

