支付漏洞

凌晨两点，支付漏洞我盯着屏幕上那串返回的支付漏洞HTTP 200，手指有点发抖。支付漏洞不是支付漏洞因为冷，是支付漏洞兴奋。那是支付漏洞一个电商平台的支付接口，我往订单金额字段里塞了负数，支付漏洞系统居然真的支付漏洞给我退了钱。不是支付漏洞漏洞赏金计划里的测试环境，是支付漏洞生产环境，真实用户数据在跑的支付漏洞那种。 这事儿得从支付逻辑说起。支付漏洞大多数人以为黑客攻击是支付漏洞花里胡哨的SQL注入、零日漏洞，支付漏洞但真正值钱的支付漏洞漏洞往往藏在业务逻辑的褶皱里。支付流程尤其如此——它像一条精密的流水线，每个环节都信任上一环节的输出，却没人检查这信任本身是否合理。 我第一次接触支付漏洞是在三年前，给一家小型SaaS公司做安全审计。他们的支付流程是这样的：前端生成订单，把商品ID和数量发给后端，后端计算总价，然后跳转支付网关。听起来没问题对吧？但当我抓包时发现，后端计算总价用的商品价格竟然是从前端传过来的。我改了请求里的单价，从299改成0.01，支付网关那边只验证签名，不核对金额。结果我花了1分钱买了个企业版年费会员。 这不算高明，但足够说明问题——支付系统最危险的假设，就是“服务器会自己算钱”。实际上很多开发者为了省事，会信任客户端传过来的金额、折扣、甚至最终支付状态。他们觉得反正有HTTPS加密，别人看不到内容，但加密只防窃听，不防恶意构造请求。 更隐蔽的漏洞藏在退款逻辑里。有些系统允许部分退款，但没做幂等控制。你发起退款请求，服务器处理完返回成功，但如果你在网络超时后重发同一个请求，某些设计不严谨的系统会再退一次。我见过一个案例，攻击者利用这个逻辑，把一笔100元的订单反复退款，直到把账户余额刷成负数——平台不仅没赚到钱，还得倒贴。 还有种玩法叫“并发竞争”。支付回调通知是异步的，平台收到通知后更新订单状态。如果同一笔订单同时触发多个回调，而数据库没有加锁，就可能出现状态覆盖。攻击者利用这个，先发起一个正常支付，再伪造一个取消通知，让系统先标记已支付再标记已取消，但钱已经到账了。订单状态是“已取消”，钱却进了商户账户，对账时根本对不上。 这些漏洞的共同点是什么？它们都不需要多高深的技术，不需要绕过WAF或者破解密码。只需要理解业务流程，找出那些“开发时假设用户会按正常流程操作”的地方。支付系统最怕的不是黑客，是开发者的惯性思维——他们默认用户会老老实实选商品、点支付、等结果，却忘了世界上存在会抓包、会并发、会改参数的人。 现在很多平台学聪明了，金额计算全放后端，退款加唯一请求ID，回调处理用分布式锁。但道高一尺魔高一丈，新的漏洞形态也在出现——比如利用优惠券叠加规则的漏洞，或者通过修改用户等级来影响折扣计算。支付安全本质上是一场猫鼠游戏，防守方要堵住所有可能被滥用的逻辑缝隙，而进攻方只需要找到一个没被想到的角落。 那天凌晨我最终没利用那个负数漏洞，只是截了图，写了份报告发给厂商。但我知道，就在我关掉电脑的同一时刻，某个地下论坛里，正有人讨论着另一种我没见过的支付漏洞。这行当永远不缺新故事。