jeesite5 BOPLA VULNs Report

审计报告（jeesite5）

生成时间：2026-04-25

范围说明

  • 仅基于当前仓库代码分析

  • 按「入口授权 → sink 写入 → 后续生效点」链路收敛

  • 本文为代码级初筛结果，不等同最终裁决

漏洞接口一览

POST ${adminPath}/sys/empUser/save
POST ${adminPath}/sys/empUser/importData
POST ${adminPath}/cms/article/save
POST ${adminPath}/sys/post/save

Issue 1：员工编辑越权（组织/岗位重绑定）

接口

POST ${adminPath}/sys/empUser/save

缺失检查

  • empUser.employee.office.officeCode

  • empUser.employee.company.companyCode

  • empUser.employee.employeePostList[].postCode

  • empUser.employee.employeeOfficeList[].officeCode

  • empUser.employee.employeeOfficeList[].postCode

核心问题

入口仅校验目标用户是否在可见范围内，但未校验：

“提交的新组织 / 公司 / 岗位是否属于当前操作者的可管理范围”

链路

  • 入口：仅 sys:empUser:edit / authRole + 单对象 data scope

  • sink：

    • employeeService.save

    • employeeOfficeDao.insertBatch

    • employeePostList 删除重建

  • 生效点：

    • addDataScopeFilter 使用 office/company

    • switchPost / switchOffice 写入 session.roleCode

风险结论

对象壳校验正确，但内部属性完全可控 → 典型属性级越权写

人工审计结论

最大危害（给开发者一句话）

  • 低权限管理员可将可管理用户重绑定到其权限范围之外的公司、机构或岗位，从而污染数据权限边界，并在岗位权限模式下间接获得不应拥有的角色权限。

最佳修复建议

  • 在保存前逐项校验：

    • officeCode / companyCode / postCode
      必须全部属于当前操作者数据权限范围，否则整体拒绝。

Issue 2：批量导入越权（组织重绑定放大）

接口

POST ${adminPath}/sys/empUser/importData

缺失检查

  • importedEmpUser.employee.office.officeCode

  • importedEmpUser.employee.company.companyCode

核心问题

  • importData → 直接调用 save

  • 未做逐行权限校验

本质

Issue 1 的批量放大版本

风险结论

  • 单次操作 → 多用户越权写入

人工审计结论

最大危害

  • 攻击者可通过批量导入一次性篡改大量员工的组织归属，造成系统级权限边界污染。

最佳修复

  • 在 importData 中逐行校验：

    • officeCode / companyCode 必须可管理

    • 任一不合法 → 拒绝该行

Issue 3：文章写入（栏目/状态控制）

接口

POST ${adminPath}/cms/article/save

缺失检查

  • article.category.id

  • article.status

分析结论

  • 写路径未校验 category 权限

  • 但存在：

    • 查询侧 data scope 控制

    • 审核流（可能存在补偿）

人工结论

❌ 不是漏洞（偏业务设计）

Issue 4：岗位角色绑定越权（权限侧门）

接口

POST ${adminPath}/sys/post/save

缺失检查

  • post.roleCodes

核心问题

系统存在两条“角色授予路径”：

路径权限控制
用户直接授权 sys:empUser:authRole（受控）
岗位绑定角色 sys:post:edit（未受控）

当：

user.postRolePermi = true

岗位角色 → 会进入用户 session.roleCode

链路

  • 入口：sys:post:edit

  • sink：

    • 删除旧 PostRole

    • 插入新 roleCodes

  • 生效点：

    • switchPost → 写 session.roleCode

    • switchOffice → 聚合 roleCode

    • 登录返回 roleCode

本质

用“岗位编辑权限”绕过“用户授权权限”

人工审计结论

最大危害（给开发者一句话）

  • 具备岗位编辑权限的低权限用户可以通过修改 post.roleCodes 赋予岗位高权限角色，并在岗位切换后生效，从而绕过专门的用户角色授权控制路径，实现权限提升。

最佳修复建议

  • 在 PostService.save 中增加角色上界校验：

    • post.roleCodes ⊆ 当前操作者可授角色集合

  • 或：

    • 将岗位角色绑定纳入 sys:empUser:authRole 同级权限控制

  • 或：

    • 在 user.postRolePermi=true 时，限制岗位编辑者不能修改 roleCodes

总体结论

本批问题的共性：

1️⃣ 典型缺陷模式

入口有权限 → sink 缺对象/属性约束

集中表现为：

  • 数据范围（Data Scope）只作用于“查询”

  • 写路径完全信任请求参数

2️⃣ 风险分级建议

Issue风险
Issue 1 高（权限边界污染）
Issue 2 高（批量放大）
Issue 3 低（设计问题）
Issue 4 高（权限绕过/提权）

3️⃣ 一句话总结（可放报告开头）

当前系统的主要安全问题在于：数据权限控制只在读取阶段生效，而在写入阶段未对关键组织与角色属性做一致性校验，导致低权限用户可通过合法入口构造越权数据关系，进而在后续权限判定中被系统“合法化”。

 

posted @ 2026-05-06 14:14  Aibot  阅读(22)  评论(0)    收藏  举报