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

If you perform an initStandardObjects() on your top level scopes, then you  
will want to remove the standard objects "Packages", "java", and  
"getClass" -- they give access to class loading facilities. I'm not 100%  
certain about what standard objects "JavaAdapter" and "JavaImporter" do,  
but if you know your script writers won't need it, remove them too just in  
case.

This is probably not the only tweaking you need to do -- this is just what  
I remembered offhand.

Attila.

-- 
home: http://www.szegedi.org
weblog: http://www.jroller.com/page/aszegedi
Visit Szegedi Butterfly fractals at:
   http://www.szegedi.org/fractals/butterfly/index.html

On Thu, 28 Apr 2005 10:55:35 +0200, jan grant <jan.grant@bristol.ac.uk>  
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!

.