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

On Wed, 04 May 2005 12:57:23 +0200, Jan Grant <Jan.Grant@bristol.ac.uk>  
wrote:

> On Wed, 4 May 2005, Attila Szegedi wrote:
>
>> 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.
>
> Many thanks, I'd already come across this, but it's nice to have it
> confirmed. (Is there a handy way to tweak the behaviour of
> initStandardObjects() or do I need to hack away at the rhino
> implementation?)
>

No need to hack Rhino internals, just call  
ScriptableObject.deleteProperty() for these objects after you have  
initialized the scope:

....
Context.initStandardObject(scope);
ScriptableObject.deleteProperty(scope, "Packages");
ScriptableObject.deleteProperty(scope, "java");
ScriptableObject.deleteProperty(scope, "getClass");
....

> I'm still sticking together a bunch of test cases that demonstrate the
> functionality I'd like to be able to either turn off or have finer
> control over. It seems like the untrusted JS route is one quite a few
> people have gone down already (like the Batik guys) - I was mostly
> hoping that that wisdom was already summarised somewhere :-)

It'd indeed be nice if it was -- my system only runs internally deployed  
scripts, so I'm not facing this problem for now...

>
> Cheers,
> jan
>

Cheers
   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

.