本記事では『Webアプリケーション診断』の実施ケースをご紹介します。

【1】『脆弱性診断するべき』という「理想」と「現実」の予算

情報を提供する企業にとって、Webサイトの信頼性は生命線です。特に親会社が上場企業であるお客様にとって、セキュリティリスクの可視化と対策は必須のミッションです。

しかし、セキュリティ対策には予算と工数がかかりますし、ましてやそれが正しく行われているか確認するために脆弱性診断を行うとなればさらに予算がかかります。

すべての機能をくまなく診断することが理想ですが、限られた予算やリソースの中で、最も危険なリスクを確実に潰したいという現実的なニーズがあります。

弊社ではこうしたニーズに応えるため、診断を機械的に提供することはせず、費用対効果を最大化する柔軟な提案を行っています。

1-1.◆診断対象の選定

すべての機能をくまなく診断することは理想ではありますが、実際には難しいケースも多いため、対象を絞っての診断実施もご提案しています。

どのくらい、または、どのように絞るかの判断は難しいですが、デジタル庁が公開している「政府情報システムにおける脆弱性診断導入ガイドライン」は指針として参考にしていただけるかと思います。

---

▼以下、抜粋

Web アプリ診断は 50〜100 リクエスト程度、スマートフォンアプリ診断は 10〜20 画面程度の間で定めると良い。
また、実際に各システムの診断対象を決める際は、サイトのトップページから辿れる範囲で行うことや、同様の作りの画面が複数ある場合は代表する 1 画面のみを診断対象とすること等の選定方針を決めておくと良い。
また、同じシステムを再度診断する場合は、過去に行った診断とは異なる画面や API を対象とすることが望ましい。
いずれにせよ、最終的な診断対象は、対象システムの内部構成を把握する運用担当者を交えて決定するものとする。

引用元：デジタル庁 デジタル社会推進標準ガイドライン
『政府情報システムにおける脆弱性診断導入ガイドライン』
（2024年2月6日版）

---

これはあくまでも政府情報システムに対して実施する時の一つの目安でしかなく、絶対の指針ではありません。

しかし、すべての画面を実施するのではなく、『ある程度絞る』『似たような画面であれば、代表して一つだけ診断する』というのはわかりやすく、納得性の高い指針です。

【2】顧客の要望に合わせて約50件を35件ほどに絞り込む

一例として、ここではサイトを確認した結果、診断対象となるリクエストが「50件程度だったケース」をご紹介します。
弊社では対象の洗い出しを行った際に併せて診断優先度を記載してお送りすることも可能です。

たとえば、優先度「高」は認証機能やファイルアップロード機能など、不正アクセスなどの重大な問題に繋がりやすい機能が該当します。

優先度づけ自体は機械的に行っていますが、抜粋してご提案する場合には、機械的に優先度の高い項目から実施するのではなく、似ていると推測される機能を省くなどして優先度「中」や「低」からも幅広く選定を行います。

本案件では優先度「高」の全てと、優先度「中」「低」から抜粋して合計35件程度に絞り、診断を実施しました。

【3】実施プロセス：お問い合わせから報告まで「1ヶ月」のスピード感

ご依頼内容やサイトのご状況にもよりますが、対象50件のサイト規模、診断35件の場合は、お客様からのご連絡からレポート提出まで、約1ヶ月というスピード感をイメージいただければと思います。

3-1.ステップ 1：サイト確認と対象範囲の確定（3日〜7日）

診断対象であるサイトのURLをご提供いただき、診断サイトを弊社側で確認し、診断対象となるリクエストを確認します。

---

≪ポイント1👆「想定」項目の取り扱いについて≫
何らかの制限があってサイト上の機能を実行できない場合、見積もり時点では「想定」として仮の見積もりを行います。その場合、診断開始後の確認で対象数が確定次第、お客様に実施する対象数(費用)のご相談をさせていただきます。
たとえば、本番環境だからお問合せは送信しないよう「想定」にしたり、テスト環境だけどXXX画面のYYY機能はまだデータが入っていないため「想定」にしたりなどのケースがしばしばあります。

---

あわせて、このタイミングでは診断にあたっての診断用の環境準備をおすすめしています。

3-2.ステップ 2：診断時期の調整（3日〜7日）

お申し込み後、ヒアリングシートにご記入いただき、スケジュールを調整します。

---

≪ポイント2👆業務に影響を出さないための鉄則≫
脆弱性診断では、記事の投稿や大量のお問い合わせ送信など、業務を妨害する操作を意図的に行います。そのため、原則として本番とは別環境（開発用、ステージング環境など）をご用意いただくことを推奨しています。

---

ただし、「テスト環境がない…」という場合でも対応可能です。
本番環境での実施する場合は、業務影響を事前に明確にお伝えし、ご同意いただいた上であれば実施可能です。

3-3.ステップ 3：診断実施（7日間）

目安ですが、診断対象が35件だった場合は、7日間程度の診断期間をいただき、集中的に検査を行います。
診断中に危険度の高い脆弱性が検出されるケースもありますが、その場合は日次で速報レポートを送付することも可能です。

3-4.ステップ 4：診断完了とご報告（5日）

診断完了から5営業日で、報告書を送付します。
報告書には脆弱性の再現方法と対策を記載しておりますが、お客様の環境によっては、対策が難しいケースもあります。
そういった場合でもお客様から修正方針についてのご相談をいただき、個別にアドバイスをさせていただきます。

【4】検出される深刻な脆弱性の例：「ファイルアップロード機能の不備」

本診断対象で、危険度が高めの脆弱性として検出されたものをピックアップしてご紹介します。

◆ファイルアップロード機能の不備
診断対象のファイルアップロード機能に不備があり、任意のファイルをアップロード可能な状態となっていました。

サーバーサイドで動作するプログラムファイルの実行は成立しなかったものの、クライアントサイド（ブラウザー）で実行可能なファイルについては実行できました。

クライアントサイドで実行可能なファイル（HTMLやJavaScriptなど）をアップロード・実行できる状態にあるため、クロスサイトスクリプティング（XSS）などが実行可能な状態にありました。

---

≪📖クロスサイトスクリプティング（XSS）とは？≫
Webサイトに任意のJavaScriptを埋め込むことで、ユーザーのブラウザー上で任意のプログラムが実行可能となる脆弱性です。

<XSSのイメージ>

この例では、ログイン時にセッションIDの変更を行っていませんでした。これにより、クロスサイトスクリプティングを利用することでセッション固定化攻撃が可能でした。

---

≪セッション固定化攻撃とは？≫
攻撃者が用意したセッションIDをユーザーに強制し、そのセッションIDを利用したユーザーがログインを行うことで、攻撃者がユーザーのログイン状態を乗っ取る攻撃。

<セッション固定化攻撃のイメージ>

【5】事例を通じたまとめ

一つのケースを通して、脆弱性診断の流れをご紹介しました。
脆弱性には、「うっかりしたミスで生じるもの」と「知識不足や考慮漏れによって設計段階から作り込まれてしまうもの」があります。

前者が見つかった場合には、ミスを防ぐためにどのような体制やプロセスで開発を行うかを見直す契機になります。
後者が見つかった場合には、新たな知見として開発チーム全体のスキル向上につながる可能性があります。

もちろん、脆弱性が検出されないのが理想ですが、検出されたとしても「リリース前に気づけてよかった」「チームの成長につながった」と前向きに捉えることができます。

ご予算やリソースに制限がある中でも「どこから手をつけるべきか」お悩みの企業様にとって、この事例がリスク対策の一歩を踏み出すきっかけになれば幸いです！

皆様からのご相談、お待ちしております！🦁
>>>Webアプリケーション診断の詳細はこちら