GraphQL 邀请流程IDOR导致账户接管复现

本文章仅用于网络安全研究与学习，请勿使用相关技术进行违法犯罪活动。
声明：本文搬运自互联网，如你是原作者，请联系我们！
类型：IDOR

图片来源：象形图

各位黑客朋友们，我是帕尔特·纳鲁拉 (Parth Narula)。我是一名渗透测员、漏洞猎手、红队成员，也是一名安全研究员。我热爱那些跳出思维定式、破解关键漏洞的时刻。

事情起因是我在测试一款聊天支持 SaaS 软件的团队管理功能。表面上一切正常，邀请流程也一切如常。但网络流量里的一个小细节引起了我的注意，最终我发现自己创建了一些本不应该创建的账户。

假设目标对象已被 redacted，就像其他任何 SaaS 环境一样。

从用户界面角度看，这个流程非常简单：只有一个 “邀请代理” 按钮。我作为 evil.com 的所有者，可以邀请代理/成员加入我的团队。

点击后会弹出一个窗口，我可以输入一个或多个邮箱并发送邀请。这是非常常见的功能，所以当时我并没有觉得有什么异常。

我输入受害者邮箱 victim1234@gmail.com 并点击“邀请”，随后把注意力转移到 Burp Suite。该应用使用 GraphQL，因此所有请求都通过单个 /graphql 端点完成，而不是多个 REST 端点。

发送的请求看起来像是一个标准的 GraphQL mutation。

截获的请求如下所示：

POST /graphql/ HTTP/2
Host: redacted
Content-Type: application/json
{
  "operationName":"InviteAgentsFromInviteAgentModal",
  "query":"mutation InviteAgentsFromInviteAgentModal($emails: [String!]!) { inviteAgents(emails: $emails) { success message invitations { id email __typename } failedEmailInvitations __typename } }",
  "variables":{
    "emails":["victim1234@gmail.com"]
  }
}

乍一看，这似乎没什么问题：我只是邀请对方，服务端发送邀请邮件也合理。真正让我警觉的是 响应。

服务器返回了以下 JSON 数据：

{
  "data": {
    "inviteAgents": {
      "success": true,
      "message": "Successfully invited agents",
      "invitations": [
        {
          "id": "4ffacc07efdecea45dc4a0f1c4a704e9d1",
          "email": "victim1234@gmail.com"
        }
      ],
      "failedEmailInvitations": []
    }
  }
}

这个 id 立刻引起了我的注意。它看起来不像“仅供内部使用”的普通标识符。因为在我之前的测试中，我在激活链接里见过类似形态的值。于是我复制了这个 id，开始确认它究竟会在什么地方被使用。

根据经验，受邀用户通常会用类似 /signup/activate/<token> 的 URL 来激活账户。之前我邀请过自己，URL 是这样的：

https://[REDACTED]/signup/activate/eb3b13efdec3415384a0f1c4a773f576

也就是说，在 /signup/activate/ 之前的部分都是固定的，我们只需要替换令牌即可。我把响应里拿到的令牌替换进激活链接中。

结果让我很意外：浏览器直接打开了账户激活页面。页面要求我设置账户名称和密码，但完全不需要点击邮箱里的链接 （因为激活令牌已经从 API 响应里泄露出来了）。

我填写了相关信息，把名称设置为 hacked account，然后提交表单。账户创建成功。

几秒后，我刷新了团队管理页面。

受邀邮箱现在显示为我团队中的活跃代理；显示名称与我激活时输入的名称完全一致。整个过程里，我从未访问受害者邮箱。一切之所以能顺利发生，是因为应用在 GraphQL 响应中公开了激活令牌，并且下游流程无需任何额外校验就信任该令牌。

有趣的是，整个链路非常短：

• 我邀请一个邮箱地址
• API 返回一个 id
• 这个 id 可以直接用于激活 URL
• 令牌与邮箱“实际所有权”之间没有绑定关系
• 仅凭令牌就足以完成账户创建

这就是一个典型的 IDOR 在现代 GraphQL 应用中的表现：一个看似无害的标识符，最终却扮演了“强令牌”的角色。一旦它通过 API 响应泄露，下游所有组件就会盲目信任它。

吸取的教训

• 并非所有 ID 都是无害的。如果某个标识符能够改变账户状态，就必须将其视为机密信息。
• 基于电子邮件的流程，必须在服务器端强制执行所有权证明，而不是只信任令牌本身。
• 如果字段未经严格审查就暴露出来，GraphQL 响应可能会在你不注意时泄露敏感数据。
• 当应用在没有进行适当验证或范围界定的情况下信任公开标识符时，IDOR 往往就会出现。

推荐阅读：更多 Web 安全/渗透测试相关话题，也可以到 云栈社区 继续交流与沉淀。