赏金故事 | 绕过邀请流程，获取管理员访问权限

扫码领资料

获网安教程

来Track安全社区投稿~  

赢千元稿费！还有保底奖励~（https://bbs.zkaq.cn）

在这篇文章中，我将分享我是如何在一个 Web 应用中发现一个访问控制缺失（Broken Access Control，BAC）漏洞的。这个漏洞使我在邀请被禁用之后，仍然能够获得该公司的完整管理员权限。

首先，让我们了解一下这个应用是如何工作的：

以下是该应用中的正常用户流程：

1. 1. 创建一个账户。
2. 2. 创建一家公司。
3. 3. 你可以邀请其他人加入你的公司（作为管理员或员工）。

被邀请的用户会收到一封带有加入链接的电子邮件。

一旦他们接受邀请，就会加入你的公司。

现在事情开始变得有趣了……

如果你是公司的所有者，你可以在对方接受邀请之前禁用该邀请。

一旦被禁用，被邀请的人点击他们的链接时，就会看到如下内容：

如果他们在登录后尝试手动切换到那家公司，也会遇到错误。

到目前为止，一切看起来都很稳固，前端在正常工作。但这时我产生了一个想法……

如果我直接与后端通信会怎么样？

在使用 Burp Suite 研究这个应用时，我注意到了一些东西：

该应用使用了经典的 Authorization: Bearer <token> 头来验证你是否已登录以及你可以执行哪些操作。

“如果我在邀请被禁用之后，仍然使用我的 token 手动发送 API 请求，会怎么样？”

于是我尝试了。

以下是我一步一步做的操作：

1. 1. 创建了两个账户：账户 A（公司所有者），账户 B（攻击者）。
2. 2. 用账户 A 邀请账户 B 作为管理员。
3. 3. 在我接受邀请之前，我登录账户 A 并禁用了该邀请。
4. 4. 然后我登录账户 B，打开 Burp Suite，获取了我的授权 token（Authorization token）。
5. 5. 我开始直接操作 API 请求 —— 不通过前端。

你猜怎么着？

成功了，居然真的成功了。

我可以：

• • 访问公司
• • 邀请新用户
• • 移除现有成员
• • 重新邀请我自己
• • 基本上就像一个完整的管理员一样操作

问题原因

后端只检查了 token 是否有效，以及用户是否在被邀请列表中。

它根本不关心我是否接受了邀请，也不关心邀请是否已被禁用。

只要你有一个有效的 token + 你在被邀请列表中 = 你相当于是管理员。

这就是一个典型的访问控制缺失（Broken Access Control）漏洞。

于是我向该项目提交了这个漏洞，他们成功复现了，并对其进行了分类处理（triage）。