一、先搞懂GraphQL 到底是什么在聊漏洞之前先科普下 GraphQL 的核心逻辑老手可直接跳过——毕竟很多开发者都在用 GraphQL却未必真正理解它的架构特性这也是漏洞频发的根源。GraphQLGraph Query Language图查询语言是由 Facebook 2012 年内部研发、2015 年开源的API 查询语言与服务器端运行时核心定位是替代传统 REST API解决 REST 接口“数据冗余”“多接口多请求”的痛点目前已被 GitHub、PayPal 等众多平台广泛采用。和 REST API 相比GraphQL 有两个最核心的特点也是它的优势同时也是安全漏洞的重灾区1. 单一端点所有操作统一入口REST API 是“多接口多路径”比如查询用户用/api/user、修改密码用/api/user/updatePwd、删除内容用/api/article/delete可以通过 URL 路径直接做权限区分而 GraphQL 所有操作查、改、删、添、上传都走同一个端点通常是/graphql后端无法通过 URL 路径判断操作权限只能依赖 Resolver解析函数做校验。2. 客户端按需请求灵活性极高REST API 会固定返回整包数据比如请求/api/user/1会返回用户所有字段容易造成数据冗余而 GraphQL 允许客户端自主指定需要的字段比如只查用户名和邮箱就不会返回密码、手机号等多余信息极大提升了网络效率尤其适合移动端场景。举个简单的 GraphQL 查询示例查询用户信息query { user(id: 1) { name # 只请求用户名 email # 只请求邮箱 } }响应结果会和查询结构完全一致不多返回任何冗余数据——这是它的优势但也埋下了安全隐患灵活性越高权限控制的难度就越大一旦校验缺失攻击者就可能利用该漏洞获取非授权数据或操作。补充一句GraphQL 并非数据库查询语言如 SQL而是客户端与服务端之间的数据交互协议。其权限控制的核心在于 Resolver 的实现。二、步入正题GraphQL 权限缺失隐患不容忽视网上关于 GraphQL 安全的文章大多集中在“信息泄露”“内省查询”“深度嵌套 DoS”这三类却极少有人关注Mutation增删改操作的权限控制缺失——而这正是我近期在真实渗透测试中发现的致命漏洞也是本文的核心GraphQL 权限控制若存在缺失各类操作查、改、删、添、上传、查看个人信息都可能被越权执行任意用户密码重置就是其中典型且高危的场景。先从最直观、最高危的「任意用户密码重置」说起——这是我第一个发现的漏洞也是最容易被忽视、网上报道极少的场景。1. 实战漏洞任意用户密码重置无限制、无验证本次测试的系统的 GraphQL 接口为POST /mmm-dgraph-backend-http-server/graphql核心漏洞出在updateUser这个 Mutation 操作上用于修改用户信息。1.1 漏洞触发场景系统新用户注册时默认密码为 6 个 6登录后会强制修改新密码。此时抓包发现修改密码的请求正是调用updateUser接口传入loginUserName目标账号、newPassword新密码两个核心参数无任何其他校验。关键发现无论目标用户是否改过密码、改了多少次、密码多复杂只要传入其账号就能直接覆盖重置密码——学生、老师、管理员等各类角色均可能受影响无需原密码、无需短信/邮箱验证码普通用户即可操作。1.2 越权重置 Payload 示例mutation UpdateUser($targetAccount: String!, $newPwd: String!, $updateTime: Date!) { updateUser( filter: { account: $targetAccount }, set: { password: $newPwd, updatedAt: $updateTime } ) { user { account updatedAt } } }请求变量自定义目标账号和新密码{ targetAccount: targetUser, # 目标账号示例非真实账号 newPwd: examplePwd123., # 自定义新密码示例 updateTime: 2026-04-12T10:00:00Z }1.3 漏洞本质核心逻辑问题这个漏洞的本质不是某个接口的“小bug”而是GraphQL 权限设计的根本性逻辑错误后端 Resolver 代码的核心问题的是只校验“用户是否登录”不校验“当前用户是否有权限修改该账号”也不校验“数据归属权”。用伪代码还原漏洞现场错误逻辑# 漏洞代码后端 Resolver 逻辑 def resolver_updateUser(args, context): # 只校验是否登录不校验操作权限 if not context.current_user: return PermissionDenied(请先登录) # 直接根据传入的 loginUserName 定位用户覆盖密码 loginUserName args[filter][login_user_name] newPassword args[set][password] db.user.update_one( {login_user_name: loginUserName}, {$set: {password: hash(newPassword)}} ) return {success: True}一句话总结只认账号不认人只认登录不认权限无旧密码、无二次验证直接覆盖——这属于典型的“失效的访问控制”OWASP Top 1 2021也是 GraphQL Mutation 操作中常见的安全疏漏。2. 延伸风险权限缺失可能导致全功能越权发现任意用户密码重置漏洞后进一步测试发现若权限控制存在缺失GraphQL 的各类操作都可能被越权执行——这是由 GraphQL 单一端点的架构特性决定的也是目前相关安全报道中较少提及的风险点。结合本次测试场景以及 GraphQL 通用安全特点若权限控制不到位以下操作均可能出现越权情况普通用户操作其他用户或管理员数据2.1 越权查看获取任意用户/管理员敏感信息通过queryUser、queryAllStudents等 Query 操作普通用户可直接查询其他用户的手机号、身份证号、成绩、考勤等敏感信息甚至可通过queryAllAdmins获取所有管理员账号信息——这正是我之前发现的“全校身份信息泄露”漏洞与密码重置漏洞形成“组合拳”先批量获取账号再批量重置密码。越权查看 Payload 示例query { user(login_user_name: admin_001) { # 管理员账号 name identity_card # 身份证号明文 mobile_number # 手机号明文 role # 角色信息管理员 } }2.2 越权修改篡改任意用户信息除了重置密码通过updateUser接口还可能修改任意用户的手机号、邮箱、头像、角色等信息——例如将普通用户角色改为“admin”获取管理员权限或修改他人手机号接收验证码进而接管账号。2.3 越权删除删除任意用户/内容若系统存在deleteUser删除用户、deleteArticle删除文章等 Mutation 操作普通用户可能直接删除其他用户的账号、发布的内容甚至删除管理员账号影响系统正常运行。2.4 越权上传上传恶意文件到任意目录若系统存在uploadFile接口普通用户可能上传恶意文件如webshell到管理员目录、其他用户空间进而获取服务器权限对系统造成进一步渗透影响。2.5 越权发布冒充他人发布内容通过createArticle、createNotice等接口普通用户可能传入他人的账号 ID冒充老师、管理员发布通知、公告甚至发布不良信息造成负面影响。这里有一个核心结论也是本文最有价值的观点建议单独加粗放在文章中GraphQL 越权并非单点漏洞可能引发系统性安全风险。若权限控制缺失查看、修改、删除、上传、发布、重置密码等操作都可能被越权执行。3. GraphQL 易出现全功能越权的原因核心原因在于开发者对 GraphQL 权限设计的理解存在疏漏容易混淆“登录校验”和“权限校验”具体主要有3点1. 误区一“只要用户登录了就可以调用所有接口”——忽略了“数据归属权”比如普通用户只能操作自己的账号不能操作他人的2. 误区二“GraphQL 只需要做入口校验”——忽略了 GraphQL 单一端点的特性无法通过 URL 控制权限必须在每个 Resolver、每个字段上做细粒度校验3. 误区三“Mutation 操作和 Query 操作权限一致”——忽略了 Mutation 是“写操作”增删改风险远高于 Query读操作需要更严格的权限控制和二次验证。对比 REST API 和 GraphQL 的权限控制差异更能理解这个问题对比维度REST APIGraphQL权限控制方式可通过 URL 路径、HTTP 方法做粗粒度控制只能通过 Resolver 做细粒度控制字段级、操作级操作入口多接口、多路径单一接口/graphql开发者易犯错误路径权限配置遗漏只做登录校验不做数据归属权校验三、漏洞危害与实战利用链2. 完整利用链从信息泄露到系统接管结合本次测试发现的两个核心漏洞完整利用链如下可直接写进漏洞报告Step 1通过 GraphQL 内省查询未关闭获取系统所有 Query、Mutation 接口确认queryAllStudents批量查询用户和updateUser修改用户接口的存在Step 2调用queryAllStudents接口传入first: 100000、offset: 0批量获取全校所有用户的login_user_name学号/手机号Step 3调用updateUser接口批量重置所有用户含管理员的密码自定义新密码Step 4用重置后的密码登录任意目标用户账号接管账号后可能进一步越权修改、删除数据或上传文件对系统安全造成严重影响。四、漏洞修复建议方案针对 GraphQL 权限缺失导致的全功能越权修复的核心是“做细粒度的权限控制”从紧急修复到长期加固分两步落地1. 修复建议1. 强数据归属权校验核心修复所有 Query、Mutation 接口必须校验“当前登录用户 ID 目标用户 ID”普通用户只能操作自己的账号管理员只能操作授权范围内的账号正确 Resolver 逻辑伪代码def resolver_updateUser(args, context): currentUser context.current_user # 当前登录用户 # 1. 校验是否登录 if not currentUser: return PermissionDenied(请先登录) # 2. 定位目标用户 targetUser db.user.find_one({login_user_name: args[filter][login_user_name]}) # 3. 核心校验只能修改自己的账号管理员需额外判断角色 if currentUser.id ! targetUser.id and currentUser.role ! admin: return PermissionDenied(无权限修改该用户信息) # 4. 校验原密码新增 if not verify_password(args[oldPassword], targetUser.password): return PermissionDenied(原密码错误) # 5. 执行密码更新 db.user.update_one(...) return {success: True}2. 增加二次验证修改密码、删除账号、修改角色等敏感操作必须增加原密码校验、短信/邮箱验证码二次验证禁止无验证直接操作3. 限制批量操作单次请求只能操作一个用户/一条数据禁止批量修改、批量删除4. 关闭生产环境内省查询禁用__schema、__type等内省查询避免接口结构泄露不给攻击者“全图透视”的机会5. 敏感字段脱敏身份证号、手机号等敏感信息仅本人和管理员可查且必须脱敏如 1****************9。2. 长期加固1. 实现字段级操作级双重权限控制每个字段、每个 Query/Mutation 操作都要单独做权限校验不能一刀切2. 区分 Query 和 Mutation 权限Mutation 操作增删改的权限控制要比 Query 操作读更严格3. 做查询复杂度、深度限制防止深度嵌套查询导致 DoS 攻击同时限制单次查询的字段数、数据量4. 全量日志审计记录所有 GraphQL 操作请求 IP、用户、操作内容、时间便于漏洞溯源和攻击排查5. 定期安全测试针对 GraphQL 接口重点测试越权、注入、批量操作等漏洞避免类似问题重复出现6. 规范 Resolver 开发将权限控制逻辑抽离为公共工具函数避免重复开发导致的校验遗漏同时将权限控制移至业务逻辑层而非仅在 Resolver 中简单校验。五、漏洞挖掘思路结合本次实战经验给大家分享一套 GraphQL 越权漏洞的挖掘思路适用于所有使用 GraphQL 的系统新手也能快速上手1. 第一步判断系统是否使用 GraphQL——查看请求地址若存在/graphql端点且请求方法为 POST大概率是 GraphQL 接口2. 第二步尝试内省查询获取所有接口结构——通过__schema查询获取所有 Query、Mutation 接口以及参数、返回字段3. 第三步测试 Query 接口越权——用普通用户登录尝试查询其他用户、管理员的信息看是否能成功返回4. 第四步测试 Mutation 接口越权——重点测试updateXXX、deleteXXX、createXXX等操作尝试操作其他用户的数据5. 第五步测试批量操作——尝试在一个请求中批量查询、批量修改多个用户的数据看是否能绕过限制6. 第六步测试敏感操作——重点测试密码重置、角色修改、文件上传等操作看是否需要二次验证、是否有权限校验。六、总结与思考GraphQL 的灵活性是其显著优势但也使其成为安全漏洞的高发领域。本文所剖析的「GraphQL 权限缺失可能导致全功能越权」问题之所以相关报道较少核心原因是多数开发者、安全从业者更多关注 GraphQL 的“查询侧”安全而忽视了“修改侧”Mutation的权限控制——这恰恰是容易引发高危风险的环节。最后用一句金句总结本文核心也希望能提醒所有开发者GraphQL 安全离不开登录校验、操作权限校验、数据归属权校验三者缺一不可。任何一项缺失都可能导致系统出现越权漏洞给攻击者可乘之机。希望本文能填补网上 GraphQL 安全领域的相关空白让更多开发者重视 GraphQL 权限设计也让更多安全从业者掌握这类漏洞的挖掘思路共同提升系统安全防护水平。声明合规必加本文仅用于网络安全技术交流、漏洞防御科普所有案例均为授权测试或已修复场景。严禁未经授权对任何系统进行渗透测试违者自行承担法律责任。创作不易收藏关注后续持续更新实战漏洞分析、渗透测试技巧