很多人把“逻辑漏洞”当成一个筐，下面什么都往里装。漏洞逻辑漏洞SQL注入？可被逻辑漏洞。越权访问？下面逻辑漏洞。验证码能被爆破？漏洞逻辑漏洞逻辑漏洞。这不对。可被逻辑漏洞有它自己的下面边界，不是漏洞逻辑漏洞所有“看起来不按套路出牌”的漏洞都配得上这个名字。

先给一个判断标准：如果一个漏洞的可被成因是代码对业务规则的理解出了偏差，而不是下面对输入数据的处理出了技术性错误，它才可能是漏洞逻辑漏洞逻辑漏洞。换句话说，可被逻辑漏洞不是下面“代码写错了”，而是漏洞逻辑漏洞“代码写对了，但规则本身被绕过了”。可被

典型的逻辑漏洞长什么样

举个我亲身遇到的例子。某电商平台的退货流程：用户申请退货，系统生成退货单，商家同意后用户寄回商品，商家确认收货，退款到账。整个流程没有SQL注入，没有XSS，参数校验严得离谱。但问题出在——退货单生成后，用户可以反复点击“申请退货”按钮。每点一次，系统就多生成一张退货单，而退款金额是按退货单数量累加的。用户买了100块的东西，点十次退货，退了1000块。

这就是逻辑漏洞。代码没写错，它忠实地执行了“每次申请退货就生成一张退货单”这个规则。错的是规则本身没有考虑重复提交的业务含义。你没法靠加引号转义或者参数化查询来防住它，因为攻击者提交的每一个参数都是合法的。

再比如，某APP的邀请返利活动：邀请一个新用户注册，返10元。有人发现，用同一个手机号反复注册、注销、再注册，每次都能被当成“新用户”。系统校验了手机号格式、验证了短信验证码、检查了设备指纹——技术层面滴水不漏。但它没校验“这个手机号是否曾经注册过”。这也是逻辑漏洞。规则说“新用户”，但“新”的定义被钻了空子。

哪些不算逻辑漏洞

SQL注入不是逻辑漏洞。它的成因是代码把用户输入拼进了SQL语句，导致数据库执行了非预期的命令。这是技术实现缺陷，跟业务规则没关系。你修它靠的是参数化查询，不是重新设计业务流程。

越权访问呢？要看情况。如果是代码忘了加权限校验，比如某个API接口没检查用户身份就直接返回了数据，这算访问控制缺陷，不叫逻辑漏洞。但如果是权限校验本身有逻辑问题——比如系统规定“只有订单所有者能查看订单”，但代码判断的是“只要用户ID和订单里的用户ID相等就放行”，而攻击者发现把订单ID改成自己的、用户ID改成别人的就能绕过——这就是逻辑漏洞。区别在于：前者是“漏了检查”，后者是“检查的逻辑可以被操纵”。

验证码能被爆破，通常也不算逻辑漏洞。那是验证码机制本身强度不够，属于防护措施失效。除非系统规定“验证码错误三次就锁定账户”，但攻击者发现只要在第三次错误后重新获取验证码，计数器就归零——这才是逻辑漏洞，因为它绕过了“锁定”这个业务规则。

一个更隐蔽的案例

某金融APP的转账功能：单笔限额5万，单日累计限额20万。攻击者发现，系统只校验了“单笔转账金额≤5万”和“当日已转账总额+本次金额≤20万”，但没校验“转账次数”。于是他拆成100笔1999元的转账，每笔都合法，累计却转了19.99万。这算逻辑漏洞吗？算。因为限额规则的本意是控制风险敞口，而拆分转账绕过了这个意图。代码没bug，规则有洞。

但如果你说“这个APP没有限制转账次数，所以是逻辑漏洞”，那就太宽泛了。逻辑漏洞的核心不是“缺少某个限制”，而是“已有的限制可以被合法操作绕过”。缺少限制是设计缺陷，绕过限制才是逻辑漏洞。

我的判断

逻辑漏洞这个词被滥用了。很多安全报告把任何非内存破坏类的漏洞都叫逻辑漏洞，图省事。但这样做的后果是，开发人员听到“逻辑漏洞”就头疼，觉得防不胜防。其实逻辑漏洞有明确的特征：它依赖于对业务流程的深刻理解，攻击者需要知道系统“应该”怎么运转，然后找到规则之间的缝隙。它不是靠扫描器能扫出来的，也不是靠加WAF能挡住的。它考验的是设计者对业务规则完整性的思考。

所以，下次你想说某个漏洞是逻辑漏洞之前，先问自己：这个漏洞的成因，是代码把数据搞错了，还是规则本身被绕过了？如果是前者，别叫逻辑漏洞。如果是后者，那它就是了。