Back to Blog

Solanaエコシステムを守る(4)— アカウント検証

April 1, 2022
6 min read

0. レビュー

1. 概要

前回のブログでは、プログラムのアップグレード方法について説明しました。今回の投稿では、DeFi分野において最も一般的かつ基本的なセキュリティトピックの一つであるアクセス制御に関連する問題を紹介します。

2. インストラクション

Solanaでは、各プログラムはentrypoint!で定義された単一のentrypointをエクスポートします。Ethereumとは異なり、クライアントはentrypointとして定義された単一の関数(通常process_instructionと呼ばれる)しか呼び出すことができません。entrypoint関数は3つのパラメータを受け取ります。それらはスマートコントラクトのプログラムID、プログラムが操作するアカウント、そしてインストラクションデータです。インストラクションデータはどのインストラクションが呼び出されるかを指定します。以下の図はその例を示しています。インストラクションデータをアンパックすることで、異なるインストラクション(例:Lock、Unlock)が選択されます。したがって、entrypointから到達できるインストラクションは誰にでも公開されており、指定されたインストラクションデータで実行できます。

3. アカウントの検証

前述のとおり、プログラムは読み取りまたは書き込みが必要なアカウントを受け取ります。この設計により2つの問題が生じます。読み取られるアカウントについては、アカウントに保存されているデータが信頼できることをどのように保証するか。書き込まれるアカウントについては、権限を持つユーザーのみがアカウントへの書き込みインストラクションを呼び出せることをどのように保証するか。以下では、アクセス制御の問題を説明します。すべてのテストコードはこちらで確認できます。

3.1 コードレビュー (PrivilegeOwner)

まずDoorConfigという2つの構造体を定義します。構造体doorで指定されたkeyアカウント(17行目)のみが作成されたdoorを開くことができます。ただし、構造体Config(81行目)で指定されたシステム状態がロックされている場合、ドアを開くことはできません。

前述のとおり、Configアカウントはドアを開けるかどうかを指定します。この場合、プログラム内にConfigアカウントは1つだけ存在する必要があります。これを実現するために、PDAを使用してConfigのデータを保存します。Configアカウントを初期化した後、攻撃者によって再初期化されないよう属性is_initializedtrueに設定します(108行目〜110行目)。

インストラクションOpen()はドアを開くために使用されます。このインストラクションは、開くべきドアアカウント、configアカウント、およびdoorを開こうとするownerアカウントを含む複数のアカウントを受け取ります。ドアがプログラムに属し設定が有効であることを保証するために、doorアカウントとconfigアカウントのオーナーを確認します(204行目〜205行目)。これにより、悪意あるユーザーが偽のアカウントを渡すことを防ぎます。これが最初の質問への答えです。読み取られるアカウントが信頼できることを保証するには、アカウントのオーナーを確認する必要があります!doorアカウントのオーナーのみがドアを開くことができることに注意してください。この場合、ownerアカウントがdoorの実際のownerであるかどうか、そして重要なことに、インストラクションがオーナーによって承認されているかどうかを確認します(217行目〜219行目)。

関数validate_owner()では、まず2つのアカウントの公開鍵が同じかどうかを確認し、次にオーナーの署名を確認します。これが2番目の質問への答えです。権限を持つユーザーのみがopenインストラクションを呼び出せることを保証するには、アカウントのオーナーと署名者を確認する必要があります。closeインストラクションはopenと同様であり、詳細はコードで確認できます。

プログラムをテストネットにデプロイしました。以下のリンクで確認できます。

https://explorer.solana.com/address/2Q7FFMWCthBvc6ubLQRx9TRswvaimmd66VaCAfHwsYuC?cluster=testnet

すべてのテストトランザクションを以下に示します。このトランザクションの全体的なプロセスは AllocatePDA()-> InitializeDoor()-> InitializeConfig()-> Unlock() -> Open() -> Close() です。

https://explorer.solana.com/tx/2X9CyMrHTNEvbzXTE95gem2j8spnvsQsabFeSpV8hiNpYjiQPPzLRqt5KN86ZYRjnQvydvs7y5eUjJK7no8knDhk?cluster=testnet
https://explorer.solana.com/tx/2XfVWiXeQeHbpqAEYm3AH2RU6hunnqtr155EC4EAM5Bq9VVZNP6QocAav9cPjEQdJFcQrbsSSxiKadr4HPMov8pz?cluster=testnet
https://explorer.solana.com/tx/5Em41sg7yFXeNpnEJnhUQJanfLWKwjMqiBeNAqEEzFrSN9P8zKKafcv5F7RKT2pseB171qeoa8Uz4fKgazzayCnW?cluster=testnet
https://explorer.solana.com/tx/2PMtzpSgjnKDLGmRWBdUSFBPimWnudCPekUYbWzPzokENFYa4N4ab4HCtynfGrzswFPTgGYKHU8PccUMHv3mXHkR?cluster=testnet
https://explorer.solana.com/tx/3kviP9MqkWGMV4yA7k7yPQ5BGfXmcYLcctmY1u2D7n56eT1nx8jMtDumkUNJy8yA3KkmzrmfQLjqpigc8ehGZzBN?cluster=testnet
https://explorer.solana.com/tx/38iEaJBzuGMLbfcszdVB8pkniezH8JrA3XGq7JdADZTQ4hNQC82GSTUA2bmcypdVy3t7htWnUzkZ4F8EakmNvqz8?cluster=testnet

3.2 攻撃トランザクション

オーナーチェックと署名者チェックの重要性を示すために、2つの攻撃シナリオを例として使用します。

最初のシナリオ

1つ目は、configがロックされている状態でドアのオーナーがドアを開こうとするケースです。これを実現するために、別のプログラムに偽のconfigアカウントを作成し、属性is_lockに値falseを割り当てます。カスタムプログラムのコードを以下に示します。

偽のconfigアカウントを作成するトランザクションを送信します。偽のconfigアカウントの公開鍵は: 2MtSrbWp24VjPZQcSUkiWrvNro7qqKemVCsh3Yxc8LTy です。

https://explorer.solana.com/tx/2qSyrL5gdQXmgGCFzmzMm1StFQRkDgWpss9A9jV11q2fgDGM5C1XRuXvbX1N5Dt3q2pRqnmyXHVtXGF5dqadAzpJ?cluster=testnet

偽のconfigアカウントが作成されたら、それをプログラムに渡します(423行目)。

結果を以下に示します。ログにはincorrect program id for instructionと表示されており、configアカウントのオーナーはそのプログラムでなければならないことを意味します。したがって、攻撃者はこのチェックを回避できません。

2番目のシナリオ

2番目のシナリオは、悪意あるユーザーがドアのロックが解除されている状態でドアを開こうとするケースです。

この場合、実際のオーナーアカウントをプログラムに渡し(419行目)、トランザクションを送信します。結果を以下に示します。

Signature verification failedと表示されており、ドアを開くには実際のオーナーがトランザクションに署名しなければならないことを意味します。したがって、2番目の攻撃も失敗します。

4. まとめ

Solanaでは、インストラクションはクライアントまたは他のプログラムから渡された異なるアカウントに基づいて指定されたロジックを実装します。そのため、アカウントの適切なチェックは非常に重要です。

この記事では、アカウントを適切にチェックする方法を紹介し、2つの攻撃シナリオを使用してこれらのチェックの重要性を説明しました。引き続きご覧ください。今後もさらに多くの記事を共有していきます。

このシリーズの他の記事を読む:


BlockSecについて

BlockSecは、世界的に著名なセキュリティ専門家のグループによって2021年に設立された先駆的なブロックチェーンセキュリティ企業です。同社は、大規模な普及を促進するために、新興のWeb3世界のセキュリティとユーザビリティの向上に取り組んでいます。そのために、BlockSecはスマートコントラクトおよびEVMチェーンのセキュリティ監査サービス、セキュリティ開発と脅威のプロアクティブなブロッキングのためのPhalconプラットフォーム、資金追跡と調査のためのMetaSleuthプラットフォーム、そして暗号世界を効率的に閲覧するweb3ビルダー向けのMetaSuites拡張機能を提供しています。

現在までに、同社はMetaMask、Uniswap Foundation、Compound、Forta、PancakeSwapなど300社以上の著名なクライアントにサービスを提供し、Matrix Partners、Vitalbridge Capital、Fenbushi Capitalなどの著名な投資家から2回の資金調達ラウンドで数千万米ドルを調達しています。

公式ウェブサイト: https://blocksec.com/

公式Twitterアカウント: https://twitter.com/BlockSecTeam

Sign up for the latest updates
〜1800万ドルの損失:jaredFromSubway、Aztecなど|BlockSecウィークリー
Security Insights

〜1800万ドルの損失:jaredFromSubway、Aztecなど|BlockSecウィークリー

ブロックチェーンセキュリティ週次レポート(2026年6月15日〜21日):EthereumとBNB Chainで3件の重大インシデントが発生し、総損失約1830万ドル。注目のjaredFromSubway事件では、MEVボットが裁定取引のために自身の資産を未検証の第三者コントラクトに承認するという逆承認攻撃が判明。攻撃者は実イベントを発行しながら承認を消費しない偽トークンとプールを構築し、損失は約1500万ドル。またAztecでは3日間で2度目の攻撃が発生、エスケープハッチZK回路でold_data_rootの等価制約欠如を悪用し、偽マークルツリーに対するノート所有権の証明が可能となった。

Web3コンパニオン:オープンソースのセキュアなエージェント型ウォレット

Web3コンパニオン:オープンソースのセキュアなエージェント型ウォレット

BlockSecがWeb3 Companionをオープンソース化。セキュリティ優先のエージェント型ウォレットで、自社AIエージェントを非信頼として扱い、キー分離・厳格なポリシー・Passkeyでオンチェーン資産を保護する。

〜598万ドルの損失:Aztec、Raydiumなど|BlockSec週次レポート
Security Insights

〜598万ドルの損失:Aztec、Raydiumなど|BlockSec週次レポート

週次ブロックチェーンセキュリティレポート(2026年6月8日〜15日)では、EthereumとSolanaで4件の重大インシデントを分析し、総損失は約598万ドル。Aztec Connectでは入力検証の欠如によりロールアップの証明経路とL1決済が不整合に。RaydiumではレガシーAMM v3の検証不備でLPトークン償還計算が操作され4プールが流出。両脆弱性は悪用前から数年間存在。入力検証不備、整数オーバーフロー、ガバナンス乗っ取りも検証。