Vulnérabilités de contrat intelligent communs

Attaques de réentrance

L'une des vulnérabilités les plus infâmes des contrats intelligents est l' attaque de réentrance , qui a conduit au hack DAO en 2016. Cette vulnérabilité se produit lorsqu'un contrat malveillant rappelle le contrat d'origine avant l'exécution de la fonction initiale. En conséquence, les fonctions qui gèrent les appels externes sans vérification appropriée peuvent être exploitées.

Pour éviter les attaques de réentrance, les développeurs devraient éviter de passer des appels externes à des contrats inconnus ou non fiables. Une technique d'atténuation courante utilise le modèle de contrôle-effectif-interactions . Cela implique la mise à jour de l'état du contrat avant de passer des appels externes. De plus, la mise en œuvre des gardes de réentrance à l'aide de verrous Mutex peut aider à bloquer les appels récursifs.

Une autre méthode consiste à utiliser des bibliothèques bien auditées telles que ReenturancyGuard d'OpenZeppelin, qui fournit des modificateurs comme non réentrant pour restreindre la rentrée de la fonction pendant l'exécution. Les développeurs doivent également envisager de limiter la quantité d'éther ou de jetons qui peuvent être transférés en un seul appel pour réduire les dommages potentiels de ces attaques.

Débordement entier et sous-écoulement

Les contrats intelligents rédigés dans les versions Solidity avant 0,8,0 sont sensibles au débordement et au sous-flux entier . Ceux-ci se produisent lorsque les opérations arithmétiques entraînent des valeurs qui dépassent le maximum ou la chute en dessous de la valeur minimale autorisée pour un type de données donné, tel que Uint256.

Par exemple, si une variable de type UINT256 contient la valeur 0 et est décrémentée, elle sous-tente à la valeur maximale (2 ^ 256 - 1), conduisant potentiellement à des équilibres incorrects ou à un accès non autorisé. Pour atténuer cela, les développeurs doivent utiliser des bibliothèques SafeMath fournies par Openzeppelin, qui effectuent des vérifications explicites sur les opérations arithmétiques.

En commençant par Solidity 0.8.0, ces vérifications sont activées par défaut, et les opérations arithmétiques lanceront des erreurs sur les débordements ou les sous-flux, sauf non explicitement non contrôlés à l'aide de blocs {...} incontrôlés . Cependant, même avec cette protection intégrée, les développeurs doivent rester prudents lorsqu'ils désactivent les contrôles de sécurité pour l'optimisation des performances.

Il est également crucial de valider toutes les entrées et de garantir que les opérations mathématiques sont correctement limitées, en particulier lorsqu'ils traitent des valeurs fournies par l'utilisateur ou des calculs dynamiques impliquant des transferts de jetons.

Attaques de premier plan

Dans les blockchains publics comme Ethereum, les transactions sont visibles avant d'être extraites, ce qui ouvre la porte aux attaques de premier plan . Les attaquants peuvent observer les transactions en attente et soumettre les leurs avec des frais de gaz plus élevés pour les faire exécuter en premier, manipulant ainsi les résultats.

Cette vulnérabilité affecte généralement les échanges décentralisés (DEX) et d'autres applications où l'ordre de transaction est important. Par exemple, si un utilisateur soumet un commerce à un certain prix, un attaquant pourrait être en tête de cette transaction pour obtenir un meilleur taux, volant efficacement la valeur.

Pour se défendre contre le premier cycle, les développeurs peuvent mettre en œuvre des mécanismes tels que des schémas de validation. Dans cette approche, les utilisateurs soumettent d'abord une version hachée de leur transaction (phase de validation), et ne révèlent plus tard que les détails complets (révèlent la phase), empêchant les attaquants de connaître l'action exacte jusqu'à ce qu'il soit trop tard.

Alternativement, l'utilisation de conditions aléatoires ou basées sur le temps dans les contrats peut rendre la prévision des résultats des transactions plus difficiles. Cependant, la véritable aléatoire sur la chaîne est difficile, donc les développeurs comptent souvent sur des oracles hors chaîne ou des engagements cryptographiques à des informations sensibles obscures.

Contrôle d'accès inapproprié

Le contrôle d'accès est un aspect essentiel du développement de contrats intelligents sécurisés. Un contrôle accès inapproprié peut conduire à une exécution non autorisée de fonctions privilégiées, permettant aux attaquants de modifier les états de contrat, de vider des fonds ou de désactiver les fonctionnalités contractuelles.

Une erreur typique n'est pas de restreindre qui peut appeler des fonctions sensibles. Par exemple, une fonction censée être appelée uniquement par le propriétaire du contrat peut manquer d'un modificateur comme uniquement , permettant à quiconque de l'invoquer. Un autre problème se pose lorsque les autorisations sont codées en dur ou non correctement révoquées après utilisation.

Pour y remédier, les développeurs devraient utiliser des modèles de contrôle d'accès basés sur les rôles, tels que ceux trouvés dans les bibliothèques propriétaires et rôles d'OpenZeppelin. Les fonctions qui modifient les paramètres critiques doivent inclure des instructions ou des modificateurs qui vérifient l'identité ou le rôle de l'appelant.

De plus, des portefeuilles multi-signatures peuvent être utilisés pour des actions administratives, nécessitant plusieurs approbations avant d'exécuter des opérations à haut risque. Des audits réguliers et des tests des fonctions autorisés sont essentiels pour s'assurer qu'aucun chemin d'accès involontaire n'existe.

Vulnérabilités du déni de service (DOS)

Les contrats intelligents peuvent être victimes d'attaques de déni de service (DOS) , où les acteurs malveillants empêchent les utilisateurs légitimes d'interagir avec le contrat. Cela peut se produire par divers moyens, tels que forcer la consommation excessive de gaz ou bloquer les chemins d'exécution indéfiniment.

Un exemple est un contrat qui boucle via un tableau d'adresses à envoyer de l'éther. Si l'un des destinataires a une fonction de secours qui consomme un gaz ou revient excessif, il peut faire échouer toute la boucle, laissant les fonds coincés.

Pour atténuer les risques DOS, les développeurs doivent éviter les boucles qui dépendent de tableaux dynamiques. Au lieu de cela, des solutions hors chaîne ou des modèles de paiement de push-over-push peuvent être implémentés, où les utilisateurs lancent eux-mêmes les retraits plutôt que de se faire pousser des fonds.

En outre, les contrats devraient inclure des mécanismes de secours en cas de défaillance, tels que l'autorisation d'intervention manuelle par un administrateur ou la réessayer des opérations ratées. L'utilisation des limites de gaz et des délais d'attente dans les appels de fonction peut également empêcher le blocage indéfini.

Vulnérabilités de la fonction de secours

Les fonctions de secours servent de gestionnaires par défaut pour les transferts d'éther ou les appels de fonction non reconnus. Cependant, s'ils ne sont pas soigneusement conçus, ils peuvent introduire de sérieux défauts de sécurité. La fonction de secours doit être maintenue simple et ne doit pas contenir de modifications de logique ou d'état complexes.

Un risque notable est lorsqu'une fonction de secours contient une boucle ou appelle un autre contrat, augmentant les chances d'exceptions ou de réentrance hors gaz. De plus, si un contrat repose sur la réception de l'éther via la repli, mais ne tient pas compte des scénarios où l'expéditeur utilise transfert () ou envoyage (), il peut échouer de manière inattendue en raison du gaz limité transmis.

Les développeurs doivent s'assurer que les fonctions de secours rejettent l'éther inattendu avec un retour ou gérer une logique minimale. Il est également recommandé de séparer les comportements de secours payables et non payables en utilisant des fonctions recevoir () et de secours () introduites dans Solidity 0.6.0.

Auditer la logique de secours à fond et tester les cas de bord, comme l'envoi de l'éther à partir de contrats avec des replies personnalisées, est essentielle pour éviter les perturbations ou les exploits.

Questions fréquemment posées

Quels outils puis-je utiliser pour détecter les vulnérabilités des contrats intelligents? Vous pouvez utiliser des outils d'analyse statique comme Slither, Mythx et Oyente pour identifier les vulnérabilités communes. Des plates-formes comme Openzeppelin Defender et offrent tendrement les capacités de surveillance et de débogage d'exécution. Combinez toujours des outils automatisés avec des revues de code manuel et une vérification formelle pour une couverture complète.

Comment puis-je tester la réentrance dans mon contrat intelligent? Écrivez des tests unitaires qui simulent les appels externes à des contrats malveillants conçus pour réintégrer vos fonctions. Utilisez des cadres HardHat ou Truffle pour déployer et interagir avec les contrats simulés. Vous pouvez également tirer parti des outils de puzzing comme Echidna pour automatiser les tests des cas de bord.

Est-il sûr d'utiliser l'assemblage en ligne dans Solidity? L'assemblage en ligne accorde un contrôle de bas niveau sur l'EVM mais contourne de nombreuses caractéristiques de sécurité de la solidité. Il ne doit être utilisé que par des développeurs expérimentés et examiné en profondeur. Évitez de l'utiliser sauf si vous avez absolument nécessaire pour l'optimisation ou les fonctionnalités EVM spécifiques.

Un contrat peut-il être mis à niveau en toute sécurité après le déploiement? Oui, les contrats de mise à niveau utilisant des modèles proxy permettent des mises à jour tout en préservant l'état. Cependant, ils introduisent la complexité et les nouvelles surfaces d'attaque. Utilisez des modèles de mise à niveau établis comme les proxys transparents ou UUPS d'Openzeppelin et assurez les contrôles d'accès appropriés et les tests approfondis.