FreeBuf.COM网络安全行业门户，每日发布专业的安全资讯、技术剖析。

特权升级漏洞是一种安全缺陷，它允许某个用户获取比应有权限更高的权限。换言之，它使得权限受限的用户可以执行本应只有更高权限用户（比如管理员或所有者）才能做的操作，可能会因此未经授权地控制数据、设置，甚至整个系统。我在一个创业融资平台上发现了这样一个漏洞：可以把自己从 Viewer（查看者）升级为 Owner（所有者）。在该问题修复后，我又找到了一个绕过修复的方法，并负责任地披露了该问题。

该平台允许用户创建初创公司并管理团队。邀请成员时会分配角色：Viewer、Editor 或 Owner。Owner 拥有全部控制权。

事情从一件看似完全正常的事开始。我在浏览管理后台，检查用户管理、访问控制和权限等功能。表面上没什么异常。

然后我注意到一个细微之处 —— 当 Owner 邀请我作为 Viewer（最低权限）时，同时还有一个面向另一个用户的待处理 Owner 邀请，那条 Owner 邀请链接仍然存在：

https://example.com/invitations/{hash_token}

我想到了一个念头：如果我尝试使用这条链接以另一个人的身份加入会怎样？一开始系统会阻止我，要求我用被邀请用户的账号登录。

经过进一步的策划和测试，我拦截了这个请求：

GET /invitations/{invitation_token}

通过拦截响应，我看到了被邀请 Owner 的邮箱和角色。我在响应中把邮箱改成了我之前用 Google 在同一浏览器上注册过的邮箱，然后继续后续流程。

我修改响应，把被邀请的邮箱替换为我之前用 Google 注册在同一浏览器里的邮箱。

Boom! 我被添加到了团队，且角色是 Owner，从而可以删除原来的 Owner，完全接管该公司。

我把此问题报告了，漏洞被修复并获得了赏金。

绕过修复：

修复措施使得待处理邀请仅对角色匹配的用户可见 —— Viewer 只看见 Viewer 邀请，Editor 看见 Editor 邀请，Owner 看见 Owner 邀请。

我接着尝试再次绕过该修复。

我没有就此止步 —— 我分析了请求与修复逻辑，发现了绕过场景。

当一个 Editor 发起邀请动作（发送邀请）时，后端对该邀请请求的响应载荷中包含了所有的待处理邀请（包括 Owner 的邀请）。

这意味着一个 Editor（或具有 Editor 级别请求能力的人）可以在响应中看到或提取到 Owner 邀请的哈希，即使前端 UI 不再展示这些邀请。

我也把这个绕过方法举报了，并在披露后再次获得了奖励。

这是一个业务逻辑层面的特权升级漏洞，需要对邀请工作流有深入理解。教训是：仅靠前端修复不足以防止此类问题；必须在服务端进行严格校验。即便问题看似修复，也要分析后端 —— 可能还藏着等待被发现的绕过方法。

免责声明

1.一般免责声明：本文所提供的技术信息仅供参考，不构成任何专业建议。读者应根据自身情况谨慎使用且应遵守《中华人民共和国网络安全法》，作者及发布平台不对因使用本文信息而导致的任何直接或间接责任或损失负责。

2. 适用性声明：文中技术内容可能不适用于所有情况或系统，在实际应用前请充分测试和评估。若因使用不当造成的任何问题，相关方不承担责任。

3. 更新声明：技术发展迅速，文章内容可能存在滞后性。读者需自行判断信息的时效性，因依据过时内容产生的后果，作者及发布平台不承担责任。

本文为 独立观点，未经授权禁止转载。
如需授权、对文章有疑问或需删除稿件，请联系 FreeBuf 客服小蜜蜂（微信：freebee1024）