Smart Contract Security Audit — Reentrancy e Overflow che gli Sviluppatori Non Possono Ignorare

Hai deployato uno smart contract su Ethereum. Sembra funzionare. Poi qualcuno chiama una funzione più volte prima che la prima finisca, e il saldo va a zero. Oppure un calcolo aritmetico sfora e qualcuno conia token dal nulla. Non è fantascienza: è reentrancy e overflow, i due buchi neri della sicurezza on-chain.

Noi, di Meteora Web, non scriviamo smart contract tutti i giorni, ma lavoriamo con sviluppatori che lo fanno, e abbiamo visto progetti saltare per una linea di codice sbagliata. Veniamo dalla contabilità: un errore in uno smart contract è come un saldo di partita doppia sballato di centinaia di migliaia di euro. La differenza? Su blockchain non c'è "storno" semplice.

Questa guida è per chi ha già scritto almeno un contratto in Solidity e vuole capire come prevenire reentrancy e overflow, e cosa cercare in un audit. Niente teoria astratta: esempi di codice reali, strumenti che usiamo, errori che abbiamo visto.

Come funziona un attacco di reentrancy e come si previene in uno smart contract?

L'attacco di reentrancy sfrutta una chiamata esterna (`call`, `delegatecall`, `send`) fatta prima che lo stato del contratto venga aggiornato. Il contratto attaccante richiama la funzione originale prima che la prima esecuzione finisca, creando un ciclo che drena i fondi.

Esempio classico: il contract di prelievo vulnerabile

// VULNERABILE
contract VulnerableBank {
    mapping(address => uint) public balances;
    
    function withdraw(uint _amount) public {
        require(balances[msg.sender] >= _amount);
        (bool sent, ) = msg.sender.call{value: _amount}("");
        require(sent, "Failed to send");
        balances[msg.sender] -= _amount; // aggiornamento DOPO la chiamata
    }
    
    function deposit() public payable {
        balances[msg.sender] += msg.value;
    }
}

Se `msg.sender` è un contratto con una `fallback` o `receive` che richiama di nuovo `withdraw`, i fondi vengono prelevati multipli fino a esaurimento del saldo del contratto.

Come prevenirlo: Checks-Effects-Interactions pattern

La regola è semplice: aggiorna lo stato prima di fare chiamate esterne.

// SICURO
contract SecureBank {
    mapping(address => uint) public balances;
    
    function withdraw(uint _amount) public {
        require(balances[msg.sender] >= _amount, "Saldo insufficiente");
        balances[msg.sender] -= _amount; // AGGIORNAMENTO PRIMA
        (bool sent, ) = msg.sender.call{value: _amount}("");
        require(sent, "Invio fallito");
    }
}

Alternativa: usare un mutex (lock) per impedire rientranze durante l'esecuzione. OpenZeppelin fornisce ReentrancyGuard.

import "@openzeppelin/contracts/security/ReentrancyGuard.sol";

contract SecureBank is ReentrancyGuard {
    function withdraw(uint _amount) public nonReentrant {
        // logica qui
    }
}

Strumenti per rilevare reentrancy

• Slither: analisi statica; rileva pattern di reentrancy (comando: slither . --detect reentrancy).
• Mythril: analisi simbolica; cerca vulnerabilità runtime.
• Echidna: fuzzing; testa proprietà specifiche.

Cosa sono gli overflow aritmetici negli smart contract e come evitarli?

In Solidity < 0.8, gli integer overflow non generano errore: se uint8 arriva a 256, torna a 0. In versioni >= 0.8 il compilatore controlla automaticamente gli overflow aritmetici (tranne in blocchi unchecked). Ma attenzione: anche con Solidity 0.8+, alcune operazioni in unchecked, derivati o librerie custom possono causare overflow.

Esempio di overflow (pre-0.8)

// VULNERABILE (prima di Solidity 0.8)
contract Token {
    mapping(address => uint) public balances;
    uint public totalSupply;
    
    function mint(address to, uint amount) public {
        totalSupply += amount; // overflow possibile
        balances[to] += amount;
    }
}

Se totalSupply è uint256, l'overflow è improbabile ma possibile con ingressi maliziosi. In pratica, il pericolo arriva da cast impliciti, operazioni su uint8, o calcoli intermedi.

Prevenzione

• Usare Solidity >= 0.8 per controlli automatici.
• Evitare blocchi unchecked se non strettamente necessari e testati.
• Usare librerie SafeMath se si lavora con versioni < 0.8 (OpenZeppelin SafeMath).
• Attenzione ai cast: uint256(uint160(address)) è sicuro, ma uint8(uint256) tronca senza warning.

Quali strumenti usare per un audit di sicurezza efficace?

Un audit non è solo tool: è un processo. Noi consigliamo un approccio a tre livelli: statico, dinamico e manuale.

1. Analisi statica con Slither

Slither è il nostro punto di partenza. Analizza il codice senza eseguirlo e rileva decine di vulnerabilità: reentrancy, timestamp dependence, tx.origin, uncontrolled delegatecall, e altro.

pip install slither-analyzer
slither . --print human-summary --print contract-summary

2. Analisi dinamica con Foundry

Foundry (forge) permette di scrivere test in Solidity e fare fuzzing. Scriviamo test di proprietà: "con qualsiasi input, il saldo totale rimane invariato".

// Test di fuzzing con Foundry
function testWithdrawFuzz(uint amount) public {
    vm.assume(amount <= depositBalance);
    uint before = address(this).balance;
    vault.withdraw(amount);
    assert(address(this).balance == before - amount);
}

3. Verifica manuale e invarianti economiche

Nessun tool trova bug logici di business. Esempio: una funzione che permette di ritirare più del dovuto se combinata con uno sconto. Qui serve un revisore umano. Noi, di Meteora Web, quando facciamo audit per clienti, scriviamo una lista di invarianti (es. "la somma di tutti i balance mapping deve essere uguale al saldo del contratto") e le verifichiamo una per una.

Strumenti aggiuntivi

• MythX: analisi cloud (pagamento), più lento ma più profondo.
• Echidna: fuzzing basato su proprietà, ideale per contratti complessi.
• 4nalyzer: tool di reporting che combina output di più scanner.

Quali altri bug di sicurezza sono comuni negli smart contract oltre a reentrancy e overflow?

Anche se il focus è reentrancy e overflow, un audit serio copre almeno questi:

• Timestamp dependence: usare block.timestamp per generare casualità -> estraibile dai miner.
• Tx.origin authentication: tx.origin == owner può essere aggirato tramite contratto intermedio.
• Uncontrolled delegatecall: se un contratto delega chiamate a indirizzi arbitrari, il chiamante prende il controllo.
• Front-running: transazioni visibili in mempool; pattern come commit-reveal possono mitigare.

Che costo ha un audit e come valutare se serve?

Un audit professionale per un contratto semplice (poche centinaia di linee) parte da 3.000-5.000 €, per DeFi complesse anche 50.000 €+.

Ma il costo di un bug è potenzialmente illimitato: nel 2016, un reentrancy nel DAO causò un furto da 60 milioni di dollari. Oggi progetti DeFi perdono regolarmente milioni per bug evitabili. Noi consigliamo: se il contratto gestisce valore reale, non saltare l'audit. Se è un prototipo, almeno eseguire Slither e test di fuzzing.

Cosa fare adesso

• Riprendi il tuo smart contract e applica il pattern Checks-Effects-Interactions.
• Esegui slither . --detect reentrancy e correggi ogni warning.
• Verifica la versione del compilatore: se < 0.8, passa a una versione recente o integra SafeMath.
• Scrivi almeno un test di fuzzing con Foundry per ogni funzione che modifica lo stato.
• Se gestisci fondi altrui, contatta un revisore esterno per un audit formale.

Approfondisci con la nostra pillar Blockchain e Web3 per sviluppatori per una panoramica completa.

Riferimenti utili: Documentazione ufficiale Solidity, Slither su GitHub, OpenZeppelin Contracts.