5

I want to use node.js (or other SSJS solution), running my own code + external written code inside (untrusted).

Any way to seperate and protect my own code? Could I limit the modules and system effect of th untrusted code (limit access to files, non HTTP ports, etc.)?

Adam
  • 51
  • 1

3 Answers3

1

You can check out this project, it seems very promising:

http://github.com/gf3/node-sandbox

Personally, I don't use Node to do arbitrary SSJS execution. You probably won't like this solution, but it's worked fine for me for about a year:

There's a Perl implementation of Spidermonkey's API (Spidermonkey is Firefox's JS engine) that's available. I hooked that up with the help of some CGI. You can specify in it exactly what functions you want to expose (granted, it's in Perl...blech) and execute whatever code you please. There's no risk of vulnerabilities since the entire setup is completely sandboxed. It does not simulate the DOM.

The way I implemented this on my server (to prevent abuse) was to issue tokens which granted a one-use access through a REST API on a different server. It's a simple HMAC implementation that includes a timestamp to enforce the legitimacy of the token. When the Perl script receives a request, it validates the token and processes the script (the script should just be part of a POST request). The Perl script then just writes the results. My server is set to hit a timeout at around 10 seconds.

Hope this helps!

mattbasta
  • 13,492
  • 9
  • 47
  • 68
  • @Rook Actually, you're wrong. It's not even encryption, it's authentication. It's the same technique that Amazon AWS uses. More technically, it's not a "crypto magic wand", it's a legitimate means of securing any front-facing REST API. It doesn't matter what is used as an HMAC secret. Hop on any random text generator and use the first 30 characters or so, it doesn't matter. Though you've made it apparent that you don't understand very much about security. – mattbasta Jul 23 '10 at 01:13
  • @mattbasta crypto is short for cryptography and a cryptographic hash function such as sha256 falls under this category. Clearly security is a very in depth topic and everyone has more to learn. But in short i strongly dislike this approach to managing a remote code execution vulnerability. There is a good quote "If eval() is the answer then you are asking the wrong question". There is absolutely no good reason for someone to be executing code like this. It is likely that the OP is taking a short cut and he will be burned by this partial answer. – rook Jul 23 '10 at 06:52
  • @Rook For the last time, it is not a vulnerability. There is no "eval", as the code is running in an environment with literally nothing to break. There is literally no means of modifying sensitive information, accessing the disk, or making outbound requests. That's the idea behind a sandbox: clearly a topic that your security professor must have skimmed over. Sure, executing code in an `eval` statement is bad, but if the OP wants to run a user's JS, then running it in a sandboxed setting is the safest and most effective means of achieving that goal. Name one vulnerability exposed by a sandbox. – mattbasta Jul 23 '10 at 07:51
  • @mattbasta Does this gf3 sandbox allow printing to the browser? If it doesn't then its not very useful, if it does then its an XSS vulnerability. This project is only a few months old, appears to be alpha, and lacks documentation. On a side note I recommend that you delete some of these comments as they are unprofessional. – rook Jul 23 '10 at 08:43
  • @Rook The gf3 sandbox returns the output of the script as a string, which can be sanitized. The age is immaterial; Node.js hasn't been around for much more than a year itself and is also partly undocumented. Also, I don't plan on deleting my comments, as I'm quite certain that my solution is both safe and efficient. I'm not afraid to defend my position in a public forum. – mattbasta Jul 23 '10 at 16:38
  • @mattbasta I give everyone a -1 who purposes a vulnerability on SO, this is not a special case and bad security answers will continue to receive -1's from me. – rook Jul 23 '10 at 18:03
1

Check out this from the node.js documentation

script.runInNewContext([sandbox])

Similar to Script.runInNewContext (note capital 'S'), but now being a method of a precompiled Script object. script.runInNewContext runs the code of script with sandbox as the global object and returns the result. Running code does not have access to local scope. sandbox is optional.

http://nodejs.org/api.html#script-runinnewcontext-105

Dan Beam
  • 3,632
  • 2
  • 23
  • 27
  • 1
    Be careful, from the current docs: 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**. – The Who Feb 19 '11 at 07:04
  • Yup, but it really depends on how privileged the current process is to begin with. This probably implies you'd create a new process with lesser privileges, which requires more privileges to be begin with (i.e. starting the daemon as root). So, yes, sandboxing a global execution to a new process is good, but if you're running as a non-privileged user to begin with you're probably OK. It also depends on how mission critical this is. If it's your cat's blog, you're probably OK whatever you do. If it's transactional PCI compliant site it'd be a bit diff. Not really said in question... – Dan Beam May 20 '11 at 22:02
0

Have a look at Caja. It translates third-party code to a form where the code only has access to the objects you explicitly grant it.

Mike Stay
  • 1,071
  • 8
  • 17
  • caja is cool, too, you just have to go through the effort of cajole-ing it and understanding what you're doing (and need java, etc.) – Dan Beam Nov 13 '10 at 09:18