Sécurité des contrats intelligents dans la DeFi : vulnérabilités courantes et comment les éviter

Avant de plonger dans les vulnérabilités techniques, il est toujours judicieux de s'assurer que vos activités de trading fondamentales se déroulent sur une plateforme sécurisée. Vous pouvez consulter les derniers prix et mouvements pour divers actifs sur la page des marchés Exbix .

Partie 2 : Vulnérabilités et Exploits Courants des Contrats Intelligents

Décomposons les catégories de vulnérabilités les plus courantes qui ont conduit à des conséquences significatives. pertes dans DeFi.

1. Attaques par réentrance : Le vol classique

L'attaque par réentrance est la vulnérabilité de contrat intelligent la plus célèbre, démontrée de manière notoire par le piratage du DAO en 2016, qui a entraîné une perte de 3,6 millions d'ETH et un hard fork d'Ethereum par la suite.

• Qu'est-ce que c'est ? Une attaque par réentrance se produit lorsqu'un contrat malveillant rappelle le contrat appelant avant que l'exécution de la fonction initiale ne soit terminée. Cela peut permettre à l'attaquant de retirer des fonds à plusieurs reprises avant que leur solde ne soit mis à jour.
• Comment cela fonctionne :
  1. Le contrat A a une withdraw() fonction qui envoie de l'ETH à un utilisateur et ensuite met à jour le solde interne de l'utilisateur.
  2. Le contrat de l'attaquant B appelle withdraw().
  3. Le contrat A envoie de l'ETH au contrat B.
  4. Le contrat B a une fallback() fonction (qui reçoit l'ETH) qui appelle immédiatement withdraw() dans le contrat A à nouveau.
  5. Le contrat A n'a pas encore mis à jour le solde de l'attaquant, il constate donc que le Contrat B a toujours droit à plus d'ETH et l'envoie à nouveau.
  6. Cette boucle continue, vidant le Contrat A, jusqu'à ce que le gaz de la transaction s'épuise ou que le contrat soit vide.
• Exemple Célèbre : Le piratage de la DAO (2016).
• Comment l'Éviter :
  • Utilisez le modèle Vérifications-Effects-Interactions : C'est la règle d'or. Toujours :
    1. Vérifiez toutes les conditions (par exemple, require(balances[msg.sender] >= amount);).
    2. Mettez à jour toutes les variables d'état internes (effets) (par exemple, balances[msg.sender] -= amount;).
    3. Ensuite, interagissez avec d'autres contrats ou EOA (interactions) (par exemple, msg.sender.call{value: amount}("");).
  • Utilisez des gardes de réentrance : OpenZeppelin propose un modificateur ReentrancyGuard qui verrouille une fonction pendant son exécution, empêchant les appels récursifs.

2. Attaques par manipulation d'oracle

Les contrats intelligents ont souvent besoin de données du monde réel. Les oracles sont des services qui fournissent ces données. Manipuler le flux de prix qu'un oracle fournit est un vecteur d'attaque principal.

• Qu'est-ce que c'est ? Un attaquant manipule le prix d'un actif sur un échange décentralisé (DEX) avec une faible liquidité pour tromper l'oracle d'un protocole en lui faisant rapporter un prix incorrect.
• Comment cela fonctionne :
  1. Un protocole de prêt utilise le prix au comptant d'un DEX comme oracle pour déterminer combien peut être emprunté contre une garantie.
  2. Un attaquant contracte un prêt flash pour vider la liquidité d'une paire de trading, par exemple, ABC/ETH, la rendant ainsi très illiquide.
  3. L'attaquant échange ensuite une petite quantité d'ABC pour faire fortement varier son prix par rapport à l'ETH sur la pool désormais illiquide.
  4. L'oracle du protocole lit ce prix manipulé.
  5. L'attaquant utilise l'ABC artificiellement gonflé comme garantie pour emprunter une énorme quantité d'autres actifs non manipulés auprès du protocole.
  6. L'attaquant rembourse le prêt éclair, et le prix de l'ABC se corrigent, mais le protocole se retrouve avec des garanties sans valeur et une énorme dette irrécouvrable.
• Exemples Célèbres : Le piratage de Harvest Finance (34 millions de dollars perdus), l'incident de DAI de Compound.
• Comment l'Éviter :
  • Utiliser des Oracles Décentralisés : Utilisez des réseaux d'oracles robustes comme Chainlink, qui agréger des données provenant de plusieurs nœuds et sources indépendants, ce qui les rend extrêmement difficiles et coûteuses à manipuler.
  • Utiliser des prix moyens pondérés par le temps (TWAP) : Utiliser une moyenne des prix sur une période (par exemple, 30 minutes) plutôt que le prix au comptant immédiat rend la manipulation à court terme non rentable.
  • Utiliser plusieurs sources de données : Ne pas compter uniquement sur la liquidité d'un DEX pour un flux de prix critique.

3. Débordements et sous-débordements d'entiers

Les ordinateurs ont des limites sur la taille d'un nombre. Un uint256 (entier non signé) dans Solidity a une valeur maximale de 2^256 - 1.

• Qu'est-ce que c'est ?
  • Dépassement : Lorsqu'une opération (comme l'addition) donne un résultat supérieur à la valeur maximale, elle “retourne” à un très petit nombre.
  • Sous-dépassement : Lorsqu'une opération (comme la soustraction) donne un résultat inférieur à zéro (pour les entiers non signés, qui ne peuvent pas être négatifs), elle retourne à un très grand nombre.
  numéro.
• Comment ça fonctionne :
  • Un solde de 100 tokens. Un utilisateur dépense 101. Le calcul 100 - 101 provoquerait un sous-dépassement, entraînant un solde de 2^256 - 1, donnant ainsi à l'utilisateur un solde presque infini.
• Comment éviter Il :
  • Utilisez Solidity 0.8.x ou une version ultérieure : Le compilateur vérifie automatiquement les débordements/sous-dépassements et annule les transactions lorsque cela se produit.
  • Utilisez SafeMath pour les anciens compilateurs : La bibliothèque SafeMath d'OpenZeppelin fournit des fonctions pour des opérations arithmétiques sécurisées avant la version 0.8.

4. Contrôles d'accès défaillants

De nombreux contrats possèdent des fonctions qui devraient être réservées à certaines adresses (par exemple, le propriétaire, un administrateur).

• Qu'est-ce que c'est ? Une fonction qui est essentielle au fonctionnement du protocole (par exemple, la mise à niveau du contrat, la création de nouveaux jetons, le changement de frais) est accidentellement rendue publique au lieu d'être protégée par un modificateur comme onlyOwner.
• Exemple Célèbre : Le piratage du portefeuille Parity (2017), où un utilisateur a accidentellement déclenché une fonction qui l'a rendu propriétaire du contrat de bibliothèque et a ensuite “suicidé” celui-ci, gelant ainsi ~500,000 ETH pour toujours.
• Comment l'Éviter :
  • Utiliser le Contrôle d'Accès Modificateurs : Utilisez des modificateurs comme Ownable ou AccessControl d'OpenZeppelin pour restreindre clairement les fonctions sensibles.
  • Auditez et testez minutieusement : Les tests automatisés doivent vérifier spécifiquement que les utilisateurs non autorisés ne peuvent pas appeler les fonctions privilégiées.

5. Frontrunning et transaction Dépendance à l'ordre