micro_community BOPLA VULNs Report

Issue 1：role.saveRoleStaff

1. 风险分析（危害分析）

该接口允许直接将角色绑定到任意员工。由于缺少“可授予角色上界”和“可管理用户范围”的限制，攻击者可将高权限角色分配给自己或任意 staff，从而实现权限提升，并被下游鉴权逻辑直接信任，最终导致后台权限体系失控。

2. 漏洞信息

• 类型：对象级授权缺失 / 权限关系越权写入

• 影响对象：p_privilege_user.user_id / p_privilege_user.p_id

• 核心问题：未校验调用者是否有权将指定 roleId 授予指定 staffId

3. 核验细节

• 入口：
  /cmd/{service} 分发机制直接路由到 role.saveRoleStaff

• Sink 写入：
  仅校验 roleId 和 staffs 存在后，将 staffs[].staffId 与 roleId 写入 p_privilege_user

• 缺失检查：
  未校验：

  • 是否有权管理目标 staffId

  • 是否有权授予该 roleId

• 后续生效点：

  • 菜单与资源权限查询直接基于 p_privilege_user

  • 下游 join 查询直接扩展权限范围

4. 安全建议

• 校验调用者是否可管理目标 staffId

• 校验 roleId 是否在可授予权限集合内

• 引入“角色授权上界”机制

• 拒绝越级授权与跨域分配

---

Issue 2：add.privilege.PrivilegeGroup

1. 风险分析（危害分析）

该接口允许将权限直接绑定到权限组，但未校验组归属和权限授予范围。攻击者可通过构造 pgId/pId，将高权限能力注入权限组，进而通过组关系扩展用户权限。

2. 漏洞信息

• 类型：对象级授权缺失 / 权限绑定越权

• 影响对象：p_privilege_rel.pg_id / p_privilege_rel.p_id

• 核心问题：未校验权限组归属与权限授予范围

3. 核验细节

• 入口：
  /cmd/{service} → add.privilege.PrivilegeGroup

• Sink 写入：
  仅校验 pgId/pIds 存在，直接写入 p_privilege_rel

• 缺失检查：
  未校验：

  • pgId 是否属于当前域或商户

  • pId 是否在可授予权限集合内

• 后续生效点：

  • 用户权限通过 p_privilege_user → p_privilege_rel → p_privilege 扩展

  • 菜单与资源权限查询直接使用该关系

4. 安全建议

• 校验 pgId 归属（如 store_id / tenant）

• 校验 pId 是否在授权白名单内

• 复用“可管理权限组”查询逻辑

• 禁止跨域权限绑定

---

Issue 3：role.saveStaffCommunity

1. 风险分析（危害分析）

该接口控制员工可访问的小区范围。由于缺少约束，攻击者可将任意 community 分配给任意 staff，从而扩大其数据访问范围，造成跨区域数据泄露。

2. 漏洞信息

• 类型：对象级授权缺失 / 范围越权写入

• 影响对象：staff_community.staff_id / staff_community.community_id

• 核心问题：未校验社区分配权限与用户管理范围

3. 核验细节

• 入口：
  /cmd/{service} → role.saveStaffCommunity

• Sink 写入：
  仅校验 staffId 与 community 存在，直接写入 staff_community

• 缺失检查：
  未校验：

  • 是否有权管理该 staffId

  • 是否有权分配这些 communityId

• 后续生效点：

  • communityId 作为员工真实可见范围返回

  • 多个查询接口直接依赖该范围进行数据过滤

4. 安全建议

• 校验 staffId 是否在管理范围

• 校验 communityId 是否可分配

• 限制跨组织或跨区域授权

• 在查询层增加防御性校验

---

Issue 4：owner.saveOwnerMember / owner.editOwnerMember

1. 风险分析（危害分析）

该接口允许修改家庭成员归属关系。由于 ownerId 可被直接覆盖，攻击者可将成员挂载到任意家庭，从而篡改家庭关系结构，并影响后续身份与权限判断。

2. 漏洞信息

• 类型：对象级授权缺失 / 归属关系篡改

• 影响对象：building_owner.owner_id

• 核心问题：未校验 ownerId 是否属于当前用户可管理范围

3. 核验细节

• 入口：
  /cmd/{service} → owner.saveOwnerMember / editOwnerMember

• Sink 写入：
  直接使用请求中的 ownerId 写入或更新 building_owner

• 缺失检查：
  未校验：

  • ownerId 是否属于当前用户

  • 是否有权附属到该家庭

• 后续生效点：

  • app 查询通过 ownerId 获取家庭关系

  • ownerId 被作为家庭主标识继续扩展查询

4. 安全建议

• 强制从服务端绑定 ownerId

• 校验成员归属关系合法性

• 禁止跨家庭绑定

• 引入家庭关系完整性校验

---

Issue 5：ownerSettled.saveOwnerSettledApply

1. 风险分析（危害分析）

该接口允许提交业主入驻申请，并在完成状态下写入房屋归属关系。由于 ownerId 完全来自请求且未重新校验，攻击者可将房屋绑定到任意 owner，篡改核心业务数据。

2. 漏洞信息

• 类型：对象级授权缺失 / 关键业务关系越权写入

• 影响对象：owner_settled_apply.owner_id / building_owner_room_rel.owner_id

• 核心问题：未校验 ownerId 是否属于当前提交者

3. 核验细节

• 入口：
  /cmd/{service} → ownerSettled.saveOwnerSettledApply

• Sink 写入：

  • 提交阶段：直接写入 owner_settled_apply.owner_id

  • 完成阶段：将相同 ownerId 写入 building_owner_room_rel

• 缺失检查：
  未校验：

  • ownerId 是否属于当前用户

  • 完成态是否基于审核结果重新绑定

• 后续生效点：

  • 房屋查询直接依赖 building_owner_room_rel.owner_id

  • 作为业主身份与房屋关系的权威数据源

4. 安全建议

• 提交阶段校验 ownerId 归属

• 完成阶段重新绑定 ownerId（基于审核结果）

• 禁止直接信任请求中的 ownerId

• 引入审核与绑定一致性校验