スマートコントラクト中的サービス拒否攻撃

サービス拒否(DoS)攻撃は、スマートコントラクトが一定期間、さらには永久に正常に使用できなくなる可能性があります。主な原因は以下の通りです:

1. 契約のロジックに欠陥が存在する。例えば、いくつかのpublic関数の実装が計算の複雑さを考慮していない場合、Gas制限を超えて取引が失敗する可能性がある。

2. クロスコントラクト呼び出しシーンでは、コントラクトの実行が外部コントラクトの状態に依存します。外部コントラクトの実行が信頼できない場合、本コントラクトの実行がブロックされる可能性があり、資金がロックされて入出金できなくなることがあります。

3. 人為的要因、例えば契約の所有者が秘密鍵を失うことにより、重要なシステムの状態が更新できなくなる。

以下に具体的な例を挙げてサービス拒否攻撃の脆弱性を分析します。

1. 外部で変更可能な大規模データ構造をループして遍歴する

以下は登録ユーザーに"分紅"を与えるための簡単なスマートコントラクトです:

契約の状態には登録ユーザーリストとアカウント残高のマッピングが含まれています。ユーザーはregister_account()を通じて登録し、初期化することができます。

管理者はdistribute_token()を通じてユーザーに配当を行い、registered配列を遍歴して各ユーザーに指定された数量のトークンを転送します。

問題は、registeredのサイズに制限がなく、悪意のある操作が可能であるため、走査時のガス消費が制限を超えて過剰になることです。

推奨ソリューション:

• データ構造のサイズを制限し、最大値に達してもGas制限を超えないようにする
• 引き出しモードを採用し、先に記帳し、ユーザーはwithdrawを通じて報酬を自分で引き戻します。

!

2. コントラクト間の状態依存によるブロック

"入札"契約シナリオを考慮する:

• 現在の最高入札者と金額を記録しておく
• ユーザーはアカウントを登録して入札に参加できます
• 現在の最高価格を上回る入札があった場合、以前の最高価格を返却し、状態を更新します。

問題は、返金が外部契約の状態に依存していることです。以前の最高入札者のアカウントが削除されている場合、返金は失敗し、最高入札価格の更新ができず、競売プロセス全体がブロックされます。

ソリューション: 外部呼び出しが失敗する可能性を考慮し、合理的なエラーハンドリングを実装します。返金できない資金を一時保管し、後でユーザーが個別に引き出せるようにします。

!

3. 管理者の秘密鍵がありません

部分关键関数(は、取引の一時停止/再開)は管理者のみが呼び出すことができます。管理者の秘密鍵が失われると、これらの機能は使用できなくなり、契約は長期間正常に動作しなくなる可能性があります。

ソリューション: 複数の署名メカニズムを使用して単一の管理者を置き換え、分散型ガバナンスを実現し、単一障害点を回避します。