Comment auditer un contrat intelligent ? (Bases de la sécurité)

Comprendre les vulnérabilités des contrats intelligents

1. Les attaques de réentrée se produisent lorsqu'un contrat malveillant rappelle à plusieurs reprises le contrat vulnérable avant que les changements d'état ne soient finalisés, drainant ainsi des fonds de manière inattendue.

2. Des dépassements et des dépassements inférieurs d'entiers se produisent lorsque des opérations arithmétiques dépassent les valeurs maximales ou minimales de uint256, entraînant des soldes incorrects ou des contournements logiques.

3. Les appels externes non contrôlés peuvent entraîner des échecs silencieux si les valeurs de retour ne sont pas validées, permettant ainsi l'exécution de se poursuivre malgré l'échec des transferts ou des invocations de fonctions.

4. Un contrôle d'accès inapproprié permet à des utilisateurs non autorisés d'invoquer des fonctions privilégiées telles que des mises à niveau réservées au propriétaire ou la frappe de jetons.

5. L’anticipation devient possible lorsque les transitions d’état critiques reposent sur un ordre prévisible des transactions, exposant ainsi des opérations sensibles telles que les enchères ou les arbitrages de prêts flash.

Outils d'analyse statique et leur rôle

1. Slither analyse le code source de Solidity à la recherche d'anti-modèles et de vulnérabilités courants sans exécuter le contrat, offrant ainsi une détection rapide et évolutive.

2. MythX s'intègre aux IDE et aux pipelines CI/CD pour effectuer une exécution symbolique et une analyse basée sur le fuzzing, identifiant ainsi des failles logiques plus profondes.

3. Solhint applique les normes de codage et les meilleures pratiques en signalant les spécificateurs de visibilité incohérents, les instructions require manquantes et les appels de bas niveau dangereux.

4. Echidna de Crytic effectue des tests basés sur les propriétés à l'aide d'assertions personnalisées écrites dans Solidity, vérifiant les invariants sur des milliers d'entrées générées.

5. L’utilisation de plusieurs analyseurs statiques en parallèle augmente considérablement la couverture : aucun outil ne détecte à lui seul toutes les classes de bogues.

Éléments essentiels de la révision manuelle du code

1. Suivez tous les appels externes et vérifiez s'ils surviennent après des mises à jour d'état, notamment dans les fonctions de retrait ou de transfert.

2. Confirmez que toutes les entrées fournies par l'utilisateur passent par les instructions require ou revert avant d'affecter le stockage ou d'émettre des événements.

3. Inspectez les fonctions de secours et de réception pour détecter tout comportement involontaire, en particulier lors de la gestion des transferts ETH avec une logique complexe.

4. Recherchez les adresses codées en dur, les nombres magiques ou les liens de bibliothèques non versionnés qui pourraient compromettre la reproductibilité ou introduire des dépendances cachées.

5. Chaque modificateur doit être audité pour la sécurité de la réentrée, les effets secondaires et la composabilité avec d'autres modificateurs.

Méthodologies de test au-delà des contrôles unitaires

1. Les tests d'intégration simulent les interactions entre plusieurs contrats déployés pour révéler les inadéquations d'interface et les modèles de consommation de gaz inattendus.

2. Les tests fuzz injectent des entrées aléatoires dans les fonctions publiques pour déclencher des comportements extrêmes que les tests unitaires oublient souvent.

3. Les tests basés sur la propriété définissent des invariants de haut niveau, tels que « l'offre totale ne diminue jamais » ou « les soldes ne peuvent pas devenir négatifs » – et les valident dans divers scénarios.

4. Les réseaux de test comme Sepolia et Arbitrum Goerli fournissent des environnements réalistes où la dynamique réelle du gaz et la congestion du réseau peuvent être observées.

5. La logique dépendante du temps doit être testée sous simulation de manipulation d'horodatage de bloc pour garantir l'exactitude en cas de retards ou de planification future.

Foire aux questions

Q : Puis-je compter uniquement sur des outils automatisés pour l’audit des contrats intelligents ? R : Non. Les outils automatisés détectent les modèles connus, mais ne peuvent pas évaluer l'exactitude de la logique métier, les incitations économiques ou les nouveaux vecteurs d'attaque nécessitant l'intuition humaine et la connaissance du domaine.

Q : Que signifie « configuration fiable » dans le contexte de contrats à preuve de connaissance nulle ? R : Il fait référence à la génération initiale des paramètres cryptographiques requis pour la vérification zk-SNARK ; s’il est compromis, il rompt les garanties de solidité et permet aux fausses preuves de passer la validation.

Q : Pourquoi devrais-je éviter d'utiliser tx.origin pour les contrôles d'autorisation ? R : Parce que tx.origin renvoie l'EOA d'origine qui a initié la chaîne de transaction, ce qui le rend vulnérable au phishing via des contrats intermédiaires qui transfèrent les appels tout en préservant l'origine.

Q : En quoi les vulnérabilités des appels délégués diffèrent-elles des vulnérabilités des appels normaux ? R : Delegatecall exécute du code dans le contexte du contrat appelant, ce qui signifie que des discordances de disposition de stockage ou des variables non initialisées dans la cible peuvent corrompre directement l'état de l'appelant.