Web Agentic Deep Scan のレポートをご覧ください

意図的に脆弱に作られた銀行アプリ VulnBank とその API に対する 217 ページの評価レポートです。各発見事項が再実行可能なリクエストで実証され、根本原因まで追跡される様子を示します。

対象
VulnBank の Web アプリと API
スキャン
Web Agentic Deep Scan
ページ数
217 ページ
結果
総合リスク:重大

意図的に脆弱性を持たせたデモ環境で実施しています。顧客データは含まれていません。

検出事項の詳細解説検出事項の概要表紙とリスク評価

レポートの内容

エグゼクティブサマリー

総合リスクと、深刻度ごとの発見事項の件数を冒頭にまとめています。

検出事項一覧

各発見事項のリスク、ステータス、簡単な説明。

実証済みのエクスプロイト

各発見事項を、悪用に使ったリクエストと得られた証拠とともに詳しく解説しています。

修正方法

各発見事項の根本原因と修正方法、再実行できる再現手順。

解説付きの検出事項

1つの検出事項をステップごとに

レポートが1つの検出事項を、テスト対象から修正まで、どのように扱うかを示します。各ステップに、完全版レポートの該当ページを記載しています。

  1. 対象

    vulnbank.org、稼働中のデモ銀行

    セキュリティトレーニング用に意図的に脆弱に作られたオンラインバンキングアプリと API を、実環境でテストしました。エグゼクティブサマリーは総合リスク「重大」から始まります。

    レポート 2 ページ
  2. 結果

    リスク順に並んだ 57 件の発見事項

    確認済みの脆弱性 42 件(重大 21 件、高 14 件、中 7 件)に加え、追加調査が必要な潜在的な問題 12 件と、3 件のハードニング対策。

    レポート 4 ページ
  3. 検出事項一覧

    一覧化して追跡

    検出事項一覧には、各問題のリスク、ステータス、簡単な説明が載っています。この問題は重大で、未対応のままです。

    レポート 7 ページ
  4. 検出事項

    重大:JWT の署名が検証されていない

    サーバーがアクセストークンの署名を確認せずに受け入れていたため、誰でも管理者トークンを偽造できました。さらに共有シークレット secret123 は容易に推測できるものでした。

    レポート 71 ページ
  5. 根本原因

    デコードはしても、検証はしないトークン

    レポートは、署名検証を無効にして jwt.decode を呼び出していることが原因だと特定しています。そのためサーバーは、is_admin を含め、トークンの主張をすべて信頼してしまいます。

    レポート 71 ページ
  6. 証拠

    それを証明するリクエスト

    トークンなしでは /admin/create_admin は 401 を返します。偽の署名を付けた偽造トークンでは、同じリクエストで管理者アカウントが作成され、別のリクエストでユーザーのアカウントが削除されました。

    レポート 72 ページ
  7. 検証

    すべての試行を 1 つの表に

    試したトークン、その署名、結果を並べて示しています。レスポンスの deleted_by フィールドには偽造トークンのユーザー名が入っており、サーバーがそれを信頼したことがわかります。

    レポート 73 ページ
  8. 修正

    シークレットを変更し、すべてのトークンを検証

    secret123 を強力なランダムシークレットに置き換え、すべてのリクエストで署名と有効期限を確認し、トークンを信頼せずにデータベースからユーザーを読み込みます。

    レポート 73 ページ

エージェントの判断

リスクと判断した理由

スキャナーはルールに一致したものをすべて報告します。エージェントは報告する前に、手がかりが実際の被害につながるかを確かめ、無害な説明を一つずつ排除します。vulnbank.org の発見事項について、エージェントがどう判断したかを示します。

  1. ステップ 1

    なぜ取引ページがログインなしで応答するのか?

    GET /transactions/123456 は 200 を返し、その口座の取引履歴をすべて表示しました。リクエストにはトークンも Cookie もありませんでした。

    レポート 47 ページ
  2. ステップ 2

    このエンドポイントはトークンに寛容なだけなのか?

    偽の Bearer トークン、偽のセッション Cookie、でたらめな API キーのいずれでも同じ 200 が返りました。このエンドポイントは認証をまったく見ていません。

    レポート 48 ページ
  3. ステップ 3

    どの口座でも通用するのか?

    はい。どの口座番号でもデータが返り、admin や test といった単語でさえ通りました。test 口座だけで 1,499 件の取引が返されました。

    レポート 48 ページ
  4. ステップ 4

    なぜ起きるのか?

    このルートは URL から口座番号を読み取り、そのままデータベースを検索します。口座が呼び出し元のものかどうかは何も確認していません。

    レポート 48 ページ
  5. ステップ 5

    では、リスクなのか?

    はい、重大(Critical)です。インターネット上の誰でも任意のユーザーの取引金額、日付、取引相手を読み取れ、口座番号を順に試してすべてを収集できます。

    レポート 47 ページ
  6. ステップ 6

    どう修正するのか?

    有効なログインを必須にし、ない場合は 401 を返します。次に口座が呼び出し元のものかを確認し、違えば 403 を返します。レポートには修正を確認するためのリクエストが記載されています。

    レポート 50 ページ

自社アプリでこのレポートを作成しませんか?

デモをご予約いただければ、お客様のモバイルアプリ、Web アプリ、API のスキャンをご案内します。