前言

在 Web 接口渗透测试中，开发常使用 UUID 复杂字符串作为业务资源 ID，误以为长随机 ID 就能阻挡越权遍历，这是非常典型的安全误区。本次分享海外考勤班次系统真实渗透案例，系统同时存在UUID 长 ID、数字短 ID两套资源标识，低权限普通员工通过替换请求内 ID 值，实现越权查看、操作管理员班次记录，属于高危水平越权漏洞。全文完整还原测试步骤、漏洞根源、风险危害与落地修复方案，适合开发、安全测试、运维人员学习参考。

一、漏洞 & 测试基础信息

1. 目标系统业务与权限体系

该平台为企业考勤班次管理系统，核心功能为员工打卡、班次记录查看、下班签退（Check Out），划分两类基础账号：

• 低权限普通员工（user_id：22684363）：仅允许查看、操作自身创建的班次记录；
• 高权限管理员（user_id：22684364）：可查看团队全部人员班次数据。

2. 漏洞核心特征

1. 资源 ID 双格式混用：数据库同时存储UUID 复杂字符串 ID与纯数字简易 ID，接口未做 ID 格式强校验，两种 ID 均可正常访问资源；
2. 缺失归属权校验：接口仅校验 ID 是否存在，未校验当前登录账号是否拥有该班次记录的操作权限；
3. 覆盖多类风险操作：不仅可越权读取他人班次详情，还能执行下班签退（Check Out）修改他人业务数据，属于读写复合型高危越权。

3. 漏洞风险等级

高危漏洞，攻击者仅需普通员工账号，即可读取团队内全部人员考勤、薪资关联班次数据，还能篡改管理员考勤记录，干扰企业人事核算。

二、漏洞实操 / 测试流程（原文原句完整保留，步骤标连续序号）

漏洞完整利用步骤

1、使用不同权限账号登录系统，各自创建一个班次记录 低权限用户 22684363

高权限用户 22684364

2、低权限用户只能看自己能看到的记录，高权限用户可以看到所有的记录

3、用户访问记录时，请求包中默认都是该记录的复杂 id，以低权限用户为例

4、此时，尝试替换复杂 id 为 简单 id，即 xxxxx-xxxxx-xxxxx-xxxxx 为 22xxxx 发现可以正常访问相同的数据

5、尝试遍历 id，发现访问团队内其他用户的 id 是 403，非团队内其他用户的是 404 6、对该记录进行其他功能的使用，发现 check out 存在越权 请求为https://xxxx.asdasdasdasd.xom/api/internal/shifts/xxxx-yyyyyy-asdasdadasda-dgfhdfhfghjfgh/check_out.json 替换 id https://xxxx.asdasdasdasd.xom/api/internal/shifts/226xxxxx/check_out.json 最后替换 id 为高权限用户的记录 id 22684364

发现不仅能越权获取记录详情，同时还可以 checkout 他人记录

操作细节补充梳理

1. 系统前端展示资源时，默认携带 UUID 格式长 ID 发起请求，开发寄希望 UUID 无规律防止遍历；
2. 抓包修改接口路径中的资源标识，将 UUID 替换为数据库内对应的纯数字短 ID，后端无格式拦截，正常返回完整班次数据；
3. 读接口存在越权后，延伸测试写接口（下班签退 Check Out），同样替换管理员班次数字 ID，服务端直接执行签退逻辑，管理员班次记录被清空，业务数据被恶意篡改；
4. 边界测试：遍历同团队其他员工 ID 返回 403，跨团队陌生 ID 返回 404，说明仅做了团队粗粒度隔离，未做单条记录归属人精准校验。

三、漏洞挖掘思路梳理

1. 测试切入点：带资源 ID 的 RESTful 接口形如/api/xxx/{资源ID}/操作的路径型接口是越权重灾区，尤其是考勤、订单、文件、工单类带归属关系的业务，优先抓包修改路径内 ID 值测试。
2. ID 格式双重测试思维若系统同时存在 UUID、自增数字 ID、哈希 ID 等多套标识，不要只测试前端展示的 ID 格式，需要替换数据库底层原始数字 ID、主键 ID 尝试绕过限制。
3. 读写联动测试逻辑先测试查询类读接口确认越权存在，立刻延伸测试修改、删除、状态变更等写接口，多数场景读接口存在越权时，写接口同步存在风险，危害会成倍放大。
4. 边界遍历辅助判断校验逻辑批量遍历不同归属、不同团队的 ID，通过返回码（403/404/200）判断后端校验粒度：仅区分团队、未区分记录所有人，是本次漏洞的核心校验缺失点。
5. 底层逻辑漏洞根源开发错误认为「UUID 复杂 ID 能防越权」，将安全防护寄托在 ID 复杂度上，完全忽略接口必须校验当前用户是否属于本条资源归属人，ID 仅作为资源定位标识，不具备任何权限防护能力。

四、漏洞完整总结（核心问题 + 业务危害 + 修复建议 + 测试心得）

（一）漏洞核心问题

1. 权限校验逻辑严重缺失接口仅校验资源 ID 是否存在、是否属于同一团队，未精准校验当前登录账号是否为班次记录创建人 / 归属人，是越权根本诱因；
2. 多格式 ID 无统一强校验系统混用 UUID、数字自增 ID 两套主键，后端未对接口传入的 ID 格式做白名单拦截，攻击者可随意替换两种格式 ID 访问资源；
3. 防护思路本末倒置依赖 UUID 长 ID 的随机性做安全防护，混淆「资源唯一标识」和「访问权限控制」的作用，ID 复杂度无法抵御抓包篡改、ID 遍历攻击；
4. 读写接口校验标准不统一查询、签退修改接口共用同一套薄弱校验逻辑，读数据、篡改数据双重越权全部放行，无差异化权限拦截。

（二）业务安全危害

1. 敏感人事数据泄露低权限员工可越权读取管理员、同团队全员考勤打卡时间、工作地点、薪资计价标准等隐私人事数据，违反个人信息保护相关法规；
2. 业务数据恶意篡改可对任意他人班次执行下班签退操作，清空考勤记录，直接干扰企业工时统计、工资核算，造成财务与人事纠纷；
3. 横向渗透风险放大攻击者通过遍历数字 ID，批量爬取团队内部全部考勤数据，若叠加其他漏洞可进一步获取员工邮箱、手机号等核心信息；
4. 企业管理秩序破坏恶意篡改管理员考勤记录，可伪造旷工、迟到记录，引发内部管理纠纷，造成企业管理公信力受损。

（三）标准化落地修复建议

1. 增加资源归属强制校验（核心修复）所有班次查询、修改、签退接口，在查询数据库班次数据后，必须比对班次绑定的user_id与当前登录 Token/Session 内用户 ID，不一致直接返回 403 权限不足；
2. 统一资源 ID 格式，拦截非法 ID

• 全系统统一使用单一 UUID 作为对外暴露的业务资源 ID，数据库自增数字主键仅后端内部使用，禁止前端、接口传输；
• 后端增加 ID 格式正则白名单，仅允许 UUID 格式字符串访问接口，纯数字 ID 直接拦截；

1. 读写接口分级权限控制查询接口、修改 / 删除类写接口拆分校验逻辑，写接口增加更严格权限校验，仅资源归属人、超级管理员可执行修改操作；
2. 新增操作日志与异常监控记录班次查看、签退操作的账号、目标班次 ID；监控短时间大量遍历不同用户班次 ID、频繁操作他人班次的行为，实时告警拦截；
3. 安全开发规范约束明确开发红线：任何业务资源 ID 都不能作为权限防护手段，权限控制必须基于登录身份与资源归属关系双重校验。

（四）渗透测试心得

1. 不要被前端展示的复杂 UUID 迷惑，数据库底层自增数字主键往往是越权突破口，抓包替换不同格式 ID 是基础必测项；
2. 越权测试不能只测查询功能，修改、删除、状态变更等写接口危害更大，必须联动测试；
3. 很多开发存在认知误区：长随机 ID 不会被遍历，实际上攻击者只要获取一条有效数字 ID，即可批量遍历同团队全部资源；
4. 校验粒度是关键：仅区分团队、部门的粗粒度校验无法抵御越权，必须精确到单条资源归属用户。

五、安全声明

1. 本文全部测试操作均在企业授权渗透测试环境内完成，案例仅用于网络安全技术学习、企业安全体系建设参考；
2. 根据《网络安全法》《数据安全法》《个人信息保护法》，任何未经授权擅自检测、访问、篡改第三方信息系统数据的行为，属于违法行为，将承担民事、行政乃至刑事责任；
3. 企业开发、安全、运维团队可直接参考文中修复方案优化接口权限逻辑，上线前将 ID 篡改越权纳入自动化接口安全测试用例，提前规避同类漏洞。