以太坊智能合约为何安全漏洞频发？

最近，随着 defi 火热，以太坊智能合约安全漏洞频发。究竟是什么原因造成的，以及如何更好地防范这些漏洞？

概述

相比于比特币而言，以太坊更易发生安全事故。这主要是因为以太坊虚拟机是图灵完备的，以太坊可实现函数间相互调用、嵌套调用，智能合约间相互调用等各种复杂逻辑。而比特币只实现了基于栈的非图灵完备的虚拟机，并只能通过操作码进行入栈和出栈操作。另外比特币也没有复杂的 DApp 应用，所以逻辑上简单，故而没有太多空间引发安全漏洞。

以太坊上各种 DApp 复杂的智能合约逻辑是引发安全漏洞的主因。以太坊智能合约的安全漏洞主要可以分为和两种。

逻辑问题 

最近频繁的“”攻击是一个典型的逻辑问题引起的安全漏洞。在各种闪电贷攻击中你可以看到清晰的逻辑问题。攻击者只要制造出两个系统之间的价格差，便能通过闪电贷攻击获利。

闪电贷攻击的逻辑细节大家可以阅读之前一篇专门讲闪电贷的文章：“造富神器”闪电贷。本文主要阐述。

合约代码问题 

我们知道，几乎稍微复杂一点的代码都或多或少地存在问题（bug）。了解出现问题的原因，并且归纳问题类别可以帮助我们更好地防范它们。下面是 Ownbit 钱包团队整理的关于以太坊智能合约安全最容易出现问题的点。

1. 重入（Reentrancy）

这是排名第一的问题。所谓“重入”就是一个方法被多次循环调用。而这通常是合约开发者所意想不到的。例如一个取款合约：

function withdrawEther() public { uint amount = userBalances[msg.sender]; bool success, ) = msg.sender.call.value(amount)(""); // 这里重入     require(success);     userBalances[msg.sender] = 0; }

这是一段很简单的取款合约，让用户取走他的 ETH 余额。开发者并没有意识到这段代码可能会被重入。方法是：只要调用者是一个合约账户，那么 msg.sender.call 将默认调用该合约账户的  函数。攻击者只需要在其 fallback 函数再次调用 withdrawEther 就可以源源不断地取走 ETH。

发生在 2016年6月，著名的 The DAO 攻击，从而导致了 ETC 分叉的事件，就是通过同样的方法实施攻击的。从事后看来，这只是一个小小的程序问题（却造成了如此严重的后果）。要修复这个问题也非常容易，只需要将两行代码调换顺序即可：

userBalances[msg.sender] = 0; (bool success, ) = msg.sender.call.value(amount)("");

2. 让你的交易不打包

以太坊区块的打包机制是，并且每个区块有总 GasLimit 的限制（目前为每区块 1200万 Gas）。所以攻击者可以制造出若干使用 GasLimit 非常大，并且 GasPrice 给得非常高的交易，让它们优先占满区块，从而让目标交易无法被打包。

所以，在编写合约逻辑时，不能假设你的交易会在有限时间内被打包，否则就容易受到此类攻击。。

Fomo3D 游戏规则是奖励最后一个购得某个商品的人。每次商品被买入将重置该商品的定时器，如果在定时器达到0之前没有其他购买者，则你将获得系统的奖励。攻击者在 Fomo3D 中买入商品，然后同时发送大量占用区块的攻击交易，以至于在接下来的 13 个区块内，其他购买者的交易无法被打包。这时定时器达到 0，并认为无其他购买者。攻击者便获得了奖励，完成了攻击。

3. 错误使用 tx.origin

如果你发现一个合约使用了 tx.origin，那么可以留心一下此处可能存在的漏洞。在大部分情况下，我们应该使用 msg.sender 来替代 tx.origin，因为使用 tx.origin 容易引发安全漏洞。

很多时候，合约开发人员会假定 msg.sender 和 tx.origin 是相等的，但其实不是。例如： 调用 ，而  进一步调用 ，那么在合约B和C中 tx.origin 都将是 A，而 msg.sender 则一个是 A，一个是B。

一般攻击者会引诱 A 调用一个诱导合约B，而B再去调用由 A 部署的目标合约C，因为 合约C 错误地使用了 tx.origin，合约B可以通过传递过来的 tx.origin 获得对 合约C 的控制权，从而完成攻击。

4. 溢出攻击

智能合约里的数据是可能溢出的，例如：uint256，你觉得很大：2^256。它的确很大，但依然可以溢出。例如一个合约允许对一个数据进行加减，攻击可以通过对这个数据进行精心策划的调用，让其通过溢出达到允许执行某些逻辑的目的，从而实现攻击。

5. fallback 可以 revert

fallback 是可以 revert 的，就是说，你如果向对方转移 ether，对方可以让你总是不成功。

例如你编写一段合约，并且依赖于你成功向某个地址转移 ether，那么攻击可以部署一个合约，将其 fallback 写成 revert 来让你来的调用总是失败：

function () public payable {    revert () ;  }

6. selfdestruct 可以定义任意受益者，而不会调用 fallback

当你以为可以通过 revert 进行阻止所有人向你付款 ether 时，你可能又错了。攻击者通过创建一个合约，并且然后销毁这个合约。销毁合约以太坊将退还一部分 ether 作为鼓励，而这个退还可以指定任意受益者，而对方的 fallback 函数不会被调用。

这就是说，开发者要意识到你没有办法完全阻止别人向你的合约账户转移 ether。

7. 未正确使用 delegatecall

在使用 delegatecall 时，要注意上下文（即 msg.sender 等）的变化。用 call 进行合约调用时，上下文被切换至被调用合约。而用 delegatecall 进行合约调用时，上下文依然在本合约。

delegatecall 和 call 不同的调用上下文也是合约安全漏洞较常出现的地方。

8. 不同方法传气不一样

当我们进行 ether 转移时，不同的方法传气（Gas）不一样。使用 send() 和 transfer() 传递气仅为 2300，而使用 call.value()() 则将剩余的气全部传递。因此，最新的安全规范是建议使用  而不是  或者  进行 ether 转移。

如果你发现一个合约还是使用 send 或者 transfer，那么你可以制造出目标合约，让其转移 Out of Gas。

结语

以上这些点是合约代码最常出现问题的点。每个错误的原因都比较原子化，理解相应的原理可以帮助我们有效地避免这些问题。当合约逻辑复杂时，一定会有更加复杂、隐藏得更深的逻辑问题，这时，这些原子点的检查依然可以帮助我们找到它们。

以太坊智能合约的安全问题主要是因为其“过于灵活”引起的。灵活性和安全性如同天平的两端。以太坊选择了灵活性，某种程度上便把安全性的潜在风险留给了市场。

一个 DeFi 项目能否安全稳定地运行，或是会被黑客攻击，取决于合约开发人员对原理的理解、对细节的把控，以及严肃认真的态度。线上合约犯错的代价是巨大的，这就对合约开发人员提出了更高的要求！