Mailing-List: contact user-help@ofbiz.apache.org; run by ezmlm
Precedence: bulk
Reply-To: user@ofbiz.apache.org
Received-SPF: pass (nike.apache.org: local policy)
From: Scott Gray <scott.gray@hotwaxmedia.com>
Mime-Version: 1.0 (Apple Message framework v1081)
Content-Type: multipart/signed; boundary=Apple-Mail-41--919599699;
 protocol="application/pkcs7-signature"; micalg=sha1
Subject: Re: Calling service remotely - security concern
Date: Fri, 2 Jul 2010 13:48:30 +1200
In-Reply-To: <AANLkTilSRLQcjhwsL3bxHxHzDm1ISfSbjZCaiqD50Zme@mail.gmail.com>
To: user@ofbiz.apache.org
References: <AANLkTimvcfGS-kj_S3bKpnTl3dJtdIW95nCILIKYidi8@mail.gmail.com>
  <1EE96E41-BF17-4187-BBEF-035E284128F8@me.com>
 <AANLkTilaCzJ_iZNN_WXu8FY5uTvsUL0bZgKTdmeicJxa@mail.gmail.com>
  <6431B6F4-87E5-4900-B7B2-6A45E2FA7610@aamir.pk>
 <4F2F4FE4-B1D9-4B3D-A7AF-291FDAED1DC8@me.com>
  <06098585-DFDC-48DA-92A8-3DBF72B17A91@aamir.pk>
 <2D15EDCFC5BA44FF8F657023BDDC5269@inspiron530>
  <AC4DED8F-88FA-4BBE-BF41-8A2FB153D906@hotwaxmedia.com>
 <17FEA4B4-D6F4-4213-87DE-FF6698AAFC86@me.com>
  <98FCB6F4-05DB-4316-AFCC-C1F08AC87F52@hotwaxmedia.com>
 <161E6410-6113-40AF-BC40-5942CBC8CA79@me.com>
  <366A73FE-2A2B-4F73-A48E-44C43635CD1E@hotwaxmedia.com>
 <AANLkTilSRLQcjhwsL3bxHxHzDm1ISfSbjZCaiqD50Zme@mail.gmail.com>
Message-Id: <5650E376-0116-418F-BCC9-E75885334C94@hotwaxmedia.com>

--Apple-Mail-41--919599699
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=us-ascii

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.").
>=20
> Regards
>=20
>=20
> On Thu, Jul 1, 2010 at 12:09 PM, Scott Gray =
<scott.gray@hotwaxmedia.com>wrote:
>=20
>> Not necessarily direct access to the database but perhaps access to a
>> service that is capable of returning another user's UserLogin record.
>>=20
>> 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?
>>=20
>> Regards
>> Scott
>>=20
>> On 1/07/2010, at 8:52 PM, David E Jones wrote:
>>=20
>>>=20
>>> 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...
>>>=20
>>> -David
>>>=20
>>>=20
>>> On Jul 1, 2010, at 2:39 AM, Scott Gray wrote:
>>>=20
>>>>> 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.
>>>>=20
>>>> 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.
>>>>=20
>>>> Regards
>>>> Scott
>>>>=20
>>>> On 1/07/2010, at 8:23 PM, David E Jones wrote:
>>>>=20
>>>>>=20
>>>>> I believe I addressed that in my original response.
>>>>>=20
>>>>> -David
>>>>>=20
>>>>>=20
>>>>> On Jul 1, 2010, at 2:21 AM, Scott Gray wrote:
>>>>>=20
>>>>>> 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.
>>>>>>=20
>>>>>> Regards
>>>>>> Scott
>>>>>>=20
>>>>>> HotWax Media
>>>>>> http://www.hotwaxmedia.com
>>>>>>=20
>>>>>> On 1/07/2010, at 7:58 PM, Jacques Le Roux wrote:
>>>>>>=20
>>>>>>> In your example you needed 1st to know the login/pwd couple. So =
I
>> can't see the problem here.
>>>>>>>=20
>>>>>>> Jacques
>>>>>>>=20
>>>>>>> From: "Muhammed Aamir" <mail@aamir.pk>
>>>>>>>>>> All service where auth=3D"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.
>>>>>>>=20
>>>>>>> Sent from my iPhone
>>>>>>>=20
>>>>>>> On Jul 1, 2010, at 1:42, David E Jones <dejc@me.com> wrote:
>>>>>>>=20
>>>>>>>>>>> All service where auth=3D"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.
>>>>>>>=20
>>>>>>>=20
>>>>>>=20
>>>>>=20
>>>>=20
>>>=20
>>=20
>>=20


--Apple-Mail-41--919599699
Content-Disposition: attachment;
	filename=smime.p7s
Content-Type: application/pkcs7-signature;
	name=smime.p7s
Content-Transfer-Encoding: base64

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIGPTCCBjkw
ggUhoAMCAQICEQDYl7EXGWhQIpBs19Ozq1G2MA0GCSqGSIb3DQEBBQUAMIGuMQswCQYDVQQGEwJV
UzELMAkGA1UECBMCVVQxFzAVBgNVBAcTDlNhbHQgTGFrZSBDaXR5MR4wHAYDVQQKExVUaGUgVVNF
UlRSVVNUIE5ldHdvcmsxITAfBgNVBAsTGGh0dHA6Ly93d3cudXNlcnRydXN0LmNvbTE2MDQGA1UE
AxMtVVROLVVTRVJGaXJzdC1DbGllbnQgQXV0aGVudGljYXRpb24gYW5kIEVtYWlsMB4XDTA5MTAx
NDAwMDAwMFoXDTEwMTAxNDIzNTk1OVowgeAxNTAzBgNVBAsTLENvbW9kbyBUcnVzdCBOZXR3b3Jr
IC0gUEVSU09OQSBOT1QgVkFMSURBVEVEMUYwRAYDVQQLEz1UZXJtcyBhbmQgQ29uZGl0aW9ucyBv
ZiB1c2U6IGh0dHA6Ly93d3cuY29tb2RvLm5ldC9yZXBvc2l0b3J5MR8wHQYDVQQLExYoYykyMDAz
IENvbW9kbyBMaW1pdGVkMRMwEQYDVQQDEwpTY290dCBHcmF5MSkwJwYJKoZIhvcNAQkBFhpzY290
dC5ncmF5QGhvdHdheG1lZGlhLmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBALNA
v8gB9OAet+B7Pm6SjpVHtavdj8RO5h75hmqYIu4gMhQmU/AJYL/pVddK85VQOMtJyngDvlKvlH5v
Xc8HwLyM3IsfrxrNzZ6mbwM1eU2BbISYMzB5BmDjieLe6xQ7sQBKPV3cSZbTAyDPs5qm/mj3jDBH
ynz5sSKcHDEvTAmubpD28mnROOSqIstApC8enFr/zMCMofL85DxOkqOjJlX0xUdvOrTaKqfk1Sej
ZJtSg0gZ5M2Tkfah/2/ALGVXKSh3cceHwuP3yMvv/uYllQZBRZiHehvTBP6qEENNxYC1LN4Zg/YD
h4+MieK2vMENUiv4qfrR5JKkaAl8A7EyI68CAwEAAaOCAhwwggIYMB8GA1UdIwQYMBaAFImCZ33E
nSZwAEu0UEh83j2uBG59MB0GA1UdDgQWBBSuGHgRPxvu0/VVHM/UmH0tUUO2sDAOBgNVHQ8BAf8E
BAMCBaAwDAYDVR0TAQH/BAIwADAgBgNVHSUEGTAXBggrBgEFBQcDBAYLKwYBBAGyMQEDBQIwEQYJ
YIZIAYb4QgEBBAQDAgUgMEYGA1UdIAQ/MD0wOwYMKwYBBAGyMQECAQEBMCswKQYIKwYBBQUHAgEW
HWh0dHBzOi8vc2VjdXJlLmNvbW9kby5uZXQvQ1BTMIGlBgNVHR8EgZ0wgZowTKBKoEiGRmh0dHA6
Ly9jcmwuY29tb2RvY2EuY29tL1VUTi1VU0VSRmlyc3QtQ2xpZW50QXV0aGVudGljYXRpb25hbmRF
bWFpbC5jcmwwSqBIoEaGRGh0dHA6Ly9jcmwuY29tb2RvLm5ldC9VVE4tVVNFUkZpcnN0LUNsaWVu
dEF1dGhlbnRpY2F0aW9uYW5kRW1haWwuY3JsMGwGCCsGAQUFBwEBBGAwXjA2BggrBgEFBQcwAoYq
aHR0cDovL2NydC5jb21vZG9jYS5jb20vVVROQUFBQ2xpZW50Q0EuY3J0MCQGCCsGAQUFBzABhhho
dHRwOi8vb2NzcC5jb21vZG9jYS5jb20wJQYDVR0RBB4wHIEac2NvdHQuZ3JheUBob3R3YXhtZWRp
YS5jb20wDQYJKoZIhvcNAQEFBQADggEBAJ6ziClX9Dz6y35D8yjDqnEcoBrkbWPMekTFuMBI8j7O
Wzz9ADIon1wgWGAuDKkaDi/RixEsx8WlESbcJX15egqICh09KtzjNg3G6IFHFtZH7Lkl9VX0zrS2
T409wyVWUEekBFnIKVuTwhNazsILn8nlwEWN0EoAziDNutlOH5F+G17139oMi2OfY9qK5HUn9VcV
XCy72LeCo/ABtZRBnr12FaT6V6mfWwBvS35NTpJOWPS0/mEuS3+gQcOxA3Q+eNhbAj8+TQ6j41uA
sg7Oxe36WPLgtIyDEk5MRaFBZnokkEo2m+QVfq4a4acYiX6veJ+dxDNSzLwbP+G+IYCXAUgxggP/
MIID+wIBATCBxDCBrjELMAkGA1UEBhMCVVMxCzAJBgNVBAgTAlVUMRcwFQYDVQQHEw5TYWx0IExh
a2UgQ2l0eTEeMBwGA1UEChMVVGhlIFVTRVJUUlVTVCBOZXR3b3JrMSEwHwYDVQQLExhodHRwOi8v
d3d3LnVzZXJ0cnVzdC5jb20xNjA0BgNVBAMTLVVUTi1VU0VSRmlyc3QtQ2xpZW50IEF1dGhlbnRp
Y2F0aW9uIGFuZCBFbWFpbAIRANiXsRcZaFAikGzX07OrUbYwCQYFKw4DAhoFAKCCAg8wGAYJKoZI
hvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTAwNzAyMDE0ODMxWjAjBgkqhkiG
9w0BCQQxFgQUSVcNsrnP9p0WBOY6cAJ7HGf9U5owgdUGCSsGAQQBgjcQBDGBxzCBxDCBrjELMAkG
A1UEBhMCVVMxCzAJBgNVBAgTAlVUMRcwFQYDVQQHEw5TYWx0IExha2UgQ2l0eTEeMBwGA1UEChMV
VGhlIFVTRVJUUlVTVCBOZXR3b3JrMSEwHwYDVQQLExhodHRwOi8vd3d3LnVzZXJ0cnVzdC5jb20x
NjA0BgNVBAMTLVVUTi1VU0VSRmlyc3QtQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBFbWFpbAIR
ANiXsRcZaFAikGzX07OrUbYwgdcGCyqGSIb3DQEJEAILMYHHoIHEMIGuMQswCQYDVQQGEwJVUzEL
MAkGA1UECBMCVVQxFzAVBgNVBAcTDlNhbHQgTGFrZSBDaXR5MR4wHAYDVQQKExVUaGUgVVNFUlRS
VVNUIE5ldHdvcmsxITAfBgNVBAsTGGh0dHA6Ly93d3cudXNlcnRydXN0LmNvbTE2MDQGA1UEAxMt
VVROLVVTRVJGaXJzdC1DbGllbnQgQXV0aGVudGljYXRpb24gYW5kIEVtYWlsAhEA2JexFxloUCKQ
bNfTs6tRtjANBgkqhkiG9w0BAQEFAASCAQBkzkCaoJbRhqjK+ZFREZLKXH9+MSFfcRcZzgoDDtbi
q9ZKTjOTgrlHnb/zKY9BrlgEilEpLcJdYUfbXssjNryS1dmDHIj0y3ITm8cSDoeRja/JnM7Fv6GR
9Y01YU4t6nyThXaBxZHwZ384d/hmDrrep9lkk5JQI6ENuVWkmdWcBy2xOP7p/wr1gowpykJJjKq/
Uskk49EK3JqYngfMTnYLcoDXQaJmy6tgaQBtoStgDl3lCfpt1KDYXGSgYHZ52IeBUN59KpQfXDyy
Q/hm44PVQUha2N8iY0S9JbNOHJfDuNKBx3pXPm8pxyzLPG4oM7JfoQ/tnqAIbcNw+FOfZaqeAAAA
AAAA

--Apple-Mail-41--919599699--