I'm neutral on the issue. If you do the release this time around I'm all for it :) I'd like to add a demo of jabsorb using the ExtJS framework and maybe get it into this release. Since you added most of the new features in 1.3, how stable do you think it is? Are the changes extensive enough that an RC build is warranted?
On Tue, Apr 1, 2008 at 8:53 PM, William Becker <[EMAIL PROTECTED]> wrote: > Re: issue34, > > It *should* be ok, so long as the user cannot access the calls of > JSONRPCBridge from javascript. I don't think this is possible so it ought to > be ok. If you are serious about security however, I would avoid releasing > any system classes out in the wild, just to be double careful. > > Given that we agree on this, pending input from Michael, should we go and > release 1.3 some time soon? > > Will > > > On Wed, Apr 2, 2008 at 12:15 AM, Arthur Blake <[EMAIL PROTECTED]> > wrote: > > > I agree with your analysis.. If > > http://issues.jabsorb.org/show_bug.cgi?id=34 were implemented, would > > that change anything? That would allow class objects themselves to be > > serialized... > > I guess the bridge is the ultimate stopper in that you can't call > > anything at all unless it is explicitly registered. If someone registers > > something stupid, like File or the System object (is that even possible?) > > then they are playing with fire... > > > > On Tue, Apr 1, 2008 at 2:03 AM, William Becker <[EMAIL PROTECTED]> > > wrote: > > > > > 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.2release 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 > > > > > > > > > > _______________________________________________ > > Jabsorb-dev mailing list > > [email protected] > > http://lists.jabsorb.org/mailman/listinfo/jabsorb-dev > > > > > > _______________________________________________ > Jabsorb-dev mailing list > [email protected] > http://lists.jabsorb.org/mailman/listinfo/jabsorb-dev > >
_______________________________________________ Jabsorb-dev mailing list [email protected] http://lists.jabsorb.org/mailman/listinfo/jabsorb-dev
