Subj : Re: Rhino security cookbook for untrusted javascript?
To   : netscape.public.mozilla.jseng
From : Jan Grant
Date : Thu May 05 2005 06:28 pm

On Wed, 4 May 2005, Jan Grant wrote:

> Well, the other problem I'm facing is that the following snippet of 
> javascript still works ("raw" is bound to an external java object):
> 
>     var anotherObject = raw.getClass().newInstance(); // doh!
> 
> ... I might summarise what I'm after as this: I really don't want the 
> user to be scripting java using javascript; all I'm interested in is 
> them being able to script the objects I expose explicitly, with none of 
> this other jiggery-pokery.

Let me expand on this. The code all lives inside a webapp in tomcat, 
which supplies a pretty traditional SecurityManager implementation.

The webapp itself has objects which manage programmatic security within 
the webapp, assuming they're called correctly.

What I'd like to do is expose some of these objects to otherwise 
untrusted javascript code running inside rhino, so that the javascript 
snippets can get access to the functionality wrapped up in the exposed 
objects (filesystem access, that kind of thing) ONLY via method calls on 
the exposed objects.

However, method calls on those objects include the ability to chain 
things together such as 
	.getClass().getClass().forName("foo").newInstance()
....and so on.

Unfortunately, it appears (as far as I can tell) that if I use a 
security policy to limit the ability of javascript code to do this, then 
it also breaks rhino (because rhino needs some of the reflection 
permissions in order to operate). Also, because the tomcat security 
manager / policy implementation uses the principle of least privilege in 
a call stack, the objects exposed to javascript and methods called on 
those objects by javascript wind up without sufficient privilege to 
operate:

webapp -> myObject -> filesystem access:
	works
webapp -> rhino -> javascript -> bound myObject -> filesystem access:
	fails due to security restrictions on the rhino codebase.

One way around this appears to be to explicitly wrap the webapp objects 
with ScriptableObject wrappers; however, this means that I have to 
duplicate the class structure of the underlying webapp and wrap up lots 
of classes. Heavily modifying the third-party webapp itself isn't an 
option.

So I'm kind of stumped. If I'm missing something I'd love to know what 
it is :-)

Cheers,
jan

.