Perhaps the rmi services can be grouped to several groups and open them to different ports.
在 2010-07-01四的 03:27 -0600，David E Jones写道： > This is kind of along the lines of how do we ensure that all code is secure. > Along with that service which would be a big security whole, what about a > service that gets all credit card numbers from the database and emails them > to whatever email address is passed in? > > There is probably no limit to the variations of code that would be considered > serious security breaches. If you can run code on the server, again... the > deal is blown. I guess that's why so many security issues involve some way of > either accessing the database directly, or getting code to run on the server. > > Some stuff you can avoid or at least discover with tar pits, honey pots, and > all variety of sticky things, but for every sticky thing there is a work > around if enough is known. They're still a good idea, but in many ways once > an attacker can run code on the server or get into the db then it's gonna be > a bad day for a bunch of people. > > -David > > > On Jul 1, 2010, at 3:09 AM, Scott Gray wrote: > > > Not necessarily direct access to the database but perhaps access to a > > service that is capable of returning another user's UserLogin record. > > > > I'm not sure if any services like that exist currently, my feeling is that > > it is very unlikely since there are few good reasons to return a UserLogin > > record of anyone other than the caller. So the question becomes should we > > hope that no one ever creates a service like that or should we attempt to > > deal with this potential scenario in the service engine somehow? > > > > Regards > > Scott > > > > On 1/07/2010, at 8:52 PM, David E Jones wrote: > > > >> > >> Do you mean like getting a UserLogin record from the database? If they > >> have access to the database then I don't know what can be done about > >> security. It seems like from that point the deal is blown... > >> > >> -David > >> > >> > >> On Jul 1, 2010, at 2:39 AM, Scott Gray wrote: > >> > >>>> Take a look at the service engine code. You'll see that even if you pass > >>>> in the userLogin GenericValue object the username/password are verified, > >>>> it isn't just accepted as pre-authenticated or something. > >>> > >>> Your response only appears to cover the scenario of a malicious user > >>> attempting to generate a fake UserLogin record on their own. If the > >>> UserLogin record came from the database (or is manufactured with a > >>> correct userLoginId and encrypted password) then authentication will > >>> succeed. After looking at the code in ServiceDispatcher.checkAuth(...) > >>> it looks to me like if an RMI user can somehow get hold of someone else's > >>> UserLogin record then they should be able to successfully impersonate > >>> that user. > >>> > >>> Regards > >>> Scott > >>> > >>> On 1/07/2010, at 8:23 PM, David E Jones wrote: > >>> > >>>> > >>>> I believe I addressed that in my original response. > >>>> > >>>> -David > >>>> > >>>> > >>>> On Jul 1, 2010, at 2:21 AM, Scott Gray wrote: > >>>> > >>>>> I think Muhammed's point is that once a user has authenticated using > >>>>> their own username/password, it is possible that they could retrieve > >>>>> another user's UserLogin record and then use it to execute services > >>>>> without needing to know that user's password. > >>>>> > >>>>> Regards > >>>>> Scott > >>>>> > >>>>> HotWax Media > >>>>> http://www.hotwaxmedia.com > >>>>> > >>>>> On 1/07/2010, at 7:58 PM, Jacques Le Roux wrote: > >>>>> > >>>>>> In your example you needed 1st to know the login/pwd couple. So I > >>>>>> can't see the problem here. > >>>>>> > >>>>>> Jacques > >>>>>> > >>>>>> From: "Muhammed Aamir" <[email protected]> > >>>>>>>>> All service where auth="true" take at least three IN (or INOUT) > >>>>>>>>> parameters > >>>>>>>>> by deffault 1) login.username 2) login.password and 3) loginUser. > >>>>>>>>> No. 1 and 2 definitely make sense. However 3 might be a security > >>>>>>>>> threat (or > >>>>>>>>> my understanding is wrong). Any user (calling service remotely) can > >>>>>>>>> pass > >>>>>>>>> loginUser GV (which he some how got hold of, may be by invoking > >>>>>>>>> getRelated > >>>>>>>>> sort of method on some other GV) which might not belong to her. > >>>>>> > >>>>>> Sent from my iPhone > >>>>>> > >>>>>> On Jul 1, 2010, at 1:42, David E Jones <[email protected]> wrote: > >>>>>> > >>>>>>>>>> All service where auth="true" take at least three IN (or INOUT) > >>>>>>>>>> parameters > >>>>>>>>>> by deffault 1) login.username 2) login.password and 3) loginUser. > >>>>>>>>>> No. 1 and 2 definitely make sense. However 3 might be a security > >>>>>>>>>> threat (or > >>>>>>>>>> my understanding is wrong). Any user (calling service remotely) > >>>>>>>>>> can pass > >>>>>>>>>> loginUser GV (which he some how got hold of, may be by invoking > >>>>>>>>>> getRelated > >>>>>>>>>> sort of method on some other GV) which might not belong to her. > >>>>>> > >>>>>> > >>>>> > >>>> > >>> > >> > > >
