スマートコントラクトにおける一般的なセキュリティリスクを回避するには?

スマートコントラクトの脆弱性を理解する

1. リエントランシー攻撃は依然としてイーサリアムベースのスマートコントラクトで最も悪用される弱点の 1 つであり、状態の変更が完了する前に外部コントラクトが現在のコントラクトをコールバックします。

2. 整数のオーバーフローおよびアンダーフローの問題は、算術演算が uint256 でサポートされている最大値または最小値を超えると発生し、予期しない残高のリセットや資金の重複につながります。

3. 受信者のコントラクトにフォールバック機能がないか、予期せず元に戻った場合、チェックされていない外部呼び出しによりサイレント エラーが発生し、重要なロジックが重要な検証をバイパスする可能性があります。

4. 不適切なアクセス制御により、権限のないユーザーが所有者限定の引き出しやアップグレードのメカニズムなどの特権機能を呼び出すことができ、資産が盗難や操作の危険にさらされることになります。

5. ブロックのタイムスタンプはマイナーによって制御され、15 秒以内に操作されるため、タイムスタンプの依存性により非決定性が生じ、権利確定スケジュールなどの時間に敏感なロジックが損なわれます。

コード監査のベスト プラクティス

1. Slither や MythX などの静的分析ツールは、危険なデリゲートコールの使用、保護されていない自己破壊命令、初期化されていないストレージ ポインターなどの一般的なアンチパターンを検出します。

2. Certora Prover などのツールを使用した正式な検証は、指定された不変条件への準拠を数学的に証明し、関数がバランスの保持やアクセス制限に違反しないことを保証します。

3. 手動ピアレビューには、すべての外部呼び出しパスをトレースし、元に戻せない操作の前に、すべての require() ステートメントが入力の有効性と状態の一貫性の両方を強制していることを確認することが含まれている必要があります。

4. ガス制限を考慮するには、ユーザー指定のアレイに合わせて拡張するループのテストが必要で、実行中の過剰なガス消費によるサービス妨害を防止します。

5. コンパイラのバージョンの固定により、Solidity アップデートによる予期せぬ動作が回避されます。0.8.0 より前のバージョンでコンパイルされたコントラクトには、明示的に実装されていない限り、組み込みのオーバーフロー チェックがありません。

導入とアップグレードの安全対策

1. マルチシグネチャウォレットは所有権の移転と管理アクションを管理し、ハードコードされた所有者アドレスに関連する単一点障害のリスクを排除する必要があります。

2. プロキシ パターンでは、ロジック コントラクトとストレージ コントラクトを慎重に分離する必要があります。実装とプロキシ間のストレージ スロットの位置合わせが不適切であると、致命的な状態の破損が発生する可能性があります。

3. 緊急一時停止機能により、異常が検出されたときにコア動作を一時的に停止できますが、一時停止トリガーはフロントランニングから保護する必要があり、複数の当事者の合意が必要です。

4. 不変の初期化により、デプロイメント後のコンストラクター ロジックへの再入力が防止され、初期供給の生成や料金パラメーターの設定などのセットアップ ルーチンが 1 回だけ実行されることが保証されます。

5. Etherscan でのバイトコード検証により、オンチェーン コードが監査されたソースと一致することが確認され、侵害されたツールチェーンまたは CI パイプラインを介した展開中の悪意のある置換がブロックされます。

フロントエンド相互作用のリスク

1. EIP-712 型付きデータ署名の署名可鍛性により、ドメイン区切りハッシュでチェーン ID またはバージョン フィールドが省略されている場合、攻撃者が承認を偽造できる可能性があります。

2. ウォレット接続ハイジャックは、MetaMask または WalletConnect ハンドシェイク中に dApp が悪意のあるスクリプトを挿入し、秘密キーを取得したり、トランザクション ペイロードを傍受したりするときに発生します。

3. トランザクションのプレビューが不十分な場合、ユーザーは無制限のトークン許可により攻撃者が管理するコントラクトへの永久アクセスを許可する「承認」の罠にさらされます。

4. RPC エンドポイントの操作により、悪意のあるサイトが不正なノードを介してクエリをルーティングし、偽の残高や捏造されたイベント ログを返してユーザーの決定を誤解させることができます。

5. フィッシング耐性のあるドメイン バインディングでは、ウォレットから発信されたメッセージを登録済みの dApp ドメインに対して厳密に検証する必要があり、なりすましされた発信元からの署名を拒否します。

よくある質問

Q: デプロイ後にプロキシを使用せずにスマート コントラクトを更新できますか? A: いいえ。一度デプロイされると、バイトコードはイーサリアム上で不変になります。変更を行うには、新しいコントラクトを展開し、手動またはサードパーティの調整を介して状態を移行する必要があります。

Q: 認証に Solidity のtx.origin を使用しても安全ですか? A: いいえ。tx.origin は、トランザクション チェーンを開始する元の EOA アドレスを返すため、悪意のあるコントラクトによってなりすます可能性があり、アクセス制御にとって安全ではありません。

Q: 契約の実行中にガスが不足した場合はどうなりますか? A: トランザクション全体が元に戻り、すべての状態変更が復元されますが、消費されたガスは失われます。これには、失敗した送信、require ステートメント、および明示的な取り消しが含まれます。

Q: 一部の契約では、ストレージ内の残高を追跡する代わりにaddress(this).balanceを使用するのはなぜですか? A: address(this).balanceに依存すると、ストレージへの書き込みが回避され、ガスコストが削減されますが、反映されるのは ERC-20 トークンではなく ETH だけであり、複雑な会計ロジックを表すことはできません。