Top 5 des vulnérabilités de sécurité des contrats intelligents et comment les prévenir

Attaques de réentrée

1. Une vulnérabilité de réentrance se produit lorsqu'un contrat externe rappelle le contrat actuel avant la fin de l'exécution initiale.

2. Cette faille permet aux attaquants de drainer des fonds en appelant à plusieurs reprises une fonction de retrait avant que les variables d'état ne soient mises à jour.

3. Le tristement célèbre piratage de DAO en 2016 a exploité ce modèle précis, entraînant la perte de plus de 60 millions de dollars d'ETH.

4. Les développeurs peuvent atténuer ce risque en appliquant le modèle Vérifications-Effets-Interactions, garantissant que tous les changements d'état se produisent avant tout appel externe.

5. L'utilisation du modificateur ReentrancyGuard d'OpenZeppelin ajoute un mécanisme de verrouillage qui empêche l'entrée récursive dans les fonctions sensibles.

Dépassement et dépassement inférieur d'entier

1. Avant Solidity 0.8.0, les opérations arithmétiques ne s'annulaient pas automatiquement en cas de débordement ou de sous-dépassement.

2. Les attaquants pourraient manipuler les soldes en forçant les valeurs à s'enrouler, par exemple en soustrayant de zéro pour produire un nombre extrêmement positif.

3. En 2018, le projet BeautyChain a subi un exploit critique où un débordement a conduit à la frappe non autorisée de jetons.

4. La mise à niveau vers Solidity 0.8.0+ résout ce problème au niveau du compilateur, car les vérifications intégrées déclenchent désormais des annulations automatiques.

5. Pour les bases de code existantes utilisant toujours des versions antérieures, les bibliothèques SafeMath doivent être explicitement importées et utilisées pour chaque opération arithmétique.

Appels externes non cochés

1. Les contrats supposent souvent que les appels externes réussiront sans vérifier les valeurs de retour ni gérer les échecs.

2. Si un contrat appelé échoue ou échoue silencieusement, le contrat appelant peut continuer avec des hypothèses invalides sur l'état.

3. Lors du piratage de Parity Wallet, un appel non contrôlé à un contrat de bibliothèque a permis à des acteurs malveillants de détourner la propriété du portefeuille.

4. Utilisez toujours require(call.success, 'External call failed') ou des appels de bas niveau avec une validation explicite du succès.

5. Évitez les appels de délégué sauf en cas d'absolue nécessité ; les appels de délégués mal utilisés peuvent entraîner des collisions de stockage et l'exécution de code arbitraire.

En première ligne via les transactions publiques

1. Le pool de mémoire d'Ethereum expose les transactions en attente à tous les validateurs et chercheurs avant leur inclusion dans les blocs.

2. Les attaquants recherchent des opportunités rentables, comme des échanges importants ou des propositions de gouvernance, et soumettent des transactions concurrentes avec des frais de gaz plus élevés.

3. En 2020, les robots de pointe ont extrait plus de 12 millions de dollars des fournisseurs de liquidité Uniswap v2 lors de changements de marché volatils.

4. Mettre en œuvre des systèmes de révélation d'engagement pour les actions critiques telles que les offres d'enchères ou les votes de gouvernance.

5. Utilisez des relais de transaction privés comme Flashbots Protect ou intégrez un cryptage de seuil pour masquer l'intention jusqu'à l'exécution.

Erreurs logiques dans le contrôle d'accès

1. Des modificateurs mal configurés ou une logique d'attribution de rôle défectueuse peuvent accorder des privilèges d'administrateur à des utilisateurs non autorisés.

2. Lors de l'incident de Cream Finance, un bug logique dans la fonction de transfert de propriétaire a permis à un attaquant de se définir comme nouveau propriétaire.

3. Les adresses codées en dur ou la renonciation à la propriété manquante après le déploiement créent des surfaces d'attaque persistantes.

4. Appliquez les exigences de multi-signature pour les fonctions privilégiées à l'aide de normes telles que Gnosis Safe.

5. Effectuez des audits manuels de tous les modificateurs d'accès onlyOwner , onlyRole et personnalisés pour confirmer les chemins d'héritage et outrepasser la sécurité.

Foire aux questions

Q : La vérification formelle peut-elle éliminer toutes les vulnérabilités des contrats intelligents ? R : La vérification formelle prouve mathématiquement que certaines propriétés sont valables pour toutes les entrées, mais elle ne peut pas couvrir les défauts de logique métier, les attaques économiques ou les problèmes d'intégration avec des protocoles externes.

Q : Est-il sûr de réutiliser le code audité d’autres projets ? R : Pas intrinsèquement. Même le code audité peut contenir des hypothèses spécifiques au contexte, des dépendances obsolètes ou des cas extrêmes non testés lorsqu'il est déployé dans de nouveaux environnements.

Q : Les réseaux de test reproduisent-ils entièrement les conditions de sécurité du réseau principal ? R : Non. Les réseaux de test manquent de véritables incitations économiques, ont un comportement de mineur différent et exécutent souvent des versions client modifiées, ce qui les rend insuffisants pour détecter les vecteurs précurseurs ou problématiques.

Q : Quel est le lien entre les manipulations d'Oracle et les vulnérabilités des contrats intelligents ? R : La manipulation d'Oracle n'est pas un bug au niveau du contrat en soi, mais les contrats reposant sur des flux de prix centralisés ou à faible couverture héritent d'un risque systémique : par exemple, un seul nœud compromis alimentant de fausses données peut déclencher des liquidations à travers les protocoles DeFi.