Ask yourself these questions:
- Are you one of the smartest persons on the planet?
- Do you turn down job offers by Google, Mozilla and Kaspersky Lab routinely because it would bore you?
- Does the "untrusted code" come from people working at the same company as you or from criminals and bored computer kids all over the globe?
- Are you sure that node.js has no security holes that could leak through your sandbox?
- Can you write perfect 100% error free code?
As you already know by your experiments with the sandbox module, writing your own sandbox isn't trivial. The main problem with sandboxes is that you must get everything right. One mistake will ruin your security completely which is why browser developers fight a constant battle with crackers all over the globe.
require() (both would allow crackers to escape your sandbox).
The interpreter must make sure that the interpreted code cannot access anything besides the few global symbols that you provide. This means there can't be an
Drawback of this approach: A lot of work and if you make a mistake in your interpreter, the crackers can leave the sandbox.
Another approach is to clean the code and run it with node.js's
eval(). You can clean existing code by running a bunch of regexp's over it like
/eval\s*[(]//g to remove malicious code parts.
Drawback of this approach: It's easy to make a mistake that will leave you vulnerable to an attack. For example, there might be mismatch between what regexp and what node.js think of as "whitespace". Some obscure unicode whitespace might be accepted by the interpreter but not by regexp which would allow an attacker to run
My suggestion: Write a small demo test case that shows how the sandbox module is broken and have it fixed. It will save you a lot of time and effort and if there is a bug in the sandbox, it won't be your fault (well, not entirely at least).