18业务逻辑漏洞

## 概述

业务逻辑漏洞（Business Logic Vulnerability）是指由于应用程序业务流程设计不合理、逻辑判断不严谨或规则实现存在缺陷，导致攻击者可绕过正常业务规则，获取非授权权限、篡改数据或执行恶意操作的安全漏洞。

与 XXE、SQL 注入等 “技术型漏洞” 不同，业务逻辑漏洞不依赖特定技术组件的缺陷，而是业务规则本身的逻辑错误，隐蔽性更强，常被传统安全工具（如 WAF）忽略。

## 核心特征

与业务流程强关联：仅存在于特定业务场景（如登录、支付、订单、权限管理等），脱离业务场景则无意义。

逻辑绕过或滥用：攻击者利用规则中的 “漏洞”，用不符合预期的方式完成业务操作（如 “越权下单”“零元支付”）。

隐蔽性高：不涉及特殊字符或恶意代码，攻击行为往往看似 “正常操作”，难以被技术手段直接检测。

## 常见场景与示例

业务逻辑漏洞的表现形式与具体业务强相关。

| 业务场景 | 漏洞表现 | 攻击示例 |
| ------------------ | ------------------------------------------------------------ | ------------------------------------------------------------ |
| 身份认证与会话管理 | 密码重置逻辑缺陷、会话过期机制失效、多因素认证绕过等。 | 密码重置时，服务器仅验证 “用户名” 而不验证 “邮箱验证码”，攻击者可直接重置他人密码； 登录后会话 ID 不变，攻击者窃取会话 ID 后可长期冒充用户。 |
| 支付与订单系统 | 金额篡改、重复支付、订单状态异常变更等。 | 购物时，前端提交订单金额为100元，攻击者通过抓包将金额改为0.01元，服务器未重新校验； 订单支付成功后，重复发送 “支付完成” 请求，导致重复发货。 |
| 权限控制 | 水平越权（访问同级别用户数据）、垂直越权（普通用户执行管理员操作）。 | 用户 A 查看自己的订单（/order?id=123），将id改为124即可查看用户 B 的订单； 普通用户访问/admin/delete?user=1，服务器未校验权限，直接执行删除。 |
| 数据校验与提交 | 前端校验绕过、参数依赖缺陷、业务状态篡改等。 | 注册时前端限制 “用户名长度≥6”，攻击者直接发送 POST 请求提交长度为 3 的用户名（服务器未校验）； 电商平台 “限购 1 件”，攻击者通过修改请求参数购买 10 件。 |
| 业务流程跳转 | 跳过关键步骤（如协议确认、手机验证）、逆向操作（如订单取消后仍可支付）。 | 注册账号需 “阅读协议并勾选”，攻击者直接发送下一步请求，跳过勾选步骤； 订单已取消后，攻击者仍可向支付接口发送请求，导致 “已取消订单被支付”。 |

## 危害

业务逻辑漏洞的危害取决于业务场景的敏感度，可能导致：

- 权限泄露：越权访问他人数据（如用户隐私、订单信息）；
- 财产损失：支付金额篡改、重复提现、免费获取商品等；
- 业务混乱：订单状态异常、数据统计错误、服务流程失效；
- 声誉影响：用户信任度下降（如账号被恶意重置、订单被篡改）。

## 防护措施

业务逻辑漏洞的防护核心是完善业务规则设计，强化逻辑校验，需结合业务场景从多维度入手：

**梳理业务流程，明确规则边界**

绘制完整业务流程图（如登录→下单→支付→发货），标注每个步骤的 “前置条件” 和 “校验规则”（如 “支付前必须校验订单金额是否与商品一致”）；

针对关键操作（如支付、权限变更），明确 “谁能做、做什么、怎么做”，避免模糊的逻辑判断。

**服务器端重校验，拒绝信任前端**

所有业务参数（如金额、数量、用户 ID）必须在服务器端重新校验，不依赖前端验证（前端验证可被轻易绕过）；

示例：支付时，服务器应根据商品 ID 重新计算金额，而非直接使用前端提交的金额。

**强化权限与状态管理**

权限校验：每个操作前严格验证 “操作者是否有权限”（如查看订单时，验证订单的所属用户 ID 与当前登录用户 ID 一致）；

状态控制：用 “状态机” 管理业务状态（如订单状态：待支付→已支付→已发货→已完成），禁止不合理的状态跳转（如 “已取消”→“已支付”）。

**增加异常检测与日志审计**

监控异常操作（如短时间内多次重置密码、同一 IP 大量下单），触发时要求二次验证（如短信验证码）；

记录关键操作日志（包括操作者、时间、参数、结果），便于事后追溯异常行为。

**业务逻辑测试**

除常规功能测试外，针对性进行 “逻辑漏洞测试”：模拟攻击者尝试绕过步骤、篡改参数、越权访问；

引入 “红队演练”，从攻击者视角发现业务流程中的隐藏缺陷。

## 总结

业务逻辑漏洞的本质是 “规则设计的不严谨”，其防护不能仅依赖技术手段，更需要深入理解业务流程，在设计阶段就明确规则边界，在开发阶段强化服务器端校验。

对于核心业务（如支付、权限），需通过 “最小权限”“多重校验”“状态固化” 等原则，确保业务按预期流程执行，避免被攻击者滥用。