Qu'est-ce qu'un Contrat Intelligent ?

Ethereum possède deux types courants de comptes : les Comptes Détenus Extérieurement (EOA) et les Comptes de Contrat Intelligent (SCA).

Les EOA sont très similaires aux comptes financiers électroniques que nous utilisons couramment pour stocker des fonds et interagir avec des applications. Par exemple, les utilisateurs déposent de la monnaie fiduciaire via PayPal et interagissent avec divers sites web, magasins et applications pour effectuer des paiements. Les mineurs DeFi stockent généralement des cryptomonnaies dans leurs EOA, interagissent avec les dApps DeFi et déposent des fonds dans les dApps pour en tirer profit. Cependant, les EOA possèdent une caractéristique que les comptes financiers électroniques n'ont pas : les utilisateurs doivent avoir le contrôle de leurs EOA vérifié par la possession de clés privées — pas vos clés, pas vos pièces.

Les SCA sont également un type de compte qui est essentiellement associé à un segment de code octet exécutable (également connu sous le nom de contrat intelligent). Le contrat intelligent décrit diverses logiques commerciales et sert de backend pour les dApps. Cependant, malgré des restrictions plus importantes par rapport aux langages de développement Turing-complets traditionnels, les contrats intelligents quasi-Turing-complets ont néanmoins été vulnérables à de nombreuses attaques, portant d'innombrables coups à l'industrie de la blockchain.

Attaques Courantes sur les Contrats Intelligents

1. Attaque par Réentrance

L'attaque la plus courante et la plus notoire est l'attaque par réentrance, qui a été responsable de la fourche d'Ethereum ayant conduit à la création d'Ethereum Classic. En 2016, des pirates ont exécuté une attaque par réentrance sur le contrat The DAO, volant 3 600 000 ETH d'une valeur de plus de 150 millions de dollars à l'époque. Cette attaque, survenue aux premiers stades d'Ethereum, a dévasté l'écosystème et brisé la confiance des investisseurs, conduisant finalement à une fourche.

Logique Spécifique

Voici un exemple pour vous aider à mieux comprendre le principe de l'attaque par réentrance. La Banque B avait précédemment prêté de l'argent à la Banque A. Un jour, la Banque B initie un transfert vers la Banque A, demandant le transfert de tout l'argent vers la Banque B. Le chemin normal est le suivant :

Étape 1 : La Banque B demande le retrait des fonds

Étape 2 : La Banque A transfère les fonds à la Banque B

Étape 3 : La Banque A confirme le transfert réussi à la Banque B

Étape 4 : La banque A met à jour le solde du compte de la banque B.

Cependant, si la banque B crée une faille après l'étape 2 et continue de demander tout l'argent à la banque A sans confirmation à l'étape 3, alors le solde du compte de la banque A à la banque B restera inchangé. Cet appel récursif videra tous les actifs de la banque A.

Contrats intelligents associés

Le contrat de la banque A comprend deux fonctions :

deposit() : Une fonction de dépôt qui dépose de l'argent dans la banque A et met à jour le solde de l'utilisateur ;
withdraw() : Une fonction de retrait qui permet aux utilisateurs de retirer tous leurs fonds de la banque A.

Le contrat d'attaque de la banque B implique principalement une boucle qui déclenche la fonction de rappel receive(), qui à son tour appelle la fonction withdraw() du contrat de la banque pour vider les actifs de la banque A à travers une séquence de 1 dépôt, 1 retrait, et des appels de fonction de rappel receive(), et finalement met à jour le solde de B chez A. Il comprend deux fonctions : receive() : Une fonction de rappel déclenchée lorsque l'ETH est reçu, qui appelle récursivement la fonction withdraw() du contrat de la banque pour effectuer des retraits.
attack() : Elle appelle d'abord la fonction deposit() du contrat de la banque pour rafraîchir le solde, puis la fonction withdraw() pour initier le premier retrait, et déclenche la fonction de rappel receive() pour appeler récursivement withdraw() afin de vider les actifs du contrat de la banque.

Solution

Mise en œuvre d'un verrou de réentrée

Un verrou de réentrée est un modificateur utilisé pour empêcher la réentrée, garantissant qu'un appel doit terminer son exécution avant de pouvoir être invoqué à nouveau. Par exemple, puisque l'attaque de la Banque B nécessite d'appeler la fonction withdraw() du contrat Bank plusieurs fois, elle échouera avec la mise en œuvre d'un verrou de réentrée.

Comment l'utiliser

2. Mauvaise utilisation de tx.origin

La fonction principale de tx.origin dans un contrat intelligent est de récupérer le compte d'origine qui a initié la transaction. Ici, nous discuterons de deux variables courantes dans les contrats intelligents : msg.sender et tx.origin . msg.sender récupère le compte appelant directement le contrat intelligent, tandis que dans le monde de la blockchain, en raison des appels imbriqués et mutuels de différents contrats intelligents (comme le DeFi Lego), tx.origin est nécessaire pour obtenir le compte d'origine qui a initié la transaction. Une vulnérabilité survient lorsque les développeurs de dApps ne vérifient que la sécurité de tx.origin dans le code, négligeant la vérification de sécurité des attaquants déployant des contrats intermédiaires pour contourner tx.origin et lancer des attaques.

Logique spécifique

Voici un exemple pour vous plonger dans le scénario d'attaque courant. Bill possède un portefeuille intelligent qui vérifie si Bill est l'initiateur d'un transfert. Une fois, Bill a créé un NFT sur un site web de phishing. Cela a permis au site web d'obtenir l'identité de Bill et d'initier un transfert depuis son portefeuille intelligent en utilisant son identité, entraînant des pertes d'actifs. Dans des circonstances normales, les utilisateurs sont moins susceptibles de tomber dans ce piège, mais lors de l'interaction avec des dApps en utilisant un portefeuille, ils oublient souvent de vérifier les invites d'interaction. Par exemple, si les deux impliquent la fonction Mint(), les utilisateurs inattentifs peuvent facilement tomber dans un piège de phishing. La logique métier au sein du site web de phishing est truffée de pièges, il est donc important de vérifier les invites d'interaction pour détecter les erreurs lors des interactions régulières.

Contrat de portefeuille intelligent

Le contrat de portefeuille intelligent comprend une fonction :

transfer() : Une fonction de retrait qui ne peut être initiée que par le propriétaire du portefeuille, qui dans ce cas est Bill.

Contrat d'attaque de phishing

Dans un contrat d'attaque par hameçonnage, Mint() incite les utilisateurs à transférer des fonds vers l'adresse d'un pirate informatique. Il comprend une fonction :

Mint() : Une fois appelée, la fonction de hameçonnage exécute en interne transfer() du contrat Wallet. Comme l'initiateur original est l'utilisateur lui-même (dans cet exemple, Bill), la vérification require(tx.origin == owner, "Not owner") ne posera pas de problème. Cependant, l'adresse cible du transfert a déjà été modifiée pour correspondre à l'adresse du pirate, entraînant ainsi un vol de fonds.

Solutions

1. Utiliser msg.sender au lieu de tx.origin

Quel que soit le nombre d'appels de contrat impliqués (Contrat A → Contrat B →...→ contrat cible), vérifiez uniquement msg.sender, c'est-à-dire l'appelant direct, pour éviter les attaques causées par des contrats intermédiaires malveillants.

2. Vérifier tx.origin == msg.sender

Cette méthode peut tenir les contrats malveillants à l'écart, mais les développeurs doivent prendre en compte leurs propres réalités commerciales car elle isole effectivement tous les autres appels de contrats externes.

3. Attaque du Générateur de Nombres Aléatoires (GNA)

Cela remonte à la tendance des applications décentralisées de jeux de hasard ou de paris autour de 2018 et 2019. Généralement, les développeurs utilisent certaines graines dans les contrats intelligents pour générer des nombres aléatoires afin de sélectionner les gagnants lors des tirages. Les graines courantes incluent block.number, block.timestamp, blockhash et keccak256. Cependant, les mineurs peuvent contrôler entièrement ces graines, donc dans certains cas, des mineurs malveillants peuvent manipuler les variables pour en tirer profit.

Contrats de dés courants

Le contrat de dés comprend une fonction :

Bet() : Une fonction de pari où les utilisateurs saisissent un numéro de pari et paient un ETH. Un nombre aléatoire est généré avec plusieurs graines, et si le numéro de pari correspond au nombre aléatoire, l'utilisateur remporte l'intégralité de la cagnotte.

Contrat d'attaque du mineur

Les mineurs peuvent gagner tant qu'ils pré-calculent le nombre aléatoire gagnant et l'exécutent dans le même bloc. Cela inclut une fonction :

attack() : Une fonction d'attaque par pari, où le mineur pré-calcule le nombre aléatoire gagnant. Comme elle est exécutée dans le même bloc, blockhash(block.number - 1) et block.timestamp dans le même bloc sont identiques. Ensuite, le mineur appelle Bet() du contrat de dés pour compléter l'attaque.

Solution

Utiliser des nombres aléatoires hors chaîne fournis par des projets d'oracle

Grâce aux services fournis par des projets d'oracle tels que Chainlink, des nombres aléatoires on-chain sont injectés dans les contrats on-chain pour garantir l'aléatoire et la sécurité. Cependant, les projets d'oracle comportent également des risques de centralisation, nécessitant ainsi des services d'oracle plus matures.

4. Attaque par rejeu

Une attaque par rejeu consiste à réinitier une transaction en utilisant une signature précédemment utilisée pour voler des fonds. L'une des attaques par rejeu les plus connues de ces dernières années a été le vol de 20 millions de jetons $OP du teneur de marché Wintermute sur Optimism, qui était une attaque par rejeu inter-chaînes. Étant donné que le compte de portefeuille multi-signatures de Wintermute n'était temporairement déployé que sur le réseau principal Ethereum, le pirate a utilisé la signature de la transaction pour le déploiement d'une adresse multi-signatures de Wintermute sur Ethereum pour ré-exécuter la même transaction sur la chaîne Optimism, obtenant ainsi le contrôle du compte de portefeuille multi-signatures sur Optimism. Un compte de portefeuille multi-signatures est essentiellement un compte de contrat intelligent, ce qui démontre également une différence significative entre SCA et EOA. Pour un EOA, un utilisateur normal n'a besoin que d'une seule clé privée pour contrôler toutes les adresses sur Ethereum et les chaînes compatibles EVM (les chaînes d'adresses sont exactement les mêmes), tandis qu'un SCA n'est efficace que sur une seule chaîne après avoir été déployé.

Logique spécifique

Ici, nous fournissons un exemple d'une attaque par rejeu typique (attaque par rejeu sur la même chaîne). Bill possède un portefeuille intelligent qui nécessite qu'il entre sa signature électronique avant que chaque transaction ne puisse être exécutée. Maintenant que la pirate Lucy a volé la signature électronique de Bill, elle peut initier un nombre illimité de transactions pour vider le portefeuille intelligent de Bill.

Exemple

Un contrat avec des vulnérabilités se compose de trois fonctions :

checkSig() : Fonction de vérification ECDSA, s'assurant que le résultat de la vérification est le signataire initialement défini.
getMsgHash() : Fonction de génération de hash, qui combine to et amount pour former le hash.
transfer() : Fonction de transfert, permettant aux utilisateurs de retirer des fonds du pool de liquidité. En raison de l'absence de restrictions sur la signature, la même signature peut être réutilisée, permettant aux pirates de voler continuellement des fonds.

Solution

Inclure le nonce dans la combinaison de signature pour prévenir les attaques par rejeu. Le principe du paramètre est le suivant :

nonce : Il décrit la variable du nombre de transactions d'un EOA dans le réseau blockchain. Il a un ordre et une unicité. À chaque transaction supplémentaire, la valeur du nonce augmentera de 1. Le réseau blockchain vérifiera si le nonce de la transaction est cohérent avec le nonce actuel du compte. Par conséquent, un pirate échouerait s'il utilisait une signature déjà utilisée car la valeur du nonce dans la combinaison de signature serait inférieure à la valeur actuelle du nonce de l'EOA.

5. Attaque par déni de service (DoS)

L'attaque par déni de service (DoS) n'est pas nouvelle dans le monde traditionnel du Web2. Elle fait référence à toute interférence avec un serveur, comme l'envoi d'une grande quantité d'informations indésirables ou perturbatrices, entravant ou détruisant complètement la disponibilité. De même, les contrats intelligents sont affectés par de telles attaques, qui visent essentiellement à faire dysfonctionner le contrat intelligent.

Logique spécifique

Prenons un exemple. Le Projet A mène une offre publique pour le jeton du protocole, où tous les utilisateurs peuvent contribuer des fonds au pool de liquidité (Contrat Intelligent) pour acheter des quotas selon le principe du premier arrivé, premier servi, et les fonds excédentaires seront restitués aux participants. Le pirate Alice exploite le contrat d'attaque pour participer à l'offre publique. Une fois que le pool de liquidité tente de restituer les fonds au contrat d'attaque d'Alice, une attaque DoS sera déclenchée, empêchant l'action de retour de se réaliser. En conséquence, une grande quantité de fonds sont bloqués dans le contrat intelligent.

Exemple de contrat d'offre publique

Exemple

Le contrat d'offre publique comprend deux fonctions :

deposit() : fonction de dépôt, enregistrant l'adresse du déposant et le montant contribué.
refund() : fonction de remboursement, avec laquelle l'équipe du projet restitue les fonds aux investisseurs.

Contrat d'attaque DoS

Le contrat d'attaque DoS comprend une fonction :

attack() : Bien qu'il s'agisse d'une fonction d'attaque, elle ne présente aucun problème. Le problème principal réside dans la fonction de rappel de paiement receive() intégrée au contrat Hacker, qui inclut un jugement d'exceptions. Tout contrat externe transférant des fonds au contrat Hacker déclenchera une exception via revert(), empêchant ainsi l'opération de se terminer.

Solutions

1. Éviter que les fonctionnalités critiques ne se bloquent lors de l'invocation de contrats externes

Retirer require(success, "Refund Fail!"); de la fonction refund() ci-dessus du contrat PublicSale, garantissant ainsi que l'opération de remboursement puisse se poursuivre même si un remboursement à une seule adresse échoue.

2. Découplage

Dans la fonction refund() ci-dessus du contrat PublicSale, permettre aux utilisateurs de réclamer eux-mêmes leurs remboursements plutôt que de distribuer les remboursements, minimisant ainsi les interactions inutiles avec des contrats externes.

6. Attaque par permit

Dans une attaque par autorisation, le Compte A fournit à l'avance la signature à une partie désignée, puis le Compte B, après avoir obtenu la signature, peut effectuer des transferts de jetons autorisés pour dérober une certaine quantité de jetons. Ici, nous discutons principalement de deux fonctions courantes pour l'autorisation de jetons dans les Contrats Intelligents : approve() et permit().

Dans le contrat ERC20 courant, le Compte A peut appeler approve() pour autoriser une certaine quantité de jetons pour le Compte B, permettant à ce dernier de transférer ces jetons du premier. De plus, permit() a été introduit dans les contrats ERC20 dans l'EIP-2612, et Uniswap a publié une nouvelle norme d'autorisation de jetons, Permit2, en novembre 2022.

Logique spécifique

Voici un exemple. Un jour, Bill naviguait sur un site web d'actualités blockchain lorsque soudainement une fenêtre de signature Metamask est apparue. Comme de nombreux sites web ou applications blockchain utilisent des signatures pour vérifier les connexions des utilisateurs, Bill n'y a pas accordé beaucoup d'importance et a complété directement la signature. Cinq minutes plus tard, ses actifs Metamask ont été vidés. Bill a ensuite découvert dans l'explorateur blockchain qu'une adresse inconnue avait initié une transaction permit(), suivie d'une transaction transferFrom() qui a vidé son portefeuille.

Exemple

Les deux fonctions sont les suivantes :

approve() : Une fonction d'autorisation standard où le Compte A autorise un certain montant de fonds au Compte B.
permit() : Une fonction d'autorisation par signature où le Compte B soumet et complète la vérification de signature pour obtenir le montant autorisé du Compte A. Les paramètres incluent le propriétaire accordant l'autorisation, le bénéficiaire autorisé, le montant autorisé, la date limite de la signature, et les données de signature v, r, et s du propriétaire.

Solutions

1. Prêtez attention à chaque signature dans les interactions sur la chaîne

Malgré les mesures prises par certains portefeuilles pour décoder et afficher les informations de signature d'autorisation approve(), ils ne fournissent presque aucun avertissement pour le hameçonnage de signature permit(), augmentant ainsi le risque d'attaques. Par conséquent, il est fortement recommandé d'inspecter rigoureusement chaque signature inconnue pour s'assurer qu'elle vise bien la fonction permit().

2. Séparez le portefeuille pour les interactions régulières du portefeuille stockant les actifs

Ceci est extrêmement important pour les utilisateurs de crypto-monnaies, en particulier les chasseurs d'airdrops, car ils interagissent quotidiennement avec d'innombrables dApps ou sites web et sont sujets aux pièges. Stocker uniquement une petite quantité de fonds dans un portefeuille pour les interactions régulières peut maintenir les pertes dans une fourchette gérable.

7. Attaque par pot de miel

Dans l'industrie de la blockchain, une attaque par pot de miel fait référence à un type de contrats de jetons malveillants déployés par les équipes de projet. Le contrat n'accorde qu'à l'équipe du projet la permission de vendre, tandis que les utilisateurs réguliers ne peuvent qu'acheter au lieu de vendre, subissant ainsi des pertes.

Logique spécifique

Voici un exemple. Dans une annonce sur Telegram, le Projet A informe les utilisateurs que le jeton a été déployé sur le réseau principal et est disponible pour le trading. Comme le jeton ne peut être qu'acheté et ne peut pas être vendu, le prix a d'abord continué à augmenter, et les utilisateurs qui craignent de manquer l'occasion continuent d'acheter. Après un certain temps, lorsque les utilisateurs découvrent qu'il est impossible de vendre, l'équipe du projet saisit l'opportunité et vend massivement les jetons, provoquant une chute du prix.

Exemple

Fonction principale :

_beforeTokenTransfer() : Une fonction interne appelée lors des transferts de jetons, qui ne peut réussir que lorsqu'elle est appelée par le propriétaire ; les appels provenant d'autres comptes échoueront.

Solution

Utiliser des outils d'analyse de sécurité

a. Token Sniffer pour les jetons Ethereum

b. Ave Check pour les jetons sur d'autres chaînes

c. Sites web de marché avec des outils de détection intégrés comme Dextools

Évitez de négocier des jetons avec des scores faibles.

8. Attaque de front-running

Le front-running est apparu à l'origine sur les marchés financiers traditionnels, où l'asymétrie de l'information permettait aux intermédiaires financiers de réaliser des profits en agissant rapidement sur la base d'informations spécifiques à l'industrie. Dans l'industrie de la blockchain, le front-running provient principalement du front-running sur la chaîne, qui consiste à manipuler les mineurs pour qu'ils donnent la priorité à l'intégration de ses propres transactions sur la chaîne afin de réaliser des profits.

Dans le domaine de la blockchain, les mineurs peuvent tirer profit en manipulant les transactions qu'ils intègrent dans les blocs, par exemple en excluant certaines transactions et en réorganisant l'ordre des transactions. Ce profit peut être mesuré par la Valeur Extractible par le Mineur (MEV). Avant qu'une transaction d'un utilisateur ne soit ajoutée au réseau principal Ethereum, la majorité des transactions sont agrégées dans le mempool. Les mineurs recherchent dans ce mempool les transactions avec des prix de gaz plus élevés et privilégient leur intégration pour maximiser leurs gains. Généralement, les transactions avec des prix de gaz plus élevés sont plus facilement intégrées par les mineurs. Parallèlement, certains robots MEV scrutent également le mempool à la recherche de transactions rentables.

Logique spécifique

Voici un exemple. Bill découvre un nouveau jeton populaire avec des fluctuations de prix significatives. Pour garantir le succès des transactions de jetons sur Uniswap, Bill définit une fourchette de glissement exceptionnellement large. Malheureusement, le robot MEV d'Alice détecte cette transaction dans le mempool et augmente rapidement les frais de gaz, initiant une transaction d'achat avant celle de Bill et insérant une transaction de vente après celle de Bill dans le même bloc. Après la confirmation du bloc, cela entraîne des pertes importantes dues au glissement pour Bill, tandis qu'Alice profite d'une opération d'arbitrage en achetant à bas prix et en vendant à prix élevé.

Exemple

La fonction est la suivante :

solve() : Une fonction de devinette où n'importe qui peut soumettre une réponse, et si la réponse soumise correspond à la réponse cible, le soumissionnaire peut recevoir 10 ethers.

Processus : Bill trouve la bonne réponse.
Alice surveille le mempool, attendant que quelqu'un soumette la bonne réponse.
Bill appelle solve() pour soumettre la réponse et fixe le prix du gaz à 100 Gwei.
Alice voit la transaction envoyée par Bill et découvre la réponse. Elle fixe un prix du gaz plus élevé que celui de Bill à 200 Gwei et appelle solve().
La transaction d'Alice est emballée par le mineur avant celle de Bill.
Alice gagne une récompense de 10 ethers.

Solution

Les trois fonctions principales sont les suivantes :

commitSolution() : Une fonction pour soumettre les résultats, plaçant la réponse soumise par l'utilisateur solutionHash, l'heure de soumission commitTime, et l'état revealed dans la structure Commit.
getMySolution() : Une fonction pour obtenir les résultats, permettant aux utilisateurs de visualiser leurs réponses soumises et les informations connexes, y compris la réponse soumise par l'utilisateur solutionHash, l'heure de soumission commitTime, et l'état revealed.
revealSolution() : Une fonction pour réclamer les récompenses pour avoir deviné l'énigme, permettant aux utilisateurs de réclamer des récompenses après avoir fourni la réponse et le mot de passe qu'ils ont défini.

Processus :

Bill trouve la bonne réponse.
Bill appelle commitSolution() pour soumettre la bonne réponse.
Dans le bloc suivant, Bill appelle revealSolution(), fournissant la réponse et le mot de passe qu'il a défini pour réclamer la récompense.

Dans commitSolution(), Bill soumet une chaîne cryptée, ne gardant que pour lui-même les données en texte clair soumises. À cette étape, le temps du bloc de soumission commitTime est également enregistré. Ensuite, dans revealSolution(), le temps du bloc est vérifié pour empêcher le front-running au sein du même bloc. Comme l'appel à revealSolution() nécessite la soumission de la réponse en texte clair, cette étape vise à empêcher les autres de contourner commitSolution() et d'appeler directement revealSolution(). Après une vérification réussie, la récompense sera distribuée si la réponse est jugée correcte.

Conclusion

Les contrats intelligents jouent un rôle crucial dans la technologie blockchain et offrent de nombreux avantages. Premièrement, ils permettent une exécution décentralisée et automatisée, assurant la sécurité et la fiabilité des transactions sans tiers. Deuxièmement, les contrats intelligents réduisent les étapes intermédiaires et les coûts, améliorant ainsi l'efficacité des transactions.

Malgré tous ces avantages, les contrats intelligents sont également exposés au risque d'attaques qui peuvent entraîner des pertes financières pour les utilisateurs. Ainsi, certaines habitudes sont essentielles pour les utilisateurs de la chaîne. Tout d'abord, les utilisateurs doivent toujours choisir soigneusement les dApps avec lesquelles ils interagissent et examiner attentivement le code du contrat et les règles associées. De plus, ils doivent régulièrement mettre à jour et utiliser des portefeuilles sécurisés et des outils d'interaction avec les contrats pour atténuer le risque d'attaques de pirates. En outre, il est conseillé de stocker leurs fonds dans plusieurs adresses pour minimiser les pertes potentielles dues aux attaques de contrats.

Pour les acteurs de l'industrie, assurer la sécurité et la stabilité des contrats intelligents est tout aussi important. La première priorité devrait être de renforcer l'audit des contrats intelligents afin d'identifier et de rectifier les vulnérabilités potentielles et les risques de sécurité. Deuxièmement, les acteurs de l'industrie devraient se tenir informés des derniers développements de la blockchain liés aux attaques de contrats et prendre des mesures de sécurité en conséquence. Enfin, et ce n'est pas le moins important, ils devraient également renforcer l'éducation des utilisateurs et la sensibilisation à la sécurité en ce qui concerne l'utilisation correcte des contrats intelligents.

En conclusion, grâce aux efforts concertés des utilisateurs et des acteurs de l'industrie, les risques de sécurité posés par les contrats intelligents peuvent être considérablement atténués. Les utilisateurs doivent toujours sélectionner soigneusement les contrats et protéger leurs actifs personnels, tandis que les acteurs de l'industrie doivent intensifier l'audit des contrats, se tenir au courant des avancées technologiques et renforcer l'éducation des utilisateurs et la sensibilisation à la sécurité. Ensemble, nous favoriserons le développement sûr et fiable des contrats intelligents.

Références :

Solidity by Example : https://solidity-by-example.org/

Blockchain Know-how de SlowMist : https://mp.weixin.qq.com/mp/appmsgalbum?__biz=MzU4ODQ3NTM2OA==&action=getalbum&album_id=1378673890158936067&scene=173&from_msgid=2247498135&from_itemidx=1&count=3&nolastread=1#wechat_redirect

Chainlink - Top 10 des meilleures pratiques de sécurité DeFi : https://blog.chain.link/defi-security-best-practices/#post-title

WTF - Solidity 104 Sécurité des contrats : https://www.wtf.academy/solidity-104/

Vulnérabilités dans les contrats intelligents DeFi en 4 catégories avec 38 scénarios : https://www.weiyangx.com/381670.html

OpenZeppelin : https://github.com/OpenZeppelin/

Une Introduction aux Vulnérabilités et Attaques Courantes dans les Contrats Intelligents