🧩 引言

在测试一个主要项目管理平台时，我发现了一个微妙但影响重大的业务逻辑缺陷。这不是典型的XSS或SQL注入漏洞——仅仅是一个静默控制付费计划访问权限的单个参数。

通过修改这个参数，我可以在无需批准或付款的情况下立即激活企业级功能。这一发现为我赢得了947美元的赏金，再次证明逻辑漏洞与技术漏洞同样具有威力。

🔍 背景

我正在测试一个免费计划下新创建的工作区。当尝试使用高级功能时，应用显示消息：“您正在使用免费计划——开始免费试用以解锁这些功能。”

自然，我点击了"开始免费试用"来观察平台如何处理升级请求。我使用Burp Suite拦截了请求，这个简单的JSON引起了我的注意：

1

{"plan_id":"15"}

这看起来非常像内部计划标识符。在那一刻，我知道值得深入探究。

🧠 想法

我在想——如果我更改计划ID会怎样？不同的ID是否对应更高级别的计划？

于是，我修改了请求体并重新发送：

1

{"plan_id":"16"}

点击Forward，几秒钟内…工作区立即升级到了Business Plus版本。无需确认、无需验证、无需人工批准。

🚀 真正的震惊

如果16解锁了Business Plus，那么17呢？我再次更改：

1

{"plan_id":"17"}

就这样——企业试用被激活了。这通常是一个需要用户验证后由公司团队手动批准的计划。没有安全检查、没有门控逻辑——什么都没有。

后端完全信任我发送的值。

⚠️ 漏洞详情

端点：

1
2
3
4

POST /plan/v2/team/{workspace_id}/trial HTTP/2
Host: <已隐藏>
Authorization: Bearer <有效所有者令牌>
Content-Type: application/json

请求体：

1

{"plan_id":"17"}

问题： 服务器未能验证plan_id参数。任何经过身份验证的工作区所有者都可以操纵此ID，直接解锁Business Plus或企业功能，绕过审批流程。

💥 影响

这个缺陷不仅仅是表面问题——它具有实际的财务影响：

🏴‍☠️ 任何人都可以免费升级到高级或企业计划 💸 由于未经授权的功能访问导致直接收入损失 ⚙️ 绕过内部审批逻辑意味着失去对企业试用系统的控制 🔐 暴露给仅限验证客户使用的高阶工具滥用风险

简而言之，这是一个打击最痛处——计费系统的业务逻辑绕过漏洞。

🛠️ 修复

在我通过负责任披露报告漏洞后，安全团队迅速修补了问题。他们为计划激活请求实施了严格的服务器端验证，确保用户只能启动分配给其账户类型的试用。

他们的快速响应和专业精神值得称赞👏

💰 奖励

对于这一发现，我获得了947美元的赏金——对于一个执行简单但影响严重的逻辑漏洞来说，这是一个相当可观的回报。

看到仔细的观察得到回报——无论是在知识上还是在赏金上——总是令人满意的。

🧭 关键要点

✅ 始终在服务器端验证参数。客户端控制可以轻松通过Burp Suite等工具绕过 ✅ 不要低估业务逻辑漏洞。即使没有任何"技术漏洞"，它们也经常造成财务和功能影响 ✅ 好奇心是你最好的武器。如果某物看起来像ID或标志——更改它、测试它，并观察系统的行为

💡 最终思考

这个漏洞是一个很好的提醒：安全不仅仅是关于注入和漏洞利用——它关乎理解业务如何运作。你拦截的每个请求都在讲述一个故事，有时，这个故事以一个价值近千美元的漏洞结束。

保持好奇心，保持道德，持续学习。🧠✨