【渗透记录】某H5炸金花游戏站支付回调越权导致的资金篡改

一、故事背景

这次是对某H5炸金花游戏站的业务逻辑安全评估。目标系统免下载的 H5 版炸金花游戏，纯网页即点即玩，流量主要来自社交裂变。客户关注的重点是资金安全，因为近期有用户投诉充值异常。我在拿到授权后，把测试重点放在了支付、提现、订单这三个核心业务流程上。业务逻辑漏洞往往比技术漏洞更隐蔽、危害更直接，尤其在涉及资金的系统里，一个逻辑缺陷就可能造成真金白银的损失。

二、信息收集

信息收集阶段，我注册了一个测试账户，先完整走了一遍充值流程。通过抓包发现，充值流程分为三步：第一步创建充值订单，第二步跳转第三方支付，第三步支付完成后第三方回调通知。我重点分析了第三步的回调请求，发现回调地址 /pay/notify 接收的参数包括订单号 order_id、支付金额 amount、支付状态 status 和支付渠道 channel。关键是，这些参数都是明文传输，没有签名字段。

三、漏洞发现

我进一步测试回调接口的校验逻辑。构造了一个伪造的回调请求：把 amount 字段从 10 修改为 10000，保持其他参数不变，然后用 POST 方式重放。出乎意料的是，服务端直接返回了 success，并且我的测试账户余额立即增加了 10000 元。这说明回调接口完全没有对请求来源做验证，也没有校验支付金额与订单金额是否一致，只是盲目信任了客户端传来的参数。

四、漏洞利用

确认漏洞后，我进行了更深入的测试。发现 order_id 参数还可以指定为其他用户的订单号，配合金额篡改，理论上可以为任意账户增加余额。这是一个典型的支付回调越权漏洞，危害等级极高。我还测试了重复回调的场景，发现同一订单可以多次回调、多次入账，即缺少幂等控制。这意味着攻击者可以构造一次支付，然后重放多次回调，实现无限充值。

五、权限获取

我将整个漏洞链条完整记录了下来，包括：伪造回调的请求报文、金额篡改的验证过程、重复入账的复现步骤。由于这是授权测试，我没有进行真实的资金转移，只是在测试环境验证了漏洞的可利用性。最终我将发现提交给客户，并协助其紧急修复了回调接口的验签逻辑，同时对所有已发生的异常订单进行了排查。

六、复盘总结

这次测试说明，支付系统的安全不能只依赖支付渠道本身的可靠性，服务端的回调校验至关重要。修复建议：第一，回调必须验签，使用第三方支付提供的密钥对回调参数做签名校验；第二，回调金额必须与订单金额严格比对，不一致则拒绝；第三，回调处理必须做幂等，同一订单只能入账一次；第四，对异常回调做监控告警，及时发现攻击行为。

本文为授权安全评估实录，目标均已脱敏（IP 为文档保留段），仅用于安全研究与学习交流。