Solidity智能合约安全：防止重入攻击的4种方法

使用检查、影响和交互模式（简称CEI:Checks, Effects, and Interactions）、互斥锁、Pull 支付方式以及gas限制都是防止可重入攻击的有效技术。

Solidity智能合约安全：防止重入攻击的4种方法

重入是一种编程技术，在这种技术中，一个函数(“A”)的执行被一个外部函数调用打断，在外部函数调用的逻辑中，能够递归地调用原函数（“A”）。在某些情况下，重复地重新进入一个函数来执行外部逻辑可能是可取的，不一定是错误。然而，这种技术不建议用于智能合约，因为它将控制流执行释放给不受信任的合约，而器可能用于盗取资金。因此，在执行对外部合约的调用时，应使用反重入模式和防护措施来防止这种类型的攻击发生。

有三种主要技术来防止重入：

使用检查、影响、交互（CEI）
使用防重入互斥锁
使用Pull 支付方式

此外，还有一种技术可能是有效的，但不推荐使用，他是使用 Gas Limit 限制。

检查、影响、交互

CEI模式是一种简单而有效的防止重入的方法。检查指的是判断是否符合条件（验证真实性）。影响指的是由交互产生的状态修改。最后，交互指的是函数或合约之间的调用。

下面是一个错误的示范（因为交互在影响之前）

// contract_A: holds user's funds

function withdraw() external {
  uint userBalance = userBalances[msg.sender];

  require(userBalance > 0);

  (bool success,) = msg.sender.call{ value: userBalance }("");
  require(success,);

  userBalances[msg.sender] = 0;
}

这里是攻击者的receive函数：

// contract_B: reentrancy attack

receive() external payable {
  if (address(contract_A).balance >= msg.value) {
    contract_A.withdraw();
  }
}

攻击者的receive函数收到提款后，本应该只返回success，但却检查contract_A是否包含更多的资金。如果是，contract_B会再次调用提款函数，递归直到contract_A所有资金用完。

下面是一个使用CEI模式的提款函数的例子：

function withdraw() external {
  uint userBalance = userBalances[msg.sender];

  require(userBalance > 0);
  userBalances[msg.sender] = 0;

  (bool success,) = msg.sender.call{ value: userBalance }("");
  require(success,);
}

通过在向contract_A转移资金之前将用户在contract_B的账户余额清零，当contract_B发起重入攻击时，提取函数中的条件将为假，执行将被回退。正如这个案例所强调的那样，一行代码的位置可能引起有重大漏洞与重入性安全之间的巨大区别。

重入保护互斥锁

重入防护互斥锁（mutex）可以被构造成一个函数或函数修改器，但其逻辑很简单：一个布尔锁被放置在易受重入影响的函数调用周围。locked的初始状态为假（unlocked），在易受攻击的函数执行开始前，它被立即设置为真（locked），然后在其终止后被设置回假（unlocked）。

下面是一个使用上面的提款函数的例子：

bool internal locked = false;

function withdraw() external {
  require(!locked);
  locked = true;

  uint userBalance = userBalances[msg.sender];
  require(userBalance > 0);
  (bool success,) = msg.sender.call{ value: userBalance }("");
  require(success,);
  userBalances[msg.sender] = 0;

  locked = false;
}

虽然这个提款函数没有遵循CEI模式，但简单的布尔 locked 变量可以防止重入，因此同样可以防止重入攻击。
因为在重入时，第一个require语句条件将为false，会回退交易。

Pull（拉）方式支付

最后这种技术被Open Zeppelin推荐为最佳实践。然而，它在自动化方面有一个小小的折衷。Pull方式支付是通过中间托管账号发送资金来避免直接和潜在的危险合约交互来实现安全。

在这里，合约资金被发送到一个中间托管账号。

function sendPayment(address user, address escrow) external {
  require(msg.sender == authorized);

  uint userBalance = userBalances[user];

  require(userBalance > 0);

  userBalances[user] = 0;

  (bool success,) = escrow.call{ value: userBalance }("");
  require(success,);
}

而在托管账户的资金，则由接收方来提取：

function pullPayment() external {
  require(msg.sender == receiver);

  uint payment = account(this).balance;

  (bool success,) = msg.sender.call{ value: payment }("");
  require(success,);
}

通过中间托管账号发送资金，合约资金受到保护，不会受到重入攻击。如果托管人持有多个账户的资金，可能会受到重入攻击，所以在适用的情况下，应该实现CEI模式和（或）重入保护互斥锁。

Gas Limit限制

最后，通过Gaslimit 限制也可以防止重入攻击，但这不应该被视为一种安全策略，因为Gas成本取决于以太坊的操作码，而操作码gas是可以改变的。另一方面，智能合约代码是不可改变的。不过， send, transfer, 和 call 这些函数之间的区别是值得了解的。

send和 transfer函数本质上是相同的，但如果交易失败，transfer会回退，而send则不会，而是会返回 false。

// transfer will revert if the transaction fails
address(receiver).transfer(amount);

// send will not revert if the transaction fails
address(receiver).send(amount);

关于重入问题， send和 transfer都有2300个单位的Gas限制。使用这些函数应该可以防止重入性攻击的发生，因为他们没有足够的Gas来递归调用到原函数来利用资金。

与 send和 transfer不同，call没有Gas限制，为了执行复杂的多合约交易（当然，也包括重入攻击），会转发其所有剩余Gas。

结论

一次成功的重入攻击后果可能是毁灭性的，可能会耗尽受害者合约中的所有资金，因此，意识到潜在的漏洞并实现有效的保障措施是很重要的。

无论是否存在漏洞，CEI模式都应该被默认实现，这只是一种良好的做法。额外的安全可以通过使用重入锁和（或）Pull支付方式来完成。最后，Gas限制可以防止重入，但不应该被视为一种安全策略。

本翻译由 Duet Protocol 赞助支持。
转载：https://learnblockchain.cn/article/4162

版权属于：区块链中文技术社区 / 转载原创者
本文链接：https://www.bcskill.com/index.php/archives/1623.html
相关技术文章仅限于相关区块链底层技术研究，禁止用于非法用途，后果自负！本站严格遵守一切相关法律政策！