JHS_ERP updateUser

Vulnerability call chain
1.1 Entry: UserController.updateUser
UserController exposes PUT /User/update, and the request body is directly passed without authorization judgment to
UserService. updateUserAndOrgUserRel：

/**
* create by: cjl
* description:
* Modify user, department, and user relationships
* create time: 2019/3/8 16:06
* @Param: beanJson
* @return java.lang.Object
*/
@PutMapping("/updateUser")
@ApiOperation(value = "Modify User")
@ResponseBody
public Object updateUser(@RequestBody JSONObject obj, HttpServletRequest request)throws Exception{
JSONObject result = ExceptionConstants.standardSuccess();
UserEx ue= JSONObject.parseObject(obj.toJSONString(), UserEx.class);
userService.updateUserAndOrgUserRel(ue, request);
return result;
}

Evidence Location: jshERP-boot/src/main/java/com/jsh/erp/controller/UserController.java: 333-350.
Problem: The Controller does not verify whether the current operator has the permission to change the user's organizational relationship, nor does it check whether the changed organizational relationship is within its own manageable scope.
1.2 Core Write: UserService.updateUser
UserService.updateUser converts the complete request body into a User entity, and then directly performs selective updates by primary key:
@Transactional(value = "transactionManager", rollbackFor = Exception.class)
public void updateUserAndOrgUserRel(UserEx ue, HttpServletRequest request) throws Exception{
if(BusinessConstants.DEFAULT_MANAGER.equals(ue.getLoginName())) {
throw new BusinessRunTimeException(ExceptionConstants.USER_NAME_LIMIT_USE_CODE,
ExceptionConstants.USER_NAME_LIMIT_USE_MSG);
} else {
…
oul.setUserBlngOrgaDsplSeq(ue.getUserBlngOrgaDsplSeq());
if (oul.getId() != null) {
// The association relationship between the existing department and user already exists, update it
oul = orgaUserRelService.updateOrgaUserRel(oul);
} else {
// There is no association between the department and the user, so create a new one.
oul = orgaUserRelService.addOrgaUserRel(oul);
}
}


Evidence location: jshERP-boot/src/main/java/com/jsh/erp/service/UserService.java:684-755.
Problem points:
Did not call userService.getCurrentUser() or userService.getUserId(request) to obtain the operator and perform authorization.
Authorization checks were not performed on relationship tables such as UserOrg.

Figure 1: Administrator Account A can open the User Management page. Figure 2: Regular Account B can only open Retail Management. Figure 3 uses token 50f1efaf16bd4ad78111547232daecec_197062 of regular account B to downgrade administrator account A (with id 197062) to a regular user. Figure 4 shows that after being downgraded to a regular user, the Csaaaa user page has changed and is consistent with Csbbbb.

 

 

 

 

 

3. Root Cause Analysis
Root Cause 1: Lack of interface-level authorization.
/User/update is the role template write interface, but the server does not check whether the current user has the role management editing permission. As long as the login filter allows access, the user can enter the core write function.
Root Cause 2: Lack of object-level authorization.
The target role is specified by the request body ID, and the update SQL only updates by the primary key, without verifying whether the role belongs to the current tenant, the current organizational boundary, or the set of roles manageable by the current operator.
Root Cause 3: Missing field-level upper bound.
Both type and priceLimit are fields related to permissions/business rules. The current implementation treats them as ordinary editable attributes, without preventing low-privilege users from promoting their roles to a higher data scope or removing existing price shielding items.
Root Cause 4: Using a complete entity as the update DTO.
The direct conversion of the request body to User.class results in all non-null fields in the entity being updatable by the Client. There is a lack of boundaries between permission-sensitive fields and ordinary descriptive fields.