内容摘要：2017年，某电商平台把“满199减100”的优惠券逻辑写成了“满199减100，可叠加”。上线三小时，有人用17张券买走了一台标价2199的扫地机器人，实付99块。运维团队在后台看着订单量曲线几乎垂

2017年，系统某电商平台把“满199减100”的逻辑漏洞优惠券逻辑写成了“满199减100，可叠加”。分析上线三小时，系统有人用17张券买走了一台标价2199的逻辑漏洞扫地机器人，实付99块。分析运维团队在后台看着订单量曲线几乎垂直拉升，系统第一反应是逻辑漏洞“被DDoS了”——结果不是，是分析逻辑漏洞被羊毛党扒了个干净。

这类事故的系统根源很少是代码写错了。代码往往“按需求跑通了”。逻辑漏洞问题出在需求本身漏掉了一个维度：当规则被重复触发时，分析系统会发生什么？系统

逻辑漏洞和SQL注入、XSS那些不一样。逻辑漏洞后者是分析技术层面的防御被击穿，前者是业务规则在设计时就没想清楚边界。你没法用WAF拦住一个“合法用户按正常流程操作但顺序不对”的请求。防火墙看到的是一个持有效token的用户在调用优惠券接口——一切正常。

优惠券只是最容易被看见的那一类

我见过一个更隐蔽的案例。某SaaS产品做团队协作工具，权限模型是这样的：管理员可以移除成员，被移除的成员自动失去所有文档访问权。听起来没问题。但他们的“回收站”功能保留了被移除成员删除的文档，而回收站的访问控制只检查“当前团队成员身份”。一个被踢出团队的人，只要在移除生效前打开回收站页面不刷新，就能继续看到后续所有被删文档——因为前端路由没做二次鉴权，后端只校验了session有效性，没校验团队归属的实时状态。

这个漏洞活了八个月才被发现。发现它的人不是安全研究员，是一个被移除后闲着没事乱点的前员工。

逻辑漏洞的可怕之处就在这里：它藏在正常功能的缝隙里，不触发异常日志，不产生错误码，监控大盘上什么都看不出来。

状态机是重灾区

任何有“状态流转”的系统都值得盯死。订单从“待支付”到“已支付”到“已发货”，每一步的校验如果只依赖前端传来的状态值，而不是服务端自己维护的状态机，就等着出事。有人把退款流程反过来走：先调“确认收货”接口，再调“申请退款”——系统给他退了全款，货还在路上。这不是段子，是某二手交易平台2021年的真实工单。

修法也简单：服务端每次状态变更都从数据库读当前状态，不信任任何客户端参数。但设计阶段很少有人主动想“用户如果乱序调用接口会怎样”。

并发是另一个维度

单用户顺序操作没问题，不代表多请求并发没问题。积分兑换优惠券，用户余额1000分，券需要800分。正常流程：查余额→扣分→发券。两个请求同时进来，都查到余额1000，都扣800，余额变成-600，发了两张券。数据库事务能解决，但很多团队在业务层用“先查后改”的写法，没加行锁，也没用原子操作。

这类问题在秒杀、抢购、领红包场景里反复出现，每年都有新团队踩进去。不是技术难，是设计时脑子里只有“一个人正常操作”的画面。

逻辑漏洞没法靠扫描器发现。它需要设计者主动切换视角：把自己当成一个不按套路出牌的用户，一个同时点两次按钮的用户，一个用Burp Suite重放请求的用户。需求评审时多问一句“如果这一步被跳过会怎样”“如果这个参数被改成负数会怎样”，能挡掉八成以上的事故。

剩下的两成，靠上线后的日志审计和业务指标监控兜底。比如优惠券核销率突然从12%跳到47%，不用等用户举报，系统就该自己报警了。