aiflowy BOPLA Vulns Report

1）潜在漏洞：/api/v1/sysAccount/save，/api/v1/sysAccount/update

问题类型： grant_role / SysAccount.roleIds

1. 风险分析

如果服务端未对 roleIds 做“可授予上界”校验，则任何具备账号保存/更新权限的用户，都可以通过构造请求将高权限角色绑定给自己或同伙账号。
最严重情况下，可导致租户级完全控制：包括批量读取/篡改/删除数据、接管关键配置、创建持久化后门账号，以及权限链的进一步扩散。

2. 漏洞信息

• 入口： 仅在入口处进行了粗粒度的 CRUD save/update 校验
  D:\zaqizaba\tangganhuo\aiflowy\aiflowy-modules\aiflowy-module-auth\src\main\java\tech\aiflowy\auth\config\CurdInterceptor.java:64
• 落库点： 控制器调用 syncRelations
D:\zaqizaba\tangganhuo\aiflowy\aiflowy-api\aiflowy-api-admin\src\main\java\tech\aiflowy\admin\controller\system\SysAccountController.java:87
• 实际写入： 服务层直接使用请求体中的 roleIds 重写 tb_sys_account_role
D:\zaqizaba\tangganhuo\aiflowy\aiflowy-modules\aiflowy-module-system\src\main\java\tech\aiflowy\system\service\impl\SysAccountServiceImpl.java:42
• 缺失校验字段： SysAccount.roleIds

3. 核验细节

该问题本质类似“导入团队成员”类漏洞：入口只校验“是否能修改账号”，但未校验“写入的 roleIds 是否在操作者可授予范围内”。

后续权限生效链路成立：

• AuthServiceImpl.java:72
• SysMenuServiceImpl.java:36

系统会直接将 account_role -> role_menu -> permissionTag 映射作为真实权限使用。

4. 安全建议

在账号 save/update 最终落库前增加严格的服务端校验：

• 必须同租户
• 必须属于操作者“可授予角色集合”的子集
• 禁止越级授予（尤其管理类角色）

不满足条件应拒绝请求，并记录安全审计日志。

---

2）潜在漏洞：/api/v1/sysRole/saveRole，/api/v1/sysRole/saveRoleMenu/{roleId}

问题类型： grant_permission_set / SysRole.menuIds

1. 风险分析

如果系统仅校验“是否具备角色保存权限”，而不校验 menuIds 是否在操作者可授予范围内，则角色权限集合可以被任意重写。
攻击者可以将高危菜单权限注入到可控角色中，并进一步赋权给自己或同伙，实现从普通管理权限到租户级控制的纵向越权。

2. 漏洞信息

• 入口： 仅校验 @SaCheckPermission("/api/v1/sysRole/save")

  • SysRoleController.java:46
  • SysRoleController.java:81

• 落库点： 服务层删除原有 tb_sys_role_menu 后插入请求中的 menuIds

  • SysRoleServiceImpl.java:43
  • SysRoleServiceImpl.java:73

• 缺失校验字段： SysRole.menuIds

3. 核验细节

系统仅校验“是否可以保存角色”，未校验“menuIds 是否超出当前操作者的授权上界”。

已有代码只在“删除特殊角色”时做了保护：

• SysRoleController.java:109

但在“更新角色菜单”时没有对应防护。

该漏洞在以下条件下可直接利用：

• 攻击者已拥有该角色
• 或与第一个漏洞联动使用

4. 安全建议

在角色菜单关系落库前增加严格校验：

• menuIds 必须是操作者可授予菜单集合的子集
• 必须同租户
• 受保护菜单禁止下放

不满足条件应拒绝请求，并记录安全审计日志。

---

3）潜在问题：/api/v1/sysApiKey/update

问题类型： grant_api_access / SysApiKey.permissionIds

1. 风险分析

如果产品语义要求 API Key 权限不能超过操作者自身权限上界，则该路径可能允许攻击者将高权限资源直接绑定到 API Key，从而扩大公网调用面。
可能造成未授权数据访问、敏感接口滥用、批量自动化调用以及持久化后门访问。
如果系统本身设计允许 API Key 独立授权，则该问题属于高风险设计点，而非已确认漏洞。

2. 漏洞信息

• 入口： CRUD update 路径（实际进入 save 流程）

• 落库点：

  • SysApiKeyController.java:81
  • SysApiKeyResourceMappingServiceImpl.java:29

• 确认会重写 tb_sys_api_key_resource_mapping

• 缺失校验字段： SysApiKey.permissionIds

• 当前结论： 证据不足

3. 核验细节

后续权限生效链路成立：

• SysApiKeyServiceImpl.java:35（基于 requestURI → resource → mapping 放行）
• PublicApiInterceptor.java:23
• PublicBotController.java:47

但仓库中没有证据证明 permissionIds 必须受操作者权限上界约束。
相反：

• SyncApis.java:44 显示其更像独立的 public API 授权模型

4. 安全建议

首先明确并固定授权语义，然后统一实现服务端校验与审计：

• permissionIds 必须符合既定授权策略
• 必须同租户
• 必须满足“可授予子集”或审批白名单（取决于设计）

不满足条件应拒绝写入，并记录安全日志。