

Node.js sandbox - executes untrusted JavaScript for embedded scripting - cjfont
https://github.com/gf3/sandbox

======
thepumpkin1979
This is highly recommended according to the
docs([http://nodejs.org/docs/v0.4.12/api/vm.html#vm.runInNewContex...](http://nodejs.org/docs/v0.4.12/api/vm.html#vm.runInNewContext)):
"Note that running untrusted code is a tricky business requiring great care.
To prevent accidental global variable leakage, script.runInNewContext is quite
useful, but safely running untrusted code requires a separate process."

So IMHO, it's a good start but is not quite there yet, I'm not an expert in
security but I don't think just because you are using V8 and a separate
process model doesn't mean you will achieve the same level of sandboxing that
Chromium provides. In fact, Chromium relies a lot in several security
mechanism of the OS:

Windows: <http://www.chromium.org/developers/design-documents/sandbox>

Linux: <http://code.google.com/p/chromium/wiki/LinuxSandboxing>

OSX: [http://www.chromium.org/developers/design-
documents/sandbox/...](http://www.chromium.org/developers/design-
documents/sandbox/osx-sandboxing-design)

So if you just want to keep your globals clean, running the code in a separate
V8 Context is more than enough, I did it once for a javascript library that
was corrupting one of my global
types(<https://github.com/firebaseco/safe_datejs>).

We are in a Cloud era, if you really need to run untrusted code on the server
side you should be using Virtual Machines instead of a processes, or even
better, create a web hook for your web app. I like the initiative but I'm
having a hard time trying to find a use case for this.

------
endianswap
Excuse my ignorance, but how frequently do developers find an application for
such a system? I haven't written many external-facing web projects (I can
generally trust each of the couple dozen users of my internal applications) so
I don't have much experience in this field, but still I can't imagine an
application I might want to write someday that would consume user submitted
code (save for a product like CodePad but I figure there are plenty of those
already :).)

~~~
adamlindsay
Take an eCommerce system for instance, you want to open up complex shipping or
discount calculations to your end users. A great way to to do this is to allow
them to write a function that takes in known objects and returns a result. Say
it takes in a cart/line_items and returns back a calculated amount. Obviously
its a bit more complex then that, but it is a great way to expose some
functionality without exposing the entire system.

------
lightblade
I don't see the point of using this when there is the vm core package.

~~~
wonderercat
I took a quick look and here's what I've gathered.

This thing gives the impression that user code is pre-emptible (it really just
forks the process under the hood), whereas using vm naively risks blocking
your process (infinite loop in user code will gimp the server).

There's also some pseudo-console.log hack to allow communication from user
code to the outside world.

Even so, I don't see the point of this either. vm + forked child process will
do the same thing, it's much more versatile, and if you're working a use-case
where running untrusted code is necessary, you're probably good enough with
Node to cook up this kind of solution in no more than a few minutes.

