代码没写错，业务却被薅了：扫描器为何抓不到逻辑漏洞？

自动化安全扫描器很有用。它们能识别许多常见漏洞，发现过时的依赖，标记可疑行为。但有一个重要问题：并非每一个安全漏洞，都源于扫描器能识别的编码错误。

有时候，应用程序完全按照编写的方式运行——错的是底层的业务规则。这类问题被称为业务逻辑漏洞。

业务逻辑漏洞指的是：应用的工作流、规则或假设可以被操纵，从而产生非预期的结果。它未必是 SQL 注入，也未必是跨站脚本，而是在可信边界上没有执行某条业务规则。核心原则只有一句：客户端请求是输入，不是操作已被允许的证明。

拿一家网店举例，规则大致是：顾客可以购买商品；折扣适用于符合条件的订单；订单必须先付款再发货；退款只针对符合条件的交易。如果应用没能正确执行其中某一条，用户就可能获得本不该得到的好处。

比如一个结算系统，它信任浏览器提交的折扣值，而不是在服务端计算折扣。问题不出在代码写错，而出在规则没在正确的位置被执行。

扫描器为什么常常漏掉

自动化扫描器擅长测试已知的漏洞模式。业务逻辑测试则往往需要理解应用“本该怎样表现”。扫描器可能发现一个暴露的端点，但它未必知道：

• 用户必须先完成验证才能提现；
• 优惠券每位顾客只能核销一次；
• 订单在特定状态转换后不能退款；
• 一个账户绝不能访问另一个账户的私有资源；
• 工作流必须按特定顺序完成。

这些规则是应用特有的。发现违规，通常需要研究者理解预期工作流、提出假设，再测试服务端是否执行了预期限制。这不意味着扫描器无用，它只是更广泛测试流程中的一环。

先摸清工作流，再动手

测试之前，先把应用的正常行为画出来。以一个虚构网店的简化结算流程为例：浏览商品、加入购物车、服务端计算总价、完成支付、核验支付状态、确认订单。

对每一步都问四个问题：这个动作被允许之前，必须满足什么条件？哪个组件在执行这些条件？这个动作能否被乱序执行？服务端是否独立核验了上一步的结果？先记录预期行为，再去找偏差，测试会更系统，也更容易把真正的安全问题与普通应用错误区分开。

一个典型例子是信任客户端提交的价格。简化后的脆弱实现里，结算接口直接从请求中读取 price 和 quantity，用两者相乘得出总价。浏览器请求里可以写 price 为 1、quantity 为 2，服务端就用这个值算账，而不是去查权威价格。如果商品本应售价 100，应用没有可靠办法分辨合法价格与被篡改的价格。

核心问题不是 JSON 不安全，而是服务端信任了一个客户端可以控制的值。还要注意，这个例子并没有实现真实的支付系统——返回一张订单确认，并不等于处理并核验了支付。

安全的做法是：服务端只接受商品标识和数量，从可信数据源取出价格，校验数量，再自行计算总价。客户端选择买什么、买几件，价格由服务端决定。

另一类常见问题是工作流与状态转换。订单状态可能是待支付、已支付、已发货、已送达。安全的应用必须在服务端校验每一次状态转换。订单不该仅因为浏览器发来一个“状态：已支付”就变成已支付，服务端应通过可信的支付服务商信息核验付款，并执行允许的转换。

研究者可以在本地实现上检查：非法转换是否被拒绝；重复请求是否产生重复交易；并发请求是否造成状态不一致；未授权用户能否修改他人订单；服务端是否依赖客户端提供的状态值。涉及资金流程时，使用测试账号和支付服务商的沙箱，未经明确授权绝不操纵真实交易。

业务逻辑漏洞还可能与访问控制失效重叠。用户查看自己发票的场景里，安全的端点应同时校验发票存在、且当前认证用户有权访问。脆弱的设计可能只检查发票标识是否有效。正确的授权规则，概念上就是发票所有者标识等于用户标识。测试时对比两个独立测试账号的行为，确认一个账号无法访问另一个账号的私有发票，不要用真实用户记录来证明漏洞。

一份可用的检查清单

在评估自己拥有或获得明确授权的应用时，可以按下面几组问题过一遍：

• 输入与信任边界：价格、折扣、余额、权限是否在服务端计算或核验？服务端是否校验客户端提交的标识与数量？安全敏感值是否来自可信来源？
• 工作流完整性：动作能否乱序执行？非法状态转换是否被拒绝？重复操作是否被安全处理？并发请求能否违反业务规则？
• 授权：每个敏感资源是否都做了访问检查？每个相关服务端操作是否都核验了权限？一个测试账号能否修改另一个账号的资源？
• 证据：行为能否稳定复现？预期与实际的差异是否清晰？能否在不访问他人数据的前提下演示？安全影响是否有证据支撑，而非推测？

报告这类漏洞时，要解释安全失败，而不只是描述异常行为。一份有用的报告应包含：违反的业务规则摘要、受影响组件、前置条件、最小可复现步骤、预期行为、实际行为、有证据支撑的影响，以及针对根因的服务端校验或工作流修复建议。除非证据确实支持，不要声称漏洞可导致资金盗取、账户接管等严重后果。

业务逻辑漏洞提醒我们，应用安全不只是检测可疑字符串或已知技术模式。安全的应用必须执行那些定义“谁在什么条件下、以什么顺序可以执行什么动作”的规则。研究者最该问的问题往往很朴素：应用本该允许什么？服务端实际执行了什么？哪些假设可以被客户端影响？什么证据能证明预期规则被违反？

安全不只是代码能否正确运行，还包括应用是否执行了正确的规则。