去年有个甲方找我做渗透测试，网络目标是渗透一个电商平台。我扫完端口、基础翻完目录、课程跑完注入，第讲一无所获。业务防护做得挺扎实。逻辑漏洞结果同事在旁边点了两下鼠标——把购物车里的网络商品数量改成负数，下单，渗透平台倒贴了他三百块。基础这就是课程业务逻辑漏洞。你花三天找SQL注入，第讲不如花三分钟想想这个功能正常用之外还能怎么用。业务

这类漏洞的逻辑漏洞本质一句话能说清：代码逻辑本身没写错，但它假设了用户会按规矩操作。网络攻击者不守规矩，逻辑就崩了。OWASP给它单开了一类，但自动化扫描器基本扫不出来。原因很简单——扫描器不知道“一个优惠券只能用一次”是业务规则，它只会看响应码和报错信息。

几个真实场景

说几个我遇到过或者圈子里流传的案例。

负数与溢出。 上面那个购物车改负数就是典型。类似的还有转账时金额填负数，等于对方给你打钱。有些系统做了前端校验，但只校验了“不能为空”和“必须是数字”，忘了校验正负。Burp抓包改一下就行，前端那点JS拦不住任何人。

步骤跳过。 一个注册流程分三步：验证手机号、设置密码、填写资料。正常流程走完才能用。但如果你直接访问第三步的接口呢？有些系统真就让你过了。更狠的是密码重置流程——第一步验证身份拿到token，第二步提交新密码。如果第二步不校验token是否真的验证过，直接构造请求就能改任意用户的密码。我见过一个系统，重置密码的接口只传了用户名和新密码两个参数，连token字段都没有。这种设计等于把钥匙插在门上还贴了张纸条写着“请进”。

并发竞争。 优惠券只能用一次，代码里先查“是否已使用”，再执行“标记已使用”。两步之间有间隙。同时发二十个请求，都查到了“未使用”，然后都标记了“已使用”。结果一张券用了二十次。这不是代码写错了，是没考虑并发。修复方式是用数据库的行锁或者原子操作，但很多开发者压根没往这个方向想过。

越权。 严格说越权可以单独成课，但它跟业务逻辑漏洞高度重叠。比如查看订单的接口是 /api/order?order_id=1001，你把1001改成1002，看到了别人的订单。系统校验了“你是否登录”，但没校验“这个订单是不是你的”。水平越权。还有垂直越权——普通用户直接访问管理员的接口，有些系统只在前端藏了入口，后端根本没做角色判断。

怎么找这类漏洞

工具帮不上大忙，靠的是思维方式。我的习惯是：拿到一个系统，先把每个功能点的“正常流程”走一遍，然后在纸上画出流程步骤和涉及的接口。接着逐个问自己——

这一步能不能跳过？参数能不能改？改成什么值？能不能重复提交？提交顺序能不能换？A用户的请求换成B用户的身份还能不能用？

说白了就是两件事：改参数和改流程。参数包括数值、类型、长度、归属。流程包括步骤顺序、重复次数、并发时机。

还有个笨办法但很有效：把请求全部抓下来，用Burp的Repeater逐个手工测试。自动化跑不出来的东西，手工反而快。因为你的大脑知道这个功能的“意图”是什么，扫描器不知道。

开发端为什么老出这个问题

跟几个开发聊过，核心原因是：他们写代码时脑子里想的是“用户会怎么用”，而不是“用户可能怎么滥用”。产品经理给的PRD写的是正常流程，测试用例覆盖的也是正常流程。边界条件？异常输入？没人提，自然没人写。

另一个原因是业务逻辑漏洞没有统一的修复模板。SQL注入加参数化查询就完事了，XSS做输出编码就完事了。但业务逻辑漏洞每个点都不一样，得逐个分析。费脑子，容易漏。

我的判断是：这类漏洞未来只会越来越多。系统越复杂，业务规则越绕，逻辑漏洞的生存空间就越大。WAF挡不住它，因为请求看起来完全正常。SDLC想覆盖它，得靠人去想，工具替代不了。

练法就一个：多手动测。别老依赖扫描器。找个靶场，把每个功能点的参数都改一遍，流程都跳一遍。练多了就有直觉了。

(责任编辑：娱乐)