API 攻防实战技巧：从信息收集到各类漏洞利用

上一篇我们认全了 API 的各种形态，这一篇进入实操：具体怎么去测一个 API。我会按”先摸清单、再打鉴权、然后各类漏洞”的顺序，把常用技巧过一遍。这些技巧彼此独立，实战里常常组合使用。

本文仅用于你对自有或已授权的系统做 API 安全测试。对第三方 API 未授权测试可能违反法律法规与服务条款。

第一步：把接口清单挖出来

打 API 前先要知道”有哪些接口”。几个金矿：

Swagger / OpenAPI：试 https://目标/swagger.json、/swagger-ui.html、/v2/api-docs、/openapi.json。很多测试/预发环境忘了关，直接给你完整接口、参数、甚至示例值。
前端 JS：现代前端把接口路径写死在打包后的 JS 里，全局搜 /api/、fetch(、axios( 能捞出一堆。
Postman 集合 / 文档站：开发者可能把集合传到公开工作区，或写在 Confluence。
报错泄露：随便传个错参数，看报错栈里有没有暴露框架和内部路径。

拿到清单，等于拿到了”作战地图”，后面逐个点名。

第二步：鉴权缺陷（JWT 与 Token）

API 靠 token 认人，token 出问题就全员裸奔。最常见的是 JWT（JSON Web Token）：

header.payload.signature
# 用点分隔的三段 base64，前两段可解码看到明文声明

JWT 风险点：

算法篡改（alg=none）：服务端若接受 alg: none，攻击者把签名段删掉、改 payload（如把 role 改成 admin）就能伪造身份。测法：解码后把 alg 改成 none 重发。
弱密钥 HS256：对称签名若密钥弱，可用字典爆破（工具 jwt-cracker）。
不校验签名：极端情况下服务端根本不验签，改 payload 直接生效。

即便不是 JWT，普通 token 也要测：能不能复用（登出后还有效？）、能不能预测、有没有过期、放响应里泄露。

第三步：BOLA——对象级越权（头号风险）

BOLA（Broken Object Level Authorization）是 API 最经典漏洞：接口用 ID 定位对象，但服务端没校验”这个 ID 是不是你的”。

GET /api/v1/orders/5521 HTTP/1.1
Authorization: Bearer <你的token>
# 把 5521 改成别人的订单号 5522，若返回了他人订单 → BOLA

打法：

准备两个账号 A、B，各拿到自己的资源 ID；
用 A 的 token 去请求 B 的资源 ID；
能读到/改到 → 确认越权。

这是实战里最高频、影响最大的 API 漏洞，务必系统测：订单、消息、地址、文件、配置，凡是带 ID 的都试。

第四步：BFLA——功能级越权

BFLA 是”普通用户调了管理员接口”。比如前端只显示了普通功能，但后端 /api/admin/users 没做角色校验，普通 token 直接能调：

GET /api/admin/users HTTP/1.1
Authorization: Bearer <普通用户token>
# 若返回全部用户列表 → BFLA

打法：从 Swagger/JS 里找带 admin、manage、config 的接口，用低权限 token 去撞。

第五步：批量分配（Mass Assignment）

很多框架（如 Spring、Express）会自动把请求体里的字段映射到对象。如果攻击者多传一个字段，服务端照单全收，就出事：

// 正常请求
{ "email": "me@x.com" }
// 攻击者多加字段
{ "email": "me@x.com", "isAdmin": true, "role": "admin" }

若服务端没做字段白名单，可能直接把普通用户提权成管理员。打法：在更新个人资料、创建订单等接口，试着加 role、isAdmin、price、verified 等”不该由客户端设”的字段，看是否被采纳。

第六步：限流绕过与资源耗尽

API 若不限流，可被爆破、被拖库、被打挂。测限流：

快速重复调用登录接口，看是否触发锁定；没锁定就能爆破密码。
限流常按 IP 或 token 计数，试着换 X-Forwarded-For 头、换 token 绕过计数。
批量枚举 ID（如 /users/1、/users/2…）拖数据，看能不能无限拉。

防御上应该服务端做限流+告警，但很多系统漏了，这正是可乘之机。

第七步：GraphQL 专项

回顾上篇，GraphQL 三个重点：

关 Introspection：发 { __schema { types { name } } }，若返回完整类型定义，等于接口文档泄露。
过度查询：在 query 里加敏感字段（email、passwordHash），看是否返回。
深度/批量查询 DoS：构造超嵌套或超大列表查询，看服务是否变慢/崩。

# 试内省
{ __schema { queryType { name } } }
# 试过度字段
{ user(id:1){ email passwordHash } }

第八步：参数污染与 SSRF

参数污染（HPP）：同一参数传多次 ?id=1&id=2，不同框架取第一个或最后一个，可能绕过某些校验逻辑。
SSRF：API 有”抓取图片/预览链接”类功能时，给它一个内网地址 http://169.254.169.254/...（云元数据），若服务端真去请求，就能读到实例凭证。这是 API 里通向云环境沦陷的快车道。

防御视角：怎么才算修好

打是为了修。给开发同学的通用建议：

每个涉及对象的接口，服务端校验”当前用户是否拥有该对象”（防 BOLA）。
角色权限集中校验，不在业务代码里散落判断（防 BFLA）。
请求字段做白名单，只接收该接收的（防批量分配）。
JWT 用非对称算法或强密钥，禁止 alg:none，校验签名。
全站限流+异常告警，敏感操作加二次校验。
关掉生产环境的 Introspection、Swagger，错误信息脱敏。
出网请求做地址白名单，挡住 SSRF。

常见坑

只用一个账号测：越权必须”两个账号对照”，单账号永远测不出 BOLA。
忽略响应字段：请求看着正常，但响应里多返回了敏感字段，属于过度暴露，别只看状态码。
迷信 HTTPS：加密只保护传输，不保护”该不该给你数据”的鉴权逻辑。

把技巧练成肌肉记忆,而非背下清单

这篇列了很多技巧,但我要泼句冷水:把清单背下来没用,能在一团乱麻的请求里”直觉性地”想到该试哪招,才算真会。这种直觉来自大量练习。建议你搭一个本地漏洞靶场(比如专门练 API 的漏洞环境),把 BOLA、批量分配、JWT 弱密钥、GraphQL 内省、SSRF 一个个亲手打穿、再亲手修好。打和修都做一遍,理解才扎实——你才会明白为什么”服务端校验所有权”这句话,落到代码上是哪几行。

练习时有个好习惯:每打穿一个漏洞,都写一句”根因是什么”。BOLA 的根因是”没校验对象归属”,批量分配的根因是”字段没白名单”,JWT 弱密钥的根因是”签名可被破解或跳过”。把根因归到这一类,你以后再看到类似接口,会自动套用对应打法。技巧会过时,框架会换,但”信任了客户端、漏了服务端校验”这个根因几十年不变。

最后回到职业操守。API 技巧杀伤力极大,一个 BOLA 可能拖出整库用户,一个 SSRF 可能打穿云环境。正因如此,这些能力只该用在你明确授权的目标上,只该用来帮系统变安全。真正的安全工程师,对自己的能力有敬畏:知道能打穿,更知道不该乱打。技术可以锋利,使用它的手必须清醒。把这份清醒和这些技巧一起练成本能,你才配得上”安全”二字。

最后补一句关于工具的话:市面上的 API 测试工具很多,Burp 的 Intruder/Repeater、Postman、专用爆破工具 ffuf、GraphQL 专用的 InQL 等等。工具能帮你省力气,但别被工具牵着走。真正决定成败的,永远是你对”这个接口应该有什么校验”的判断力。工具发出去一个请求,看到响应,你要立刻能判断”这正常吗、哪里不对、下一步试什么”。这个判断只能靠理解,靠练,靠一次次在靶场里被打脸又想通。把工具当放大镜,而不是当大脑,你的 API 测试才走得远。

这一篇你该记住的

信息收集先挖 Swagger/JS/Postman，拿到接口清单再点名。
JWT 测 alg=none、弱密钥、不验签；普通 token 测复用与过期。
BOLA 用两账号改 ID 撞；BFLA 用低权限撞 admin 接口；批量分配多传敏感字段。
限流试换 IP/Token 绕过；GraphQL 关内省、防过度字段；HPP 与 SSRF 别漏。
防御核心：服务端校验所有权、字段白名单、强鉴权、限流、关调试入口。

到此，五阶段的 APP 渗透与 API 渗透七章就讲完了。从信息收集、证书绕过、反编译脱壳、小程序逆向，到一次完整实战，再到 API 的种类与打法，你已经具备移动端与 API 安全测试的主干能力。后面还有代码审计、Java 生态漏洞、渗透框架与加固等阶段，我们下回继续。

网络安全