Web安全之业务安全：支付漏洞与防护策略详解

1. 支付漏洞的背景与危害

支付漏洞是业务逻辑漏洞的一种，攻击者通过篡改支付流程中的关键参数（如金额、订单号、商品数量等）或利用业务逻辑缺陷，以异常手段完成支付，导致财产损失。常见场景包括：

• 金额篡改：前端校验不严时，攻击者修改支付接口传入的金额参数。
• 重复支付：同一订单多次支付但系统未校验状态，导致重复发货或退款欺诈。
• 负数支付：传入负金额导致余额异常增加（如充值场景）。
• 订单替换：支付时替换订单ID，以低价购买高价商品。

危害：直接经济损失、用户数据泄露、平台信誉受损。

2. 支付漏洞的成因分析

2.1 信任前端数据

若后端完全依赖前端传入的金额、订单信息，未做二次校验，则易被篡改。例如：

// 前端发送的支付请求（易被篡改）
POST /pay {orderId: "123", amount: 100, currency: "CNY"}

2.2 业务流程缺陷

• 支付状态校验缺失：未校验订单是否已支付，导致重复支付。
• 并发请求处理不当：短时间内多次发起支付请求，系统未加锁造成资金异常。
• 退款逻辑漏洞：退款时未校验用户身份或订单归属。

2.3 接口参数可预测

订单号、优惠券ID等参数若具备规律性，可能被枚举或篡改。

3. 支付漏洞的防护策略

3.1 核心原则：后端校验一切

• 金额与订单信息从数据库读取：支付时仅传入订单ID，后端根据ID查询金额并执行支付逻辑。

// 正确做法：根据订单ID查询金额
Order order = orderService.getById(orderId);
if (order == null || order.getStatus() != UNPAID) {
    throw new Exception("订单无效");
}
paymentService.pay(order.getAmount(), order.getCurrency());

• 状态机校验：严格管理订单状态流转（如“待支付→已支付→已发货”），避免重复操作。

3.2 防篡改机制

• 数字签名：对关键参数（如订单ID、金额）生成签名，后端验证签名合法性。

# 生成签名（示例）
sign = md5(orderId + amount + secretKey)
# 后端验证签名一致性

• Token机制：支付前先申请一次性Token，Token与订单绑定，防止重放攻击。

3.3 并发控制

• 数据库乐观锁：更新订单状态时检查版本号，避免并发重复支付。

UPDATE orders SET status = 'paid' WHERE id = 123 AND status = 'unpaid';

• 分布式锁：高并发场景下使用Redis或Zookeeper加锁，确保支付流程原子性。

3.4 业务逻辑加固

• 负数与零金额拦截：后端校验金额需大于零。
• 权限校验：支付前验证当前用户是否拥有操作该订单的权限。
• 日志与监控：记录支付关键日志，实时监控异常行为（如同一订单短时间多次支付）。

4. 进阶防护：风控系统介入

大型支付系统需引入风控模块，通过以下策略动态防御：

• 行为分析：检测异常支付行为（如异地登录、大额交易）。
• 设备指纹：识别可疑设备或IP。
• 人工审核：对高风险交易触发人工审核流程。

5. 总结

支付漏洞的本质是业务逻辑的完整性被破坏。防护核心在于：

1. 永不信任前端输入，关键数据需后端查询。
2. 严格校验状态与权限，避免越权或重复操作。
3. 通过签名/锁机制保证流程不可篡改与原子性。
4. 结合风控系统实现纵深防御。