【思路】某H5炸金花游戏站的API逻辑漏洞批量提现

一、故事背景

这次对某H5炸金花游戏站做业务逻辑安全评估。目标系统免下载的 H5 版炸金花游戏，纯网页即点即玩，流量主要来自社交裂变。客户重点关注提现功能，因为涉及资金安全。我在拿到授权后，重点测试了提现流程中的逻辑漏洞，尤其是并发场景下的竞态条件问题。竞态条件漏洞隐蔽性强，但一旦被利用，可能造成直接的资金损失。

二、信息收集

信息收集阶段，我注册了一个测试账户并充值了 100 元作为测试资金。提现流程是：提交提现申请 → 系统校验余额 → 冻结余额 → 生成提现记录 → 异步打款。我抓包分析了提现接口的请求，发现余额校验和扣款是两个独立的操作。

三、漏洞发现

我设计了竞态条件的测试：同时发送多个提现请求。由于余额校验和扣款之间没有加锁，多个请求可能同时通过余额校验，然后分别扣款，导致扣款总额超过实际余额。我用 Burp Suite 的 Intruder 模块，将同一个提现请求并发发送 10 次，每个请求提现 100 元。

四、漏洞利用

测试结果显示，10 个并发请求中有多个请求都通过了余额校验并成功扣款，而账户余额只有 100 元。这意味着我可以通过并发提现实现超额提现，实际提现金额远超账户余额。这是典型的竞态条件导致的资金损失漏洞。

五、权限获取

我验证了漏洞的可复现性，多次测试均能触发超额提现。我把完整的复现步骤、请求报文、并发参数整理成报告。由于这是授权测试，我没有进行真实的资金转移，只在测试环境中验证了漏洞。客户确认了漏洞存在，并紧急修复了提现接口，加入了数据库行锁。

六、复盘总结

这次评估的核心教训是：涉及资金的并发操作必须做原子性处理。修复建议：第一，余额校验和扣款必须在同一个数据库事务中完成，并使用行锁（SELECT ... FOR UPDATE）；第二，提现请求做幂等处理，同一请求只能处理一次；第三，对单账户的并发提现做限制；第四，建立资金对账机制，及时发现异常的资金变动。

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