Je viens de terminer un article d’analyse sur la reentrancy - un problème de sécurité que beaucoup de développeurs continuent d’ignorer lors de la création de contrats intelligents.

Pour faire simple, la reentrancy est lorsqu’un contrat intelligent est appelé plusieurs fois avant que le premier appel ne soit terminé. Imaginez ceci : ContractA exécute une fonction, il appelle ContractB, et ContractB rappelle ContractA avant que ce dernier ne termine. C’est une vulnérabilité que les attaquants peuvent exploiter.

Un exemple concret : EtherStore possède 10 Ether, ContractB a déjà envoyé 1 Ether. Lorsqu’il appelle la fonction de retrait, il vérifie si le solde est supérieur à 0, et si c’est le cas, il envoie l’Ether. Mais c’est là que le danger réside - la mise à jour du solde à 0 se produit après l’envoi. Par conséquent, un attaquant peut créer une fonction fallback qui, lorsqu’elle reçoit des Ether, rappelle la fonction de retrait une fois de plus. Cette boucle continue jusqu’à ce que tout l’Ether soit vidé.

Je vais présenter trois méthodes pour se protéger contre la reentrancy :

La première est d’utiliser le modificateur nonReentrant. Cette méthode bloque le contrat pendant l’exécution d’une fonction, empêchant toute nouvelle entrée. Simple mais efficace pour une seule fonction.

La deuxième est d’appliquer le modèle Checks-Effects-Interactions. Au lieu de mettre à jour le solde après l’envoi, faites-le avant. De cette façon, même si un rappel se produit, le solde sera déjà à 0, et la vérification échouera.

La troisième consiste à créer un contrat séparé GlobalReentrancyGuard. Cette méthode utilise une variable d’état globale pour contrôler la reentrancy sur plusieurs contrats simultanément. Particulièrement utile si votre projet comporte plusieurs contrats qui interagissent. Au lieu de vérifier dans chaque contrat, vous centralisez la vérification.

Le problème de la reentrancy n’est pas nouveau, mais il reste l’une des vulnérabilités les plus courantes. Je constate que beaucoup de développeurs n’appliquent pas ces mesures de manière cohérente. Si vous travaillez avec Solidity, assurez-vous de bien comprendre ce problème et d’appliquer au moins une des trois méthodes dans votre projet. La sécurité des contrats intelligents n’est pas une option, c’est une nécessité.