安全考量

优质

小牛编辑

123浏览

2023-12-01

尽管在通常情况下编写一个按照预期运行的软件很简单，但想要确保没有人能够以出乎意料的方式使用它就困难多了。

在 Solidity 中，这一点尤为重要，因为智能合约可以用来处理通证，甚至有可能是更有价值的东西。除此之外，智能合约的每一次执行都是公开的，而且源代码也通常是容易获得的。

当然，你总是需要考虑有多大的风险：你可以将智能合约与公开的（当然也对恶意用户开放）、甚至是开源的网络服务相比较。如果你只是在某个网络服务上存储你的购物清单，则可能不必太在意，但如果你使用那个网络服务管理你的银行帐户，那就需要特别当心了。

本节将列出一些陷阱和一般性的安全建议，但这绝对不全面。另外，请时刻注意的是即使你的智能合约代码没有 bug，但编译器或者平台本身可能存在 bug。一个已知的编译器安全相关的 bug 列表可以在已知bug列表找到，这个列表也可以用程序读取。请注意其中有一个涵盖了 Solidity 编译器的代码生成器的 bug 悬赏项目。

我们的文档是开源的，请一如既往地帮助我们扩展这一节的内容（何况其中一些例子并不会造成损失）！

陷阱

私有信息和随机性

在智能合约中你所用的一切都是公开可见的，即便是局部变量和被标记成 private 的状态变量也是如此。

如果不想让矿工作弊的话，在智能合约中使用随机数会很棘手（译者注：在智能合约中使用随机数很难保证节点不作弊，这是因为智能合约中的随机数一般要依赖计算节点的本地时间得到，而本地时间是可以被恶意节点伪造的，因此这种方法并不安全。通行的做法是采用链外（off-chain）的第三方服务，比如 Oraclize 来获取随机数）。

重入

任何从合约 A 到合约 B 的交互以及任何从合约 A 到合约 B 的以太币（Ether）的转移，都会将控制权交给合约 B。这使得合约 B 能够在交互结束前回调 A 中的代码。举个例子，下面的代码中有一个 bug（这只是一个代码段，不是完整的合约）：

pragma solidity ^0.4.0;

// 不要使用这个合约，其中包含一个 bug。
contract Fund {
    /// 合约中 |ether| 分成的映射。
    mapping(address => uint) shares;
    /// 提取你的分成。
    function withdraw() public {
        if (msg.sender.send(shares[msg.sender]))
            shares[msg.sender] = 0;
    }
}

这里的问题不是很严重，因为有限的 gas 也作为 send 的一部分，但仍然暴露了一个缺陷：以太币（Ether）的传输过程中总是可以包含代码执行，所以接收者可以是一个回调进入 withdraw 的合约。这就会使其多次得到退款，从而将合约中的全部以太币（Ether）提取。特别地，下面的合约将允许一个攻击者多次得到退款，因为它使用了 call ，默认发送所有剩余的 gas。

pragma solidity ^0.4.0;

// 不要使用这个合约，其中包含一个 bug。
contract Fund {
    /// 合约中 |ether| 分成的映射。
    mapping(address => uint) shares;
    /// 提取你的分成。
    function withdraw() public {
        if (msg.sender.call.value(shares[msg.sender])())
            shares[msg.sender] = 0;
    }
}

为了避免重入，你可以使用下面撰写的“检查-生效-交互”（Checks-Effects-Interactions）模式：

pragma solidity ^0.4.11;

contract Fund {
    /// 合约中 |ether| 分成的映射。
    mapping(address => uint) shares;
    /// 提取你的分成。
    function withdraw() public {
        var share = shares[msg.sender];
        shares[msg.sender] = 0;
        msg.sender.transfer(share);
    }
}

请注意重入不仅是以太币（Ether）传输的其中一个影响，还包括任何对另一个合约的函数调用。更进一步说，你也不得不考虑多合约的情况。一个被调用的合约可以修改你所依赖的另一个合约的状态。

gas 限制和循环

必须谨慎使用没有固定迭代次数的循环，例如依赖于存储（storage）值的循环：由于区块 gas 有限，交易只能消耗一定数量的 gas。无论是明确指出的还是正常运行过程中的，循环中的数次迭代操作所消耗的 gas 都有可能超出区块的 gas 限制，从而导致整个合约在某个时刻骤然停止。这可能不适用于只被用来从区块链中读取数据的 view 函数。尽管如此，这些函数仍然可能会被其它合约当作链上（on-chain）操作的一部分来调用，并使那些操作骤然停止。请在合约代码的说明文档中明确说明这些情况。

发送和接收以太币（Ether）

目前无论是合约还是“外部账户”都不能阻止有人给它们发送以太币（Ether）。合约可以对一个正常的转账做出反应并拒绝它，但还有些方法可以不通过创建消息来发送以太币（Ether）。其中一种方法就是单纯地向合约地址“挖矿”，另一种方法就是使用 selfdestruct(x) 。
如果一个合约收到了以太币（Ether）（且没有函数被调用），就会执行 fallback 函数。如果没有 fallback 函数，那么以太币（Ether）会被拒收（同时会抛出异常）。在 fallback 函数执行过程中，合约只能依靠此时可用的“gas 津贴”（2300 gas）来执行。这笔津贴并不足以用来完成任何方式的存储（storage）访问。为了确保你的合约可以通过这种方式收到以太币（Ether），请你核对 fallback 函数所需的 gas 数量（在 Remix 的“详细”章节会举例说明）。
有一种方法可以通过使用 addr.call.value(x)() 向接收合约发送更多的 gas。这本质上跟 addr.transfer(x) 是一样的，只不过前者发送所有剩余的 gas，并且使得接收者有能力执行更加昂贵的操作（它只会返回一个错误代码，而且也不会自动传播这个错误）。这可能包括回调发送合约或者你想不到的其它状态改变的情况。因此这种方法无论是给诚实用户还是恶意行为者都提供了极大的灵活性。
如果你想要使用 address.transfer 发送以太币（Ether），你需要注意以下几个细节：
1. 如果接收者是一个合约，它会执行自己的 fallback 函数，从而可以回调发送以太币（Ether）的合约。
2. 如果调用的深度超过 1024，发送以太币（Ether）也会失败。由于调用者对调用深度有完全的控制权，他们可以强制使这次发送失败；请考虑这种可能性，或者使用 send 并且确保每次都核对它的返回值。更好的方法是使用一种接收者可以取回以太币（Ether）的方式编写你的合约。
3. 发送以太币（Ether）也可能因为接收方合约的执行所需的 gas 多于分配的 gas 数量而失败（确切地说，是使用了 require ， assert， revert ， throw 或者因为这个操作过于昂贵） - “gas 不够用了”。如果你使用 transfer 或者 send 的同时带有返回值检查，这就为接收者提供了在发送合约中阻断进程的方法。再次说明，最佳实践是使用 “取回”模式而不是“发送”模式。

调用栈深度

外部函数调用随时会失败，因为它们超过了调用栈的上限 1024。在这种情况下，Solidity 会抛出一个异常。恶意行为者也许能够在与你的合约交互之前强制将调用栈设置成一个比较高的值。

请注意，使用 .send() 时如果超出调用栈 并不会 抛出异常，而是会返回 false。低级的函数比如 .call()，.callcode() 和 .delegatecall() 也都是这样的。

tx.origin

永远不要使用 tx.origin 做身份认证。假设你有一个如下的钱包合约：

pragma solidity ^0.4.11;

// 不要使用这个合约，其中包含一个 bug。
contract TxUserWallet {
    address owner;

    function TxUserWallet() public {
        owner = msg.sender;
    }

    function transferTo(address dest, uint amount) public {
        require(tx.origin == owner);
        dest.transfer(amount);
    }
}

现在有人欺骗你，将以太币（Ether）发送到了这个恶意钱包的地址：

pragma solidity ^0.4.11;

interface TxUserWallet {
    function transferTo(address dest, uint amount) public;
}

contract TxAttackWallet {
    address owner;

    function TxAttackWallet() public {
        owner = msg.sender;
    }

    function() public {
        TxUserWallet(msg.sender).transferTo(owner, msg.sender.balance);
    }
}

如果你的钱包通过核查 msg.sender 来验证发送方身份，你就会得到恶意钱包的地址，而不是所有者的地址。但是通过核查 tx.origin ，得到的就会是启动交易的原始地址，它仍然会是所有者的地址。恶意钱包会立即将你的资金抽出。

细枝末节

在 for (var i = 0; i < arrayName.length; i++) { ... } 中， i 的类型会变为 uint8 ，因为这是保存 0 值所需的最小类型。如果数组超过 255 个元素，则循环不会终止。
不占用完整 32 字节的类型可能包含“脏高位”。这在当你访问 msg.data 的时候尤为重要 —— 它带来了延展性风险：你既可以用原始字节 0xff000001 也可以用 0x00000001 作为参数来调用函数 f(uint8 x) 以构造交易。这两个参数都会被正常提供给合约，并且 x 的值看起来都像是数字 1，但 msg.data 会不一样，所以如果你无论怎么使用 keccak256(msg.data)，你都会得到不同的结果。

形式化验证

使用形式化验证可以执行自动化的数学证明，保证源代码符合特定的正式规范。规范仍然是正式的（就像源代码一样），但通常要简单得多。

请注意形式化验证本身只能帮助你理解你做的（规范）和你怎么做（实际的实现）的之间的差别。你仍然需要检查这个规范是否是想要的，而且没有漏掉由它产生的任何非计划内的效果。

安全考量

陷阱

私有信息和随机性

重入

gas 限制和循环

发送和接收以太币（Ether）

调用栈深度

tx.origin

细枝末节

推荐做法

认真对待警告

限定以太币（Ether）的数量

保持合约简练且模块化

使用“检查-生效-交互”（Checks-Effects-Interactions）模式

包含故障-安全（Fail-Safe）模式

形式化验证

安全考量

陷阱

私有信息和随机性

重入

gas 限制和循环

发送和接收 以太币（Ether）

调用栈深度

tx.origin

细枝末节

推荐做法

认真对待警告

限定 以太币（Ether） 的数量

保持合约简练且模块化

使用“检查-生效-交互”（Checks-Effects-Interactions）模式

包含故障-安全（Fail-Safe）模式

形式化验证

发送和接收以太币（Ether）

限定以太币（Ether）的数量