逻辑漏洞与业务安全

逻辑漏洞是Web应用安全中最难发现，但也最有价值的漏洞。和SQL注入、XSS这些技术漏洞不同，逻辑漏洞往往需要深入理解业务流程才能发现。这一章，我们从实战的角度，深入理解逻辑漏洞的原理、发现方法和利用技巧。这是区分"脚本小子"和"真安全工程师"的章节。

业务流程绕过

逻辑漏洞（Logic Vulnerability）是指业务流程中的设计缺陷，导致攻击者可以绕过正常的业务逻辑，达到非预期的目的。这类漏洞不依赖技术漏洞（如SQL注入、XSS），需要深入理解业务流程才能发现，但往往危害更大，因为直接造成业务损失。

支付流程绕过

假设一个电商平台的支付系统，正常的业务流程是这样的：用户选择商品加入购物车，点击结算后创建订单（比如订单金额是100元），系统跳转到支付页面，用户完成支付后，订单状态更新为“已支付”，然后商家发货。

问题出在订单创建和支付之间。如果这个系统允许在支付前修改订单金额，而支付接口只验证订单ID，不验证金额是否被篡改，就会出现严重的逻辑漏洞。

攻击者可以这样操作：先创建一个100元的订单，在跳转到支付页面之前，通过修改请求参数将订单金额改为0.01元，然后完成支付。由于支付接口只检查订单ID是否存在，不验证金额是否匹配，系统会认为支付成功，将订单状态更新为“已支付”。结果就是攻击者用0.01元买到了价值100元的商品。

这种漏洞的测试方法如下：

|
import requests
 
def test_payment_bypass():
    base_url = "https://shop.example.com"
    session = requests.Session()
    
    # 登录
    session.post(f"{base_url}/login", data={"username": "test", "password": "test"})
    
    # 创建订单（金额100元）
    order_response = session.post(f"{base_url}/order/create", json={
        "items": [{"id": 1, "quantity": 1}],
        "total": 100
    })
    order_id = order_response.json()['order_id']
    
    # 修改订单金额为0.01元
    session.post(f"{base_url}/order/update", json={
        "order_id": order_id,
        "total": 0.01
    })
    
    # 支付
    payment_response = session.post(f"{base_url}/payment", json={
        "order_id": order_id,
        "amount": 0.01
    })
    
    if payment_response.json()['status'] == 'success':
        print("VULNERABLE: Payment bypass successful!")

优惠券逻辑缺陷

优惠券系统是另一个常见的逻辑漏洞场景。假设一个电商平台的优惠券系统，用户领取优惠券后，在结算时可以选择使用优惠券，系统会根据优惠券的折扣计算最终金额。

正常情况下，用户领取一张9折优惠券（discount: 0.9），使用后订单金额会打9折。但如果系统将优惠券信息（包括折扣值）存储在前端，后端在计算金额时直接使用前端传来的discount值而不进行验证，就会出现问题。

攻击者可以在使用优惠券时，通过修改请求参数将discount改为0.01，这样订单金额就会按0.01折计算，几乎可以免费获得商品。这种漏洞的根本原因是后端过度信任前端传来的数据，没有从数据库重新验证优惠券的真实折扣值。

抽奖系统漏洞

抽奖系统的逻辑漏洞往往更加隐蔽。假设一个平台的抽奖功能，用户点击参与抽奖，系统随机抽取结果，中奖后发放奖品。

如果抽奖结果的计算逻辑存在缺陷，攻击者就可能预测或操控结果。比如，如果系统使用md5(user_id + timestamp + secret)来生成抽奖结果，而secret值因为某种原因泄露了（可能出现在前端代码、配置文件或日志中），攻击者就可以枚举不同的timestamp值，找到能让自己中奖的时间点，然后在那个时间点参与抽奖。

另一种情况是系统允许重复参与抽奖，或者可以清除参与记录后重新参与。这样攻击者就可以通过多次参与来提高中奖概率。更严重的情况是，如果抽奖结果存储在前端，攻击者可以直接修改结果，或者通过重放请求来修改结果。

状态机缺陷

什么是状态机？

状态机（State Machine）是指系统在不同状态之间转换的机制。比如订单状态通常遵循这样的流程：待支付 → 已支付 → 已发货 → 已完成。每个状态转换都应该有相应的验证和业务规则。

状态可回退的问题

假设一个订单管理系统，订单状态可以手动修改，而且没有严格的状态转换验证。如果系统允许将"已完成"的订单改回"待支付"状态，攻击者就可以利用这个缺陷：先将已完成的订单状态改回"待支付"，然后取消订单申请退款，即使已经收到商品也能获得退款。

这种漏洞的根本原因是系统没有维护状态转换的历史记录，也没有验证状态回退的合法性。正确的做法应该是：状态只能向前转换，或者回退需要特殊的权限和审批流程。

状态可跳过的风险

更严重的情况是状态可以跳过。假设一个系统允许订单状态直接从"待支付"跳转到"已完成"，而不需要经过"已支付"和"已发货"等中间状态。这样攻击者就可以免费获得商品，因为系统跳过了支付验证环节。

这种漏洞通常出现在状态更新接口没有验证前置状态的情况下。正确的实现应该检查当前状态，只允许合法的状态转换。

并发状态问题

并发操作也可能导致状态不一致。假设两个用户同时对同一个订单进行操作：用户A正在支付订单（状态从"待支付"变为"已支付"），同时用户B在取消订单（状态从"待支付"变为"已取消"）。如果系统没有处理并发，最终状态可能不一致，可能导致业务逻辑错误。

测试并发问题可以使用多线程：

|
import requests
import threading
 
def pay_order(session, order_id):
    session.post(f"{base_url}/order/pay", json={"order_id": order_id})
 
def cancel_order(session, order_id):
    session.post(f"{base_url}/order/cancel", json={"order_id": order_id})
 
# 并发操作
order_id 

金额/权限逻辑错误

假设一个电商系统在创建订单时，没有对商品数量进行负数校验。如果攻击者提交一个数量为-1的订单，系统计算订单金额时：订单金额 = 单价 × 数量 = 100 × (-1) = -100。

如果系统处理负数金额的逻辑是直接扣除用户账户金额，那么负数金额实际上会增加用户账户余额，相当于退款。攻击者就可以通过“购买”负数商品来获得退款，造成资金损失。

溢出问题

金额计算中的溢出问题也值得注意。在JavaScript中，如果金额超出Number类型的范围，可能会变成负数或其他异常值：

|
// JavaScript
var total = 999999999999999999999;  // 超出Number范围
// 可能变成负数或其他值

如果系统使用JavaScript进行金额计算，而前端计算的结果会发送到后端，攻击者就可能通过构造超大金额来触发溢出，导致金额计算错误。

浮点数精度问题

另一个常见问题是浮点数精度。JavaScript中的浮点数运算存在精度问题：

|
0.1 + 0.2 = 0.30000000000000004  // 不是0.3

如果系统使用浮点数计算金额，多次运算后可能产生累计误差。虽然单个误差很小，但在大量交易中，误差会累积，可能导致资金对账不平。

权限计算错误

权限逻辑错误可能导致权限提升。假设一个系统的权限检查代码是这样的：

|
// 错误：权限检查逻辑错误
if ($user->role == 'admin' || $user->id == 1) {
    // 管理员权限
}

如果$user->role是空字符串，在某些PHP版本中，==比较可能会产生意外的结果。更安全的做法是使用严格比较===，或者先验证变量类型。

权限缓存问题

权限缓存也可能导致问题。假设用户A原本是普通用户，系统将他的权限缓存在Redis中。后来管理员将用户A提升为管理员，但缓存没有更新。用户A仍然使用缓存的权限（普通用户），无法获得管理员权限。虽然这不会导致权限提升，但会影响正常功能。

更严重的情况是反向的：如果用户被降权，但缓存没有更新，用户仍然可以使用旧的高权限。

权限继承问题

权限继承也可能带来问题。假设用户A创建了一个资源，资源继承了用户A的权限。后来用户A被提升为管理员，那么之前创建的资源权限是否应该更新？如果系统没有处理这种情况，可能导致权限不一致。

非技术型漏洞

社会工程学（Social Engineering）是指通过心理手段，而非技术手段，获取信息或执行操作。在Web应用中，社会工程学攻击往往针对客服、管理员等人员。

假设一个系统的账户恢复流程存在缺陷：用户忘记密码后，可以通过客服恢复账户。恢复账户只需要提供姓名和邮箱，客服不验证身份就直接恢复。攻击者可以收集目标用户的姓名和邮箱（这些信息在社交媒体上很容易获取），然后联系客服，声称自己忘记了密码，申请账户恢复。如果客服不严格验证身份，攻击者就能获得账户访问权限。

类似地，密码重置功能也可能被利用。如果系统发送密码重置链接到用户邮箱，攻击者可能通过钓鱼邮件诱导用户点击恶意链接，或者通过客服重置密码。

审批流程绕过

假设一个企业内部系统有审批流程：员工提交申请 → 部门审批 → 财务审批 → 通过。如果系统没有严格控制流程顺序，攻击者可能直接访问财务审批接口，跳过部门审批环节。

这种漏洞通常出现在RESTful API设计中，如果每个审批环节都有独立的接口，而接口之间没有验证前置环节是否完成，就可能被绕过。

工作流缺陷

工作流设计不当也可能导致问题。假设正常流程是A → B → C，如果系统允许从A直接跳到C，跳过B环节，就可能绕过B环节的验证或审批。

业务规则绕过

业务规则的验证不严格也可能被绕过。假设系统规定每个用户只能领取一张优惠券，但如果系统只在前端检查，后端不验证，攻击者就可以使用多个账号领取，或者通过清除领取记录来重复领取。

总结

逻辑漏洞需要深入理解业务流程，这是区分“脚本小子”和“真安全工程师”的关键。 这一节课我们学习了逻辑漏洞和业务安全。逻辑漏洞不同于技术漏洞，需要深入理解业务流程才能发现。业务流程绕过、状态机缺陷、金额/权限逻辑错误、非技术型漏洞等，都是常见的逻辑漏洞类型。

下一节课，我们会学习客户端攻击。客户端安全往往被忽视，但也有很多安全问题。