スマート コントラクトのセキュリティ脆弱性トップ 5 とその防止方法

リエントラント攻撃

1. 再入可能性の脆弱性は、最初の実行が完了する前に外部コントラクトが現在のコントラクトにコールバックするときに発生します。

2. この欠陥により、攻撃者は状態変数が更新される前に引き出し関数を繰り返し呼び出して資金を流出させることができます。

3. 2016 年の悪名高い DAO ハッキングでは、まさにこのパターンが悪用され、 6,000 万ドル以上相当の ETH が損失しました。

4. 開発者は、Checks-Effects-Interactions パターンを適用して、外部呼び出しの前にすべての状態変更が確実に発生するようにすることで、このリスクを軽減できます。

5. OpenZeppelin の ReentrancyGuard 修飾子を使用すると、機密関数への再帰的なエントリを防ぐロック メカニズムが追加されます。

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

1. Solidity 0.8.0 より前では、算術演算はオーバーフローまたはアンダーフロー時に自動的に元に戻りませんでした。

2. 攻撃者は、値を強制的にラップアラウンドさせることで残高を操作する可能性があります。たとえば、ゼロから減算して大きな正の数を生成するなどです。

3. 2018 年、BeautyChain プロジェクトは、アンダーフローによって不正なトークンの鋳造が引き起こされるという重大な悪用を受けました。

4. Solidity 0.8.0+ にアップグレードすると、組み込みチェックによって自動復帰がトリガーされるため、この問題はコンパイラ レベルで解決されます。

5. 古いバージョンをまだ使用しているレガシー コードベースの場合、SafeMath ライブラリを明示的にインポートし、すべての算術演算に使用する必要があります。

未チェックの外部呼び出し

1. 契約では、戻り値の検証や失敗の処理を行わずに、外部呼び出しが成功すると想定することがよくあります。

2. 呼び出されたコントラクトが元に戻るかサイレントに失敗した場合、呼び出し側コントラクトは状態について無効な仮定を使用して続行する可能性があります。

3. パリティ ウォレット ハッキングでは、ライブラリ コントラクトへの未チェックの呼び出しにより、悪意のある攻撃者がウォレットの所有権を乗っ取ることが可能になりました。

4. 常に、明示的な成功検証を伴うrequire(call.success, '外部呼び出し失敗')または低レベル呼び出しを使用します。

5. どうしても必要な場合を除き、デリゲートコールを避けてください。デリゲートコールを誤って使用すると、ストレージの衝突や任意のコードの実行につながる可能性があります。

公開取引によるフロントランニング

1. イーサリアムのメモリプールは、ブロックに含める前に保留中のトランザクションをすべてのバリデーターとサーチャーに公開します。

2. 攻撃者は、大規模なスワップやガバナンス提案などの収益性の高い機会を監視し、より高いガス料金で競合するトランザクションを送信します。

3. 2020 年、市場の不安定な変化の中で、フロントランニングボットは Uniswap v2 流動性プロバイダーから1,200 万ドル以上を搾取しました。

4. オークション入札やガバナンス投票などの重要なアクションに対するコミット公開スキームを実装します。

5. Flashbots Protect などのプライベート トランザクション リレーを使用するか、しきい値暗号化を統合して、実行されるまで意図を不明瞭にします。

アクセス制御のロジックエラー

1. 修飾子の構成が間違っているか、ロール割り当てロジックに欠陥があると、権限のないユーザーに管理者権限が付与される可能性があります。

2. Cream Finance のインシデントでは、所有者転送機能のロジック バグにより、攻撃者が自分自身を新しい所有者として設定することができました。

3. アドレスがハードコードされているか、展開後に所有権の放棄が欠落していると、永続的な攻撃対象領域が作成されます。

4. Gnosis Safe などの標準を使用して、特権機能に対するマルチ署名要件を強制します。

5. すべてのonlyOwner 、 onlyRole 、およびカスタムアクセス修飾子の手動監査を実施して、継承パスとオーバーライドの安全性を確認します。

よくある質問

Q: 正式な検証により、すべてのスマート コントラクトの脆弱性を排除できますか? A: 形式的検証は、すべての入力に対して特定の特性が保持されることを数学的に証明しますが、ビジネス ロジックの欠陥、経済的攻撃、または外部プロトコルとの統合の問題をカバーすることはできません。

Q: 監査済みのコードを他のプロジェクトから再利用しても安全ですか? A: 本質的にはそうではありません。監査済みのコードであっても、新しい環境にデプロイされた場合には、コンテキスト固有の前提条件、古い依存関係、またはテストされていないエッジ ケースが含まれる可能性があります。

Q: テストネットはメインネットのセキュリティ条件を完全に再現しますか? A: いいえ。テストネットには実際の経済的インセンティブがなく、マイナーの動作が異なり、修正されたクライアント バージョンが実行されることが多いため、フロントランニング ベクトルやグリーフィング ベクトルを検出するには不十分です。

Q: オラクルの操作はスマート コントラクトの脆弱性とどのように関係しますか? A: Oracle の操作自体は契約レベルのバグではありませんが、集中型または低カバレッジの価格フィードに依存する契約はシステミック リスクを引き継ぎます。たとえば、単一の侵害されたノードが偽のデータをフィードすると、DeFi プロトコル全体で清算が引き起こされる可能性があります。