文章总结： 本文探讨了在SaaS软件GraphQL邀请流程中发现的一起IDOR漏洞案例。攻击者通过分析API响应获取了本应保密的账户激活令牌，从而绕过邮箱验证直接接管受害者账号。文章详细复现了利用过程，并强调了将状态改变标识符视为敏感信息以及严格服务端验证邮箱所有权的重要性。
综合评分： 82
文章分类： WEB安全,漏洞分析,渗透测试,实战经验
0116.通过 GraphQL 邀请流程中的 IDOR 进行账户接管
原创
Parth Narula
Rsec
2026年1月13日 15:56
贵州
本文章仅用网络安全研究学习，请勿使用相关技术进行违法犯罪活动。
声明：本文搬运自互联网，如你是原作者，请联系我们！
类型：IDOR
图片来源：象形图
各位黑客朋友们，我是帕尔特·纳鲁拉 (Parth Narula)。我是一名渗透测员、漏洞猎手、红队成员，也是一名安全研究员。我热爱那些跳出思维定式、破解关键漏洞的时刻。
事情起因是我在测试一款聊天支持 SaaS 软件的团队管理功能。表面上一切正常，邀请流程也一切如常。但网络流量中的一个小细节引起了我的注意，最终我发现自己创建了一些本不应该创建的账户。
假设目标对象已被 redacted ，就像其他任何 SaaS 环境一样。
从用户界面角度来看，流程极其简单。只有一个 “邀请代理” 按钮。我作为 evil.com 的所有者，可以邀请代理/成员加入我的团队。
点击后会弹出一个窗口，我可以在其中输入一个或多个电子邮件地址并发送邀请。这是一个非常常见的功能，所以当时我并没有觉得有什么蹊跷或可疑之处。
输入受害者邮箱地址 [email protected] 并点击“邀请”后，我将注意力转移到 Burp Suite。该应用程序使用 GraphQL，因此所有请求都通过单个 /graphql 端点进行，而不是多个 REST 端点。
发送的请求看起来像是一个标准的 GraphQL mutation。
截获的请求如下所示：
POST /graphql/ HTTP/2Host: redactedContent-Type: application/json{ "operationName":"InviteAgentsFromInviteAgentModal", "query":"mutation InviteAgentsFromInviteAgentModal($emails: [String!]!) { inviteAgents(emails: $emails) { success message invitations { id email __typename } failedEmailInvitations __typename } }", "variables":{ "emails":["[email protected]"] }}
乍一看，这似乎没什么大碍。我只是在邀请对方发送邮件，服务器也理应发送邀请邮件。但后来我看了看响应。
服务器返回了以下 JSON 数据：
{ "data": { "inviteAgents": { "success": true, "message": "Successfully invited agents", "invitations": [ { "id": "4ffacc07efdecea45dc4a0f1c4a704e9d1", "email": "[email protected]" } ], "failedEmailInvitations": [] } }}
这个 id 立刻引起了我的注意。这不仅仅是一个内部标识符。我之前在激活链接中见过类似的数值。所以，我没有忽略它，而是复制了这个 id ，并试图弄清楚它是在哪里使用的。
根据之前的测试经验，我知道受邀用户通常会使用类似 /signup/activate/<token> 的 URL 来激活他们的账户。之前我邀请过自己，URL 是这样的：
https://[REDACTED]/signup/activate/eb3b13efdec3415384a0f1c4a773f576
所以，在 /signup/activate/ 之前，一切都是静态的，我们只需要更改令牌。我替换了响应中收到的令牌。
令我惊讶的是，这直接把我带到了账户激活页面。该页面要求我设置账户名称和密码。无需点击邮箱中的链接 （因为我们已经从响应中获得了令牌） 。
我填写了详细信息，并将名称设置为 hacked account ，然后提交了表单。账户创建成功。
几秒钟后，我刷新了团队管理页面。
受邀邮件现在显示为我团队中的活跃代理。显示名称与我激活时输入的名称完全一致。我全程无需访问受害者的邮箱。一切顺利进行，完全是因为应用程序在 GraphQL 响应中公开了激活令牌，并且无需任何额外验证就信任了该令牌。
有趣的是，整个流程非常简单。我邀请了一个邮箱地址。API 返回了一个 id 。这个 id 可以直接用于激活 URL。令牌和邮箱的实际所有权之间没有任何关联。仅仅拥有这个令牌就足以完成账户创建。
这是一个典型的 IDOR 问题在现代 GraphQL 应用中出现的例子。一个看似无害的标识符最终会成为一个强大的令牌。一旦它通过 API 响应泄露，下游的所有组件都会盲目信任它。
吸取的教训
- 并非所有 ID 都是无害的。如果某个标识符可以改变账户状态，则必须将其视为机密信息。
- 基于电子邮件的流程必须在服务器端强制执行所有权证明，而不仅仅是信任令牌。
- 如果字段未经严格审查就暴露出来，GraphQL 响应可能会悄无声息地泄露敏感数据。
- 当应用程序在没有进行适当验证或范围界定的情况下信任公开的标识符时，经常会出现 IDOR 问题。
希望你能学到一些新知识。关注我，获取更多精彩文章；如果你喜欢这篇文章，请点赞支持哦 🙂
需要专业的渗透测试服务吗？
访问 https://scriptjacker.in 或让我们一起合作开展您的下一个项目！🤝
想从我的经验中学习吗？请查看我在 https://blogs.scriptjacker.in 上的文章。
免责声明：
本文所载程序、技术方法仅面向合法合规的安全研究与教学场景，旨在提升网络安全防护能力，具有明确的技术研究属性。
任何单位或个人未经授权，将本文内容用于攻击、破坏等非法用途的，由此引发的全部法律责任、民事赔偿及连带责任，均由行为人独立承担，本站不承担任何连带责任。
本站内容均为技术交流与知识分享目的发布，若存在版权侵权或其他异议，请通过邮件联系处理，具体联系方式可点击页面上方的联系我。
本文转载自：Rsec Parth Narula《0116.通过 GraphQL 邀请流程中的 IDOR 进行账户接管》