[jira] Commented: (OFBIZ-2729) special security should be required for setting passwords

["Michele Orru (JIRA)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/OFBIZ-2729?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12730994#action_12730994 ] 

Michele Orru commented on OFBIZ-2729:
-------------------------------------

As I've specified in in SF thread, and as Si correctly pointed to me, this is a logic flaw: SecurityPermissions can be as granular as we want, but basically what is happening here is that 90% of the users will use the permissions that are already in the ofbiz seed data.

Then, if we combine this flaw with the many XSRF exploitables points that are present in ofbiz, we can use an attack vector like the following:

document.body.innerHTML += '<form id="maliciousform" action="http://localhost:8080/partymgr/control/updatePassword" method="post"><input type="hidden" name="userLoginId" value="euronymous666"><input type="hidden" name="partyId" value="10010"><input type="hidden" name="currentPassword" value="blabla"><input type="hidden" name="newPassword" value="passwordwedontknow"><input type="hidden" name="newPasswordVerify" value="hardpasswd"><input type="hidden" name="passwordHint" value=""></form>'; 
document.getElementById("maliciousform").submit(); 

If this code (embedded in a properly formatted page) will be executed by *any user with PARTYMGR_UPDATE privileges in the application, then even the admin password can be changed.

A simple example is an e-commerce website based on the ofbiz trunk code: the website have a "MyAccount" page for customers, where they can modify their profiles. Almost all the time, for lack-of-time, or for requirements, the services/permissions that will be used will be the same of ofbiz. Thus, when creating a SecurityGroup for such "CUSTOMER" users, we will use a PARTYMGR_UPDATE permission, to let the users update their profiles (and for instance to prevent access to partymgr application, without giving them PARTYMGR_VIEW permission).

In this hypothetical situation (but not so far from reality), if the user can embed JS code in some parts of the application, the game is over: we change the ADMIN password, and we have full control of the application.

I've already committed a patch in opentaps trunk.

:::Michele Orru'::: 
Network& Security Manager, IntegratingWeb.com 
http://www.integratingweb.com 


>  special security should be required for setting passwords
> ----------------------------------------------------------
>
>                 Key: OFBIZ-2729
>                 URL: https://issues.apache.org/jira/browse/OFBIZ-2729
>             Project: OFBiz
>          Issue Type: Bug
>          Components: framework
>    Affects Versions: Release Branch 4.0, Release Branch 9.04, SVN trunk
>            Reporter: Si Chen
>
>  This issue was first brought up here: https://sourceforge.net/forum/message.php?msg_id=7496877
>  Basically, any user with PARTYMGR_CREATE/UPDATE  permissions can set the password of another user. This creates opportunity for  Malfeasance. For example, a customer service rep  could set the password of the admin user.
> A simple solution would be to create a new security permission PARTYMGR_PASSWD  and require that permission  for setting or changing password of a different user, instead of using PARTYMGR_UPDATE.  PARTYMGR_PASSWD  could then be associated with  the administrative user.
>  An alternative is to use the SECURITY_UPDATE  permission instead of PARTYMGR_UPDATE  or  a new PARTYMGR_PASSWD  permission.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.