Node.js sandbox - executes untrusted JavaScript for embedded scripting(github.com)
github.com
Node.js sandbox - executes untrusted JavaScript for embedded scripting
https://github.com/gf3/sandbox
6 comments
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 :).)
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.
I was just working on something like this for a coding competition. Players submit code to compete head to head. Sandboxing is required to prevent players from modifying the game state and/or the other players' state. That's just one example that comes to mind...
I don't see the point of using this when there is the vm core package.
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.
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.
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/...
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.