perms-system-server/audit-report.md

权限系统深度审计报告

审计时间：2026-04-17
审计范围：perms-system-server 全部业务源码（测试代码除外）
审计维度：逻辑一致性、并发与竞态、资源管理、数据完整性、安全漏洞、边界崩溃

---

🚩 核心逻辑漏洞 (High Risk)

1. UserList 接口数据越权泄漏

• 文件：internal/logic/user/userListLogic.go 第 45 行
• 描述：非超管用户（产品管理员）调用 UserList 时，虽然校验了 caller.ProductCode == req.ProductCode，但底层查询 SysUserModel.FindListByPage 执行的是 全表分页查询（无任何 WHERE 条件），返回了系统中所有用户，而非仅当前产品的成员用户。memberMap 只是在返回结果上附加了 memberType 信息，并不过滤非成员用户。
• 影响：产品管理员可以看到其他产品甚至全系统的用户信息（用户名、昵称、邮箱、手机号、部门等），构成水平越权数据泄漏。
• 修复方案：非超管用户查询时，应先查 sys_product_member 获取当前产品的成员 userId 列表，再用这些 userId 进行分页查询。示例：

// userListLogic.go - 非超管场景
if req.ProductCode != "" && !caller.IsSuperAdmin {
    list, total, err := l.svcCtx.SysUserModel.FindListByProductMembers(
        l.ctx, req.ProductCode, page, pageSize,
    )
    // ...
}

需要在 Model 层新增 FindListByProductMembers 方法，JOIN sys_product_member 表过滤。

---

2. BindRoles 缺少角色级别校验，存在提权漏洞

• 文件：internal/logic/user/bindRolesLogic.go 第 33-101 行
• 描述：BindRoles 仅通过 CheckManageAccess 验证操作者对目标用户当前状态的管理权限，但未校验所绑定角色的 permsLevel 是否在操作者自身权限范围内。攻击路径：
  1. 操作者 A（permsLevel=50）管理目标用户 B（当前 permsLevel=100）
  2. CheckManageAccess 通过（50 < 100，A 的权限高于 B）
  3. A 给 B 绑定一个 permsLevel=1 的角色
  4. B 的 permsLevel 变为 1，权限反超操作者 A
• 影响：任何拥有用户管理权限的操作者可以通过分配高等级角色来实现权限提升，使目标用户获得超过自身的权限级别。
• 修复方案：在校验角色有效性的循环中，增加 permsLevel 校验：

// bindRolesLogic.go - 在遍历 roles 时增加
caller := middleware.GetUserDetails(l.ctx)
for _, r := range roles {
    if r.ProductCode != productCode {
        return response.ErrBadRequest("不能绑定其他产品的角色")
    }
    if r.Status != consts.StatusEnabled {
        return response.ErrBadRequest("不能绑定已禁用的角色")
    }
    // 非超管不能分配超出自身权限级别的角色
    if !caller.IsSuperAdmin && r.PermsLevel < caller.MinPermsLevel {
        return response.ErrForbidden("不能分配权限级别高于自身的角色")
    }
}

---

3. appSecret 数据库明文存储

• 文件：perm.sql 第 15 行；internal/logic/pub/syncPermsLogic.go 第 37 行；internal/server/permserver.go 第 40 行
• 描述：sys_product.appSecret 以明文存储在数据库中。当前仅用 subtle.ConstantTimeCompare 进行比对（防时序攻击）。若数据库被拖库或备份泄漏，所有产品的 appSecret 直接暴露。
• 影响：数据库泄漏场景下，攻击者可以使用任何产品的 appSecret 调用 SyncPerms 接口，篡改该产品的全部权限定义，影响所有用户的权限体系。
• 修复方案：将 appSecret 使用 bcrypt 或 HMAC-SHA256 哈希后存储。CreateProduct 时仅一次性返回原文，之后只存哈希值。验证时改用 bcrypt.CompareHashAndPassword：

// syncPermsLogic.go / permserver.go
if err := bcrypt.CompareHashAndPassword(
    []byte(product.AppSecretHash), []byte(req.AppSecret),
); err != nil {
    return nil, response.ErrUnauthorized("appSecret验证失败")
}

---

4. UpdateUser 权限模型与其他接口不一致，产品管理员无法修改自己创建的用户

• 文件：internal/logic/user/updateUserLogic.go 第 37-45 行
• 描述：UpdateUser 的权限判断逻辑为"只有超管或用户自身可修改"，而系统中 UpdateUserStatus、BindRoles、SetUserPerms 等接口均使用 CheckManageAccess（支持产品管理员和部门层级管理）。这导致产品管理员可以创建用户（CreateUser）、冻结用户（UpdateUserStatus）、绑定角色（BindRoles），却无法修改用户的昵称、邮箱、部门等基本信息。
• 影响：产品管理员的管理权限出现逻辑断裂——能创建和冻结用户，但不能编辑用户信息，不得不依赖超管操作，严重影响管理效率。
• 修复方案：将 UpdateUser 的权限模型统一为 CheckManageAccess，并保留对自身修改的限制（不能改自己的部门和状态）：

func (l *UpdateUserLogic) UpdateUser(req *types.UpdateUserReq) error {
    caller := middleware.GetUserDetails(l.ctx)
    if caller == nil {
        return response.ErrUnauthorized("未登录")
    }

    if caller.UserId == req.Id {
        if req.DeptId != nil || req.Status != 0 {
            return response.ErrForbidden("不允许修改自己的部门和状态")
        }
    } else {
        productCode := middleware.GetProductCode(l.ctx)
        if err := authHelper.CheckManageAccess(l.ctx, l.svcCtx, req.Id, productCode); err != nil {
            return err
        }
    }
    // ... 后续逻辑不变
}

---

⚠️ 健壮性与性能建议 (Medium/Low)

5. [Medium] CreateUser 未将用户加入产品成员，工作流存在断裂

• 文件：internal/logic/user/createUserLogic.go
• 描述：CreateUser 要求 RequireProductAdminFor(productCode) 校验产品管理员身份，但创建用户后并未将其加入当前产品的成员列表。新建用户需要管理员再单独调用 AddMember 才能登录和使用产品。
• 影响：管理员可能误以为创建用户即完成了入组操作，导致新用户无法登录。增加了操作步骤和出错概率。
• 建议：考虑在 CreateUser 中增加可选参数 memberType，当传入时在同一事务中自动创建产品成员记录；或在文档/前端层面明确引导管理员完成两步操作。

---

6. [Medium] 缓存前缀变量是包级可变全局状态

• 文件：各 *Model_gen.go（如 sysUserModel_gen.go 第 26-27 行，sysPermModel_gen.go 第 26-27 行）
• 描述：cacheSysUserIdPrefix、cacheSysPermIdPrefix 等缓存前缀在 newSys*Model 函数中被直接修改（cacheSysUserIdPrefix = cachePrefix + ":cache:sysUser:id:"）。这些是 var 级别的全局变量。
• 影响：若代码中有多处以不同 cachePrefix 创建同类 Model 实例（当前不存在此情况），会产生竞态条件。虽然当前启动时仅初始化一次，但这种模式在代码演进中存在隐患。
• 建议：由于此代码由 goctl 生成，短期内可接受。长期建议修改 goctl 模板，将前缀存入 struct 字段而非修改包级变量。

---

7. [Medium] AddMember 并发重复请求错误信息不友好

• 文件：internal/logic/member/addMemberLogic.go 第 52-55 行
• 描述：使用 check-then-insert 模式检查成员是否已存在。若两个请求并发执行，都通过了检查，其中一个在 Insert 时会触发数据库唯一约束错误（uk_product_user），但此错误未被捕获转换为友好提示，而是返回原始的 500 错误。
• 影响：并发场景下用户收到 "服务器内部错误" 而非 "该用户已是该产品成员"。
• 建议：在 Insert 错误处理中捕获唯一约束冲突：

result, err := l.svcCtx.SysProductMemberModel.Insert(l.ctx, &productmember.SysProductMember{...})
if err != nil {
    if strings.Contains(err.Error(), "1062") || strings.Contains(err.Error(), "Duplicate entry") {
        return nil, response.ErrConflict("该用户已是该产品成员")
    }
    return nil, err
}

---

8. [Medium] JWT 中嵌入了完整权限列表，Token 体积随权限数增长

• 文件：internal/logic/auth/jwt.go 第 23-40 行；internal/middleware/jwtauthMiddleware.go Claims 结构
• 描述：Claims.Perms 字段将用户的所有权限 code 列表嵌入 access token。对于拥有数百个权限的用户，Token 体积会显著增长（可能超过 4KB），导致每次 HTTP 请求的 Header 过大。
• 影响：增加网络传输开销；某些反向代理（如 Nginx 默认 4KB/8KB header buffer）可能拒绝过大的请求头。
• 建议：Token 中仅保留 userId、productCode 等核心标识，权限列表通过 UserDetailsLoader（已有 Redis 缓存）在需要时加载。当前中间件已经通过 loader.Load 重新加载了完整用户信息，Token 中的 Perms 字段实际上未被中间件使用，仅用于前端展示。可以考虑在登录响应中单独返回 perms，从 Token 中移除。

---

9. [Medium] RefreshToken 未限制刷新次数，旧 RefreshToken 可无限复用

• 文件：internal/logic/pub/refreshTokenLogic.go；internal/server/permserver.go 第 162-200 行
• 描述：RefreshToken 接口在签发新的 AccessToken 后，直接将原 RefreshToken 原样返回给客户端。RefreshToken 在有效期内可以被无限次调用，每次都会生成新的 AccessToken。
• 影响：若 RefreshToken 泄漏，攻击者可在整个有效期内持续获取新的 AccessToken。通常的最佳实践是 Refresh Token Rotation——每次刷新时同时签发新的 RefreshToken 并使旧的失效。
• 建议：当前通过 tokenVersion 机制可以在修改密码/冻结用户时使所有 token 失效，这提供了基本保障。若需更严格的安全性，可实现 Refresh Token Rotation（每次刷新签发新 RefreshToken），或在 Redis 中维护一个已使用 RefreshToken 的黑名单。

---

10. [Low] 用户不存在时 JwtAuth 中间件返回误导性错误信息

• 文件：internal/middleware/jwtauthMiddleware.go 第 74-78 行；internal/loaders/userDetailsLoader.go 第 129-133 行
• 描述：当 JWT 有效但用户已被删除时，UserDetailsLoader.Load 返回一个默认的 UserDetails（Status=0）。中间件判断 ud.Status != StatusEnabled 后返回"账号已被冻结"。但实际上用户是不存在/已被删除。
• 影响：用户收到错误的提示信息，可能导致困惑或误导排查方向。
• 建议：在中间件中增加用户是否存在的判断：

ud := m.loader.Load(r.Context(), claims.UserId, claims.ProductCode)
if ud.Username == "" {
    httpx.ErrorCtx(r.Context(), w, response.NewCodeError(401, "用户不存在或已被删除"))
    return
}
if ud.Status != consts.StatusEnabled {
    httpx.ErrorCtx(r.Context(), w, response.NewCodeError(403, "账号已被冻结"))
    return
}

---

11. [Low] 缺少操作审计日志

• 描述：当前系统在所有写操作（创建用户、绑定角色、修改权限、冻结用户、删除角色等）中未记录操作审计日志。仅有 go-zero 框架默认的请求日志。
• 影响：当发生安全事件（如权限被篡改、用户被异常冻结）时，无法追溯是谁在什么时间执行了什么操作。对于权限管理系统，审计追溯能力是合规性的基本要求。
• 建议：设计一个 sys_audit_log 表，记录 operator_id、action、target_type、target_id、detail、ip、timestamp 等字段。在关键业务逻辑中通过异步方式写入审计记录，避免影响主流程性能。

---

12. [Low] DeptTree 和 ProductList 对非超管暴露全量数据

• 文件：internal/logic/dept/deptTreeLogic.go；internal/logic/product/productListLogic.go
• 描述：DeptTree 接口无任何权限过滤，所有已登录用户可看到整个组织架构。ProductList 也对所有用户返回全部产品列表（AppKey 已对非超管隐藏）。
• 影响：部门结构和产品列表属于组织内部信息，虽然不包含高敏感数据，但在安全要求较高的场景下可能不符合最小暴露原则。
• 建议：根据实际业务需求评估是否需要按产品/部门范围过滤。如果当前业务场景下所有用户确实需要查看组织架构（如选择部门），可保持现状。

---

13. [Low] UpdateDept 修改 deptType 时缺少影响评估

• 文件：internal/logic/dept/updateDeptLogic.go
• 描述：将部门类型从 DEV（研发）改为 NORMAL，该部门下所有用户会立即失去"全权限"特权（因 loadPerms 中 DEV 部门自动获取全量权限的逻辑不再生效）。代码正确清除了缓存，但未在响应中提示此操作的影响范围。
• 影响：超管执行部门类型变更后，该部门及子部门下的用户可能突然失去大量权限，如果未提前通知，可能导致业务中断。
• 建议：在响应中返回受影响的用户数量，或在执行前增加确认机制。

---

总结

级别	编号	问题	类型
🚩 High	#1	UserList 数据越权泄漏	安全漏洞
🚩 High	#2	BindRoles 提权漏洞	安全漏洞
🚩 High	#3	appSecret 明文存储	安全漏洞
🚩 High	#4	UpdateUser 权限模型不一致	逻辑一致性
⚠️ Medium	#5	CreateUser 未加入产品成员	数据完整性
⚠️ Medium	#6	缓存前缀全局可变状态	并发安全
⚠️ Medium	#7	AddMember 并发错误信息不友好	边界处理
⚠️ Medium	#8	JWT Token 体积过大风险	性能
⚠️ Medium	#9	RefreshToken 可无限复用	安全加固
⚠️ Low	#10	用户不存在时错误信息误导	边界崩溃
⚠️ Low	#11	缺少操作审计日志	安全合规
⚠️ Low	#12	DeptTree/ProductList 过度暴露	安全加固
⚠️ Low	#13	UpdateDept 修改类型缺少影响提示	健壮性

优先修复建议：#1 和 #2 为最高优先级，直接影响数据安全和权限体系的可信度；#3 和 #4 建议在下一个迭代中修复。