ofbiz-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Muhammad Aamir <m...@aamir.pk>
Subject Re: Calling service remotely - security concern
Date Fri, 02 Jul 2010 01:19:36 GMT
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 <scott.gray@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" <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
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message