以太坊智能合约开发常见的10个安全问题

本文介绍CheckMarx安全研究小组通过扫描公开的以太坊智能合约所发现的Solidity智能合约开发中常见的十大安全问题，其中__未检查的外部调用__ 和 高成本循环 分列排行榜前两名。该安全问题排行榜于2020年5月发布。

在2018年，CheckMarx安全研究小组首次发布了Solidity智能合约开发中常见的十大安全问题排行榜，其中位居榜首的两个问题分别是__外部合约拒绝服务__ 和重入。2020年的情况已经有所变化，

下表比较了2018年和2020年Solidity十大常见安全问题之间的变化。这些问题按严重程度和流行程度排序：

在这里插入图片描述

用自己熟悉的语言学习 以太坊DApp开发 ： Java | Php | Python | .Net / C# | Golang | Node.JS | Flutter / Dart

S1 – 未检查的外部调用

这是我们之前的Solidity十大安全问题榜单上第三常见的问题。由于现在解决了前两个问题，因此 未检查的外部调用 已升至2020年更新列表中最常见的问题。

Solidity低级调用方法，例如address.call()，不会引发异常。相反，如果调用遇到异常，则它们返回false。另一方面，如果 doSomething()抛出异常，则合约调用（例如 ExternalContract.doSomething() ）会自动传播异常。

使用addr.send()发送以太币是一个很好的例子，应该通过检查返回值来显式处理不成功的发送，但这对于其他外部调用也有效：

在这里插入图片描述

S2 – 高成本循环

代价高昂的循环从Solidity安全榜单的第四名上升至第二名。尽管我们以前的清单中的前2个问题都已解决，但受该问题影响的智能合约数量却增长了近30％。

以太坊环境的算力是需要付费的（使用以太币）。因此，减少完成操作所需的计算步骤不仅是优化的问题，而且还涉及成本效率。

循环是昂贵操作的一个很好的例子：由于数组中包含许多元素，因此需要更多迭代才能完成循环。如你所料，无限循环会耗尽所有可用GAS。在这里插入图片描述

如果攻击者能够影响元素数组的长度，则上述代码将导致拒绝服务，从而阻止执行跳出循环。尽管它与十大常见问题相去甚远，但在扫描的智能合约中发现有8％的合约存在数组长度操纵问题。

S3 – 权力过大的所有者

这是Soldiity十大安全问题榜单中的一个新条目，该问题影响了约16％的已扫描智能合约。

某些合约与其所有者（Owner）紧密相关，使得某些功能只能由所有者地址调用，如下例所示：

在这里插入图片描述

只有合约所有者能够调用doSomething()和doSomethingElse()函数：前者使用onlyOwner修饰符，而后者则显式执行该修饰符。这带来了严重的风险：如果所有者的私钥遭到泄露，则攻击者可以控制该合约。

S4 – 算术精度问题

由于使用256位虚拟机（EVM），因此Solidity的数据类型有些复杂。该语言不提供浮点表示形式，并且少于32个字节的数据类型将被打包到同一个32字节的槽位中。考虑到这一点，你应该会想到可能存在的精度问题：

在这里插入图片描述

如上例所示，在乘法之前执行除法时，可以预料存在很大的舍入误差。

S5 – 过于依赖tx.origin

智能合约不应依赖于tx.origin进行身份验证，因为恶意合约可能会进行中间人攻击，耗尽所有资金。建议改用msg.sender：

在这里插入图片描述可以在Solidity的文档中查看Tx Origin攻击的详细说明。简单的说，tx.origin始终是合约调用链中的第一个帐户，而msg.sender则表示直接调用者。如果链中的最后一个合约依赖于tx.origin进行身份验证，那么调用链中间环节的合约将能够榨干被调用合约的资金，因为身份验证没有检查究竟是谁（msg.sender）进行了调用。