solana-security

Solana セキュリティ監査

Anchor とネイティブ Rust の両方の実装に対応した、Solana プログラム向けの体系的なセキュリティレビューフレームワークです。

レビュープロセス

包括的なセキュリティ監査を実施するため、次の体系的な 5 ステップのプロセスに従ってください。

ステップ 1：初期評価

プログラムのコンテキストと構造を把握します。

• フレームワーク：Anchor とネイティブ Rust のどちらかを確認します（use anchor_lang::prelude::* の有無を確認）
• Anchor のバージョン：Cargo.toml を確認し、互換性と既知の問題を調べます
• 依存関係：オラクル（Pyth、Switchboard）、外部プログラム、トークンプログラム
• プログラム構造：命令の数を数え、アカウントの種類を特定し、状態管理を分析します
• 複雑さ：コード行数、命令数、PDA のパターン
• 目的：DeFi、NFT、ガバナンス、ゲームなど

ステップ 2：体系的なセキュリティレビュー

各命令について、次の順番でセキュリティチェックを行います。

1. アカウント検証 - 署名者、所有者、書き込み可能性、初期化のチェックを検証します
2. 算術演算の安全性 - すべての算術演算で checked_* メソッドが使われていることを確認します
3. PDA のセキュリティ - 正規のバンプとシードの一意性を検証します
4. CPI のセキュリティ - クロスプログラム呼び出しで呼び出し先プログラムが検証されていることを確認します
5. オラクル／外部データ - 価格の古さとオラクルのステータスチェックを検証します

→ 詳細なチェックリストについては、references/security-checklists.md を参照してください

ステップ 3：脆弱性パターンの検出

一般的な脆弱性パターンをスキャンします。

• 型偽装攻撃
• アカウント再読み込みの問題
• 不適切なアカウントのクローズ
• lamports チェックの欠落
• PDA すり替え攻撃
• 任意の CPI による脆弱性
• 所有権検証の欠落
• 整数のオーバーフロー／アンダーフロー

→ コード例とエクスプロイトのシナリオについては、references/vulnerability-patterns.md を参照してください

ステップ 4：アーキテクチャとテストのレビュー

設計全体の品質を評価します。

• PDA の設計パターンと衝突の防止
• アカウント領域の割り当てとレント免除
• エラー処理の方針と網羅性
• 重要な状態変更を示すイベントの発行
• 計算予算の最適化
• テストの網羅率（単体、統合、ファジング）
• アップグレード戦略と権限管理

ステップ 5：セキュリティレポートの作成

次の構成で調査結果を提示します。

深刻度レベル：

• 🔴 重大：資金を盗まれる／失う可能性がある、プロトコルが完全に機能しなくなる
• 🟠 高：プロトコルが妨害される可能性がある、一部の資金が失われる可能性がある
• 🟡 中：最適でない動作、エッジケース、グリーフィング攻撃
• 🔵 低：コード品質、ガスの最適化、ベストプラクティス
• 💡 参考情報：推奨事項、改善点、ドキュメント

指摘事項の形式：

## 🔴 [CRITICAL] Title

**Location:** `programs/vault/src/lib.rs:45-52`

**Issue:**
Brief description of the vulnerability

**Vulnerable Code:**
```rust
// Show the problematic code

エクスプロイトのシナリオ： どのように悪用されるかをステップごとに説明します

推奨事項：

// Show the secure alternative

参考資料：

• [関連ドキュメントまたは類似のエクスプロイトへのリンク]

**Report Summary:**
- Total findings by severity
- Critical issues first (prioritize by risk)
- Quick wins (easy fixes with high impact)
- Recommendations for testing improvements

## Quick Reference

### Essential Checks (Every Instruction)

**Anchor:**
```rust
// ✅ Account validation with constraints
#[derive(Accounts)]
pub struct SecureInstruction<'info> {
    #[account(
        mut,
        has_one = authority,  // Relationship check
        seeds = [b"vault", user.key().as_ref()],
        bump,  // Canonical bump
    )]
    pub vault: Account<'info, Vault>,

    pub authority: Signer<'info>,  // Signer required

    pub token_program: Program<'info, Token>,  // Program validation
}

// ✅ Checked arithmetic
let total = balance.checked_add(amount)
    .ok_or(ErrorCode::Overflow)?;

ネイティブ Rust：

// ✅ Manual account validation
if !authority.is_signer {
    return Err(ProgramError::MissingRequiredSignature);
}

if vault.owner != program_id {
    return Err(ProgramError::IllegalOwner);
}

// ✅ Checked arithmetic
let total = balance.checked_add(amount)
    .ok_or(ProgramError::ArithmeticOverflow)?;

重大なアンチパターン

❌ 絶対にしないでください：

• saturating_* 算術メソッドを使う（エラーが隠されます）
• 本番コードで unwrap() や expect() を使う
• 追加のチェックなしで init_if_needed を使う
• 署名者の検証を省略する（「呼び出されるはずがない」と考える）
• チェックなしの算術演算を使う
• 任意の CPI 呼び出し先を許可する
• 変更を伴う処理の後にアカウントを再読み込みし忘れる

✅ 必ず行ってください：

• checked_add、checked_sub などの checked_* 算術演算を使う
• Option のアンラップには ok_or(error)? を使う
• 適切な検証とともに明示的な init を使う
• Signer<'info> または is_signer チェックを必須にする
• CPI プログラムの検証には Program<'info, T> を使う
• 状態を変更する外部呼び出しの後にアカウントを再読み込みする
• アカウントの所有権、ディスクリミネーター、関連性を検証する

フレームワーク固有のパターン

Anchor のセキュリティパターン

→ 詳細については、references/anchor-security.md を参照してください：

• アカウント制約に関するベストプラクティス
• Anchor 固有の一般的な脆弱性
• CpiContext を使った安全な CPI パターン
• イベントの発行と監視
• カスタムエラー処理

ネイティブ Rust のセキュリティパターン

→ references/native-security.md を参照してください。

• アカウントを手動で検証するパターン
• 安全な PDA の導出と署名
• 低レベル CPI のセキュリティ
• アカウント識別子のパターン
• レント免除の検証

最新のプラクティス（2025）

• 最新のセキュリティ機能には Anchor 0.30+ を使用する
• 適切な拡張機能の処理とともに Token-2022 を実装する
• 自動的な領域サイズの計算には InitSpace derive を使用する
• すべての重要な状態変更についてイベントを発行する
• Trident フレームワークを使用してファズテストを作成する
• コードコメントに不変条件を記載する
• 段階的なロードマップに従う：開発 → 監査 → テストネット → 監査 → メインネット

セキュリティの基礎

→ references/security-fundamentals.md を参照してください。

• セキュリティ意識と脅威モデリング
• 中核となる検証パターン（署名者、所有者、可変性）
• 入力検証のベストプラクティス
• 状態管理のセキュリティ
• 算術演算の安全性
• 再入可能性に関する考慮事項

よくある脆弱性

→ references/vulnerability-patterns.md を参照してください。

• 署名者検証の欠如
• 整数のオーバーフロー／アンダーフロー
• PDA 差し替え攻撃
• アカウントの混同
• 任意の CPI
• 型のコスプレ
• 不適切なアカウントのクローズ
• 計算における精度の損失

各脆弱性には以下が含まれます。

• ❌ 脆弱なコード例
• 💥 攻撃シナリオ
• ✅ 安全な代替策
• 📚 参考資料

セキュリティチェックリスト

→ references/security-checklists.md を参照してください。

• アカウント検証チェックリスト
• 算術演算の安全性チェックリスト
• PDA とアカウントのセキュリティチェックリスト
• CPI セキュリティチェックリスト
• オラクルと外部データのチェックリスト
• トークン連携チェックリスト

既知の問題と注意事項

→ references/caveats.md を参照してください。

• Solana 固有の癖や注意点
• Anchor フレームワークの制限事項
• テストの盲点
• よくある誤解
• バージョン固有の問題

セキュリティリソース

→ references/resources.md を参照してください。

• 公式のセキュリティドキュメント
• セキュリティ講座とチュートリアル
• 脆弱性データベース
• 監査レポートの例
• セキュリティツール（Trident、ファザー）
• セキュリティ企業と監査担当者

すべての監査で確認すべき重要な質問

以下の重要なセキュリティ特性を必ず検証してください。

1. 攻撃者がアカウントを差し替えられますか？

   • PDA の検証、プログラム ID の確認、has_one 制約

2. 算術演算でオーバーフローまたはアンダーフローが発生しますか？

   • すべての演算でチェック付き操作を使用し、ゼロ除算を防止する

3. すべてのアカウントが適切に検証されていますか？

   • 所有者、署名者、書き込み可能、初期化済みのチェックがある

4. プログラムから資金を抜き取られる可能性がありますか？

   • 認可チェック、再入可能性の保護、アカウント混同の防止

5. エッジケースでは何が起こりますか？

   • ゼロの数量、最大値、クローズ済みアカウント、有効期限切れのデータ

6. 外部依存関係は安全ですか？

   • オラクルの検証（古さ、ステータス）、CPI の呼び出し先の確認、トークンプログラムのチェック

監査ワークフロー

開始前

1. プロトコルの目的と仕組みを理解する
2. ドキュメントと仕様を確認する
3. ローカル開発環境をセットアップする
4. 既存のテストを実行し、カバレッジを確認する

監査中

1. 5 段階のレビュー手順に体系的に従う
2. 重要度と修正方法を添えて検出事項を記録する
3. 重大な問題について概念実証のエクスプロイトを作成する
4. 修正をテストし、機能することを確認する

監査後

1. 重要度順に優先順位を付けて、検出事項を明確に提示する
2. 実行可能な修正手順を示す
3. 修正の実装後に再監査する
4. プロトコルで得られた教訓を記録する

セキュリティテスト

コードレビューに加えて、テストを通じてセキュリティを検証します。

• ユニットテスト：各命令のエッジケースをテストする
• 統合テスト：命令間の相互作用をテストする
• ファズテスト：Trident を使用して予期しない動作を発見する
• エクスプロイトシナリオ：発見した脆弱性の POC を作成する
• アップグレードテスト：移行経路が安全であることを検証する

中核となる原則

Solana のアカウントモデルでは、攻撃者は任意のアカウントをあらゆる命令に渡せます。

セキュリティを確保するには、以下を明示的に検証する必要があります。

• ✅ すべてのアカウントの所有者
• ✅ すべてのアカウントの型（ディスクリミネーター）
• ✅ すべてのアカウント間の関係
• ✅ すべてのアカウントの状態
• ✅ すべての署名者要件
• ✅ すべての算術演算
• ✅ すべての外部呼び出し

暗黙の保証はありません。すべてを検証し、何も信頼しないでください。