You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@ofbiz.apache.org by David E Jones <de...@me.com> on 2010/07/01 00:42:20 UTC
Re: Calling service remotely - security concern
What sort of comment were you hoping for?
-David
On Jun 30, 2010, at 1:49 PM, Muhammed Aamir wrote:
> Any comments?
>
>
> On Jun 28, 2010, at 18:20, Muhammad Aamir <ma...@aamir.pk> wrote:
>
>> I didn't dare to to see the service engine code. However, I just called a service and passed only userLogin GV and was able to execute the service (without passing username/password):
>>
>> Map res = rd.runSync("userLogin", UtilMisc.toMap("login.username",
>> "admin", "login.password", "ofbiz"));
>> System.out.println(res.get("responseMessage"));
>> System.out.println(res.get("errorMessage"));
>> System.out.println(res.get("successMessage"));
>>
>> GenericValue gv = (GenericValue)res.get("userLogin");
>>
>> res = rd.runSync("someService", UtilMisc.toMap("userLogin", gv));
>> System.out.println(res.get("responseMessage"));
>> System.out.println(res.get("errorMessage"));
>> System.out.println(res.get("successMessage"));
>>
>>
>> Regards
>>
>> On Mon, Jun 28, 2010 at 6:06 PM, David E Jones <de...@me.com> wrote:
>>
>> One quick point: it's userLogin, not loginUser.
>>
>> 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.
>>
>> -David
>>
>>
>> On Jun 28, 2010, at 8:54 AM, Muhammad Aamir 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.
>>>
>>> Regards
>>
>>
Re: Calling service remotely - security concern
Posted by David E Jones <de...@me.com>.
On Jul 1, 2010, at 7:48 PM, Scott Gray wrote:
> On 2/07/2010, at 1:19 PM, Muhammad Aamir wrote:
>
>> Many records have a related userLogin record. For example createdBy field
>> can return the userLogin who created the record which might not be the same
>> as the logged in user. (I know you cannot execute getRelated etc. method
>> remotely but one can create facade etc as a work around).
>
> This isn't a security issue unless a service exposes another user's UserLogin record, userLoginId is not enough. This doesn't happen OOTB as far as I can tell, so for this to be a security issue someone would have to write a custom service to expose it.
Keep in mind that such a service would (or should...) be an obvious security hole. The UserLogin entity includes both the username and password, and even though the password is encrypted that is still a vulnerability.
-David
Re: Calling service remotely - security concern
Posted by Scott Gray <sc...@hotwaxmedia.com>.
On 2/07/2010, at 1:19 PM, Muhammad Aamir wrote:
> Many records have a related userLogin record. For example createdBy field
> can return the userLogin who created the record which might not be the same
> as the logged in user. (I know you cannot execute getRelated etc. method
> remotely but one can create facade etc as a work around).
This isn't a security issue unless a service exposes another user's UserLogin record, userLoginId is not enough. This doesn't happen OOTB as far as I can tell, so for this to be a security issue someone would have to write a custom service to expose it.
> One way to deal with it is to do authentication using login.username and
> login.password in service engine and not rely only upon userLogin GV, as
> earlier assumed (or suggested by David "Take a look at the service engine
> code.
There is no reason why OFBiz can't internally make use of the userLogin object (and it does, heavily) for authentication. If we want to close this potential hole then it would need to be a solution specific to exported services.
You are most welcome to create a jira issue describing the problem and either submit a fix or wait for someone else to.
> 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.").
>
> Regards
>
>
> On Thu, Jul 1, 2010 at 12:09 PM, Scott Gray <sc...@hotwaxmedia.com>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" <ma...@aamir.pk>
>>>>>>>>>> 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 <de...@me.com> 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.
>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>>
Re: Calling service remotely - security concern
Posted by Muhammad Aamir <ma...@aamir.pk>.
Many records have a related userLogin record. For example createdBy field
can return the userLogin who created the record which might not be the same
as the logged in user. (I know you cannot execute getRelated etc. method
remotely but one can create facade etc as a work around).
One way to deal with it is to do authentication using login.username and
login.password in service engine and not rely only upon userLogin GV, as
earlier assumed (or suggested by David "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.").
Regards
On Thu, Jul 1, 2010 at 12:09 PM, Scott Gray <sc...@hotwaxmedia.com>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" <ma...@aamir.pk>
> >>>>>>>> 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 <de...@me.com> 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.
> >>>>>
> >>>>>
> >>>>
> >>>
> >>
> >
>
>
Re: Calling service remotely - security concern
Posted by Shi Jinghai <sh...@langhua.cn>.
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" <ma...@aamir.pk>
> >>>>>>>>> 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 <de...@me.com> 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.
> >>>>>>
> >>>>>>
> >>>>>
> >>>>
> >>>
> >>
> >
>
Re: Calling service remotely - security concern
Posted by David E Jones <de...@me.com>.
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" <ma...@aamir.pk>
>>>>>>>>>>> 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 <de...@me.com> 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.
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>
Re: Calling service remotely - security concern
Posted by Scott Gray <sc...@hotwaxmedia.com>.
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" <ma...@aamir.pk>
>>>>>>>>>> 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 <de...@me.com> 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.
>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>
Re: Calling service remotely - security concern
Posted by David E Jones <de...@me.com>.
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" <ma...@aamir.pk>
>>>>>>>>> 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 <de...@me.com> 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.
>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>
Re: Calling service remotely - security concern
Posted by Scott Gray <sc...@hotwaxmedia.com>.
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" <ma...@aamir.pk>
>>>>>>>> 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 <de...@me.com> 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.
>>>>>
>>>>>
>>>>
>>>
>>
>
Re: Calling service remotely - security concern
Posted by David E Jones <de...@me.com>.
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" <ma...@aamir.pk>
>>>>>>> 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 <de...@me.com> 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.
>>>>
>>>>
>>>
>>
>
Re: Calling service remotely - security concern
Posted by Scott Gray <sc...@hotwaxmedia.com>.
> 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" <ma...@aamir.pk>
>>>>>> 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 <de...@me.com> 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.
>>>
>>>
>>
>
Re: Calling service remotely - security concern
Posted by David E Jones <de...@me.com>.
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" <ma...@aamir.pk>
>>>>> 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 <de...@me.com> 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.
>>
>>
>
Re: Calling service remotely - security concern
Posted by Scott Gray <sc...@hotwaxmedia.com>.
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" <ma...@aamir.pk>
>>>> 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 <de...@me.com> 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.
>
>
Re: Calling service remotely - security concern
Posted by Jacques Le Roux <ja...@les7arts.com>.
In your example you needed 1st to know the login/pwd couple. So I can't see the problem here.
Jacques
From: "Muhammed Aamir" <ma...@aamir.pk>
>>> 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 <de...@me.com> 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.
Re: Calling service remotely - security concern
Posted by Muhammed Aamir <ma...@aamir.pk>.
>>> 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 <de...@me.com> 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.