系统0元购漏洞

去年冬天，系统一个做电商的元购朋友半夜给我发截图，后台订单列表里赫然躺着三笔“0元成交”的漏洞蓝牙耳机。不是系统优惠券抵扣，不是元购积分兑换，是漏洞实打实的应付金额为零，订单状态却显示“待发货”。系统他查了日志，元购发现有人用脚本在凌晨两点到四点之间，漏洞反复调用下单接口，系统每次都在支付环节把金额参数改成了0.00。元购系统没拦，漏洞风控没响，系统货就这么出去了。元购

这就是漏洞典型的系统0元购漏洞。它跟薅羊毛不是一回事。薅羊毛是利用平台规则，比如满减叠加、新人券，本质上是平台自己设计好的让利。0元购是直接钻代码的空子，把“应付”变成“不付”。

漏洞从哪来

最常见的是支付逻辑写反了。正常流程是：下单→生成订单→调支付→支付成功→回调→改订单状态。有些系统图省事，把“支付成功”的回调接口做成了只要请求就返回成功，不校验签名，不校验金额。攻击者抓包后直接伪造回调，订单立刻变成已支付。

另一种是价格参数可篡改。前端传给后端的JSON里带着price字段，后端没做二次校验，直接拿这个值去算总价。把price改成0，总价就是0。我见过一个外卖平台的老系统，连运费都能改成负数，下单一笔倒赚五块。

还有更隐蔽的：并发条件竞争。比如账户余额100元，同时发起两笔80元的支付请求。系统先查余额够，再扣款，两个请求都通过了“查余额”那一步，最后只扣了一次钱，但两笔订单都成立了。把金额改成0，就是无限下单。

为什么难防

很多团队觉得“前端已经限制了，用户改不了”。这是最要命的错觉。前端代码在用户浏览器里跑，F12一按，什么都能改。后端如果默认前端传什么就信什么，等于把保险柜钥匙插在门上。

另一个原因是业务跑得太快。新功能上线，支付模块复用老代码，老代码里有个测试用的“跳过支付”开关没关。攻击者不需要多高深的技术，扫一遍接口文档，试几个参数就摸到了。

一个真实案例的细节

某生鲜平台做拉新活动，新用户首单0元购。规则写的是“首单且金额低于30元”。但风控只查了“是否新用户”，没查“是否首单”。有人注册一个号，下十单，每单都0元。更绝的是，他用同一个手机号反复注册——系统只校验了手机号格式，没校验唯一性。那个晚上，平台损失了四十多万的货。

事后复盘，开发说“没想到有人会这么干”。安全圈有句话：你没想到的，攻击者都会替你想。

怎么堵

支付回调必须验签，金额必须从数据库里读，不能信任何客户端传过来的数字。订单状态变更要加乐观锁，防止并发覆盖。新用户资格、首单资格，这些判断要放在服务端做，而且要在扣减库存之前做。

还有一条容易被忽略：日志和告警。0元订单、同一IP短时间大量下单、支付回调来源异常，这些都应该触发实时告警。我那个朋友后来加了规则——任何应付金额为0的订单，直接进人工审核队列。再也没出过事。

漏洞不会自己消失。它就在代码的某个分支里等着，等一个无聊的人打开开发者工具。