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. >>>> >>>> >>> >> >
