Nov 12, 2009 at 8:31 PM

In our application, we have clients able to run scripts on the server.  There are several problems with this because it's possible to delete every file on the server if you have a malicious user.  It is also possible to do bad things to the database.

My question is this:  Is there a simple way to Sandbox a user based on some criteria to assist in this security problem?

As a follow up, would this be done at a level above your application, or within it?

Nov 13, 2009 at 12:52 AM

I really like Rhino's "SetClassShutter."  In summary, Rhino's "SetClassShutter" lets me specify a an object that decides if the Javascript can access a class or not.  You can also get creative and log which classes are being used, and selectively limit who has access to what.

In ObjectCloud, I use this to ensure that Javascript can only access functions and objects that I explicity grant it permission to use.

Sebastian recommends that I use .Net's MinimumTrust security context; but I really don't trust that it's an effective solution.  My call stack goes back and forth multiple times between (Rhino) Javascript and my C# code, so trying to sandbox the Javascript into its own AppDomain doesn't sit well with me.  Besides, I fear that a misplaced "eval" could allow a malicious party to eventually hit APIs that I just can't protect, or accidentally leave open.

So, I really need something like SetClassShutter, or, at minimum, a way to disable access to the underlying .Net framework so that scripts only interact with APIs that I explicitly grant them.

Nov 13, 2009 at 11:59 AM
GWBasic wrote:

So, I really need something like SetClassShutter, or, at minimum, a way to disable access to the underlying .Net framework so that scripts only interact with APIs that I explicitly grant them.

 That sounds like a possible solution(both ideas).

Without a SetClassShutter type functionality, eliminating access to the framework would work, especially if you could selectively do that.

Nov 13, 2009 at 2:12 PM

SetClassShutter is used in Rhino because Java is not a secured runtime, as oposed to .NET ;) Actually we have CAS so let's use it. Look at the following code:

 static void Main(string[] args)
     // create the permission set to grant other assemblies
     PermissionSet pset = new PermissionSet(PermissionState.None);
     pset.AddPermission(new FileIOPermission(PermissionState.None)); 

     catch (SecurityException e)


 static void DoWork()
         Console.WriteLine("Security breach attempt failed");


This shows that we can define the rights of any bunch of code. The rights can apply on any location/verb of the file system, network assets, and so on. PermissionSet makes it possible to define a set of rules (wether allow or deny). So why not let each developer define what is allowed for the scripts ? It's simple by default, and if security needs to be applied lets use JintEngine.PermissionSet !

We can then even let the script do some file system operation in a sand boxed folder if needed !

Nov 13, 2009 at 8:43 PM

That's too complicated.  Waaaaay too complicated.

I just want to disable all use of .Net from Javascript except for functions that I explicitly pass in through JintEngine.SetFunction(...).

Will something fundamental break if my application turns off access to the .Net framework?

Seriously, at this point I don't want to deal with the complexity of a permissions API / framework.

Nov 14, 2009 at 6:54 AM

Well this can't be easier. You may have missed something. Though I also understand your wish to disable any .NET access, thus I will add a property for it, like ClrEnabled. If false, scripts can't access Clr objects. If yes, you will be able to define resource permissions by setting PermissionSet.

Nov 14, 2009 at 9:01 AM

Thanks for the CAS example, it is brain dead easy!

However, I do see GW's point, especially in the case where you want to shut off the CLR entirely.

Good stuff!

Nov 15, 2009 at 1:50 PM

I have released this feature with version 0.8.5. You can find the documentation here:


Nov 16, 2009 at 6:08 AM

Awesome, thanks!