如何通过BAC绕过邀请流程，并获得管理员权限的

大家好！

在这篇技术分享中，我将分享我如何在一个Web应用程序中发现了一个BAC的漏洞。这个漏洞让我成功获取了一家公司的完整管理员权限——即便我的邀请已经被禁用了。

首先，我们来了解一下这个APP是怎么工作的。

APP中的正常用户流程是这样的：

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

1. 被邀请的用户会收到一封包含加入链接的邮件。 
2. 一旦他们接受邀请，他们就加入了你的公司。 

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

 一旦禁用，如果被邀请的人点击他们的链接，他们会看到这个： 如果他们登录后尝试手动切换到该公司，同样会遇到错误。 

到目前为止，一切看起来都很稳固。前端正在尽职尽责。但这时，我冒出了一个念头…

如果我直接和后端“对话”呢？

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

该应用使用经典的 Authorization: Bearer <token> 请求头来验证你是否已登录以及你能做什么。 

“如果我直接用我的 token 手动发送 API 请求呢——即使我的邀请已经被禁用了？”

于是，我动手尝试了。

以下是我的操作步骤：

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

结果你猜怎么着？

它成功了。它居然TMD成功了！

我能够：

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

为什么会这样？

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

它并不关心我是否已经接受了邀请。它也不关心邀请是否已被禁用。

只要你有一个有效的 token + 你在邀请列表中 = 你就进去了。

这就是一个典型的Broken Access Control漏洞。

所以我把这个漏洞提交给了他们的项目，他们成功复现了问题，漏洞也得到了分类处理。