DeFiサービスのスマートコントラクト監査｜XTELA開発支援事例

DeFiサービスのスマートコントラクト監査-ご支援事例

今回は、XTELAが実施したDeFiサービスのスマートコントラクト監査についてご紹介します。この案件では、当社の標準的な監査プロセスを実施し、お客様のシステムの脆弱性やバグを指摘し、レポート作成と修正支援を行いました。

お客様の要望

お客様は、複雑な紹介システムを持つDeFiサービスを短期間で開発されました。しかし、開発のスピードを優先したため、内部でのテストが十分に行えていないという課題がありました。そこで私たちに、基本的なテストから包括的なセキュリティ監査までを依頼されました。

支援概要

私たちは、スマートコントラクトの安全性を確保するため、以下の手順で支援を行いました。

1. スペシャリストによるコードレビュー
2. 静的解析の実施
3. テストケースの作成・実施
4. 発見した問題点と改善案をまとめたレポートの作成
5. お客様へのフィードバックと修正支援

主要な脆弱性とその対策

• リエントランシーアタック: 外部呼び出し後の状態更新順序を厳密にチェックし、防御パターンを実装。
• 整数オーバーフロー/アンダーフロー: SafeMath ライブラリの使用を徹底し、すべての算術演算を検証。
• 権限管理の不備: 適切なアクセス制御メカニズムの実装を確認し、役割ベースのアクセス制御（RBAC）を推奨。
• ランダム性の脆弱性: ブロックチェーン上の擬似乱数生成の限界を認識し、オラクルの使用を検討。
• タイムスタンプ依存性: block.timestamp の使用を最小限に抑え、大きな時間間隔でのみ使用するよう助言。
• フロントランニング: トランザクションの順序操作に対する耐性を評価し、コミットメント方式の導入を提案。
• DoS攻撃脆弱性: ガス制限を考慮したループの実装、プル支払いパターンの使用を確認。
• フォールバック関数の誤用: フォールバック関数の実装を精査し、意図しない動作がないか確認。
• アクセス制御の欠如: 重要な機能に適切なアクセス制御が実装されているか検証。
• 不適切なエラーハンドリング: 例外処理とエラーメッセージの適切な実装を確認。

静的解析ツール

本案件では、脆弱性の検出には以下の静的解析ツールを使用しました。

• Mythril: ConsenSys社が開発した静的解析ツール

テストコード作成と実行

以下のテストコードを作成し、実行しました。

1. ユニットテスト: 各関数の動作を個別に検証するテストを作成。Truffle と Mocha フレームワークを使用し、各機能の期待される動作と境界条件を網羅。Ganache を使用してローカル環境でのテストを実行
2. 統合テスト: 複数のコンポーネントが相互作用する場合の動作を検証。Ethereumテストネットを使用して、本番に近い環境でのテストを実行

監査プロセス

私たちの監査プロセスは以下の通りです。

1. コードレビュー: 専門家によるコードリーディングで、バグやリスクをチェックします。特に、コードレベルのテストでは網羅しにくい、ユーザシナリオレベルでのリスクや設計レベルの問題点などを指摘します。
2. 静的解析: ツールによるコードの検査を行います。機械的に発見できる問題点を洗い出します。
3. アドホックテスト: コードレビューの過程で動作検証が必要と判断される箇所がある場合、重点的にテストを行います。事前に設計を行うテストと違い、発見的手法によって問題検出を行います。
4. 単体テスト: functionレベルの単体テストを設計・実施します。仕様書がある場合は仕様書を基にテストを作成しますが、多くの場合ドキュメントが十分でないため、コードから仕様を推測してテストを作成します。推測した仕様について確認をとるため、テスト実施前に依頼者によるレビューや、仕様に関する質疑応答を行います。
5. シナリオテスト: ユースケースを想定したシナリオテストを設計・実施します。想定されるユースケースについて予め依頼者と協議し、テストシナリオを設計します。そして各シナリオが正しく実行できるかどうかテストします。単体テスト同様に、レビューと質疑応答によりテスト内容を合意します。
6. 自動化テスト: 単体テスト・シナリオテストを自動的に実行できるテストコードを作成します。リグレッションテストを簡単に・常時行えるため、監査後もプロダクトをアップデートしていく場合に効果的です。
7. 監査報告書: 監査の1サイクル目が完了した時点で、それまでの監査の実施事項、検出された問題などをPDF報告書にして提出します。この報告を受けて問題を修正する場合は、次の繰り返しテストフェーズに進みます。
8. 繰り返しテスト: 全ての問題がクローズ(修正のみでなく、対応しない、仕様を変更するなどの対応を含む)するまで、監査で検出された問題への対応(依頼者)と、修正箇所の再テスト(監査者)を繰り返します。
9. 修正完了報告書: 全ての問題がクローズしたことを報告するレポートを提出します。

検出した問題は深刻度に応じてレベル分けしてフィードバックします。よほど慎重にテストを重ねたプロジェクトでない限り、重要な問題が1つ以上検出されることが多いです。スマートコントラクトはリリース後に後戻りが難しいシステムであり、どのようなプロジェクトでも事前に監査を受けることが推奨されます。

関連するサービス・記事

• スマートコントラクト監査の工程と費用目安
• スマートコントラクト監査 - プロジェクトの成否を分ける鍵