Web Agentic Deep Scan のレポートをご覧ください
意図的に脆弱に作られた銀行アプリ VulnBank とその API に対する 227 ページの評価レポートです。各発見事項が再実行可能なリクエストで実証され、スコア付けされ、根本原因まで追跡される様子を示します。
- 対象
- VulnBank の Web アプリと API
- スキャン
- Web Agentic Deep Scan
- ページ数
- 227 ページ
- 結果
- 総合リスク：重大
意図的に脆弱性を持たせたデモ環境で実施しています。顧客データは含まれていません。
レポートの内容
エグゼクティブサマリー
総合リスク、主な攻撃経路、優先して修正すべき点を冒頭にまとめています。
検出事項一覧
各発見事項のリスク、CVSS スコア、ステータス、簡単な説明。
実証済みのエクスプロイト
主なクリティカル・高の問題について、証拠とビジネスへの影響を含めて詳しく解説しています。
修正方法
各発見事項の根本原因と修正方法、再実行できる再現手順。
解説付きの検出事項
1つの検出事項をステップごとに
レポートが1つの検出事項を、テスト対象から修正まで、どのように扱うかを示します。各ステップに、完全版レポートの該当ページを記載しています。
- 対象
vulnbank.org（稼働中のデモ銀行）
セキュリティトレーニング用に意図的に脆弱に作られたオンラインバンキングアプリと API を、本番環境でテストしました。レポートには機能と、確認された技術スタックが記録されています。
レポート 2 ページ - スコープ
1つのドメインと、そこで見つかったすべてのエンドポイント
ログイン、送金、ローン、カード、アップロード、管理パネル、AI エージェント API を、2025 年 12 月 14 日から 2026 年 3 月 16 日まで、テスト用認証情報なしでテストしました。サブドメインは対象外です。
レポート 2 ページ - 手法
すべての発見事項に証拠が付く
エージェントがアプリを探索し、攻撃を一つずつ試みます。確認された発見事項には、再現するリクエストと検証の試行が含まれます。確認できなかった手がかりは「潜在的」と表示されます。
レポート 7 ページ - フロー
ログインとアクセス制御
この検出事項は、管理機能を含むすべてのリクエストを保護するログインと認可の層にあります。
レポート 48 ページ - 検出事項
重大（CVSS 9.8）：アクセストークンが検証されていない
サーバーがアクセストークンの真正性を確認せずに受け入れていたため、アカウントがなくても管理画面や管理操作にアクセスできました。
レポート 48 ページ - エビデンス
それを証明するリクエストとレスポンス
レポートには、スキャンのリクエストとレスポンスを要約して掲載しています。有効なトークンのないリクエストは拒否され、その後チェックが回避されて管理操作が成功しています。
レポート 49 ページ - 修正
すべてのトークンを検証し、ロールはサーバー側で確認
レポートは、署名を確認せずにトークンをデコードしていること、そしてトークン内の is_admin の値を信頼して認可していることが原因だと特定しています。修正方法：すべての署名を検証し、ユーザーのロールをサーバー側で読み込みます。
レポート 58 ページ - ステータス
スコア、分類、追跡
発見事項の一覧表には、各問題のリスク、CVSS スコア、ステータス、簡単な説明が記載されています。
レポート 20 ページ
エージェントの判断
リスクと判断した理由
スキャナーはルールに一致したものをすべて報告します。エージェントは報告する前に、手がかりが実際の被害につながるかを確かめ、無害な説明を一つずつ排除します。vulnbank.org の発見事項について、エージェントがどう判断したかを示します。
ステップ 1
なぜ残高ページがログインなしで応答するのか？
GET /check_balance/<口座番号> は、トークンも Cookie もないリクエストに対して 200 を返し、別のユーザーのユーザー名と残高を表示しました。
レポート 23 ページステップ 2
キャッシュされたコピーではないか？
エージェントは no-cache ヘッダーと一意の nonce を付けて再送しました。応答は cf-cache-status: DYNAMIC で、キャッシュではなくサーバーから返されていました。
レポート 24 ページステップ 3
トークンの扱いが甘いだけではないか？
でたらめなトークン Bearer invalid を付けたリクエストにも、同じ 200 と同じデータが返されました。このエンドポイントはトークンをまったく確認していません。
レポート 24 ページステップ 4
本物のデータか、固定のデモデータか？
エージェントはあるユーザーとしてログインし 12.34 の送金を行い、その後ログインせずにそのユーザーの取引を読み取りました。新しい取引が含まれていました。
レポート 25 ページステップ 5
なぜ起きるのか？
POST /transfer はトークンのないリクエストを 401 で拒否するため、認証の仕組み自体はあります。しかし、この 2 つの読み取りには適用されていません。API 仕様でもセキュリティなしと記載されています。
レポート 26 ページステップ 6
では、リスクなのか？
はい、重大（Critical）です。インターネット上の誰でも口座残高と取引履歴を読み取れ、200 と 404 の応答の違いから有効な口座番号を特定できます。
レポート 27 ページステップ 7
どう修正するか？
両方のエンドポイントで有効なトークンを必須にし、ない場合は 401 を返します。さらに、口座が呼び出し元のものかを確認し、そうでなければ 403 を返します。
レポート 27 ページ