上期回顾 ：我们用 XXE 读了系统文件，用反序列化给程序"下毒"。本期换个口味，聊聊现代开发最爱用的 GraphQL 和那些年我们挖过的 API 坑。
如果你还在用传统 Web 漏洞的思路去测 API，那你就像是在用算盘算火箭轨道------完全不对路。🚀
一、GraphQL：一把双刃剑
GraphQL 是一种用于 API 的查询语言。它的优点是：前端要什么数据，后端给什么数据（按需分配）。
缺点也很明显：开发者经常忘了鉴权。
1. 内省查询（Introspection）：把后端的底裤扒光
GraphQL 默认开启"内省"功能。这意味着你可以像问数据库一样，问服务器："你有哪些表？有哪些字段？"
Payload：
graphql
{
__schema {
types {
name
fields {
name
type {
name
}
}
}
}
}结果：
服务器会返回一份完整的 API 文档！
你看到了 User、Order、Admin等对象，以及它们的字段（如 passwordHash, email）。
SRC 提示 ：如果生产环境没关内省，直接给 中危。
2. 批量查询（Batch Query）：DoS 攻击
GraphQL 允许在一个请求里查 N 个数据。
攻击思路：
graphql
query {
user1: user(id: 1) { name }
user2: user(id: 2) { name }
# ... 重复一万次
user10000: user(id: 10000) { name }
}结果：服务器 CPU 直接飙满，拒绝服务（DoS）。
3. 越权查询（IDOR in GraphQL）
这是最致命的。
请求：
graphql
{
user(id: "1001") {
username
email
isAdmin
passwordHash # 甚至能查密码哈希！
}
}操作 ：把 id从 1001改成 1000（管理员）。
结果：直接拖出管理员账号信息。
二、RESTful API 的经典"翻车"现场
除了 GraphQL，传统的 API 也有一堆坑。
1. 参数污染（HPP）
场景 ：API 接收 ?id=1。
攻击 ：?id=1&id=2&id=3。
后端解析：
-
PHP/Apache：只取最后一个
id=3。 -
Node.js：得到数组
[1,2,3]。利用：绕过 WAF 对某些参数的过滤，或者导致逻辑混乱。
2. JWT 认证绕过
JWT (JSON Web Token) 常用于 API 认证。
漏洞点：
-
None 算法 ：把
alg改成none，去掉签名，服务器可能照单全收。 -
弱密钥 ：用工具
jwt_tool爆破密钥。如果密钥是secret，一秒破解。Payload：
json
{
"alg": "none",
"typ": "JWT"
}结果：伪造管理员 Token，接管账号。
3. 过度数据暴露（Over-exposure）
场景：前端只显示昵称，但 API 返回了全部信息。
请求 ：GET /api/user/1
响应：
json
{
"nickname": "老王",
"phone": "13800138000",
"idCard": "110101199003071234", // 敏感信息泄露
"isAdmin": false
}SRC 评级 ：高危。虽然前端没显示，但数据已经泄露了。
三、实战案例：API 组合拳
-
发现 ：
/graphql端点开启内省。 -
枚举 ：找到
query { users { id, email } }。 -
越权 ：尝试查询
users(id: "admin")成功。 -
接管 ：如果 API 有修改密码接口
POST /api/user/resetPassword，结合越权，直接改掉管理员密码。
四、SRC 报告撰写指南
| 漏洞描述 | 厂商看法 | 评级 |
|---|---|---|
| GraphQL 开启内省 | 知道了，关掉 | 低危/中危 |
| API 返回明文密码 | 严重事故 | 高危 |
| GraphQL 越权拖库 | 灾难级 | **严重 (Critical)** |
报告话术：
"由于 GraphQL 接口未对查询权限进行校验，攻击者可构造恶意查询语句，批量导出全站用户的敏感信息（手机号、邮箱、密码哈希），导致大规模数据泄露。"
五、互动与思考
💬 互动话题：
大家挖 API 漏洞时，最喜欢用什么工具？
是 Postman 、Burp Suite 的 Autorize 插件，还是专门挖 GraphQL 的 InQL？
有没有遇到过那种"API 返回了整个数据库"的爽文时刻？😂
⚠️ 法律红线警示
-
严禁 利用 GraphQL 内省查询进行大规模数据爬取 或拖库。
-
严禁尝试爆破 JWT 密钥后，伪造他人身份登录系统。
-
严禁 利用批量查询进行真实的 DoS/DDoS 攻击，测试时请将数量限制在 10-20 次以内。
-
测试原则：
-
仅在自己的测试账号下验证数据过度暴露。
-
不要尝试修改他人的数据。
-
发现越权漏洞，验证 1-2 个账号即可停止。
**API 是数据的通道，请只做通道的检查者，不要做数据的搬运工。** 🛡️
-
下一期，我们将进入 "移动端安全（Android/iOS）"------ APP 里的那些猫腻"。想知道怎么绕过 SSL Pinning 抓 HTTPS 包吗？敬请期待！📱