Posted by
Vinay Agarwal on
URL: http://ofbiz.116.s1.nabble.com/Users-Hidden-partyId-Security-Risk-tp137366p137373.html
I think there is a general security risk with storing database keys, or any
"important" information, in form fields, hidden or not. Overall security is
much easier to achieve by not giving user access to this data than to try to
contain the contaminant input. In other words follow these two rules:
1. Not store any important information in user forms, instead save them in
session.
2. Save only the data in hidden user form that cannot impact security if
changed, e.g., sequence page id for multi-page data entry forms.
So, I would simply recommend converting all 241 or so potentially unsafe
ftl's and corresponding event handlers to use session and instead of hidden
fields.
Regards,
Vinay Agarwal
-----Original Message-----
From:
[hidden email] [mailto:
[hidden email]]
On Behalf Of Si Chen
Sent: Friday, February 10, 2006 4:10 PM
To: OFBiz Users / Usage Discussion
Subject: Re: [OFBiz] Users - Hidden partyId - Security Risk?
Vinay,
My hunch is that:
ServiceUtil.getPartyIdCheckSecurity(userLogin, security, context,
result, "PAY_INFO", "_UPDATE");
is not enough. This checks if the partyId of the userLogin is the
partyId in the context or if the userLogin has PAY_INFO_UPDATE.
I think the security check there should be:
1. Does userLogin have PAY_INF_UPDATE? Yes -> good. This can be done
with hasEntityPermission
2. If not (1), is the userLogin the partyId in the context AND the
partyId of the PaymentMethod? Yes -> good.
We may be missing the second part here...
Want to try it? :)
Si
Vinay Agarwal wrote:
> My testing did find problem with hidden paymentMethodId field that I
> am describing below. In addition, there are 240 other ftl files that
> contain hidden fields and may pose security risk although I have not
> looked at anyone else.
>
> File: applications/ecommerce/webapp/ecommerce/customer/editcreditcard.ftl
>
> Statement: <input type="hidden" name="paymentMethodId"
> value="${paymentMethodId}">
>
> Theory:
>
> A hacked form may change the paymentMethodId and modify data that the
> user does not have authorization for
>
> Method:
>
> 1. Ecommerce application, signed up as "firstuser" and added a
> credit card. Its paymentMethodId came out to be 10000.
> 2. Logged out and signed up as "seconduser" and added a credit
> card. Its paymentMethodId came out to be 10001.
> 3. Logged in as seconduser, clicked on update credit card. Saved
> the html page locally.
> 4. Edited the saved html page
> 1. Changed paymentMethodId from 10001 to 10000.
> 2. Added
http://localhost:8443 <
http://localhost:8443/> to
> the action url.
> 5. Expected result: firstuser and seconduser each has one credit card.
> 6. Actual result: firstuser had no card and the second user had 2
> cards as seen on the profile page.
>
> Conclusion:
>
> A user is able to modify data that he is not authorized for.
>
> I would like to know if you can reproduce it. I can add it to Jira if
> needed.
>
> Regards,
>
> Vinay Agarwal
>
>------------------------------------------------------------------------
>
>
>_______________________________________________
>Users mailing list
>
[hidden email]
>
http://lists.ofbiz.org/mailman/listinfo/users>
_______________________________________________
Users mailing list
[hidden email]
http://lists.ofbiz.org/mailman/listinfo/users
_______________________________________________
Users mailing list
[hidden email]
http://lists.ofbiz.org/mailman/listinfo/users