62

What are the options for running (possibly malicious) user-submitted scripts in node.js, securely? I.e. in an environment that prevents code from accessing sensitive data and APIs?

vm.runInNewContext(userScript, {}) is a tempting starting point... but it seems like there are known issues there.

The sandbox module looks interesting, but uses runInNewContext() as well so I'm a bit leery of it.

broofa
  • 37,461
  • 11
  • 73
  • 73
  • I'd recommend using `vm` because it's part of node core. And since node core tends to gets its bugs fixed just assume it the issue will be fixed – Raynos Sep 17 '11 at 00:39
  • @Raynos it's not a bug. The docs say it's only intended for known-good code. – thejh Oct 30 '11 at 09:02
  • @thejh - true, but the API does lend itself toward the pretty reasonable belief that the code is executing in an entirely different context, implying that said code shouldn't be able to access the current context. And I expect that the *intent* of the API is exactly that - to provide a sandbox in which to run scripts. So... I think a pretty strong case can be made that this is simply a well-documented bug. :) – broofa Oct 30 '11 at 22:54
  • Does this answer your question? [How to run untrusted code serverside?](https://stackoverflow.com/questions/10937870/how-to-run-untrusted-code-serverside) – Jerska Mar 27 '20 at 10:34

2 Answers2

40

You should always run untrusted code in a separate process, which is exactly what the sandbox module does. A simple reason is that vm.runInNewContext('while(true){}', {}) will freeze node.

It starts by spawning a separate process, which will later send the result serialized to JSON on its stdout. The parent process continues executing regardless of what the child does and can trigger a timeout.

The untrusted code is then wrapped in a closure with strict mode (in regular JavaScript, you can use arguments.callee.caller to access data outside of your scope). Finally, a very limited global object is passed to prevent access to node's API. The untrusted code can only do basic computation and has no access to files or sockets.

While you should read sandbox's code as an inspiration, I wouldn't recommend using it as is:

  • The code is getting old and hasn't been updated for 7 months.
  • The Child Process module in node already provides most of the features you need, especially child_process.fork().
  • The IPC channel provided by child_process.fork probably has better performances.

For increased security, you could also consider using setuid-sandbox. It's the code used by Google Chrome to prevent tab processes from accessing the file system. You would have to make a native module, but this example seems straightforward.

Laurent Perrin
  • 14,671
  • 5
  • 50
  • 49
  • 4
    The methods in the `vm` module now support a `timeout` parameter which lets you safely execute `while(true) {}`. It obviously doesn't address the security concerns, but it does address endless loops. – Andrew Paprocki Jun 03 '13 at 14:02
  • @AndrewPaprocki Can you link to the docs where timeout is shown? – Rob Fox Mar 02 '14 at 12:25
  • 1
    This answer is very good. Still, I want to point to another similar question (more recent) which may be helpful to people with the same problem: http://stackoverflow.com/questions/17513212/safely-sandbox-and-execute-user-submitted-javascript – Akhorus Apr 20 '15 at 13:50
16

There is a newer module on github called vm2 that addresses some of these concerns, especially in Node.JS applications. Maybe that will help some others find it, as I have just done.

Alan Mimms
  • 651
  • 9
  • 22