Securing SSJS against unverified code

Hi Adam!

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

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!

This is not true. In a sandboxed environment, where JS is simply executed and "outputted" (using a custom function) to an output stream that is serialized and delivered to the client, there is no vulnerability. The only stipulation is that a timeout and resource limit must exist to prevent infinite loops. Server side JS does not necessarily imply the lax security and full-bodied properties of the DOM.

mattbasta 2010-07-23 00:06:40

@Rook Just posted my answer. A sandboxed JS environment does not emulate the DOM, it provides a blank ECMAScript environment for code execution. The only vulnerability is via resource hogging, and that can be taken care of with careful access control and timeouts.

mattbasta 2010-07-23 00:16:46

Also, -1-ing answers out of spite is even more of a dick move.

mattbasta 2010-07-23 00:19:34

@mattbasta Actually i didn't just randomly give you a -1, i looked for a terrible security answer and i down voted it. I also told you why i down voted it.

Rook 2010-07-23 00:21:55

Perhaps if you wanted to look less like a childish coward, you'd stop deleting your comments and admit that you're wrong.

mattbasta 2010-07-23 07:53:07

If you two insist on keeping this up, @TheRook and @matt we'll have you two pull out your neckbeards and settle this once and for all like real nerds.

Will 2010-07-23 17:11:59

@Will haha i wish i had a neckbeard :*(

Rook 2010-07-23 17:58:39

@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 2010-07-23 01:13:42

@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 2010-07-23 06:52:06

@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 2010-07-23 07:51:00

@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 2010-07-23 08:43:14

@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 2010-07-23 16:38:24

@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 2010-07-23 18:03:45

@mattbasta oah and i don't give a fuck about the -1's your giving me.

Rook 2010-07-24 01:11:39

ansaurus

tags:

views:

answers:

Securing SSJS against unverified code

related questions