2019年，业务某电商平台上线了一个“满199减100”的逻辑漏洞优惠活动。运营人员在后台设置时，业务把“每人限用一次”写成了“每单限用一次”。逻辑漏洞结果有人下了10单，业务每单都用掉了那张券，逻辑漏洞平台一夜之间损失近百万。业务这不是逻辑漏洞黑客攻击，没有代码注入，业务也没有暴力破解——就是逻辑漏洞一条业务规则被钻了空子。这类问题，业务统称为业务逻辑漏洞。逻辑漏洞

它和SQL注入、业务XSS那些传统漏洞不一样。逻辑漏洞传统漏洞是业务代码层面的缺陷，扫描器能报出来。业务逻辑漏洞藏在流程里，工具扫不到，因为它“看起来一切正常”。比如一个转账功能，代码没毛病，但如果没校验转出金额不能为负数，那用户输入“-100元”，自己的余额反而增加了。这就是逻辑漏洞。

常见的类型，我按实际遇到的情况捋一捋。

越权操作是最泛滥的一种。分水平越权和垂直越权。水平越权是A用户能看B用户的数据。比如某系统查订单的接口是/order?orderId=1001，你把1001改成1002，如果能看到别人的订单，那就是水平越权。垂直越权是普通用户干了管理员的事。我见过一个后台，普通用户登录后直接访问/admin/deleteUser?id=5，系统只校验了“是否登录”，没校验“是否管理员”，结果普通用户把管理员账号删了。

支付逻辑漏洞花样最多。改价格是最经典的：前端显示100元，提交时把price参数改成1元。有些系统只在前端校验，后端直接信任了客户端传来的金额。还有改数量的——买3件商品，把数量改成-1，结算时总价变成负数，平台倒贴钱给你。更隐蔽的是“并发漏洞”：账户里有100元，同时发起两笔100元的提现请求，如果系统没加锁，两笔都成功，你就提走了200元。

验证机制缺陷也很常见。短信验证码没做次数限制，可以无限爆破。或者验证码校验通过后，没有销毁session，同一个验证码能反复用。还有密码找回逻辑：回答安全问题后，系统只返回一个“重置成功”的提示，但没校验当前用户身份，攻击者可以直接跳到重置密码那一步。

流程跳过是另一种思路。比如下单流程分三步：选商品→填地址→支付。正常必须走完三步。但如果直接访问支付完成的回调URL，系统没校验“是否已填地址”，订单就生成了。再比如某些系统在最后一步才校验库存，前面几步都不查，导致超卖。

为什么业务逻辑漏洞这么多？因为业务规则本身是“人定的”，而人总会漏掉边界情况。开发人员写代码时想的是“用户会正常操作”，但攻击者想的恰恰是“怎么不正常操作”。工具只能测“代码有没有写错”，测不了“规则有没有想全”。

怎么防？没有银弹。但有几条实用原则。第一，所有关键参数都在后端重新校验，永远不要信任客户端传来的任何数据——包括价格、数量、用户ID、权限标识。第二，对敏感操作加锁，尤其是涉及金额和库存的，用数据库行锁或分布式锁防止并发。第三，权限校验要统一收口，别在每个接口里手写if-else，容易漏。第四，业务流程的每一步都要校验前置状态，不能让人跳步。最后，上线前做一次“恶意测试”——别按正常流程走，试试改参数、跳步骤、重复提交、并发请求。

说到底，业务逻辑漏洞考验的不是技术深度，而是对业务的理解程度。你得把自己当成一个想占便宜的坏人，而不是一个规规矩矩的用户。这个视角切换，比任何扫描器都管用。