从Swagger文档到权限提升：一个真实API漏洞挖掘的完整复盘与避坑指南
去年参与某金融科技公司的众测项目时，我意外发现了一套暴露在公网的Swagger文档。这个看似普通的发现，最终演变成一次完整的权限提升攻击链。本文将用第一视角还原整个过程，重点分享那些容易被忽略的细节和思维转折点。
1. 信息收集：从Swagger文档到API端点测绘
那是一个周四的凌晨，我在进行常规的资产梳理时，发现目标域名下存在/v2/api-docs路径。访问后，一份完整的Swagger UI界面赫然在目——这就像拿到了整个API系统的设计蓝图。
关键发现点：
- 文档暴露了
/api/v1/admin接口组，但直接访问返回403 - 用户管理模块包含
PATCH /api/v1/users/{id}接口 - 文档中标注了
isActive参数，但未提及role字段
我立即用Postman构建了基础请求模板：
GET /api/v1/users/me HTTP/1.1 Host: target.com Authorization: Bearer [placeholder]此时遇到第一个坑：直接复制文档中的example值会导致服务器返回500错误。后来发现需要先通过/oauth/token获取有效token，而文档中的示例是过时的。
2. 接口交互：隐藏参数与非常规测试
获得普通用户权限后，我开始系统性地测试用户更新接口。Burp Suite的Repeater模块显示，PATCH /api/v1/users/123接口存在几个有趣现象：
| 测试场景 | 请求体 | 响应状态 | 关键发现 |
|---|---|---|---|
| 基础更新 | {"email":"test@test.com"} | 200 | 正常更新 |
| 添加文档未提及字段 | {"email":"test@test.com","role":"admin"} | 200 | 字段被接受但未生效 |
| 布尔值测试 | {"isActive":false} | 200 | 账户被禁用 |
转折点出现在测试数组参数时。偶然发现当传入嵌套对象时：
{ "preferences": { "notifications": true, "metadata": {"role":"admin"} } }服务器返回了包含完整用户对象的响应，其中赫然包含"role": "admin"字段——这个字段在文档和常规响应中从未出现。
3. 漏洞利用：参数污染与权限提升
深入分析发现系统存在两类关键问题：
3.1 对象属性污染
通过以下步骤实现了普通用户到管理员的提权：
- 获取当前用户完整对象：
curl -X GET 'https://target.com/api/v1/users/me' \ -H 'Authorization: Bearer xxxx' - 发现响应包含隐藏的
__proto__字段 - 构造特殊更新请求：
{ "__proto__": { "role": "admin", "permissions": ["*"] } }
3.2 查询参数注入
在用户搜索功能处发现更危险的漏洞：
原始请求： GET /api/v1/users?name=alice 修改后： GET /api/v1/users?name=alice%26role=admin服务器实际执行了MongoDB查询：
db.users.find({ name: "alice", role: "admin" // 注入的查询条件 })4. 防御方案：从开发到运维的全链路防护
经历这次测试后，我总结了API安全的几个关键控制点：
开发阶段：
- 使用
@JsonIgnore注解敏感字段 - 配置ObjectMapper禁用
ACCEPT_EMPTY_STRING_AS_NULL_OBJECT - 对DTO类启用final修饰
运维层面：
# 禁止访问API文档路径 location ~* (swagger|api-docs) { deny all; }测试 Checklist：
- [ ] 验证所有枚举类型参数的边界值
- [ ] 测试JSON数组和嵌套对象处理逻辑
- [ ] 检查Content-Type切换时的解析差异
那次项目最后报了个高危漏洞。有趣的是，修复后他们送来了新的测试环境，我在Swagger文档的"废弃接口"部分又发现了惊喜——但那就是另一个故事了。
