业务逻辑漏洞与防护

1. 漏洞描述
业务逻辑漏洞（Business Logic Vulnerability）是指应用程序在业务处理流程中存在的设计缺陷，攻击者通过滥用正常功能而非技术漏洞（如SQL注入）实现恶意目的。这类漏洞通常难以通过自动化工具检测，需要深入理解业务场景。常见案例如：订单金额篡改、验证码绕过、竞争条件滥用等。

2. 漏洞原理
业务逻辑漏洞的核心问题是程序未对用户操作施加合理的业务规则约束。例如：

• 信任客户端传递的数据（如价格、库存）；
• 未校验多步骤操作的完整性（如跳过支付步骤直接生成订单）；
• 对并发请求处理不当（如重复领取优惠券）。

3. 典型场景与攻击手法
场景1：订单金额篡改

• 步骤1：用户选择商品并进入结算页面，前端显示总价100元。
• 步骤2：用户通过抓包工具（如Burp Suite）拦截支付请求，将金额修改为1元。
• 步骤3：服务器未二次校验金额，直接以修改后的值完成交易。

场景2：验证码绕过

• 步骤1：用户请求短信验证码，服务器生成并存储验证码（如1234）。
• 步骤2：用户故意输入错误验证码，但拦截请求并将响应包中的状态码改为“成功”（如HTTP 200）。
• 步骤3：前端仅依赖响应状态判断验证结果，导致绕过。

场景3：竞争条件漏洞

• 步骤1：用户同时发起多个“余额提现”请求，提现前校验余额是否充足。
• 步骤2：服务器未加锁处理，并行校验均通过，导致超额提现。

4. 防护方案
原则：不信任任何用户输入，关键逻辑服务端固化

• 数据完整性校验：
  • 订单金额、数量等关键参数由服务端计算，而非依赖前端传递。
  • 使用数字签名或Token（如HMAC）确保参数未被篡改。
• 流程状态管控：
  • 用服务端Session记录多步骤流程（如下单→支付→完成），禁止跳步或回退。
• 防并发攻击：
  • 对关键操作（如支付、库存扣减）加分布式锁（Redis/Mysql锁），确保原子性。
• 验证码安全：
  • 服务端校验验证码后直接返回明确结果（如{“code”: 400, “msg”: “验证码错误”}），而非让前端解析响应状态。

5. 案例实战
以“优惠券重复使用”为例：

• 漏洞代码（伪代码）：

  def use_coupon(user_id, coupon_id):  
      coupon = db.query("SELECT * FROM coupons WHERE id = ?", coupon_id)  
      if coupon.is_used:  
          return "优惠券已使用"  
      # 未加锁，并发请求可能同时通过校验  
      db.update("UPDATE coupons SET is_used=1 WHERE id=?", coupon_id)  
      grant_credit(user_id, coupon.amount)  # 发放优惠  
  

• 修复方案：

  def use_coupon(user_id, coupon_id):  
      with redis.lock(f"lock_{coupon_id}", timeout=5):  # 加分布式锁  
          coupon = db.query("SELECT * FROM coupons WHERE id = ?", coupon_id)  
          if coupon.is_used:  
              return "优惠券已使用"  
          db.update("UPDATE coupons SET is_used=1 WHERE id=?", coupon_id)  
          grant_credit(user_id, coupon.amount)  
  

6. 总结
业务逻辑漏洞的防护关键在于：将业务规则视为安全规则，通过服务端强制校验、状态跟踪、资源锁等机制，确保流程不可被篡改或绕过。