Subj : Re: Rhino security cookbook for untrusted javascript?
To   : netscape.public.mozilla.jseng
From : Norris Boyd
Date : Wed May 04 2005 11:04 am

Take a look at ClassShutter 
(http://www.mozilla.org/rhino/apidocs/org/mozilla/javascript/ClassShutter.html) 
and SecurityController 
(http://www.mozilla.org/rhino/apidocs/org/mozilla/javascript/SecurityController.html). 


ClassShutter can be used to control visiblity of classes to untrusted 
JavaScript classes and is the recommended approach rather than just 
deleting the top-level objects like "Packages" and "java".

SecurityController implements three main pieces of functionality for 
security in JavaScript. From the javadoc: "First, it must be possible to 
define classes with an associated security domain. (This security domain 
may be any object incorporating notion of access restrictions that has 
meaning to an embedding; for a client-side JavaScript embedding this 
would typically be java.security.ProtectionDomain or similar object 
depending on an origin URL and/or a digital certificate.) Next it must 
be possible to get a security domain object that allows a particular 
action only if all security domains associated with code on the current 
Java stack allows it. And finally, it must be possible to execute script 
code with associated security domain injected into Java stack."

I'm not familiar with SecurityController so I can't speak to the 
situations when you'd need it beyond what's in the javadoc.

--Norris

jan grant wrote:
> [Would appreciate a CC: as well as newsgroup followup - cheers]
> 
> Hullo. I've got an application that runs under an external security manager
> already (it's a webapp).
> 
> The app has its own internal security model: most operations take a user object
> as a parameter and utilise the capabilities of that to determine if actions are
> permissable. So far, pretty straight-forward.
> 
> However, what I'd like to do is get the app to the point where external users
> can upload and execute scripts (written in javascript, natch). In consequence,
> these scripts are effectively untrusted and I need very careful control over
> the objects and interfaces they can access.
> 
> Assuming for the moment that the objects I expose to the javascript code are
> "smart enough" and well-written enough so that calling them via their main
> interfaces doesn't pose a problem in and of itself...
> 
> ... what I'd like to know is, what else is there that I need to worry about? In
> particular, I'm concerned about javascript getting hold of class objects, or
> classloaders, and accessing singletons that way; of using Class.forName and
> newInstance() to create objects I wasn't anticipating; of using reflection to
> access objects or methods that I wasn't anticipating. And so on and so forth.
> 
> I've yet to find a "cookbook" that details these kinds of considerations.
> 
> I'd appreciate any feedback on this subject.
> 
> Many thanks!
>

.