ソロディットチェックリスト分析：サービス拒否攻撃パート2

Solodit Checklist Analysis（2）：サービス拒否攻撃パート2

キューが安全であり、小数の低いトークンを処理し、外部通話を安全に管理することにより、スマートコントラクトでのサービス拒否（DOS）攻撃を防ぐ方法を学びます。

Solodit Checklist Resolution Seriesへようこそ。安全で回復力のあるスマートコントラクトを作成するための実用的な戦略に焦点を当てた、ソロディットスマートコントラクト監査チェックリストを引き続き検討します。

このチェックリストは、潜在的な脆弱性を特定し、積極的なセキュリティ対策を実装するのに役立ちます。前のセクション「 Solodit Checklist Resolution（1） 」では、サービス拒否（DOS）攻撃に関連する3つのチェックリスト（抽出パターン、最小トランザクション量、およびブラックリスト）を調べ、開発者にソリューションを提供しました。まだ読んでいない場合は、継続する前に記事をチェックすることをお勧めします。

この記事では、チェックリスト内の他の3つの項目について説明し、DOS攻撃に再び焦点を当てます。脆弱性、小数の低いトークンによってもたらされる課題、および外部契約コールを安全に処理することの重要性を処理するキューに飛び込みます。

最高の体験をするには、参照のためにソロディットチェックリストタグを開きます。

簡単な概要

これが今日議論することです：

• sol-am-dosa-4：キューの取り扱いのブロック：この問題は、攻撃者がキューを操作して操作を一時停止または中断し、DOSになります。攻撃者が処理キューを破壊する方法を見ていきます。

• sol-am-dosa-5：小数点以下のトークン：小数点が低いトークンを扱うときに発生する問題。計算、特に分割はゼロに切り捨てられ、予期しない有害な行動をもたらすことができます。これらの低精度のトークンは、整数部門の問題を引き起こす可能性があり、したがって重要な機能を妨害する可能性があります。

• SOL-AM-DOSA-6：安全でない外部呼び出し：適切なエラー処理なしに外部契約に依存して脆弱性を作成する方法を探ります。外部呼び出しの障害が正しく処理されない場合、契約全体がロールバックされる可能性があります。

現実世界の攻撃は、これらの脆弱性が引き起こす可能性のある潜在的な損害を証明します。このプロジェクトは、一見マイナーな過失により大きな損失を被りました。

Solodit Checklistsは、監査結果、脆弱性報告書、および実際のイベントに基づいています。これらのチェックリストを調査することにより、過去の間違いから学び、コードのセキュリティを改善できます。

次に、サンプルコードを介して各チェックアイテムを1つずつ見てみましょう。これらの例は、コアの脆弱性を強調するために簡素化されています。

SOL-AM-DOSA-4：攻撃者は、キューの処理をブロックしてサービス停止を引き起こすことができますか？

問題：スマートコントラクトがタスク処理のキューに依存する場合、攻撃者は正しい処理を防ぐためにキュー内の特定の状態を操作する場合があります。

チェックリストの質問：「攻撃者は、キューの処理をブロックしてサービス停止を引き起こすことができますか？」

解決策：キューハンドリングメカニズムには、問題が発生しても処理され続けることができるように、強力なエラー処理とフォールバックメカニズムが必要です。

例：

キューを抽出する例を考えてみましょう。

1. ユーザーは抽出を要求し、一部のフラグは、リクエストがアクティブであることを示しています。

2. 攻撃者は、他のユーザーの同じ操作を防ぐために抽出後にresetUserStatus関数を使用できます。

 // 易受攻击的函数：可以被利用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++; }

これを利用するために、攻撃者は次のことを行うことができます。

1. フェッチリクエストを開始します。
2. resetUserStatus関数を呼び出します。
3. processNextWithdrawal関数がロールバックされ、連続DOS攻撃が発生します。

救済策：

• 許可を制限して、 withdrawalRequested状態を管理者に変更します。
• ゼロ値トランザクションを避けるために、必ずチェックを確認してください。
• 予期しないエラーを処理するためのフォールバック関数を実装します。

sol-am-dosa-5：小数点以下のトークンはDOSにつながりますか？

問題：小数点が低いトークンは、整数部門の問題を引き起こす可能性があり、ゼロに丸められます。

一定期間にわたってトークンを割り当てるトークンストリーミング契約を想像してください。小数点以下のトークンを備えた整数部門により、 tokensPerSecondがゼロにラウンドすると、割り当て関数がブロックされます。チェックリストの質問：「10小数点のトークンはDOSにつながりますか？」解決策：丸めエラーによる取引プロセスの中断を防ぐために、小数点の低いポイントを処理するロジックを実装します。例：

特定の数のトークンをユーザーに定期的にストリーミングするTokenStream契約を検討してください。

1. total_tokens契約に転送する必要があります
2. token_per_second 、小数点が1のトークンを使用しているため、ゼロに丸められる場合があります
3. distributeTokens関数がロールバックされます

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; // 模拟小数点为低的代币} }

この場合、 TokenStreamTestのtestDOSWithLowDecimalTokensテストがロールバックされます。

治療：契約が低い小数点のトークンを正しく処理し、数式をスケーリングすることにより計算プロセス中に整数を丸めることによって引き起こされる問題を軽減することを確認します。

Sol-Am-Dosa-6：プロトコルは外部契約の相互作用を安全に処理しますか？

問題：多くのスマート契約は、対話するために外部契約に依存しています。外部契約の予期しない動作により、システム全体がロールバックされる可能性があります。これらの外部エラーを処理できないと、DOSの脆弱性につながる可能性があります。

チェックリストの質問：「プロトコルは外部契約の相互作用を安全に処理しますか？」

解決策：外部契約のパフォーマンスに関係なく、プロトコルの整合性を保護するために、外部契約相互作用の強力なエラー処理を確保します。

例：外部チェーンリンク価格データソースと対話する契約を検討してください。適切なエラー処理のためにTry/Catchを使用しない場合、外部データソースからのロールバックは上司に伝播し、契約をロールバックします。

1. getPrice関数は価格データを取得します。
2. 外部チェーンリンクOracleが失敗すると、コード全体がロールバックされます。
3. 重要な関数calculateSomethingImportant getPriceに依存し、ロールバックします。

 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; }

救済策：ロールバックエラーを処理し、ロールバックまたはキャッシュ値を実装するために、トライ/キャッチブロックで外部契約コールをラップします。

注：外部契約が意図的にガスを消費するエッジケースがあり、キャッチブロックにも失敗する可能性があります！これについては後で説明します。

結論は

Smart ContractのDOS攻撃に抵抗する能力を高めるために設計された3つの重要なチェックを調査します。キューの脆弱性の処理、小数の低いトークンに関連する課題、および外部契約の相互作用を安全に処理することの重要性です。

提供された例は、コアの脆弱性を説明することを目的としていることを忘れないでください。基本原則を理解し、これらの概念を特定のユースケースに適応させることが非常に重要です。

これらの提案を実装することにより、スマートコントラクトのセキュリティと回復力を大幅に改善できます。

Solodit Checklist Resolution Seriesの次の部分にご期待ください。

• オリジナルリンク： cyfrin.io/blog/solodit-c ...
• Denglian Community AIアシスタントは、すべての人のために素晴らしい英語の記事を翻訳しています。翻訳が理解できない領域がある場合は、私を許してください〜