当前位置：首页>java>智能合约的重入攻击,在代码层面有哪些通用防护方案?

智能合约的重入攻击,在代码层面有哪些通用防护方案?

2026-02-05 01:03:41

一、先搞懂：重入攻击的本质与核心逻辑

重入攻击的核心是 **“趁虚而入”**：恶意合约利用目标合约在 “外部交互（如转账 ETH、调用其他合约）” 前未完成自身状态更新的间隙，反复调用目标合约的关键函数，窃取资产。

用通俗场景类比：你去银行取钱，正常流程是 “银行检查余额→扣减账户金额→给你现金”；但如果银行流程是 “给你现金→检查余额→扣减金额”，你拿到现金后立刻再次调用 “取钱” 接口，银行还没扣减余额，就会重复给你钱 —— 这就是重入攻击的核心逻辑。

技术层面，重入攻击最典型的触发场景是：

目标合约包含向外部地址转账 ETH 的逻辑（会触发对方合约的fallback/receive函数）；
转账操作发生在合约状态更新（如扣减用户余额、修改提款额度）之前；
恶意合约在fallback/receive函数中再次调用目标合约的提款 / 转账函数，此时目标合约状态未更新，会误认为用户仍有可提取的资产。

二、代码层面的 6 类通用防护方案

方案 1：核心基础 ——Checks-Effects-Interactions（CEI）模式

这是防范重入攻击最基础、最核心的方案，也是所有防护的前提，本质是 “调整函数执行顺序”。

原理

严格遵循 “先检查→再更新状态→最后外部交互” 的执行逻辑：

Checks（检查）
：先验证所有前置条件（如用户余额是否足够、权限是否合法）；
Effects（更新）
：立即更新合约状态（如扣减用户可提取余额、标记提款完成）；
Interactions（交互）
：最后执行外部调用（如转账 ETH、调用其他合约）。

代码示例（对比坏实现与好实现）

solidity

// ❶ 不安全的实现（交互在前，状态更新在后）contractBadWithdraw{mapping(address=>uint256)public userBalances;// 提款函数：先转账，再扣减余额 → 易被重入functionwithdraw()public{uint256 amount = userBalances[msg.sender];// 外部交互：转账ETH会触发恶意合约的fallback函数(bool success,)= msg.sender.call{value: amount}("");require(success,"Transfer failed");// 状态更新：扣减余额（在交互后，重入时仍会认为余额充足）        userBalances[msg.sender]=0;}}// ❷ 安全的实现（CEI模式）contractSafeWithdraw{mapping(address=>uint256)public userBalances;functionwithdraw()public{uint256 amount = userBalances[msg.sender];// 1. Checks：验证余额充足require(amount >0,"No balance to withdraw");// 2. Effects：先更新状态，扣减余额        userBalances[msg.sender]=0;// 3. Interactions：最后执行外部转账(bool success,)= msg.sender.call{value: amount}("");require(success,"Transfer failed");}}

关键说明

CEI 模式从根本上消除了 “状态未更新就对外交互” 的漏洞，即使恶意合约重入调用withdraw，也会因userBalances已被清零而触发require校验失败；
所有包含外部交互的合约函数，都应优先遵循 CEI 模式，这是无需额外代码成本的基础防护。

方案 2：核心防护 —— 重入锁（ReentrancyGuard）

重入锁是行业标准化的防护方案，通过状态变量标记合约 “是否正在执行中”，重入调用时直接拒绝，是 CEI 模式的重要补充。

原理

定义一个布尔型状态变量（如_locked），默认值为false；
在易受攻击的函数执行前，检查_locked是否为false，若是则将其设为true（锁定）；
函数执行完成后（包括异常场景），将_locked重置为false（解锁）；
若函数执行过程中被重入调用，会因_locked为true而直接拒绝。

代码示例（OpenZeppelin 标准实现）

solidity

// 简化版ReentrancyGuard（生产环境直接用OpenZeppelin的库）contractReentrancyGuard{boolprivate _locked;// 自定义修饰器：加锁+解锁modifiernonReentrant(){// 检查是否锁定，锁定则拒绝require(!_locked,"ReentrancyGuard: reentrant call");// 加锁        _locked =true;// 执行被修饰的函数_;// 解锁（即使函数执行异常，也会执行这一步？不，异常会终止，需结合try/catch，OpenZeppelin已优化）        _locked =false;}}// 结合CEI+重入锁的安全提款合约contractSafeWithdrawWithGuardis ReentrancyGuard {mapping(address=>uint256)public userBalances;// 给核心函数添加nonReentrant修饰器functionwithdraw()public nonReentrant {uint256 amount = userBalances[msg.sender];require(amount >0,"No balance to withdraw");// Effects：更新状态        userBalances[msg.sender]=0;// Interactions：外部转账(bool success,)= msg.sender.call{value: amount}("");require(success,"Transfer failed");}}

关键说明

生产环境无需自己实现ReentrancyGuard，直接导入 OpenZeppelin 的@openzeppelin/contracts/security/ReentrancyGuard.sol，经过审计更安全；
重入锁适合所有包含外部调用的核心函数（如提款、转账、质押 / 解质押），是通用且低成本的防护手段；
注意：重入锁仅防护 “同一合约的重入”，跨合约重入需结合其他方案。

方案 3：源头管控 —— 限制接收 ETH 的能力

重入攻击常通过 ETH 转账触发fallback/receive函数，若合约无需接收 ETH，可直接禁用；若需要，则严格限制其逻辑。

原理

无 ETH 接收需求：不定义fallback和receive函数，或将其设为payable但内部直接revert；
有 ETH 接收需求：仅在receive/fallback函数中保留必要逻辑，不调用任何外部合约，也不触发合约的核心函数。

代码示例

solidity

// ❶ 禁用ETH接收（无接收需求）contractNoEthReceive{// 无receive/fallback函数 → 向该合约转ETH会直接失败functionwithdraw()public{/* ... */}}// ❷ 限制ETH接收（仅允许纯转账，无额外逻辑）contractRestrictedEthReceive{// receive函数仅接收ETH，无任何其他逻辑receive()externalpayable{// 可添加校验：仅允许特定地址转账（如合约管理员）require(msg.sender == owner,"Only owner can send ETH");}// fallback函数直接拒绝fallback()externalpayable{revert("Fallback is disabled");}}

关键说明

该方案从源头减少重入攻击的触发点，尤其适合不需要接收随机地址 ETH 的合约（如 NFT 合约、权限管理合约）；
若合约必须接收任意地址的 ETH（如 DeFi 资金池），则需结合 CEI + 重入锁使用。

方案 4：风险转移 ——Pull（拉取）支付替代 Push（推送）支付

传统的 “Push 支付” 是合约主动向用户转账（易触发重入），而 “Pull 支付” 是让用户主动发起提现请求，将外部调用的主动权交给用户，规避批量转账的重入风险。

原理

合约仅记录用户可提取的金额（如挖矿收益、分红），不主动转账；
用户需主动调用withdraw函数提取资金；
每次提现仅处理单个用户的请求，且严格遵循 CEI 模式。

代码示例

solidity

// Pull支付模式（安全的分红合约）contractDividendPullPayment{mapping(address=>uint256)public userDividends;// 记录用户可提取分红addresspublic owner;constructor(){        owner = msg.sender;}// 仅记录分红，不主动推送functionallocateDividends(address user,uint256 amount)public onlyOwner {        userDividends[user]+= amount;}// 用户主动拉取分红（CEI+重入锁）functionclaimDividends()public nonReentrant {uint256 amount = userDividends[msg.sender];require(amount >0,"No dividends to claim");// Effects：先清零        userDividends[msg.sender]=0;// Interactions：用户主动拉取，即使重入也无风险(bool success,)= msg.sender.call{value: amount}("");require(success,"Transfer failed");}modifieronlyOwner(){require(msg.sender == owner,"Not owner");_;}}

关键说明

Pull 支付适合批量分发资金的场景（如挖矿收益、DAO 分红、手续费返还），避免了 “批量 Push 转账时某一个恶意用户触发重入” 的风险；
缺点是需要用户主动操作，但安全性远高于 Push 支付，是 DeFi 合约的主流选择。

方案 5：补充防护 —— 控制外部调用的时机与权限

作为前四类方案的补充，通过限制外部调用的频率、金额或对象，降低重入攻击的影响范围。

核心手段

提现冷却期
：用户每次提现后，需等待一定时间（如 1 小时）才能再次提现，避免短时间内反复重入；
单次限额
：限制单次提现的最大金额，即使被攻击，损失也可控；
可信交互列表
：仅允许合约与白名单内的可信合约交互，禁止调用未知合约。

代码示例（提现冷却期 + 单次限额）

solidity

contractWithdrawLimitis ReentrancyGuard {mapping(address=>uint256)public userBalances;mapping(address=>uint256)public lastWithdrawTime;// 最后提现时间uint256publicconstant MAX_WITHDRAW_AMOUNT =1 ether;// 单次限额uint256publicconstant COOLDOWN =1 hours;// 冷却期functionwithdraw()public nonReentrant {uint256 amount = userBalances[msg.sender];require(amount >0,"No balance");// 单次限额检查require(amount <= MAX_WITHDRAW_AMOUNT,"Exceed max withdraw amount");// 冷却期检查require(block.timestamp - lastWithdrawTime[msg.sender]>= COOLDOWN,"Cooldown not over");// Effects        userBalances[msg.sender]=0;        lastWithdrawTime[msg.sender]= block.timestamp;// Interactions(bool success,)= msg.sender.call{value: amount}("");require(success,"Transfer failed");}}

关键说明

该方案是 “兜底防护”，无法完全杜绝重入，但能大幅降低攻击造成的损失；
适合高价值合约（如资金池、交易所合约），结合核心防护方案使用。

方案 6：基础保障 —— 使用安全库与升级编译器

这是最易被忽视但至关重要的通用防护，本质是 “站在巨人的肩膀上”，避免重复造轮子带来的安全漏洞。

核心要点

使用经过审计的安全库
：优先使用 OpenZeppelin、Solady 等开源安全库的合约模板，这些库已覆盖重入锁、权限控制、安全转账等核心逻辑，且经过多次审计；
升级 Solidity 编译器版本
：使用 0.8.0 及以上版本 —— 该版本原生修复了整数溢出 / 下溢问题，同时优化了编译器对外部调用的处理逻辑，减少潜在的重入触发点；
避免不安全的转账方式
：优先使用call{value: amount}("")（可控失败），而非transfer/send（有 gas 限制，易引发其他问题），但需配合 CEI + 重入锁。