よくある脆弱性と対策

導入

Solanaプログラムは一度デプロイされると、資金や重要なデータを扱い続けます。ちょっとしたチェック漏れが、そのまま資金流出につながることもあります。この章の最後に、Solana開発でよく起きる脆弱性のパターンと、Anchorがそれをどう予防するかを整理します。

説明

代表的な脆弱性と、対応するAnchorの防御策を対応表にまとめます。

flowchart TB
    Req[クライアントからの命令呼び出し] --> Q1{署名者は正しいか?}
    Q1 -- Signer型で検証 --> Q2{所有者プログラムは正しいか?}
    Q2 -- Account型で検証 --> Q3{PDA/関連アカウントは正しいか?}
    Q3 -- seeds/bump/has_oneで検証 --> Q4{計算にオーバーフローはないか?}
    Q4 -- checked_*系関数で検証 --> OK[命令を実行]

整数の計算だけは、Anchorの型やアカウント制約では防げず、開発者自身が意識してチェック付きの演算を使う必要がある点に注意してください。

// 危険: リリースビルドではオーバーフローが検出されないことがある
account.balance = account.balance + amount;

// 安全: オーバーフロー時はErrへ
account.balance = account.balance
    .checked_add(amount)
    .ok_or(ErrorCode::Overflow)?;

Anchorは「よくある間違いを型で防ぐ」フレームワークですが、「型で表現しきれないロジックの誤り」までは防いでくれません。制約が何を検証しているかを理解したうえで、「このアカウントは本当にこの型・この所有者であるべきか」「この計算はあふれないか」を、自分の頭で確認する習慣が最後の防波堤になります。

演習

第7章レッスン27の演習で考えた「has_one = owner を外すとどうなるか」を、この表のどの脆弱性のパターンに当てはめられるか答えてみましょう。