Récemment, un expert en sécurité a partagé une leçon de sécurité DeFi avec les membres de la communauté. L'expert a passé en revue les événements de sécurité majeurs auxquels l'industrie Web3 a été confrontée au cours de l'année écoulée, a exploré les raisons de ces événements et les méthodes d'évitement, a résumé les vulnérabilités de sécurité courantes des contrats intelligents et les mesures préventives, et a également donné quelques conseils de sécurité aux développeurs de projets et aux utilisateurs ordinaires.
Les types courants de vulnérabilités DeFi incluent les prêts flash, la manipulation des prix, les problèmes de droits d'accès des fonctions, les appels externes arbitraires, les problèmes de fonction fallback, les failles de logique commerciale, les fuites de clés privées, et les attaques par réentrance, entre autres. Nous allons nous concentrer ici sur les prêts flash, la manipulation des prix et les attaques par réentrance.
Prêt éclair
Les prêts flash sont une innovation dans la Finance décentralisée, mais lorsqu'ils sont exploités par des hackers, ils peuvent emprunter de l'argent sans coût pour réaliser des arbitrages. De nombreux projets DeFi semblent offrir des rendements élevés, mais le niveau des équipes varie, et même si le code n'a pas de vulnérabilités, des problèmes logiques peuvent encore exister. Par exemple, certains projets distribuent des récompenses à des moments fixes en fonction du nombre de jetons détenus par les détenteurs, mais les attaquants peuvent utiliser des prêts flash pour acheter une grande quantité de jetons et obtenir la majorité des récompenses au moment de la distribution. D'autres projets qui calculent les prix via des tokens peuvent également être influencés par des prêts flash. Les équipes de projet devraient être vigilantes face à ces problèmes.
Manipulation des prix
Les problèmes de manipulation des prix sont étroitement liés aux prêts flash, principalement en raison du fait que certains paramètres peuvent être contrôlés par les utilisateurs lors du calcul des prix. Il existe deux types de problèmes courants :
Lors du calcul des prix, des données tierces sont utilisées, mais une mauvaise utilisation ou un manque de vérification ont entraîné une manipulation malveillante des prix.
Utiliser le nombre de tokens d'adresses spécifiques comme variable de calcul, tandis que le solde de tokens de ces adresses peut être temporairement augmenté ou diminué.
Attaque par réentrance
L'un des principaux dangers d'appeler des contrats externes est qu'ils peuvent prendre le contrôle du flux, entraînant des modifications inattendues des données lors de l'appel de fonctions. Il existe de nombreuses façons de réentrer pour différents contrats, pouvant combiner différentes fonctions ou les fonctions de plusieurs contrats pour effectuer une attaque. Pour résoudre le problème de la réentrance, il faut faire attention :
Ne pas seulement prévenir le problème de réentrance d'une seule fonction.
Suivre le modèle Checks-Effects-Interactions
Utiliser un modificateur de protection contre la réentrance éprouvé par le temps
Ce que je crains le plus, c'est de réinventer la roue. Dans ce domaine, il existe de nombreuses meilleures pratiques de sécurité qui peuvent être directement utilisées, il n'est donc pas du tout nécessaire de réinventer la roue. Créer sa propre roue sans validation adéquate augmente clairement la probabilité de problèmes par rapport à l'utilisation de solutions matures et éprouvées.
Conseils de sécurité pour les projets
Le développement de contrats suit les meilleures pratiques de sécurité
Les contrats peuvent être mis à niveau et suspendus
Utiliser un verrouillage temporel
Accroître les investissements en matière de sécurité et établir un système de sécurité complet
Améliorer la sensibilisation à la sécurité de tous les employés
Prévenir les malversations internes tout en améliorant l'efficacité et en renforçant le contrôle des risques.
Introduire prudemment des tiers, vérifier en amont et en aval
Comment les utilisateurs/LP peuvent-ils évaluer la sécurité d'un contrat intelligent
Le contrat est-il open source ?
Le propriétaire utilise-t-il la multi-signature, la multi-signature est-elle décentralisée ?
Situations de transaction existantes du contrat
Le contrat est-il un contrat d'agence, est-il évolutif, y a-t-il un verrouillage temporel ?
Le contrat a-t-il été audité par plusieurs institutions, les droits du propriétaire sont-ils trop étendus ?
Faites attention au choix et à l'utilisation des oracles.
En résumé, les utilisateurs doivent faire preuve de prudence lorsqu'ils participent à des projets de Finance décentralisée, évaluer la sécurité des projets sous divers angles et ne pas se laisser aveugler par des rendements élevés. Les porteurs de projet doivent également construire des défenses de sécurité à plusieurs niveaux et continuer à surveiller et à améliorer la sécurité des projets.
Cette page peut inclure du contenu de tiers fourni à des fins d'information uniquement. Gate ne garantit ni l'exactitude ni la validité de ces contenus, n’endosse pas les opinions exprimées, et ne fournit aucun conseil financier ou professionnel à travers ces informations. Voir la section Avertissement pour plus de détails.
10 J'aime
Récompense
10
6
Partager
Commentaire
0/400
GhostInTheChain
· Il y a 6h
prendre les gens pour des idiots pendant un an, voir à travers le monde
Voir l'originalRépondre0
MiningDisasterSurvivor
· 07-29 19:14
Une autre vague de pigeons va être prise pour des idiots.
Voir l'originalRépondre0
BearMarketBard
· 07-29 19:12
Forum d'expérience de rug pull copié
Voir l'originalRépondre0
TestnetFreeloader
· 07-29 19:08
Portefeuille de frappe nucléaire, c'est très rapide.
Voir l'originalRépondre0
BearMarketGardener
· 07-29 18:58
Encore une fois, un discours habituel, il faut que ça craque !
Voir l'originalRépondre0
WinterWarmthCat
· 07-29 18:45
Les gens sont naïfs et ont beaucoup d'argent, dépêchez-vous.
Analyse complète des vulnérabilités de sécurité DeFi : Guide de prévention des Prêts Flash, manipulation des prix et attaques par réentrance
Finance décentralisée常见安全漏洞及预防措施
Récemment, un expert en sécurité a partagé une leçon de sécurité DeFi avec les membres de la communauté. L'expert a passé en revue les événements de sécurité majeurs auxquels l'industrie Web3 a été confrontée au cours de l'année écoulée, a exploré les raisons de ces événements et les méthodes d'évitement, a résumé les vulnérabilités de sécurité courantes des contrats intelligents et les mesures préventives, et a également donné quelques conseils de sécurité aux développeurs de projets et aux utilisateurs ordinaires.
Les types courants de vulnérabilités DeFi incluent les prêts flash, la manipulation des prix, les problèmes de droits d'accès des fonctions, les appels externes arbitraires, les problèmes de fonction fallback, les failles de logique commerciale, les fuites de clés privées, et les attaques par réentrance, entre autres. Nous allons nous concentrer ici sur les prêts flash, la manipulation des prix et les attaques par réentrance.
Prêt éclair
Les prêts flash sont une innovation dans la Finance décentralisée, mais lorsqu'ils sont exploités par des hackers, ils peuvent emprunter de l'argent sans coût pour réaliser des arbitrages. De nombreux projets DeFi semblent offrir des rendements élevés, mais le niveau des équipes varie, et même si le code n'a pas de vulnérabilités, des problèmes logiques peuvent encore exister. Par exemple, certains projets distribuent des récompenses à des moments fixes en fonction du nombre de jetons détenus par les détenteurs, mais les attaquants peuvent utiliser des prêts flash pour acheter une grande quantité de jetons et obtenir la majorité des récompenses au moment de la distribution. D'autres projets qui calculent les prix via des tokens peuvent également être influencés par des prêts flash. Les équipes de projet devraient être vigilantes face à ces problèmes.
Manipulation des prix
Les problèmes de manipulation des prix sont étroitement liés aux prêts flash, principalement en raison du fait que certains paramètres peuvent être contrôlés par les utilisateurs lors du calcul des prix. Il existe deux types de problèmes courants :
Lors du calcul des prix, des données tierces sont utilisées, mais une mauvaise utilisation ou un manque de vérification ont entraîné une manipulation malveillante des prix.
Utiliser le nombre de tokens d'adresses spécifiques comme variable de calcul, tandis que le solde de tokens de ces adresses peut être temporairement augmenté ou diminué.
Attaque par réentrance
L'un des principaux dangers d'appeler des contrats externes est qu'ils peuvent prendre le contrôle du flux, entraînant des modifications inattendues des données lors de l'appel de fonctions. Il existe de nombreuses façons de réentrer pour différents contrats, pouvant combiner différentes fonctions ou les fonctions de plusieurs contrats pour effectuer une attaque. Pour résoudre le problème de la réentrance, il faut faire attention :
Ne pas seulement prévenir le problème de réentrance d'une seule fonction.
Suivre le modèle Checks-Effects-Interactions
Utiliser un modificateur de protection contre la réentrance éprouvé par le temps
Ce que je crains le plus, c'est de réinventer la roue. Dans ce domaine, il existe de nombreuses meilleures pratiques de sécurité qui peuvent être directement utilisées, il n'est donc pas du tout nécessaire de réinventer la roue. Créer sa propre roue sans validation adéquate augmente clairement la probabilité de problèmes par rapport à l'utilisation de solutions matures et éprouvées.
Conseils de sécurité pour les projets
Le développement de contrats suit les meilleures pratiques de sécurité
Les contrats peuvent être mis à niveau et suspendus
Utiliser un verrouillage temporel
Accroître les investissements en matière de sécurité et établir un système de sécurité complet
Améliorer la sensibilisation à la sécurité de tous les employés
Prévenir les malversations internes tout en améliorant l'efficacité et en renforçant le contrôle des risques.
Introduire prudemment des tiers, vérifier en amont et en aval
Comment les utilisateurs/LP peuvent-ils évaluer la sécurité d'un contrat intelligent
Le contrat est-il open source ?
Le propriétaire utilise-t-il la multi-signature, la multi-signature est-elle décentralisée ?
Situations de transaction existantes du contrat
Le contrat est-il un contrat d'agence, est-il évolutif, y a-t-il un verrouillage temporel ?
Le contrat a-t-il été audité par plusieurs institutions, les droits du propriétaire sont-ils trop étendus ?
Faites attention au choix et à l'utilisation des oracles.
En résumé, les utilisateurs doivent faire preuve de prudence lorsqu'ils participent à des projets de Finance décentralisée, évaluer la sécurité des projets sous divers angles et ne pas se laisser aveugler par des rendements élevés. Les porteurs de projet doivent également construire des défenses de sécurité à plusieurs niveaux et continuer à surveiller et à améliorer la sécurité des projets.