That is an interesting idea, ie not allowing a userLogin object for remote service calls, perhaps even for remote dispatcher calls.
-David On Jul 1, 2010, at 3:57 AM, Scott Gray wrote: > I agree that there is always a risk of developers unwittingly exposing > security holes and we can't protect them from the endless ways in which they > might achieve that. But if we could prevent this at the framework level from > ever occurring then shouldn't we consider doing so? I have no intention > (currently at least) of working on this, but if somebody wanted to would we > not allow them to do so? Perhaps the benefits of being able to pass in a > userLogin record from a remote service call outweigh the risks, I don't know. > > Regards > Scott > > On 1/07/2010, at 9:27 PM, David E Jones wrote: > >> >> 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. >>>>>>>> >>>>>>>> >>>>>>> >>>>>> >>>>> >>>> >>> >> >
