一般的なスマートコントラクトの脆弱性

再発攻撃

スマートコントラクトで最も悪名高い脆弱性の1つは、2016年にDAOハックにつながったことで有名な再発攻撃です。この脆弱性は、初期関数の実行が完了する前に悪意のある契約が元の契約に戻って呼び戻したときに発生します。その結果、適切なチェックなしで外部呼び出しを処理する関数を悪用することができます。

再発攻撃を防ぐために、開発者は不明または信頼されていない契約に外部の呼び出しを行わないようにする必要があります。一般的な緩和手法は、チェックエフェクトインタラクションパターンを使用することです。これには、外部呼び出しを行う前に契約の状態を更新することが含まれます。さらに、Mutex Locksを使用して再発ガードを実装すると、再帰的な呼び出しをブロックするのに役立ちます。

別の方法は、OpenzeppelinのReentrancyGuardなどの監査されたライブラリを使用することです。また、開発者は、そのような攻撃による潜在的な損害を減らすために、1回の呼び出しで転送できるエーテルまたはトークンの量を制限することを検討する必要があります。

整数のオーバーフローとアンダーフロー

0.8.0より前のSolidityバージョンで書かれたスマートコントラクトは、整数のオーバーフローとアンダーフローの影響を受けやすいです。これらは、算術操作により、UINT256などの特定のデータ型の最大値を超える値または低下する値が得られる場合に発生します。

たとえば、タイプのuint256の変数が値0を保持して減少すると、最大値（2^256-1）に覆われ、誤った残高または不正アクセスにつながる可能性があります。これを緩和するには、開発者はOpenzeppelinが提供するSafeMathライブラリを使用する必要があります。これは、算術操作を明示的なチェックを実行します。

Solidity 0.8.0から始めて、これらのチェックはデフォルトで有効になり、算術操作は、チェックされていない{...}ブロックを使用して明示的にチェックされない限り、オーバーフローまたはアンダーフローのエラーをスローします。ただし、この組み込みの保護があっても、開発者はパフォーマンスの最適化のために安全チェックを無効にする際には慎重に保たなければなりません。

また、すべての入力を検証し、特にトークン転送に関連するユーザーが提供する値または動的計算を扱う場合、数学的操作が正しく制限されるようにすることも重要です。

フロントランニング攻撃

Ethereumのような公共のブロックチェーンでは、トランザクションが採掘される前に表示され、これにより、前面回転攻撃の扉が開きます。攻撃者は、保留中の取引を観察し、より高いガソリン料金で独自の取引を提出して最初に実行することができ、それにより結果を操作できます。

この脆弱性は一般に、分散型交換（DEX）およびトランザクションの順序が重要な他のアプリケーションに影響します。たとえば、ユーザーが特定の価格で取引を提出した場合、攻撃者はその取引をフロントランしてより良いレートを取得し、効果的に価値を盗むことができます。

フロントランニングを防御するために、開発者はコミットレビールスキームなどのメカニズムを実装できます。このアプローチでは、ユーザーは最初にトランザクションのハッシュバージョン（コミットフェーズ）を送信し、後で完全な詳細（フェーズを明らかにする）を明らかにし、手遅れになるまで攻撃者が正確なアクションを知ることを防ぎます。

あるいは、契約内でランダム性または時間ベースの条件を使用すると、トランザクションの結果がより困難になる可能性があります。ただし、真のランダム性オンチェーンは挑戦的であるため、開発者は多くの場合、オフチェーンのオラクルや、機密情報を曖昧にするための暗号化のコミットメントに依存しています。

不適切なアクセス制御

アクセス制御は、安全なスマートコントラクト開発の重要な側面です。不適切なアクセス制御は、特権機能の不正な実行につながり、攻撃者が契約状態を変更したり、資金を排出したり、契約機能を無効にしたりすることができます。

典型的な間違いは、誰が機密機能を呼び出すことができるかを制限しないことです。たとえば、契約所有者によってのみ呼び出されることを意味する関数には、所有者のみの修飾子が不足しているため、誰でも呼び出すことができます。別の問題が発生し、許可がハードコードされているか、使用後に適切に取り消されない場合に発生します。

これに対処するために、開発者は、Openzeppelinの所有可能なライブラリと役割ライブラリに見られるようなロールベースのアクセス制御パターンを利用する必要があります。重要なパラメーターを変更する関数には、発信者の身元または役割を検証する必要なステートメントまたは修飾子を含める必要があります。

さらに、マルチシグネチャウォレットを管理アクションに使用することができ、リスクの高い操作を実行する前に複数の承認を必要とします。意図しないアクセスパスが存在しないことを確認するには、許可された機能の定期的な監査とテストが不可欠です。

サービス拒否（DOS）脆弱性

スマート契約は、サービス拒否（DOS）攻撃の犠牲者になる可能性があり、悪意のあるアクターが合法的なユーザーが契約と対話するのを妨げます。これは、過度のガス消費を強制したり、実行パスを無期限にブロックするなど、さまざまな手段で発生する可能性があります。

1つの例は、エーテルを送信するために一連のアドレスをループする契約です。受信者の1人が過剰なガスを消費したり戻ったりするフォールバック関数を持っている場合、ループ全体が故障し、資金が詰まってしまう可能性があります。

DOSのリスクを緩和するには、開発者は動的配列に依存するループを避ける必要があります。代わりに、オフチェーンソリューションまたはプルオーバープッシュ支払いモデルを実装できます。ユーザーは、自動的にプッシュされるのではなく、自分で引き出しを開始します。

さらに、契約には、管理者による手動介入を許可したり、失敗した操作を再試行するなど、失敗の場合のフォールバックメカニズムを含める必要があります。関数呼び出し内でガス制限とタイムアウトを使用すると、無期限のブロッキングを防ぐことができます。

フォールバック関数の脆弱性

フォールバック関数は、エーテル転送または認識されていない関数呼び出しのデフォルトハンドラーとして機能します。ただし、慎重に設計されていない場合は、深刻なセキュリティの欠陥を導入できます。フォールバック関数は単純に保つ必要があり、複雑なロジックや状態の変更を含めてはなりません。

顕著なリスクは、フォールバック関数にループが含まれているか、別の契約を呼び出して、ガス外の例外または再発の可能性を高めることです。さらに、契約がフォールバックを介してエーテルの受信に依存しているが、送信者が転送（）またはsend（）を使用するシナリオを考慮していない場合、ガス転送が制限されているために予期せず失敗する可能性があります。

開発者は、フォールバック機能が、リバートで予期しないエーテルを拒否するか、最小限のロジックを処理することを確認する必要があります。また、堅牢性0.6.0で導入されたrecece（）およびfallback（）関数を使用して、支払性と賃金のないフォールバックの動作を分離することも推奨されます。

フォールバックロジックを徹底的に監査し、カスタムフォールバックとの契約からエーテルを送信するなどのエッジケースをテストすることは、混乱やエクスプロイトを避けるために不可欠です。

よくある質問

スマートコントラクトの脆弱性を検出するためにどのツールを使用できますか？ Slithers、Mythx、Oyenteなどの静的分析ツールを使用して、共通の脆弱性を特定できます。 Openzeppelinのディフェンダーなどのプラットフォームは、ランタイムの監視とデバッグ機能を優しく提供しています。自動化されたツールと手動のコードレビューと包括的なカバレッジの正式な検証を常に組み合わせてください。

スマートコントラクトで再発をテストするにはどうすればよいですか？機能を再入力するように設計された悪意のある契約への外部呼び出しをシミュレートするユニットテストを作成します。 HardHatまたはTruffleフレームワークを使用して、模擬契約を展開および対話します。 Echidnaなどのファジングツールを活用して、エッジケースのテストを自動化することもできます。

インラインアセンブリを堅牢性で使用しても安全ですか？インラインアセンブリは、EVMを低レベルの制御に付与しますが、Solidityの安全機能の多くをバイパスします。経験豊富な開発者によってのみ使用され、徹底的にレビューされる必要があります。最適化や特定のEVM機能に絶対に必要な場合を除き、使用しないでください。

展開後に契約を安全にアップグレードできますか？はい、プロキシパターンを使用したアップグレード可能な契約により、状態を保持しながら更新が可能になります。しかし、彼らは複雑さと新しい攻撃の表面を導入します。 Openzeppelinの透明性やUUPのプロキシなどの確立されたアップグレード性パターンを使用し、適切なアクセス制御と徹底的なテストを確保します。