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 大量下单），触发时要求二次验证（如短信验证码）；
- 记录关键操作日志（包括操作者、时间、参数、结果），便于事后追溯异常行为。

**业务逻辑测试**

- 除常规功能测试外，针对性进行 “逻辑漏洞测试”：模拟攻击者尝试绕过步骤、篡改参数、越权访问；
- 引入 “红队演练”，从攻击者视角发现业务流程中的隐藏缺陷。

## 总结

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

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