上期回顾我们用 XXE 读了系统文件用反序列化给程序“下毒”。本期换个口味聊聊现代开发最爱用的GraphQL 和那些年我们挖过的API 坑。如果你还在用传统 Web 漏洞的思路去测 API那你就像是在用算盘算火箭轨道——完全不对路。一、GraphQL一把双刃剑GraphQL 是一种用于 API 的查询语言。它的优点是前端要什么数据后端给什么数据按需分配。缺点也很明显开发者经常忘了鉴权。1. 内省查询Introspection把后端的底裤扒光GraphQL 默认开启“内省”功能。这意味着你可以像问数据库一样问服务器“你有哪些表有哪些字段”Payloadgraphql{ __schema { types { name fields { name type { name } } } } }结果服务器会返回一份完整的API 文档你看到了User、Order、Admin等对象以及它们的字段如passwordHash,email。SRC 提示如果生产环境没关内省直接给中危。2. 批量查询Batch QueryDoS 攻击GraphQL 允许在一个请求里查 N 个数据。攻击思路graphqlquery { 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 接收?id1。攻击?id1id2id3。后端解析PHP/Apache只取最后一个id3。Node.js得到数组[1,2,3]。利用绕过 WAF 对某些参数的过滤或者导致逻辑混乱。2. JWT 认证绕过JWT (JSON Web Token) 常用于 API 认证。漏洞点None 算法把alg改成none去掉签名服务器可能照单全收。弱密钥用工具jwt_tool爆破密钥。如果密钥是secret一秒破解。Payloadjson{ 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 包吗敬请期待