Analyse complète des vulnérabilités de la Finance décentralisée : Guide de prévention contre les Prêts Flash, la manipulation des prix et les attaques par réentrées.
Vulnérabilités de sécurité courantes dans la Finance décentralisée et mesures préventives
Récemment, un expert en sécurité a partagé des sujets liés à la sécurité DeFi avec les membres de la communauté. Cet expert a examiné les événements de sécurité majeurs rencontrés par l'industrie Web3 au cours de l'année passée, a approfondi les raisons de ces événements et comment les éviter, a résumé les vulnérabilités de sécurité courantes des contrats intelligents et les mesures préventives, et a donné quelques conseils de sécurité aux développeurs de projets et aux utilisateurs ordinaires.
Les types de vulnérabilités DeFi courants comprennent principalement les prêts flash, la manipulation des prix, les problèmes de droits d'accès aux fonctions, les appels externes arbitraires, les problèmes de fonction fallback, les vulnérabilités de logique commerciale, les fuites de clés privées et les attaques par réentrance, etc. Cet article se concentre sur les prêts flash, la manipulation des prix et les attaques par réentrance.
Prêt flash
Le prêt éclair est une innovation de la Finance décentralisée, mais il est souvent exploité par des hackers. Les attaquants peuvent emprunter de grandes sommes d'argent via des prêts éclair pour manipuler les prix ou attaquer la logique commerciale. Les développeurs doivent considérer si les fonctionnalités des contrats peuvent causer des anomalies en raison de fonds massifs ou être exploitées dans une seule transaction pour interagir avec plusieurs fonctions afin d'obtenir des gains indus.
De nombreux projets de Finance décentralisée semblent offrir des rendements élevés, mais les compétences des équipes peuvent varier considérablement. Même si le code lui-même ne comporte pas de vulnérabilités, des problèmes logiques peuvent toujours exister. Par exemple, certains projets distribuent des récompenses à des moments fixes en fonction des quantités détenues, mais peuvent être exploités par des attaquants utilisant des prêts éclair pour acheter une grande quantité de jetons, obtenant ainsi la majorité des rendements lors de la distribution des récompenses. D'autres projets, qui calculent les prix à l'aide de jetons, peuvent également être facilement affectés par des prêts éclair. Les équipes de projet doivent rester vigilantes face à ces problèmes.
Manipulation des prix
Les problèmes de manipulation des prix sont étroitement liés aux prêts éclair, 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 situations courantes :
Lors du calcul des prix, des données tierces sont utilisées, mais si la méthode d'utilisation est incorrecte ou qu'il y a un manque de vérification, cela peut entraîner une manipulation malveillante des prix.
Utiliser le solde des tokens de certaines adresses comme variable de calcul, alors que le nombre de tokens de ces adresses peut être temporairement augmenté ou diminué.
Attaque par réentrance
L'un des principaux risques d'appeler des contrats externes est qu'ils peuvent prendre le contrôle du flux et apporter des modifications inattendues aux données. Par exemple :
fonction retirerSolde() public {
uint montantÀRetirer = userBalances[msg.sender];
(bool succès, ) = msg.sender.call.value(montantÀRetirer)("");
require(succès);
userBalances[msg.sender] = 0;
}
Étant donné que le solde de l'utilisateur n'est réglé à 0 qu'à la fin de la fonction, les deuxième et suivantes appels réussiront toujours, permettant de retirer le solde de manière répétée.
Les attaques par réinjection se présentent sous diverses formes, pouvant impliquer différentes fonctions du même contrat ou des fonctions de plusieurs contrats. Lors de la résolution des problèmes de réinjection, il est important de prêter attention à :
Non seulement prévenir les problèmes de réentrance d'une seule fonction
Suivre le modèle Checks-Effects-Interactions pour le codage
Utiliser un modificateur anti-réentrance vérifié
Il vaut mieux éviter de réinventer la roue et utiliser les meilleures pratiques de sécurité éprouvées dans l'industrie. Les "roues" nouvellement créées manquent souvent de validation adéquate, et la probabilité de problèmes est souvent plus élevée que celle des solutions éprouvées.
Conseils de sécurité
conseils de sécurité pour le projet
Suivre les meilleures pratiques de sécurité lors du développement de contrats.
Concevoir des contrats évolutifs et suspendables : aide à détecter rapidement et à réduire les pertes dues aux attaques.
Utiliser un verrouillage temporel : fournir une période de grâce pour identifier et répondre aux problèmes potentiels.
Augmenter les investissements en sécurité, établir un système de sécurité complet : la sécurité est un travail systémique, qui ne se limite pas à l'audit des contrats.
Sensibiliser tous les employés à la sécurité : de nombreuses attaques exploitent les faiblesses humaines, rester vigilant peut éviter de nombreux problèmes.
Prévenir les comportements malveillants internes tout en renforçant le contrôle des risques lors de l'amélioration de l'efficacité : par exemple, en utilisant des mécanismes tels que la signature multiple et le verrouillage temporel.
Introduire des tiers avec prudence : effectuer des vérifications de sécurité pour l'ensemble de la chaîne, en particulier pour les contrats non open source.
Méthodes pour les utilisateurs/LP pour évaluer la sécurité des contrats intelligents
Vérifiez si le contrat est open source : ne participez pas aux projets qui ne le sont pas.
Confirmez si le propriétaire utilise un multi-signature décentralisé.
Vérifiez les transactions existantes du contrat : date de déploiement, nombre d'interactions, etc.
Vérifiez si le contrat est un contrat d'agent, s'il est évolutif et s'il y a un verrouillage temporel.
Vérifiez si le contrat a été audité par plusieurs institutions, si les droits du propriétaire sont trop étendus.
Faites attention à la fiabilité des oracles : les oracles leaders sont relativement sûrs, tandis que les oracles construits en interne ou à faible barrière d'entrée doivent être utilisés avec prudence.
En somme, dans le domaine de la Finance décentralisée, les participants doivent rester vigilants, les porteurs de projet doivent considérer les problèmes de sécurité sous tous les angles, et les utilisateurs doivent évaluer prudemment la sécurité du projet avant de prendre une décision.
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.
12 J'aime
Récompense
12
5
Partager
Commentaire
0/400
HackerWhoCares
· Il y a 13h
L'argent est emprunté, la sécurité ne peut pas être empruntée.
Voir l'originalRépondre0
SurvivorshipBias
· Il y a 20h
Encore une fois l'histoire sanglante des pigeons qui se font prendre pour des idiots.
Voir l'originalRépondre0
MetaMaskVictim
· Il y a 20h
Encore quelqu'un qui se fait prendre pour des cons... Qui a perdu, dites-moi.
Analyse complète des vulnérabilités de la Finance décentralisée : Guide de prévention contre les Prêts Flash, la manipulation des prix et les attaques par réentrées.
Vulnérabilités de sécurité courantes dans la Finance décentralisée et mesures préventives
Récemment, un expert en sécurité a partagé des sujets liés à la sécurité DeFi avec les membres de la communauté. Cet expert a examiné les événements de sécurité majeurs rencontrés par l'industrie Web3 au cours de l'année passée, a approfondi les raisons de ces événements et comment les éviter, a résumé les vulnérabilités de sécurité courantes des contrats intelligents et les mesures préventives, et a donné quelques conseils de sécurité aux développeurs de projets et aux utilisateurs ordinaires.
Les types de vulnérabilités DeFi courants comprennent principalement les prêts flash, la manipulation des prix, les problèmes de droits d'accès aux fonctions, les appels externes arbitraires, les problèmes de fonction fallback, les vulnérabilités de logique commerciale, les fuites de clés privées et les attaques par réentrance, etc. Cet article se concentre sur les prêts flash, la manipulation des prix et les attaques par réentrance.
Prêt flash
Le prêt éclair est une innovation de la Finance décentralisée, mais il est souvent exploité par des hackers. Les attaquants peuvent emprunter de grandes sommes d'argent via des prêts éclair pour manipuler les prix ou attaquer la logique commerciale. Les développeurs doivent considérer si les fonctionnalités des contrats peuvent causer des anomalies en raison de fonds massifs ou être exploitées dans une seule transaction pour interagir avec plusieurs fonctions afin d'obtenir des gains indus.
De nombreux projets de Finance décentralisée semblent offrir des rendements élevés, mais les compétences des équipes peuvent varier considérablement. Même si le code lui-même ne comporte pas de vulnérabilités, des problèmes logiques peuvent toujours exister. Par exemple, certains projets distribuent des récompenses à des moments fixes en fonction des quantités détenues, mais peuvent être exploités par des attaquants utilisant des prêts éclair pour acheter une grande quantité de jetons, obtenant ainsi la majorité des rendements lors de la distribution des récompenses. D'autres projets, qui calculent les prix à l'aide de jetons, peuvent également être facilement affectés par des prêts éclair. Les équipes de projet doivent rester vigilantes face à ces problèmes.
Manipulation des prix
Les problèmes de manipulation des prix sont étroitement liés aux prêts éclair, 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 situations courantes :
Lors du calcul des prix, des données tierces sont utilisées, mais si la méthode d'utilisation est incorrecte ou qu'il y a un manque de vérification, cela peut entraîner une manipulation malveillante des prix.
Utiliser le solde des tokens de certaines adresses comme variable de calcul, alors que le nombre de tokens de ces adresses peut être temporairement augmenté ou diminué.
Attaque par réentrance
L'un des principaux risques d'appeler des contrats externes est qu'ils peuvent prendre le contrôle du flux et apporter des modifications inattendues aux données. Par exemple :
solidité mapping (address => uint) private userBalances;
fonction retirerSolde() public { uint montantÀRetirer = userBalances[msg.sender]; (bool succès, ) = msg.sender.call.value(montantÀRetirer)(""); require(succès); userBalances[msg.sender] = 0; }
Étant donné que le solde de l'utilisateur n'est réglé à 0 qu'à la fin de la fonction, les deuxième et suivantes appels réussiront toujours, permettant de retirer le solde de manière répétée.
Les attaques par réinjection se présentent sous diverses formes, pouvant impliquer différentes fonctions du même contrat ou des fonctions de plusieurs contrats. Lors de la résolution des problèmes de réinjection, il est important de prêter attention à :
Il vaut mieux éviter de réinventer la roue et utiliser les meilleures pratiques de sécurité éprouvées dans l'industrie. Les "roues" nouvellement créées manquent souvent de validation adéquate, et la probabilité de problèmes est souvent plus élevée que celle des solutions éprouvées.
Conseils de sécurité
conseils de sécurité pour le projet
Suivre les meilleures pratiques de sécurité lors du développement de contrats.
Concevoir des contrats évolutifs et suspendables : aide à détecter rapidement et à réduire les pertes dues aux attaques.
Utiliser un verrouillage temporel : fournir une période de grâce pour identifier et répondre aux problèmes potentiels.
Augmenter les investissements en sécurité, établir un système de sécurité complet : la sécurité est un travail systémique, qui ne se limite pas à l'audit des contrats.
Sensibiliser tous les employés à la sécurité : de nombreuses attaques exploitent les faiblesses humaines, rester vigilant peut éviter de nombreux problèmes.
Prévenir les comportements malveillants internes tout en renforçant le contrôle des risques lors de l'amélioration de l'efficacité : par exemple, en utilisant des mécanismes tels que la signature multiple et le verrouillage temporel.
Introduire des tiers avec prudence : effectuer des vérifications de sécurité pour l'ensemble de la chaîne, en particulier pour les contrats non open source.
Méthodes pour les utilisateurs/LP pour évaluer la sécurité des contrats intelligents
Vérifiez si le contrat est open source : ne participez pas aux projets qui ne le sont pas.
Confirmez si le propriétaire utilise un multi-signature décentralisé.
Vérifiez les transactions existantes du contrat : date de déploiement, nombre d'interactions, etc.
Vérifiez si le contrat est un contrat d'agent, s'il est évolutif et s'il y a un verrouillage temporel.
Vérifiez si le contrat a été audité par plusieurs institutions, si les droits du propriétaire sont trop étendus.
Faites attention à la fiabilité des oracles : les oracles leaders sont relativement sûrs, tandis que les oracles construits en interne ou à faible barrière d'entrée doivent être utilisés avec prudence.
En somme, dans le domaine de la Finance décentralisée, les participants doivent rester vigilants, les porteurs de projet doivent considérer les problèmes de sécurité sous tous les angles, et les utilisateurs doivent évaluer prudemment la sécurité du projet avant de prendre une décision.