GraphQL 安全测试

要解决的问题

GraphQL 接口的安全测试往往散落在各种工具文档里：有的只讲内省查询，有的只讲注入 Payload，缺少一条能从头走到尾的排查路径。实际评估一个 GraphQL 端点时，你会面对一组连贯的问题：

• 端点是否在生产环境暴露了完整 schema，攻击者能否用一行 __schema 查询完成侦察？
• 查询深度、复杂度和别名滥用是否被限制，能否用嵌套查询或批量请求打挂 resolver？
• 查询和 mutation 中的 ID 是否做了授权校验，替换 ID 就能读到别人数据（IDOR）的情况是否存在？
• 字符串参数进入数据库或系统命令时有没有注入点（SQLi、NoSQLi、SSRF、命令执行）？
• 订阅走 WebSocket 长连接时，连接建立后的鉴权是否还会重新校验，会不会随时间泄漏数据？
• 客户端拿到的 Relay 全局 ID、错误信息里的字段建议、Apollo 的扩展响应，这些看似无害的细节是否在泄露内部结构？

这个技能如何工作

它把上述问题整理成一份按顺序执行的操作清单，核心流程分为三步。

第一步：侦察与 schema 获取。 先通过 /graphql、/graphiql 等常见路径和浏览器开发者工具确认端点；然后发送内省查询 {__schema{types{name}}} 拉取完整 schema，分析其中的敏感类型、字段、mutation 和订阅。如果内省被关闭，则退到字段猜测路线：用 __typename 做存活探测，再借助 clairvoyance、inql 等工具配合词表爆破类型和字段名。

第二步：分类测试。 清单覆盖六个测试面：信息泄露（用户数据、配置）、授权绕过（IDOR、权限检查缺失）、注入（在字符串参数中投递 SQL/NoSQL/OS/XSS/SSRF 载荷）、拒绝服务（深层嵌套、limit: 999999、批量请求、@include/@skip 指令洪泛）、业务逻辑缺陷（mutation 的竞态与副作用），以及订阅连接鉴权。每一步都给出可执行的具体手法，比如用别名重复请求绕过复杂度限制、解码 base64 的 Type:ID 做 IDOR 枚举、探测 Did you mean... 错误信息恢复字段名。

第三步：绕过与升级。 针对 WAF 给出查询变形（别名、片段、空白差异、嵌套输入对象）和 @defer 隐藏敏感字段的手法；针对授权缺陷给出链式利用路径，例如 IDOR 泄漏 ID 后通过 mutation 改他人邮箱、SSRF 打内网 GraphQL 端点、错误信息泄露数据库结构后再构造定向 SQLi。最后列出生产加固方向：关闭内省、在 schema 层和 resolver 层双重鉴权、参数化查询、深度/复杂度限制，以及 GraphQL Armor 这类中间件。

适用边界与注意点

这份清单面向的是安全评估视角——渗透测试、bug bounty、应用上线前自查。它不负责修复代码，也不替代服务端本身的权限模型设计。

• 目标授权是前提。 DoS 测试、批量滥用和指令洪泛都会真实消耗服务端资源，未获授权的目标上不应执行。
• 工具链按场景选。 graphw00f 做指纹识别（Apollo/Yoga/Hasura），graphql-cop 做配置审计，Nuclei 跑模板，Burp Suite 配合 inql 做人工 Fuzz；不同目标适合的组合不同，清单只列能力不强制流程。
• 语言生态差异要留意。 async-graphql（Rust）与 Apollo Server 在指令洪泛、@defer 行为上的表现不一致，CVE 编号和复现条件需要按具体实现核实。
• 订阅和联邦网关是薄弱点。 WebSocket 长连接的 token 过期复验、跨 subgraph 的授权一致性，通常是常规测试最容易漏掉的部分，清单里单列了测试项但需要结合目标架构判断。