Hi all,
I'm trying to see what we need to do to satisfy the Security Policy issue in
the bugtracker: http://issues.jabsorb.org/show_bug.cgi?id=7, so I'm writing
a list of ways you can exploit our code to access the server, to see what we
need to prevent.
On the unit test page, I can run the following from the console of FireBug:
JSONRpcClient._sendRequest(jsonrpc,{data:'{id:2,method:"test.concat",params:["a",
"b"]}'});
This will do a synchronous call and get the result. This is just emulating
what happens when you make a normal call, so it doesn't seem to be anything
to worry about. It does allow users to inject arbitary code to the server,
but there is no way of preventing users from doing this. As I will show, the
server is good at filtering out bogus requests. However it does give us an
easy hook into sending messages to the server.
So, the next thing we want to do is try to call some malicious code on the
server, eg accessing a File object. To do this isn't easy, since we need to
convince the bridge to do this for us. To convince the bridge to do this, we
need to be able to register classes, objects and callable references. This
is the first thing that I am trying to attack. Ideally I should be able to
go:
JSONRpcClient._sendRequest(jsonrpc,{data:'{id:2,method:"bridge.registerClass
",params:["className"]}'});
There are 2 problems here:
* how do I get access to the bridge?
The only way is if it is itself registered (which can only be done on
the servlet/jsp), eg JSONRPCBridge.registerObject("bridge",
JSONRPCBridge);
* The bridge's register class method takes a java.lang.Class as an arg, not
a string. How do I create a Class?
The only way to create a class is to firstly have it registered as a
reference type (which can only be done on the servlet/jsp) and then to have
it return by some Java object which is registered on the server. Note that
getClass() cannot be called on any callable reference, since
ClassAnalyzer.createMap() prevents methods from java.lang.Object from being
called.
So I don't think this can be done in any normal way, on the 1.2 release of
Jabsorb.
The trunk, on the other hand, has the ability to create constructors. Does
this help us exploit Jabsorb?
Not really. To access a constructor, it needs to be provided by the servlet.
This requires two things:
* The class which is to be constructed needs to be registered on the bridge
eg: JSONRPCBridge.registerClass("ConstructorTest",
org.jabsorb.test.ConstructorTest.class);
* The object which is constructed also needs to be registered as a
reference type:
eg: JSONRPCBridge.registerCallableReference(
org.jabsorb.test.ConstructorTest.class);
So is it possible for a user to maliciously attack your server using
Jabsorb?
Yes, but only if you are *really* careless. You need to register
JSONRPCBridge as an object and register the class java.lang.Class as a
reference and furthermore have some way of creating classes through your own
objects. So I would suggest that so long as you do not do this, you should
be safe.
One further issue would be if clients can create their own servlets/jsps and
run them on your server. Through doing this, they should be able to register
anything they want. But if they can do this, they don't need Jabsorb to
cause you grief!
In conclusion, I do not think that the security policy issue is very
relevant. Jabsorb's method of registering all resources that are given to
the user provides a robust way of ensuring that only the code you want can
be run and prevents clients from injecting malicious code into your system.
If anyone can think of any methods that I have overlooked, please let me
know. Otherwise I would recommend releasing Jabsorb 1.3 (containing
Constructors) soon into the community as the next version, without worrying
about implementing Security Policies.
Cheers,
Will
_______________________________________________
Jabsorb-dev mailing list
[email protected]
http://lists.jabsorb.org/mailman/listinfo/jabsorb-dev
