200 个接口 30 分钟筛完：越权测试的半自动化流程

原创

奋斗的小浪
奋斗的小浪

船山信安

2026年10月23日 16:14
湖南

去阅读

实战笔记 · PENTEST

200 个接口 30 分钟筛完：越权测试的半自动化流程

越权不是技术难，是量大事杂。接口两百个、角色三四种、参数位置五六个，人工点一遍要两天，还一定漏。

这套流程我用了三年，核心不是工具，是把“判断标准”先写死，再让工具去跑。

本文为授权范围内的越权测试方法论，需要至少两个测试账号与书面授权。不涉及任何第三方系统的测试。

01先分清三种越权，判据完全不同

很多人把越权混成一件事，测起来自然乱。三种类型，测法和判据都不一样：

判据写死之后，剩下的就是机械劳动。而机械劳动，应该交给工具。

02准备：两个账号，两条会话

A 账号（普通用户）、B 账号（另一个普通用户），有条件再加一个 C（管理员）。三个账号的权限边界要清楚，否则测出来的“越权”可能只是设计如此。

关键前提：A 和 B 必须能访问同一批资源类型。比如都能下单、都能看自己的订单。不能访问同一类资源，水平越权根本无从测起。

再记一条容易漏的：两个账号的注册时间、等级、所属组织最好不同。有些系统的数据权限按组织隔离，同组织下的两个账号测不出问题。

03Burp 里怎么配

装 Autorize 插件，把 B 的完整 Cookie 或 Authorization 头填进它的配置。之后你正常浏览，它会把每个请求自动重放两次：一次去掉认证，一次换成 B 的身份。

结果用三种颜色标：拒绝（绿）、可能有问题（黄）、通过（红）。红色的那些，就是第一批要人工确认的。

一个必须调的参数：过滤规则。把静态资源、埋点、心跳接口全部排除掉，否则列表会被几百条 /static/xxx.png 淹掉，人就不想看了。

04参数藏在哪：五个高频位置

1URL 路径：/user/123，最简单的水平越权，改数字就行。

2Query：?id=123&type=1，注意有些系统只校验 id 不校验 type。

3Body JSON：{\"userId\":123，改完要看返回的是谁的数据，不是看状态码。

4自定义 Header：X-User-Id、X-Org-Code，最容易被漏，也最容易中。

5Cookie 里的 uid / orgId，明文存的情况比想象中多。

后两个是我见过命中率最高的位置。原因很简单：开发者觉得“这是客户端自己带的，改不了”，于是服务端直接信任了。

05批量：Intruder 别用来爆破，用来换 ID

Intruder 的正确定位不是撞库，是“参数位替换”。把资源 ID 设成变量，payload 用另一个账号的资源 ID 列表，跑一遍看哪些返回了别人的数据。

grep match 里加业务关键词，比看状态码有效得多：余额、手机号、订单号、身份证、收货地址。返回 200 但内容是空数组的，不算越权。

这一步的产出不是“有多少红点”，是“有几条能稳定复现的数据泄露”。前者是噪声，后者才是报告。

06三个必踩的坑

1接口有防重放（时间戳加签名），重放直接失败。这种只能手工构造，工具帮不上，先识别出来别浪费时间。

2数据权限做在 SQL 层，接口返回 200 但数据是空的。判据必须看响应体，只看 code 会得出“没有越权”的错误结论。

3缓存。连着发两次请求拿到同一份缓存响应，看着像越权其实是 CDN。加个随机参数再试。

07报告怎么写才有人认

别写“存在越权漏洞”。写“A 账号（userA）通过修改 userId 参数，可读取 B 账号（userB）的姓名、手机号、收货地址”。一句话说清谁、怎么改、拿到什么。

附两张对比截图：一张 A 的请求带 B 的 ID，一张响应体里 B 的数据。再补一句影响面——这个 ID 是否可遍历，能遍历多少条。

越权报告的杀伤力不在“漏洞”两个字，在“能遍历”三个字。写不出可遍历，就只是一个 bug。

参考来源

OWASP WSTG v4.2 — WSTG-ATHZ 授权测试

OWASP API Security Top 10 2023 — API1:2023 Broken Object Level Authorization

OWASP API Security Top 10 2023 — API5:2023 Broken Function Level Authorization

CWE-639: Authorization Bypass Through User-Controlled Key

本文为技术事实陈述与防护建议，全部案例基于授权测试与公开研究；不提供针对未修复系统的完整攻击链，不构成未授权测试的建议。