ofbiz-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David E Jones <d...@me.com>
Subject Re: Calling service remotely - security concern
Date Thu, 01 Jul 2010 09:27:11 GMT

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" <mail@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 <dejc@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.
>>>>>> 
>>>>>> 
>>>>> 
>>>> 
>>> 
>> 
> 


Mime
View raw message