🔎 引言

在测试HackerOne上一个项目的Web应用程序时，我发现了一个业务逻辑错误漏洞，允许以低于最低限额的价格购买信用点。正常情况下最低购买额为2,000信用点，但我成功创建了仅需100信用点的结账会话。包含的概念验证具有非破坏性，在测试过程中我没有完成或进行实际支付。

⚙️ 漏洞背景

问题出现的原因是服务器没有正确验证输入。用户界面确实限制了最低2,000信用点，但后端仍然接受通过请求修改的信用点数值。

🧪 概念验证（PoC）— 非破坏性

复现步骤

1. 登录服务账户
2. 打开定价页面，选择2,000信用点套餐，然后点击结账
3. 在按下支付选项→继续时捕获结账会话创建请求
4. 将JSON body中的"credits":2000改为"credits":100
5. 转发/发送修改后的请求
6. 检查JSON响应—将包含checkout.session id（例如：{“id”:“cs_XXXXXXXXXXXXX”, …}）

POC — 原始请求体：

1

{"credits":2000,"consent":false,"mode":"payment","success_url":"[REDACTED]","cancel_url":"[REDACTED]"}

POC — 修改后请求体：

1

{"credits":100,"consent":false,"mode":"payment","success_url":"[REDACTED]","cancel_url":"[REDACTED]"}

响应：

1
2

HTTP/2 200 OK
{"id":"cs_XXXXXXXXXXXXX","object":"checkout.session"}

💥 影响

• 直接财务损失：用户可以低于最低价格购买信用点
• 绕过定价策略：如果后端接受原始输入，UI中的最低限额规则将无效
• 大规模利用：有可能通过自动化被滥用

🛠️ 简要建议

在服务器端验证信用点数量，确保只接受官方套餐数值。

✅ 结论

业务逻辑验证应在服务器端执行，而不仅仅在UI端。验证输入的小失误可能导致财务损失并削弱结账系统的完整性。

📌 最终说明

由于之前已经报告过类似的漏洞，该报告随后被HackerOne项目团队标记为"重复"状态。