🔎 引言

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

⚙️ 漏洞背景

该问题源于服务器未能正确验证输入。用户界面确实限制了最低2,000信用点，但后端仍然接受通过请求修改的信用点数值。

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

复现步骤

1. 登录服务账户
2. 打开定价页面，选择2,000信用点套餐，然后点击结算
3. 在按下支付选项→继续时，拦截结算会话创建请求
4. 将JSON主体中的"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项目团队标记为"重复"状态关闭，因为类似的漏洞之前已被报告过。