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 incidents de sécurité et comment les éviter, a résumé les vulnérabilités de sécurité courantes des contrats intelligents et les mesures de prévention, et a également donné quelques conseils de sécurité aux équipes de projet et aux utilisateurs ordinaires.
Les types de vulnérabilités DeFi courants incluent généralement les prêts flash, la manipulation des prix, les problèmes de permission des fonctions, les appels externes arbitraires, les problèmes de fonction fallback, les vulnérabilités logiques des affaires, les fuites de clés privées, les réentrées, etc. Nous allons nous concentrer sur les prêts flash, la manipulation des prix et les attaques par réentrée.
Prêt éclair
Le prêt éclair est lui-même une innovation de la Finance décentralisée, mais lorsqu'il est exploité par des hackers, ils peuvent emprunter d'énormes sommes d'argent sans aucun coût, exécuter l'ensemble du processus d'arbitrage, puis rembourser, ne payant qu'une petite taxe de Gas pour réaliser des bénéfices colossaux.
Au cours des deux dernières années, de nombreux problèmes sont apparus avec les prêts flash. Certains projets de Finance décentralisée semblent offrir des rendements élevés, mais en réalité, le niveau des équipes derrière ces projets est inégal. Dans certains cas, le code du projet peut avoir été acheté, même si le code lui-même n'a pas de vulnérabilités, il peut toujours y avoir des problèmes logiques. Par exemple, il y a eu un projet qui distribuait des récompenses à des moments fixes en fonction du nombre de tokens détenus par les détenteurs, mais un attaquant a profité des prêts flash pour acheter une grande quantité de tokens, et lors de la distribution des récompenses, la majorité de celles-ci a été siphonnée par l'attaquant. De plus, certains projets qui calculent les prix via des tokens peuvent également être influencés par des prêts flash. Les équipes de projets 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. Ce problème est principalement dû au fait que certains paramètres lors du calcul des prix peuvent être contrôlés par les utilisateurs. Les types de problèmes qui se posent fréquemment sont de deux sortes :
Lors du calcul des prix, des données de tiers sont utilisées, mais une mauvaise utilisation ou un manque de vérification entraînent une manipulation malveillante des prix.
Utilisé le nombre de tokens de certaines adresses comme variable de calcul, alors 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 et apporter des modifications inattendues aux données en appelant des fonctions.
En raison du fait que le solde de l'utilisateur n'est réglé à 0 qu'à la fin de la fonction, le deuxième appel ( et les appels suivants ) réussiront toujours et le solde sera retiré encore et encore.
Pour différents contrats, il existe de nombreuses façons de réentrer, ce qui peut être réalisé en combinant les différentes fonctions d'un contrat ou les fonctions de plusieurs contrats différents pour mener une attaque par réentrées. Par conséquent, lorsque nous résolvons le problème de réentrées, nous devons prêter attention aux points suivants :
Pas seulement pour prévenir le problème de réentrance d'une seule fonction;
Suivre le modèle Checks-Effects-Interactions lors de la programmation;
Utilisez un modificateur de protection contre les réentrées éprouvé dans le temps.
En fait, ce que l'on craint le plus, c'est de réinventer la roue, de tout écrire soi-même. Dans ce domaine, il existe de nombreuses meilleures pratiques de sécurité que nous pouvons utiliser, il n'est donc pas nécessaire de réinventer la roue. Lorsque vous créez une roue, elle n'a pas été suffisamment vérifiée, et à ce moment-là, la probabilité de rencontrer des problèmes est clairement beaucoup plus élevée que celle d'utiliser une solution très mature et éprouvée.
Conseils de sécurité
Conseils de sécurité pour les projets
Le développement de contrats suit les meilleures pratiques de sécurité.
Contrats pouvant être mis à jour et suspendus : de nombreuses attaques ne consistent pas à transférer toutes les pièces d'un coup, mais à exécuter plusieurs transactions. S'il existe un mécanisme de surveillance relativement solide, cela peut être détecté. Une fois identifié, si le contrat peut être suspendu, cela peut permettre de réduire efficacement les pertes.
Utiliser un verrouillage temporel : s'il y a un verrouillage temporel, supposons qu'il faille 48 heures pour le compléter, à ce moment-là, de nombreuses personnes peuvent découvrir que le créateur a mis à jour une méthode de mint, et que tout le monde peut l'utiliser. Les personnes qui surveillent sauront que le projet a probablement été piraté et pourront informer l'équipe du projet de changer. Même si, supposons, ils sont informés et que personne ne s'en soucie, au moins ils peuvent d'abord retirer leur part d'argent, garantissant ainsi que leurs bénéfices ne soient pas affectés. Ainsi, on peut dire qu'un projet sans verrouillage temporel augmente théoriquement la probabilité de problèmes.
Augmenter les investissements en sécurité, établir un système de sécurité complet : la sécurité n'est pas un point, ni une ligne, la sécurité est un système. Ne pensez pas qu'en tant que projet, le fait que le contrat ait été audité par plusieurs entreprises signifie qu'il n'y a pas de problème. Il est nécessaire de procéder à une modélisation des risques autant que possible, puis d'éliminer progressivement la plupart des risques, les risques restants étant également des risques acceptables, dans la limite du tolérable. La sécurité et l'efficacité ne peuvent pas être garanties en même temps, il faut faire des compromis. Mais si l'on ne tient absolument pas compte de la sécurité et qu'on n'y investit pas, il est normal d'être attaqué.
Élever la sensibilisation à la sécurité de tous les employés : Élever la sensibilisation à la sécurité ne nécessite pas beaucoup de technique. Dans ce grand environnement, il suffit de poser un peu plus de questions sur le pourquoi et de réfléchir un peu plus pour éviter de nombreux problèmes.
Prévenir les actes répréhensibles internes, tout en améliorant l'efficacité et en renforçant la gestion des risques.
Sécurité des tiers : En tant qu'élément de l'écosystème, les projets ont leurs propres flux en amont et en aval. En matière de sécurité, il existe un principe selon lequel "par défaut, les flux en amont et en aval sont considérés comme non sécurisés". Que ce soit pour l'amont ou l'aval, des vérifications doivent être effectuées. Pour les tiers, il est très difficile de contrôler, l'exposition au risque de sécurité est en fait particulièrement grande, donc il faut faire très attention à l'introduction des tiers. Les contrats sont open source, il est possible de les intégrer et de les appeler ; si le contrat n'est pas open source, il ne doit absolument pas être référencé.
Comment les utilisateurs/LP peuvent-ils évaluer la sécurité d'un contrat intelligent ?
Pour les utilisateurs ordinaires, nous jugeons si un projet est sûr en nous basant principalement sur les six points suivants :
Le contrat est-il open source : Nous ne touchons absolument pas aux projets dont le contrat n'est pas open source, car nous ne savons pas ce qui est écrit dans le contrat.
Propriétaire : utilise-t-il une signature multiple, et cette signature multiple est-elle décentralisée ? Si nous n'utilisons pas de signature multiple, nous ne pouvons pas juger de la logique et du contenu des affaires du projet. En cas d'événement de sécurité, il sera impossible de déterminer s'il s'agit d'un acte de piratage. Même en utilisant une signature multiple, il est nécessaire de vérifier si cette signature multiple est décentralisée.
Situation des transactions existantes du contrat : surtout qu'il existe de nombreux projets de phishing sur le marché, il se peut qu'un contrat similaire soit créé. Dans ce cas, nous devons examiner le temps de déploiement du contrat, le nombre d'interactions, etc. Tous ces éléments sont des critères de mesure pour évaluer si le contrat est sécurisé.
Le contrat est-il un contrat d'agence, est-il évolutif, y a-t-il un verrouillage temporel : si le contrat ne peut pas du tout être mis à niveau, il sera trop rigide, il est préférable que le contrat du projet soit évolutif. Cependant, la mise à niveau doit être faite de manière appropriée, lorsque des contenus de mise à niveau ou des modifications de paramètres importants sont impliqués, il doit y avoir un verrouillage temporel, afin de donner à tout le monde une fenêtre de temps pour juger si la mise à niveau réelle est nuisible ou bénéfique pour les utilisateurs, c'est aussi une manière de transparence.
Le contrat a-t-il été audité par plusieurs organismes ( ne faites pas aveuglément confiance aux sociétés d'audit ), Les droits du propriétaire sont-ils trop étendus : tout d'abord, ne faites pas confiance à une seule société d'audit, car différentes sociétés d'audit et différents auditeurs ont des perspectives différentes sur les problèmes. Ensuite, il faut vérifier si les droits du propriétaire sont trop étendus. Les droits d'un propriétaire dans un projet normal doivent être contrôlables, afin qu'il n'y ait pas trop d'opérations à haut risque, et les opérations doivent également être effectuées par le biais de verrous de temps, permettant aux utilisateurs de savoir quelles opérations sont en cours.
Attention aux oracles : si le projet utilise un oracle de premier plan sur le marché, il ne devrait pas y avoir de gros problèmes, mais s'il utilise un oracle construit en interne, ou un oracle où l'on peut alimenter les prix en utilisant simplement des tokens en garantie, il faut faire attention. Lorsque des problèmes potentiels avec l'oracle sont découverts, ou s'il y a une possibilité de manipulation, même si les rendements du projet sont élevés, il ne faut pas participer.
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.
16 J'aime
Récompense
16
4
Partager
Commentaire
0/400
MetaverseHobo
· Il y a 13h
Vous devez être prudent faites vos propres recherches (DYOR)
Voir l'originalRépondre0
GameFiCritic
· Il y a 19h
Il ne fait aucun doute que c'est un poste sûr.
Voir l'originalRépondre0
WalletDetective
· Il y a 19h
Prévenir d'abord pour ne pas perdre.
Voir l'originalRépondre0
ruggedNotShrugged
· Il y a 20h
La sécurité des contrats est toujours la priorité.
Cours de sécurité DeFi : Analyse des vulnérabilités courantes et mesures préventives
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 incidents de sécurité et comment les éviter, a résumé les vulnérabilités de sécurité courantes des contrats intelligents et les mesures de prévention, et a également donné quelques conseils de sécurité aux équipes de projet et aux utilisateurs ordinaires.
Les types de vulnérabilités DeFi courants incluent généralement les prêts flash, la manipulation des prix, les problèmes de permission des fonctions, les appels externes arbitraires, les problèmes de fonction fallback, les vulnérabilités logiques des affaires, les fuites de clés privées, les réentrées, etc. Nous allons nous concentrer sur les prêts flash, la manipulation des prix et les attaques par réentrée.
Prêt éclair
Le prêt éclair est lui-même une innovation de la Finance décentralisée, mais lorsqu'il est exploité par des hackers, ils peuvent emprunter d'énormes sommes d'argent sans aucun coût, exécuter l'ensemble du processus d'arbitrage, puis rembourser, ne payant qu'une petite taxe de Gas pour réaliser des bénéfices colossaux.
Au cours des deux dernières années, de nombreux problèmes sont apparus avec les prêts flash. Certains projets de Finance décentralisée semblent offrir des rendements élevés, mais en réalité, le niveau des équipes derrière ces projets est inégal. Dans certains cas, le code du projet peut avoir été acheté, même si le code lui-même n'a pas de vulnérabilités, il peut toujours y avoir des problèmes logiques. Par exemple, il y a eu un projet qui distribuait des récompenses à des moments fixes en fonction du nombre de tokens détenus par les détenteurs, mais un attaquant a profité des prêts flash pour acheter une grande quantité de tokens, et lors de la distribution des récompenses, la majorité de celles-ci a été siphonnée par l'attaquant. De plus, certains projets qui calculent les prix via des tokens peuvent également être influencés par des prêts flash. Les équipes de projets 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. Ce problème est principalement dû au fait que certains paramètres lors du calcul des prix peuvent être contrôlés par les utilisateurs. Les types de problèmes qui se posent fréquemment sont de deux sortes :
Lors du calcul des prix, des données de tiers sont utilisées, mais une mauvaise utilisation ou un manque de vérification entraînent une manipulation malveillante des prix.
Utilisé le nombre de tokens de certaines adresses comme variable de calcul, alors 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 et apporter des modifications inattendues aux données en appelant des fonctions.
En raison du fait que le solde de l'utilisateur n'est réglé à 0 qu'à la fin de la fonction, le deuxième appel ( et les appels suivants ) réussiront toujours et le solde sera retiré encore et encore.
Pour différents contrats, il existe de nombreuses façons de réentrer, ce qui peut être réalisé en combinant les différentes fonctions d'un contrat ou les fonctions de plusieurs contrats différents pour mener une attaque par réentrées. Par conséquent, lorsque nous résolvons le problème de réentrées, nous devons prêter attention aux points suivants :
Pas seulement pour prévenir le problème de réentrance d'une seule fonction;
Suivre le modèle Checks-Effects-Interactions lors de la programmation;
Utilisez un modificateur de protection contre les réentrées éprouvé dans le temps.
En fait, ce que l'on craint le plus, c'est de réinventer la roue, de tout écrire soi-même. Dans ce domaine, il existe de nombreuses meilleures pratiques de sécurité que nous pouvons utiliser, il n'est donc pas nécessaire de réinventer la roue. Lorsque vous créez une roue, elle n'a pas été suffisamment vérifiée, et à ce moment-là, la probabilité de rencontrer des problèmes est clairement beaucoup plus élevée que celle d'utiliser une solution très mature et éprouvée.
Conseils de sécurité
Conseils de sécurité pour les projets
Le développement de contrats suit les meilleures pratiques de sécurité.
Contrats pouvant être mis à jour et suspendus : de nombreuses attaques ne consistent pas à transférer toutes les pièces d'un coup, mais à exécuter plusieurs transactions. S'il existe un mécanisme de surveillance relativement solide, cela peut être détecté. Une fois identifié, si le contrat peut être suspendu, cela peut permettre de réduire efficacement les pertes.
Utiliser un verrouillage temporel : s'il y a un verrouillage temporel, supposons qu'il faille 48 heures pour le compléter, à ce moment-là, de nombreuses personnes peuvent découvrir que le créateur a mis à jour une méthode de mint, et que tout le monde peut l'utiliser. Les personnes qui surveillent sauront que le projet a probablement été piraté et pourront informer l'équipe du projet de changer. Même si, supposons, ils sont informés et que personne ne s'en soucie, au moins ils peuvent d'abord retirer leur part d'argent, garantissant ainsi que leurs bénéfices ne soient pas affectés. Ainsi, on peut dire qu'un projet sans verrouillage temporel augmente théoriquement la probabilité de problèmes.
Augmenter les investissements en sécurité, établir un système de sécurité complet : la sécurité n'est pas un point, ni une ligne, la sécurité est un système. Ne pensez pas qu'en tant que projet, le fait que le contrat ait été audité par plusieurs entreprises signifie qu'il n'y a pas de problème. Il est nécessaire de procéder à une modélisation des risques autant que possible, puis d'éliminer progressivement la plupart des risques, les risques restants étant également des risques acceptables, dans la limite du tolérable. La sécurité et l'efficacité ne peuvent pas être garanties en même temps, il faut faire des compromis. Mais si l'on ne tient absolument pas compte de la sécurité et qu'on n'y investit pas, il est normal d'être attaqué.
Élever la sensibilisation à la sécurité de tous les employés : Élever la sensibilisation à la sécurité ne nécessite pas beaucoup de technique. Dans ce grand environnement, il suffit de poser un peu plus de questions sur le pourquoi et de réfléchir un peu plus pour éviter de nombreux problèmes.
Prévenir les actes répréhensibles internes, tout en améliorant l'efficacité et en renforçant la gestion des risques.
Sécurité des tiers : En tant qu'élément de l'écosystème, les projets ont leurs propres flux en amont et en aval. En matière de sécurité, il existe un principe selon lequel "par défaut, les flux en amont et en aval sont considérés comme non sécurisés". Que ce soit pour l'amont ou l'aval, des vérifications doivent être effectuées. Pour les tiers, il est très difficile de contrôler, l'exposition au risque de sécurité est en fait particulièrement grande, donc il faut faire très attention à l'introduction des tiers. Les contrats sont open source, il est possible de les intégrer et de les appeler ; si le contrat n'est pas open source, il ne doit absolument pas être référencé.
Comment les utilisateurs/LP peuvent-ils évaluer la sécurité d'un contrat intelligent ?
Pour les utilisateurs ordinaires, nous jugeons si un projet est sûr en nous basant principalement sur les six points suivants :
Le contrat est-il open source : Nous ne touchons absolument pas aux projets dont le contrat n'est pas open source, car nous ne savons pas ce qui est écrit dans le contrat.
Propriétaire : utilise-t-il une signature multiple, et cette signature multiple est-elle décentralisée ? Si nous n'utilisons pas de signature multiple, nous ne pouvons pas juger de la logique et du contenu des affaires du projet. En cas d'événement de sécurité, il sera impossible de déterminer s'il s'agit d'un acte de piratage. Même en utilisant une signature multiple, il est nécessaire de vérifier si cette signature multiple est décentralisée.
Situation des transactions existantes du contrat : surtout qu'il existe de nombreux projets de phishing sur le marché, il se peut qu'un contrat similaire soit créé. Dans ce cas, nous devons examiner le temps de déploiement du contrat, le nombre d'interactions, etc. Tous ces éléments sont des critères de mesure pour évaluer si le contrat est sécurisé.
Le contrat est-il un contrat d'agence, est-il évolutif, y a-t-il un verrouillage temporel : si le contrat ne peut pas du tout être mis à niveau, il sera trop rigide, il est préférable que le contrat du projet soit évolutif. Cependant, la mise à niveau doit être faite de manière appropriée, lorsque des contenus de mise à niveau ou des modifications de paramètres importants sont impliqués, il doit y avoir un verrouillage temporel, afin de donner à tout le monde une fenêtre de temps pour juger si la mise à niveau réelle est nuisible ou bénéfique pour les utilisateurs, c'est aussi une manière de transparence.
Le contrat a-t-il été audité par plusieurs organismes ( ne faites pas aveuglément confiance aux sociétés d'audit ), Les droits du propriétaire sont-ils trop étendus : tout d'abord, ne faites pas confiance à une seule société d'audit, car différentes sociétés d'audit et différents auditeurs ont des perspectives différentes sur les problèmes. Ensuite, il faut vérifier si les droits du propriétaire sont trop étendus. Les droits d'un propriétaire dans un projet normal doivent être contrôlables, afin qu'il n'y ait pas trop d'opérations à haut risque, et les opérations doivent également être effectuées par le biais de verrous de temps, permettant aux utilisateurs de savoir quelles opérations sont en cours.
Attention aux oracles : si le projet utilise un oracle de premier plan sur le marché, il ne devrait pas y avoir de gros problèmes, mais s'il utilise un oracle construit en interne, ou un oracle où l'on peut alimenter les prix en utilisant simplement des tokens en garantie, il faut faire attention. Lorsque des problèmes potentiels avec l'oracle sont découverts, ou s'il y a une possibilité de manipulation, même si les rendements du projet sont élevés, il ne faut pas participer.