[Help] Execute User Provided JavaScript

[arunoda.s...@gmail.com]

hi,

One of our product requires to execute user provided JavaScript.

And It so dangerous. 

I've previously started discussion on https://groups.google.com/forum/#!topic/nodejs/f7N_TO8fpjs

Then I've come up with a project [0] using those recommendation.

Please evaluate it if u got some spare time.

[0] - https://github.com/arunoda/jailguard

Thanks.

--
Arunoda Susiripala

@arunoda

https://github.com/arunoda

http://www.linkedin.com/in/arunoda

[Jann Horn]

Looks insecure as hell. I can still eval using the Function constructor, parsing code with regexes is an awful idea, it's still possible to use the constructors of stuff passed into the vm to get the outside Function thingie and I can probably still crawl up the caller chain. This is a bad approach anyway. The new process shouldn't be a node process, it should be a v8 process.

--
Job Board: http://jobs.nodejs.org/
Posting guidelines: https://github.com/joyent/node/wiki/Mailing-List-Posting-Guidelines
You received this message because you are subscribed to the Google
Groups "nodejs" group.
To post to this group, send email to nod...@googlegroups.com
To unsubscribe from this group, send email to
nodejs+un...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/nodejs?hl=en?hl=en

[arunoda.s...@gmail.com]

Oh my :)

Thanks a lot for showing me this.

Can you please give me some sample of using Function Constructor

And What's the difference between v8 process and NodeJs process.

thanks.

[arunoda.s...@gmail.com]

Hi,

I've done measures to prevent Function Constructor [0]

See whether it is working or not.

[0] - https://github.com/arunoda/jailguard/commit/0c8c12342cfdeb8de951a801853d605061ba9b07

cheers.

[Tauren Mills]

Perhaps you should consider walking the AST using a tool like one of these instead of regex:

https://github.com/mishoo/UglifyJS

https://github.com/substack/node-burrito

[arunoda.s...@gmail.com]

Cool.

I have tried node-burrito.

And I use RegEx for finding out loops and add timeout check to prevent never ending loops.

I couldn't able to do it using burrito. 

that means I need replace 

while(true) {} 

with

while(true) { if(timeout.excceded()) break; }

But I will try uglifyJS.

Thanks.

[Dominic Tarr]

that is exactly the sort of thing that burrito was designed for.

what sort of things are you intending your users to write?

should you block their access to the file system?

[arunoda.s...@gmail.com]

actually they just need to do allow users to compute some thing using pure JS.

And I want to block NodeJS specific functionalities.

This is what I needed.

[Jann Horn]

What about (function(){}).constructor? Really, this is the wrong approach, please stop this.

Am 23.10.2011 14:44 schrieb "arunoda.s...@gmail.com" <arunoda.s...@gmail.com>:

Hi,

I've done measures to prevent Function Constructor [0]

See whether it is working or not.

[0] - https://github.com/arunoda/jailguard/commit/0c8c12342cfdeb8de951a801853d605061ba9b07

cheers.

On Sun, Oct 23, 2011 at 5:18 PM, arunoda.s...@gmail.com <arunoda.s...@gmail.com> wrote...

[arunoda.s...@gmail.com]

Okai. Then what would be the approach? any suggestions?

--

Job Board: http://jobs.nodejs.org/
Posting guidelines: https://github.com/joyent/node/wiki/Mailing-List-Posting-Guidelines
You received this message because you are subscribed to the Google
Groups "nodejs" group.
To post to this group, send email to nod...@googlegroups.com
To unsubscribe from this group, send email to
nodejs+un...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/nodejs?hl=en?hl=en

[Damianos Mylonakis]

Why do you need to allow users to do calculations in JS?
Can you give a usage example?

Usually if you're going to run user code on your machine, you would do that with help of other software eg VMs, selinux etc.
That, in order to be sure you have blocked operations on the filesystem, network etc.
I mean, if we find out a way to solve your problem in another way, then there is no need for the hassle :)

@danmilon.

[arunoda.s...@gmail.com]

Here is the situation
We are building an integration engine for an system where there are serveral inputs and outputs.
We allow end users to create custom integration by providing flow chart like controls.
But sometimes some complex manipulation can be easily created using scripting languages.
So we do allows custom Javascript to do that

So this javascript code should not contain any Io or network stuff.
Only pure ecma JS.

So we are trying to find a way for it to acheice with NodeJs.
Some problems we are facing is

1. Block users from accessing NodeJs apis
2. Identify or prevent never ending loops.

Hope this will help to help us to do the job :-)

Thanks.

[Bradley Meck]

Short checklist as a start:

1. Use a child process to run the code. This process can be a node process that is running another VM inside of it for user code to be run in (it both the process and separated VM).

2. Chroot the child process / Jail it / Run as Nobody:Nobody / run it in a new session / run it with empty environmental variables / remove ALL globals from node by setting them to undefined (not null) / everything reasonable to lock down the environment.

3. Use a serialization channel when talking to user code, never ever directly share objects.

4. Never reuse a child process.

5. ANY variable given to a child process for interaction with a parent should be through a strict mode function that can talk to code outside of our VM, never give direct references to objects from the privileged vm. This function should be generated inside of the user code context prior to executing any user code and should not use eval(). All references to objects including functions from the privileged context should be done via a closure. Any arguments passed through the function should be serialized via JSON in the user context and parsed in the privileged context. NEVER PASS FUNCTIONS TO YOUR PRIVILEGED CONTEXT (this includes proxy handlers / getters / setters / toString / toJSON / valueOf / ; those should be calculated via the original toJSON call). Finally, the function should not use the `this` keyword.

6. Set timeouts to kill your child process by.

7. Use memory monitors outside of your child process to manage size.

8. You should never run the debugger on your child process.

9. Run the code.

[Bradley Meck]

forgot to write down: any exceptions you get from the user code vm should not be inspected. Getter / setter traps on these are brutal, and since you can throw any kind of object, don't do it. wrap the user code in a try/catch and serialize it up to the privileged context.

[Jorge]

On 24/10/2011, at 07:33, Bradley Meck wrote:

> remove ALL globals from node by setting them to undefined (not null)

Why undefined not null ?
--
Jorge.

[arunoda.s...@gmail.com]

Cool this list is awesome.

It seems like I would have to create a some kind of multi processing environment with heavy monitoring and jailed os support.

Just for an thought how about migrating this to rhino since it works in a multi threading. But I'm not sure it still shares the heap. That might be an problem.

What you guys think about it?

On Monday, October 24, 2011, Bradley Meck <bradley.meck@gmai l.com> wrote:
> forgot to write down: any exceptions you get from the user code vm should not be inspected. Getter / setter traps on these are brutal, and since you can throw any kind of object, don't do it. wrap the user code in a try/catch and serialize it up to the privileged context.
>

[Jorge]

On 24/10/2011, at 07:33, Bradley Meck wrote:

> remove ALL globals from node / everything reasonable to lock down the environment.

Which are the reasonable ones ?

Object.getOwnPropertyNames(function(){return this}())
[
** 'clearInterval',
'TypeError',
'decodeURI',
** 'Buffer',
'parseFloat',
'Number',
'URIError',
'encodeURIComponent',
'RangeError',
'ReferenceError',
'RegExp',
'Array',
'isNaN',
** 'setTimeout',
** 'console',
'Date',
'Infinity',
'Uint32Array',
'Boolean',
'Float32Array',
'Error',
** 'root',
'NaN',
** 'module',
'Uint8Array',
'DataView',
** 'require',
'Int32Array',
'String',
'Function',
'Math',
'undefined',
'encodeURI',
'Int16Array',
'escape',
'unescape',
** 'process',
'decodeURIComponent',
'EvalError',
** 'clearTimeout',
** 'GLOBAL',
'Int8Array',
** 'setInterval',
'Float64Array',
'SyntaxError',
'Object',
'eval',
** 'global',
'Uint16Array',
'parseInt',
'ArrayBuffer',
'JSON',
'isFinite' ]

The ones marked with ** ?
--
Jorge.

[arunoda.s...@gmail.com]

I Think someone can figure it out whether this global exists or not if its null.
That's why I think.

[Jorge]

I think that instead of launching a new node process and then try to disable all its node-specific functionality, perhaps you could just launch a plain vanilla JS whose only io were nothing but a print() (such as d8 or jsc), and receive its output by reading its stdout.

-- 

Jorge.

[Jorge]

But *setting* it to undefined is not the same thing as *deleting* it...

-- 

Jorge.

[Bruno Jouhier]

You may be able to identify some never ending loops but you won't be
able to identify all of them. You need to introduce a different, non
Turing-complete, language to do this. See http://en.wikipedia.org/wiki/Halting_problem

If you want to stay with Javascript you have no choice but spawn
processes and monitor their CPU usage to kill them if they get into an
infinite (or just very long) loop. And you have to take the preventive
measures that Bradley describes.


On Oct 24, 6:13 am, "arunoda.susirip...@gmail.com"

<arunoda.susirip...@gmail.com> wrote:
> Here is the situation
> We are building an integration engine for an system where there are serveral
> inputs and outputs.
> We allow end users to create custom integration by providing flow chart like
> controls.
> But sometimes some complex manipulation can be easily created using
> scripting languages.
> So we do allows custom Javascript to do that
>
> So this javascript code should not contain any Io or network stuff.
> Only pure ecma JS.
>
> So we are trying to find a way for it to acheice with NodeJs.
> Some problems we are facing is
>
> 1. Block users from accessing NodeJs apis
> 2. Identify or prevent never ending loops.
>
> Hope this will help to help us to do the job :-)
>
> Thanks.
>

> On Monday, October 24, 2011, Damianos Mylonakis <danmylona...@gmail.com>

> wrote:> Why do you need to allow users to do calculations in JS?
> > Can you give a usage example?
>
> > Usually if you're going to run user code on your machine, you would do
>
> that with help of other software eg VMs, selinux etc.> That, in order to be sure you have blocked operations on the filesystem,
> network etc.
> > I mean, if we find out a way to solve your problem in another way, then
>
> there is no need for the hassle :)
>
> > @danmilon.
>

> > On 10/24/2011 12:40 AM, arunoda.susirip...@gmail.com wrote:
>
> > Okai. Then what would be the approach? any suggestions?
>

> > On Mon, Oct 24, 2011 at 2:03 AM, Jann Horn <jannh...@googlemail.com>

> wrote:
>
> >> What about (function(){}).constructor? Really, this is the wrong
>
> approach, please stop this.
>

> >> Am 23.10.2011 14:44 schrieb "arunoda.susirip...@gmail.com" <
>
> arunoda.susirip...@gmail.com>:

>
> >> Hi,
> >> I've done measures to prevent Function Constructor [0]
> >> See whether it is working or not.
> >> [0] -
>

> https://github.com/arunoda/jailguard/commit/0c8c12342cfdeb8de951a8018...>> cheers.
>
> >> On Sun, Oct 23, 2011 at 5:18 PM, arunoda.susirip...@gmail.com <
> arunoda.susirip...@gmail.com> wrote...

> @arunoda <http://twitter.com/arunoda>
> <http://gplus.to/arunoda>https://github.com/arunodahttp://www.linkedin.com/in/arunoda

[Bruno Jouhier]

BTW, just saw announcement about node-kiwf on the mailing list. This
might help you.

On Oct 24, 8:45 am, Bruno Jouhier <bjouh...@gmail.com> wrote:
> You may be able to identify some never ending loops but you won't be
> able to identify all of them. You need to introduce a different, non

> Turing-complete, language to do this. Seehttp://en.wikipedia.org/wiki/Halting_problem

[arunoda.s...@gmail.com]

Thanks yes, I just saw that. I think yes it would be. :-)
This is very useful.
Thank you all.

[Jorge]

On 24/10/2011, at 08:27, Jorge wrote:

> I think that instead of launching a new node process and then try to disable all its node-specific functionality, perhaps you could just launch a plain vanilla JS whose only io were nothing but a print() (such as d8 or jsc), and receive its output by reading its stdout.

Forget jsc, it's got debug, run and load. (and a nice readline). Perhaps node would need a switch to launch it in plain-vanilla-js mode: node --plainVanillaJS srcFile.js ?

$ jsc
> Object.getOwnPropertyNames(function(){return this}()).toString().replace(/\,/g,'\n')
Math
NaN
undefined
Infinity
JSON
Object
Function
Array
Boolean
String
Number
Date
RegExp
Error
EvalError
RangeError
ReferenceError
SyntaxError
TypeError
URIError
eval
** debug
print
quit
gc
version
** run
** load
** checkSyntax
readline
preciseTime
arguments
encodeURIComponent
decodeURIComponent
unescape
isFinite
parseFloat
isNaN
parseInt
encodeURI
escape
decodeURI

--
Jorge

[Isaac Schlueter]

You realize that what you're discussing here is a blacklist, which has
been shown again and again to be an ineffective approach to security?
If you have any thread back to the original context at all, it's going
to be a hole. You'll never plug all of them. The only effective
security is a small whitelist of allowed behaviors, in an isolated
environment, where every message coming out is scrutinized by the
parent process.

Just run the code in a child process, as a user with no privileges, in
a chroot (or better yet, a vm/zone/jail), monitor the memory usage and
kill it after a timeout, and if you must, communicate with it through
message-passing only. It's not perfect, but you can be damn sure that
your operating system is a lot better at this sort of thing than any
of us are, and it's a lot easier than the hoops that everyone is
trying to jump through here.

All the stuff about restricting globals or whatever is kind of
pointless at that point. Just lock down the underlying system, and
then it doesn't matter.

[arunoda.s...@gmail.com]

Issac ++

I think I got the answer :) 

[Marcel Laverdet]

http://code.google.com/p/google-caja/

[Mark S. Miller]

[+cowbertvonmoo]

On Mon, Oct 24, 2011 at 2:25 AM, Marcel Laverdet <mar...@laverdet.com> wrote:

http://code.google.com/p/google-caja/

Hi Marcel, thanks. Since NodeJS is a) not a browser, and b) can run a recent version of v8 which is adequately compliant with EcmaScript 5, the most relevant portion is SES (Secure EcmaScript), which achieves these security properties without translation. See <http://code.google.com/p/google-caja/source/browse/trunk/src/com/google/caja/ses/>, also found at <http://code.google.com/p/es-lab/>. The initSES.js script which is built from these sources is at <http://es-lab.googlecode.com/svn/trunk/src/ses/initSES.js> or <http://es-lab.googlecode.com/svn/trunk/src/ses/initSES-minified.js>. 

To see whether a given browser's ES5 implementation is adequate to support SES without translation, visit <http://google-caja.googlecode.com/svn/trunk/src/com/google/caja/ses/explicit.html> in that browser. Chrome 16.0.912.10 canary passes, as does WebKit Nightly. The development tips of all other major browsers are expected to pass shortly.

My presentations and interview at the QCon SF and QCon London, at <http://www.infoq.com/presentations/From-E-to-EcmaScript>, <http://www.infoq.com/interviews/ecmascript-5-caja-retrofitting-security>, and <http://www.infoq.com/presentations/Secure-Distributed-Programming>, explain more about SES and the next steps we plan to take -- Distributed Resilient Secure EcmaScript (Dr. SES) -- which is essentially SES plus Kris Kowal's Q library, all of which Kris has gotten running on NodeJS.

--
    Cheers,
    --MarkM

[Jorge]

On 24/10/2011, at 10:12, Isaac Schlueter wrote:
>
> All the stuff about restricting globals or whatever is kind of
> pointless at that point. Just lock down the underlying system, and
> then it doesn't matter.

It's been bradl...@joyent.com who suggested that.

In any case, it does not matter what functionality node provides as long as you don't have access to it.

And given that all of node functionality comes from a bunch of globals (afaics), if you just delete them soon enough, the game of node is over, and you're left with a plain vanilla JS vm.

Or not?
--
Jorge.

[Bradley Meck]

All globals are reasonable to remove. The child context will get new built-ins, except setTimeout/setInterval.

Set it to undefined instead of null (this could be using the delete operator it does not really matter). Object.getPrototypeOf(null) gets the object prototype, and allows prototype attacks should someone get a reference to the parent context (possible if leaking closure from type coersion etc. via your communication layer).

If you really need the globals for later, just cache a reference to them.

[Jann Horn]

Not necessarily. arguments.callee.caller.caller.arguments for example even can get out of the jail context.

Am 24.10.2011 16:00 schrieb "Jorge" <jo...@jorgechamorro.com>:

On 24/10/2011, at 10:12, Isaac Schlueter wrote:
>

> All the stuff about restricting globals or what...

It's been bradl...@joyent.com who suggested that.

In any case, it does not matter what functionality node provides as long as you don't have access to it.

And given that all of node functionality comes from a bunch of globals (afaics), if you just delete them soon enough, the game of node is over, and you're left with a plain vanilla JS vm.

Or not?
--
Jorge.

--
Job Board: http://jobs.nodejs.org/

Posting guidelines: https://github.com/joyent/node/wiki/Mail...

[Bradley Meck]

It should be a strict mode function as your communication channel, this will break the caller chain as well as avoid argument injection.

[arunoda.s...@gmail.com]

I just heard about JS strict mode (http://javascriptweblog.wordpress.com/2011/05/03/javascript-strict-mode/)

So bad :)

Seems interesting

On Mon, Oct 24, 2011 at 8:32 PM, Bradley Meck <bradle...@gmail.com> wrote:

It should be a strict mode function as your communication channel, this will break the caller chain as well as avoid argument injection.

--
Job Board: http://jobs.nodejs.org/

Posting guidelines: https://github.com/joyent/node/wiki/Mailing-List-Posting-Guidelines
You received this message because you are subscribed to the Google
Groups "nodejs" group.
To post to this group, send email to nod...@googlegroups.com
To unsubscribe from this group, send email to
nodejs+un...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/nodejs?hl=en?hl=en

[Jorge]

On 24/10/2011, at 16:44, Bradley Meck wrote:

> All globals are reasonable to remove. The child context will get new built-ins, except setTimeout/setInterval.

setTimeout/setInterval leak some (and perhaps it's something to worry about) internal details:

setTimeout(Array,22222)
{ _idleTimeout: 22222,
_onTimeout: [Function: Array],
_idlePrev: { repeat: 22, _idleNext: [Circular], _idlePrev: [Circular], callback: [Function] },
_idleNext: { repeat: 22, _idleNext: [Circular], _idlePrev: [Circular], callback: [Function] },
_idleStart: Mon, 24 Oct 2011 16:04:25 GMT }

> Set it to undefined instead of null (this could be using the delete operator it does not really matter). Object.getPrototypeOf(null) gets the object prototype

Not in my book:

Object.getPrototypeOf(null)
TypeError: Object.getPrototypeOf called on non-object
at Function.getPrototypeOf (native)
at repl:1:8
at Interface.<anonymous> (repl.js:168:22)
at Interface.emit (events.js:67:17)
at Interface._onLine (readline.js:153:10)
at Interface._line (readline.js:408:8)
at Interface._ttyWrite (readline.js:585:14)
at ReadStream.<anonymous> (readline.js:73:12)
at ReadStream.emit (events.js:88:20)
at ReadStream._emitKey (tty_posix.js:306:10)

> , and allows prototype attacks should someone get a reference to the parent context (possible if leaking closure from type coersion etc. via your communication layer).
>
> If you really need the globals for later, just cache a reference to them.

Exactly.

But, how would it (the node child process) write to stdout without node's functionality ?
--
Jorge.

[Arthur Blake]

I have the same need as Arunoda. It seems like there ought to be a
NodeJS built in way to provide a custom JS context/global object in
the same way the browser does. After all, this is why JavaScript was
first invented, right? In order to provide a light, sandboxed
scripting environment on top of some heavier weight APIs (like the
DOM.) JS is embedded in many other tools in this way (I know Rhino
has a mechanism for doing this...)

On Oct 24, 4:12 am, Isaac Schlueter <i...@izs.me> wrote:
> You realize that what you're discussing here is a blacklist, which has
> been shown again and again to be an ineffective approach to security?
> If you have any thread back to the original context at all, it's going
> to be a hole.  You'll never plug all of them.  The only effective
> security is a small whitelist of allowed behaviors, in an isolated
> environment, where every message coming out is scrutinized by the
> parent process.
>
> Just run the code in a child process, as a user with no privileges, in
> a chroot (or better yet, a vm/zone/jail), monitor the memory usage and
> kill it after a timeout, and if you must, communicate with it through
> message-passing only.  It's not perfect, but you can be damn sure that
> your operating system is a lot better at this sort of thing than any
> of us are, and it's a lot easier than the hoops that everyone is
> trying to jump through here.
>
> All the stuff about restricting globals or whatever is kind of

> pointless at that point.  Just lockdownthe underlying system, and

> > To post to this group, send email tono...@googlegroups.com

[Jorge]

On 24/10/2011, at 10:12, Isaac Schlueter wrote:

> You realize that what you're discussing here is a blacklist, which has
> been shown again and again to be an ineffective approach to security?
> If you have any thread back to the original context at all, it's going
> to be a hole. You'll never plug all of them. The only effective
> security is a small whitelist of allowed behaviors, in an isolated
> environment, where every message coming out is scrutinized by the
> parent process.
>
> Just run the code in a child process, as a user with no privileges, in
> a chroot (or better yet, a vm/zone/jail), monitor the memory usage and
> kill it after a timeout, and if you must, communicate with it through
> message-passing only. It's not perfect, but you can be damn sure that
> your operating system is a lot better at this sort of thing than any
> of us are, and it's a lot easier than the hoops that everyone is
> trying to jump through here.

Isaac,

Would you mind to explain a little bit more how would one do that, step by step :-) please ?

What exactly would not work when run as a user with no privileges ?

Is it really better to leave broken functionality there and let things fail (e.g. get an error on createServer()) than to make things unavailable (e.g., a node that did not require any of its core modules, and does not provide require() nor a way to require them) ?

Thanks in advance,
--
Jorge.

[arunoda.s...@gmail.com]

With the all the complex stuff we are discussing in this thread.

I feel it would be great to move into Rhino based solution with Jailed OS Setup.

Communicating with nodeJS over redis by passing messages.

To post to this group, send email to nod...@googlegroups.com

To unsubscribe from this group, send email to
nodejs+un...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/nodejs?hl=en?hl=en

[dvbportal]

This is not a use case node.js was made for. The opposite is true. Node.js creates a powerful environment where everything is accessible and controllable via JS. Several posts here referred to Rhino and I agree that this is the way to go. Rhino runs isolated on the JVM. You can use class shutters to restrict access to every function you want to forbid. For instance without IO classes you can never reach the file system out of the VM. You have access to the byte code counter where you can abort execution after a specified number of VM cycles.

[arunoda.s...@gmail.com]

I agree with you since NodeJS is built for letting us to use IO and Network with JavaScript in a non blocking way. Not just as an JS embedding platform (but somewhat possible).

And Rhino's case is other way around.

On Mon, Oct 24, 2011 at 11:05 PM, dvbportal <dvbp...@gmail.com> wrote:

This is not a use case node.js was made for. The opposite is true. Node.js creates a powerful environment where everything is accessible and controllable via JS. Several posts here referred to Rhino and I agree that this is the way to go. Rhino runs isolated on the JVM. You can use class shutters to restrict access to every function you want to forbid. For instance without IO classes you can never reach the file system out of the VM. You have access to the byte code counter where you can abort execution after a specified number of VM cycles.

--

Job Board: http://jobs.nodejs.org/
Posting guidelines: https://github.com/joyent/node/wiki/Mailing-List-Posting-Guidelines
You received this message because you are subscribed to the Google
Groups "nodejs" group.
To post to this group, send email to nod...@googlegroups.com
To unsubscribe from this group, send email to
nodejs+un...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/nodejs?hl=en?hl=en

[Bradley Meck]

setTimeout / setInterval are not provided by a context, those are provided by node:

> vm=require('vm');vm.runInNewContext('setTimeout');

ReferenceError: setTimeout is not defined

Good to know Object.getPrototypeOf doesn't work, but at one point I think it did. Either way, typeof null === 'object' and that just worries me.

You could write to stdout by providing a wrapper to console via deep copies created in the user code context.

1. deep copy console from inside user context

2. follows rules listed for a comm channel (you are passing messages telling something to perform an action, in this case what to print).

3. your copy can communicate to the real console via a cached closure variable.

[Arthur Blake]

By the way, if you are using Java 6 or above, you can use the Java
Scripting API (which is really just Rhino rebranded and included as
part of the official JVM.) The only pity (in my mind) with reverting
to that solution is that you lose the super high performance of NodeJS/
V8. But if you are doing something simple it might be just the
ticket.

On the other hand, I think exploring the avenue of using something
akin to Caja or Adsafe to pre-parse/compile the entire JS to make it
safe so that it can run in the NodeJS without worry is an intriguing
idea to explore.

[Marcel Laverdet]

Ah very cool. I wasn't sure if v8 or SES had matured to the point where they should be used over Caja. That's good to hear!

@arunoda I highly recommend taking Mark Miller's advice above :-p

[arunoda.s...@gmail.com]

But I'm not so good about it since all of those are designed for Browsers but Node is different? What about that?

[Marcel Laverdet]

How is Node different? Only difference is that Node can use a more modern version of JS which makes your job easier.

To be clear you are working on a very difficult problem. There is no "good enough" solution for this. You need to do it the right way from the start or you will be facing dire problems in the future. Look at es-lab which Mark linked to above.

[arunoda.s...@gmail.com]

This is what it says at http://code.google.com/p/es-lab/

    var compartment1 = makeMembrane(cajaVM.eval);


    var eval1 = compartment1.wrapper;


    var gate1 = compartment1.gate;


    var badCode = //... obtain potentially malicious code from somewhere ...


    var result = eval1(badCode);


    //... use result ...
    gate1.revoke();


    //... contents of compartment gone and collectible ...

I feel this is something like vm module in node? isn't it?

If yes then I still need to go through bradley.meck's  recommendations. Am I correct?

Some one can clarify on this?