Apprenez à empêcher les attaques de déni de service (DOS) dans les contrats intelligents en garantissant que les files d'attente sont sécurisées, en gérant des jetons à faible décimale et en gérant en toute sécurité les appels externes.
Bienvenue à la série Solodit Check List Resolution . Nous continuerons d'explorer les listes de contrôle de l'audit des contrats intelligents Solodit, en nous concentrant sur des stratégies pratiques pour rédiger des contrats intelligents sécurisés et résilients.
Cette liste de contrôle vous aide à identifier les vulnérabilités potentielles et à mettre en œuvre des mesures de sécurité proactives. Dans la section précédente " Résolution de liste de contrôle Solodit (1) ", nous avons examiné trois listes de contrôle ( modèle d'extraction, montant minimum de transaction et liste noire ) liées à une attaque de déni de service (DOS) et à fournir des solutions pour les développeurs. Si vous ne l'avez pas encore lu, je vous recommande de consulter l'article avant de continuer.
Dans cet article, nous discuterons de trois autres éléments de la liste de contrôle, en nous concentrant à nouveau sur les attaques DOS. Nous plongerons dans les vulnérabilités de manipulation de la file d'attente , les défis posés par des jetons décimaux faibles et l'importance de gérer en toute sécurité les appels de contrat externes .
Pour la meilleure expérience, ouvrez une balise de liste de contrôle Solodit pour référence.
Voici ce que nous discuterons aujourd'hui:
SOL-AM-DOSA-4: Bloquer la manipulation de la file d'attente : Ce problème se produit lorsqu'un attaquant manipule la file d'attente pour faire une pause ou interrompre ses opérations, résultant en DOS. Nous examinerons comment les attaquants peuvent détruire les files d'attente de traitement.
SOL-AM-DOSA-5: jetons décimaux faibles : problèmes qui se produisent lorsqu'ils traitent avec des jetons à faible décimale. Le calcul, en particulier la division, peut être tronqué à zéro, entraînant un comportement inattendu et nocif. Ces jetons à faible précision peuvent causer des problèmes de division entière, interférant ainsi avec les fonctions clés.
SOL-AM-DOSA-6: appels externes dangereux : nous explorerons comment s'appuyer sur des contrats externes sans une gestion des erreurs appropriée pour créer des vulnérabilités. Lorsque la défaillance d'un appel externe n'est pas gérée correctement, elle peut entraîner le retour de l'ensemble du contrat.
Les attaques du monde réel prouvent les dommages potentiels que ces vulnérabilités peuvent causer. Le projet a subi d'énormes pertes en raison d'une négligence apparemment mineure.
Les listes de contrôle Solodit sont basées sur les résultats d'audit, les rapports de primes de vulnérabilité et les événements du monde réel. En étudiant ces listes de contrôle, vous pouvez apprendre des erreurs passées et améliorer la sécurité de votre code .
Regardons maintenant chaque élément de vérification un par un via l'exemple de code. Ces exemples ont été simplifiés pour mettre en évidence les vulnérabilités de base.
Problème : Si votre contrat intelligent dépend d'une file d'attente pour le traitement des tâches, un attaquant peut manipuler un état spécifique dans la file d'attente pour éviter le traitement correct.
Question de la liste de contrôle : "Un attaquant peut-il bloquer ou empêcher le traitement des files d'attente pour provoquer une panne de service?"
Solution : Votre mécanisme de manutention de la file d'attente nécessite de puissants mécanismes de gestion des erreurs et de secours pour garantir que les problèmes peuvent continuer à être traités même s'ils se produisent.
Exemple :
Considérez un exemple d'extraction d'une file d'attente:
L'utilisateur demande l'extraction et certains indicateurs indiquent que la demande est active.
L'attaquant peut utiliser la fonction resetUserStatus après que l'extraction est en cours pour empêcher le même fonctionnement des autres utilisateurs.
// 易受攻击的函数：可以被利用function resetUserStatus() external { // 任何人在仍然处于队列中的情况下都可以重置他们的状态withdrawalRequested[msg.sender] = false; // 注意：用户没有被移出队列！ } // 处理队列中的下一次提取function processNextWithdrawal() external { require(withdrawalQueue.length > currentIndex, "没有可处理的提取"); // 获取下一次提取Withdrawal memory withdrawal = withdrawalQueue[currentIndex]; // 可被攻击者利用：此检查可能会被重置状态所攻击require(withdrawalRequested[withdrawal.user], "提取请求不再有效"); // 处理提取uint256 amount = withdrawal.amount; require(balances[withdrawal.user] >= amount, "余额不足"); // 更新余额balances[withdrawal.user] -= amount; // 重置提取请求withdrawalRequested[withdrawal.user] = false; // 发送资金(bool success, ) = payable(withdrawal.user).call{value:amount}(""); require(success, "资金发送失败"); // 移动到队列中的下一个currentIndex++; }Pour en profiter, un attaquant peut faire ce qui suit:
resetUserStatus .processNextWithdrawal va reculer, provoquant une attaque DOS continue.Remèdes :
withdrawalRequested à l'administrateur.Problème : Les jetons à faible décimale peuvent provoquer des problèmes de division entière, ce qui s'arrête à zéro .
Imaginez un contrat de streaming de jetons allouant des jetons sur une période de temps. Si des rouages tokensPerSecond à zéro en raison de la division entière avec des jetons décimaux faibles, la fonction d'allocation sera bloquée. Question de la liste de contrôle : "Est-ce que les jetons à décimaux faibles mènent à DOS?" Solution : implémentez la logique pour gérer de faibles points décimaux pour éviter l'interruption des processus de trading en raison des erreurs d'arrondi. Exemple :
Considérez un contrat TokenStream qui diffuse régulièrement un certain nombre de jetons aux utilisateurs, où:
total_tokens doit être transféré au contrattoken_per_second peut être arrondi à zéro car nous utilisons des jetons avec un point décimal de 1distributeTokens va reculer contract TokenStream { IERC20 public token; uint256 public streamDuration; uint256 public tokensPerSecond; constructor(IERC20 _token, uint256 _streamDuration, uint256 _tokensPerSecond) { token = _token; streamDuration = _streamDuration; tokensPerSecond = _tokensPerSecond; } function distributeTokens(address recipient) external { uint256 balance = token.balanceOf(address(this)); uint256 amount = tokensPerSecond * streamDuration; uint256 tokensToSend = amount > balance ? balance : amount; require(tokensToSend > 0, "没有足够的代币进行流送"); token.transfer(recipient, tokensToSend); } } contract LowDecimalToken is ERC20 { constructor() ERC20("LowDecimalToken", "LDT") { _mint(msg.sender, 100000 * (10 ** decimals())); } function decimals() public view virtual override returns (uint8) { return 1; // 模拟小数点为低的代币} } Dans ce cas, le test testDOSWithLowDecimalTokens dans TokenStreamTest sera annulé.
Remède : Assurez-vous que le contrat gère correctement les jetons décimaux, atténuant les problèmes causés par l'arrondi entiers pendant le processus de calcul en étendant les formules mathématiques .
Problème : De nombreux contrats intelligents reposent sur des contrats externes pour interagir. Le comportement inattendu des contrats externes peut faire reculer l'ensemble du système . Le fait de ne pas gérer ces erreurs externes peut entraîner des vulnérabilités DOS.
Question de la liste de contrôle : "Le protocole gère-t-il les interactions contractuelles externes en toute sécurité?"
Solution : assurer une forte gestion des erreurs pour les interactions contractuelles externes afin de protéger l'intégrité du protocole, quelles que soient les performances des contrats externes.
Exemple : Considérons un contrat qui interagit avec une source de données de prix de liaison chaîne externe. Si vous n'utilisez pas d'essai / capture pour une gestion des erreurs appropriée, tout recul provenant de sources de données externes se propagera au supérieur et provoquera le retour du contrat.
getPrice récupère les données des prix.calculateSomethingImportant la fonction importante de quelque chose qui dépend de getPrice et va également reculer. contract PriceDependentContract { AggregatorV3Interface public priceFeed; constructor(address _priceFeed) { priceFeed = AggregatorV3Interface(_priceFeed); } // 易受攻击的函数，在没有处理可能的Chainlink 回滚的情况下获取价格function getPrice() public view returns (uint256) { (, int256 price, , , ) = priceFeed.latestRoundData(); // 易受攻击的行：没有错误处理require(price > 0, "价格必须为正"); return uint256(price); } function calculateSomethingImportant() public view returns (uint256) { uint256 price = getPrice(); // ... 使用价格的一些重要计算return price * 2; }Remède : enveloppez les appels de contrat externes dans un bloc d'essai / capture pour gérer les erreurs de recul et mettre en œuvre des valeurs de retour ou de cache.
Remarque : Il y a un cas de bord où le contrat externe consomme intentionnellement le gaz , qui peut également échouer le bloc de capture! Nous en discuterons plus tard.
Nous explorons trois vérifications clés conçues pour améliorer la capacité de votre contrat intelligent à résister aux attaques DOS: les vulnérabilités de manipulation des files d'attente , les défis associés à de faibles jetons décimaux et l'importance de gérer en toute sécurité les interactions contractuelles externes .
N'oubliez pas que les exemples fournis sont destinés à illustrer les vulnérabilités de base. Il est très important de comprendre les principes de base et d'adapter ces concepts à vos cas d'utilisation spécifiques.
En mettant en œuvre ces suggestions, vous pouvez améliorer considérablement la sécurité et la résilience de vos contrats intelligents.
Restez à l'écoute pour la prochaine partie de la série Solodit Check List Resolution.
- Lien original: cyfrin.io/blog/solodit-c ...
- Denglian Community AI Assistant traduit d'excellents articles anglais pour tout le monde. S'il y a des domaines où la traduction n'est pas compréhensible, veuillez me pardonner ~
