Contrats intelligents auto-audités avec ChatGPT

Lors de l'audit des contrats intelligents, un large éventail de questions doit être couvert pour s'assurer que le code est sécurisé. Ces questions couvrent différents aspects, notamment le contrôle d'accès, la gestion des actifs, la gestion des données, les hypothèses, les dépendances et les listes de contrôle de sécurité. Vous trouverez ci-dessous une liste de contrôle détaillée et des instructions pour les requêtes ChatGPT afin de vous guider dans le processus d'audit des contrats intelligents.

Si vous souhaitez enquêter vous-même sur un contrat intelligent pour détecter les vulnérabilités et les techniques d'escroquerie cachées, la première étape est une invite ChatGPT correctement rédigée.

Une requête utile pour ChatGPT serait la commande suivante :

Fournissez une liste complète de tous les problèmes et de toutes les vulnérabilités du contrat intelligent suivant. Décrivez les problèmes et les vulnérabilités possibles en détail. Fournir un scénario d'exploitation pour chaque vulnérabilité. Sortie sous forme de tableau valide au format markdown avec une liste d'objets, chacun avec les colonnes 'description', 'action', 'severity', 'actors', 'scenario', 'type' et 'line'. Le "type" peut être "utilisabilité", "vulnérabilité", "optimisation" ou "suggestion". 'acteurs' est une liste d'acteurs impliqués. gravité" peut être "faible", "moyenne" ou "élevée". La "ligne" est le numéro de ligne du problème. Assurez-vous que tous les champs du tableau sont remplis.

Puis utilisez les questions suivantes pour explorer le contrat intelligent plus en profondeur.

Scénarios d'utilisation :

1. Qui sont les acteurs du système?


2. Quelles sont les actions du système?


3. Quelles sont les limitations du système?


4. Quels sont les moyens potentiels de casser le système?


5. Quelles sont les défenses utilisées pour contrer les attaques?


6. Décrivez, à partir des contraintes, les changements d'état de chaque fonction.


7. Fournir des informations sur les modèles Solidity et DeFi utilisés.


8. Écrire des axiomes positifs et négatifs à partir d'informations sur le système.


9. Lister les moyens d'optimiser et de modifier le code pour le rendre plus fiable (avec des extraits de code).


10. Lister les méthodes d'escroquerie cachées utilisées dans le code (avec des extraits de code).

Conseil: La représentation visuelle des données permet souvent de mieux comprendre le fonctionnement du système. Lorsque vous travaillez avec ChatGPT, il est recommandé de demander des visualisations des données de sortie, telles que les modifications d'état sous la forme de diagrammes de caractères ASCII. Bien que toutes les visualisations n'aient pas de sens, certaines peuvent fournir des informations très précieuses sur le fonctionnement d'un contrat intelligent.

En fait, bien que ChatGPT ne puisse pas remplacer un auditeur humain, il complète de manière significative le processus d'audit en fournissant une compréhension plus claire des transitions d'état du protocole, des contraintes, des invariants et de la compatibilité. Cet outil est particulièrement efficace pour comprendre les transitions d'état et les contraintes du protocole.

Conseil: Avant de commencer un audit, fournir au chatbot de la documentation sur le protocole audité peut grandement améliorer la précision et la pertinence des réponses. Il suffit de mentionner "Voici la documentation qui fournit le meilleur contexte pour le 'nom_du_protocole' que je suis en train d'auditer" et d'insérer le document.

On peut dire que ChatGPT est un assistant puissant pour les auditeurs, qui fournit une approche structurée et approfondie de l'audit des contrats intelligents. Cependant, il faut garder à l'esprit que ChatGTP (et les services similaires) ne sont que des interprétations complexes de l'analyse de la machine travaillant avec des probabilités, de sorte qu'il produit souvent des erreurs et des inexactitudes. Par conséquent, on ne peut pas se fier entièrement aux résultats de ChatGPT - il s'agit seulement d'un bon outil entre de bonnes mains et d'un "point de départ" pour la recherche sur les contrats intelligents.

Par conséquent, afin de vous protéger contre les risques éventuels, les contrats intelligents devraient être examinés plus attentivement pour détecter les vulnérabilités et les manœuvres frauduleuses possibles.

Comment effectuer un audit approfondi d'un contrat intelligent? Top 100 des requêtes adressées à ChatGPT

Plus haut, nous avons considéré une requête générale (prompt) adressée à ChatGPT, à partir de laquelle vous pouvez commencer à analyser un smart contract. Mais, bien sûr, l'analyse détaillée ne se limite pas à l'invite d'introduction.

Les escrocs améliorent constamment leurs tactiques, vous devez donc être informé et prudent sur de nombreux aspects - ce sont des stratégies essentielles pour protéger votre investissement en jetons.

Voyons une liste des 100 principales requêtes qui vous donneront une approche professionnelle d'un audit de contrat intelligent :

1. Le code se compile-t-il avec succès?
2. Quelle version de Solidity est utilisée dans le code? S'agit-il de la version stable actuelle?
3. Des commentaires clairs expliquant le but des fonctions et des variables sont-ils présents?
4. Le contrat utilise-t-il un schéma "Ownable"? Si oui, pour quelles fonctions ?
5. Les variables d'état sont-elles correctement allouées à l'aide de modificateurs de visibilité?
6. Les événements sont-ils utilisés pour une journalisation correcte?
7. Des messages d'erreur conviviaux sont-ils fournis?
8. La valeur de retour des appels de bas niveau est-elle vérifiée?
9. Existe-t-il des scénarios dans lesquels le propriétaire peut s'autoriser lui-même, ce qui pourrait conduire à un arrachage de tapis?
10. Qui a le contrôle des comptes privilégiés et quels sont les mécanismes de contrôle?
11. Quels mécanismes de gouvernance existent dans le contrat, et la gouvernance est-elle totalement ouverte ou limitée?
12. D'autres contrats sont-ils utilisés dans le système et quels rôles remplissent-ils (par exemple, un contrat de procuration)?
13. Existe-t-il un mécanisme de verrouillage du temps et peut-il être contourné ?
14. Une documentation adéquate est-elle disponible?
15. Le code présente-t-il des vulnérabilités potentielles aux attaques par déni de service ou par réentrance?
16. Toutes les fonctions sont-elles internes, à l'exception de celles qui doivent explicitement être publiques/externes?
17. Aucun débordement/sous-débordement arithmétique dans les opérations mathématiques?
18. Utilise-t-on la bibliothèque sécurisée OpenZeppelin?
19. L'éther ou les jetons ne peuvent pas être envoyés accidentellement à une adresse nulle (0x0)?
20. Les conditions sont vérifiées avec require avant les opérations et les changements d'état?
21. L'état est-il défini avant et pendant l'exécution des actions?
22. Une protection contre les attaques par réentrée (A appelle B appelle A) est-elle utilisée?
23. L'interface ERC20 est-elle correctement mise en œuvre?
24. Le modificateur est-il utilisé à plusieurs endroits uniquement s'il est vraiment nécessaire?
25. Tous les types sont-ils définis explicitement (par exemple, uint256 est utilisé au lieu de uint)?
26. Toutes les méthodes et tous les cycles respectent-ils la limite maximale de gaz autorisée?
27. Aucune initialisation inutile dans le constructeur (rappelez-vous que les valeurs par défaut sont définies)?
28. Il existe une couverture de test complète : chaque méthode de contrat intelligent et tous les types de données d'entrée possibles sont testés?
29. Des tests fuzz ont-ils été effectués en utilisant des entrées aléatoires?
30. Tous les états possibles dans lesquels un contrat peut se trouver ont-ils été testés?
31. Les quantités par défaut d'éther et de jetons sont-elles spécifiées en unités de wei?
32. Le bloc/heure de fin de crowdsale vient-il après le bloc/heure de début (démarrage/activation des échanges)?
33. Le taux d'échange/de conversion des jetons de crowdsale est-il défini correctement?
34. Une limite souple/dure de crowdsale est-elle définie?
35. La contribution minimale/maximale autorisée à la crowdsale est-elle fixée et testée?
36. La fonctionnalité de liste blanche de la crowdsale a-t-elle été testée?
37. La logique de remboursement de la crowdsale a-t-elle été vérifiée?
38. Les participants à la crowdsale reçoivent-ils un nombre proportionnel de tokens ou peuvent-ils réclamer leur contribution?
39. La durée de chaque étape de la crowdsale (p. ex, prévente, vente publique) est-elle correctement configurée?
40. Les fonctions qui ne doivent être contrôlées que par le propriétaire sont-elles spécifiées (par exemple, interrompre la vente publique, passer à la vente publique, etc, )?
41. La logique d'acquisition des droits de la vente populaire a-t-elle été vérifiée?
42. Crowdsale dispose d'un mode de sécurité intégrée qui, lorsqu'il est activé par le propriétaire, limite les appels de fonction et inclut une fonction de remboursement?
43. Crowdsale dispose d'une fonctionnalité de repli si elle est raisonnable.
44. Les bibliothèques importées ont-elles été vérifiées au préalable et ne contiennent-elles pas de parties indésirables qui pourraient être remplacées dans de futures versions et être utilisées à des fins malveillantes?
45. Les méthodes de transfert de jetons (transfer) sont-elles enveloppées dans require?
46. Les méthodes require et assert sont-elles utilisées correctement? La méthode assert n'est utilisée que pour des choses qui ne devraient jamais se produire, habituellement elle est utilisée pour vérifier l'état après que des changements aient été effectués.
47. Est-ce qu'il y a une défense contre les attaques par appel récursif?
48. Les longueurs des chaînes arbitraires dans l'entrée sont-elles limitées?
49. Lorsque c'est possible, évitez d'utiliser des tableaux et utilisez plutôt des mappages?
50. Les blocs de hachage ne sont pas utilisés pour traiter les valeurs aléatoires (les mineurs peuvent affecter cela)?
51. On n'utilise tx.origin nulle part?
52. Les éléments des tableaux sont décalés vers le bas lorsqu'un élément est supprimé afin de ne pas laisser de vide?
53. Le revert est-il utilisé à la place du throw?
54. Les fonctions se terminent immédiatement si les conditions ne sont pas remplies?
55. Les avertissements du compilateur ont-ils été résolus?
56. La bibliothèque SafeMath est-elle utilisée dans les calculs?
57. Des emplacements de mémoire (emplacements de stockage) sont-ils lus plus d'une fois?
58. Des boucles/réseaux non bornés sont-ils utilisés, ce qui pourrait entraîner un déni de service?
59. Le bloc.timestamp n'est-il utilisé que pour les longs intervalles?
60. Ne pas utiliser le bloc. number pour calculer le temps écoulé?
61. Est-ce que l'appel de délégué est évité, en particulier pour les contrats externes (même s'ils sont de confiance)?
62. La longueur du tableau n'est-elle pas mise à jour lors de l'itération sur celui-ci?
63. Les signatures sont-elles protégées contre le rejeu par le nonce et le block.chainid?
64. Vérifiez que toutes les signatures utilisent l'EIP-712?
65. La sortie de abi.encodePacked() ne doit pas être hachée si plus de 2 types dynamiques sont utilisés. En général, il est préférable d'utiliser abi.encode().
66. Vérifiez soigneusement les insertions de code assembleur.
67. Évitez la consommation insuffisante de gaz (gas griefing).
68. Toutes les données privées sont-elles vraiment privées?
69. La mise à jour d'une structure/réseau en mémoire (memory) ne la modifiera pas en stockage (stage)?
70. Les variables de stage sont-elles éclipsées?
71. Le calcul à la volée de la valeur d'une variable est-il moins coûteux que son stockage?
72. Toutes les variables d'état sont-elles lues à partir du bon contrat (maître vs. clone)?
73. Les opérateurs de comparaison (> ;, < ;, >=, <=) sont-ils utilisés correctement, notamment pour éviter les erreurs de type "off-by-one"?
74. Les opérateurs logiques (==, ! =, && ;, ||, !) sont-ils utilisés correctement, en particulier pour éviter les erreurs de type "un par un"?
75. La multiplication est-elle toujours effectuée avant la division (sauf si la multiplication peut déborder)?
76. Les nombres magiques sont-ils remplacés par une constante portant un nom intuitif?
77. Si un destinataire de l'EPF dispose d'une fonction de repli (fallback ) qui peut être annulée, cela peut-il entraîner un déni de service?
78. La norme SafeERC20 est-elle utilisée et les valeurs de retour sont-elles vérifiées de manière sûre?
79. Suppose-t-on que l'expéditeur du message est toujours un utilisateur pertinent?
80. n'est-il pas utilisé pour l'autorisation?
81. N'utilise-t-on pas address.transfer() ou address.send() au lieu de .call.value()?
82. Lorsque l'on utilise des appels de bas niveau, il faut s'assurer qu'un contrat existe avant l'appel.
83. Le code assembleur est-il utilisé pour accéder au chainid ou au code/taille/cash du contrat au lieu de la syntaxe de Solidity?
84. Le mot-clé delete est-il utilisé pour donner une valeur nulle à une variable (0, false, "", etc.)?
85. Les expressions passées aux opérateurs logiques/comparaisons (&&/||/>=/==/etc) ne doivent pas avoir d'effets de bord.
86. Lorsque vous avez affaire à des adresses multiples, demandez-vous ce qui se passe si elles sont identiques?
87. À quel point le code est-il documenté? Des commentaires et des exemples sont-ils fournis lorsque du code non standard est utilisé?
88. Si un appel externe est utilisé, assurez-vous qu'un appel de contrat externe est réellement nécessaire?
89. Le résultat de l'appel externe est-il vérifié et les erreurs sont-elles gérées?
90. Que se passe-t-il si l'appel externe utilise tous les gaz fournis?
91. Si l'appel externe appelle une fonction spécifique, assurez-vous que la fonction existe réellement (fonctions fantômes).
92. Vérifiez qu'aucun appel externe n'est utilisé dans les modificateurs (modifiers)
93. Des événements sont-ils émis pour chaque fonction qui modifie le stockage?
94. Vérifiez vos hypothèses sur ce que font et renvoient les contrats externes utilisés dans le principal.
95. Surveillez les jetons qui utilisent trop ou pas assez de décimales. Veillez à ce que les valeurs maximales et minimales prises en charge soient documentées.
96. L'autorité associée aux rôles est-elle documentée?
97. Quels sont les risques en cas de violation des droits d'accès et comment cela peut-il affecter les différents composants du système?
98. Le propriétaire peut-il manipuler les jetons et l'ETH dans le cadre du contrat?
99. Comment l'adresse de l'oracle (Oracle) est-elle définie et quel est le processus qui la sous-tend? Existe-t-il des oracles de rechange pour la sauvegarde?
100. Comment des fonctions similaires sont-elles mises en œuvre dans d'autres projets, les meilleures pratiques ont-elles été prises en compte?

Cette liste de contrôle vous aidera à vous assurer que vous menez un audit de sécurité approfondi des contrats intelligents Solidity. Elle couvre un large éventail d'aspects critiques pour identifier et atténuer les vulnérabilités et les risques potentiels dans le code et les systèmes connexes.

 

Nous espérons que ces exemples vous ont aidé à mieux comprendre la méthodologie d'audit des smart contracts.

 

Dans la mesure où toutes les informations de la blockchain sont ouvertes (à condition, bien sûr, que le code source du contrat soit vérifié), armé de ces connaissances, vous pouvez étudier de manière indépendante les smart contracts et identifier les différentes arnaques.

Toutefois, nous avons déjà fait tout cela pour vous ! Souscrivez à un abonnement premium et accédez à des filtres exclusifs sur les caractéristiques des smart contracts et à des analyses fraîches. Augmentez vos chances d'investir avec succès dans des jetons rentables.

Regards, Lotus Market team.

All posts