Webアプリケーション脆弱性診断とは？主な診断項目と進め方を解説

Webアプリケーション脆弱性診断とは、Webサイトやサービス特有の弱点を洗い出す診断です。見つかる脆弱性の種類、ツール診断だけでは不十分な理由、診断範囲の決め方、事前準備まで整理しました。

自社でWebサイトやWebサービスを運営しており、Webアプリケーション脆弱性診断の依頼を具体的に検討し始めた方の中には、「実際どのような弱点が見つかるのか」「どこまでが診断範囲になるのか」「依頼前に何を準備すればよいのか」がつかめず、見積もり依頼に踏み出せずにいるケースも多いのではないでしょうか。本記事では、代表的な脆弱性の種類から診断範囲の決め方、依頼前の準備までを実務的な観点で解説します。

1. Webアプリケーション脆弱性診断とは？Webサイト特有の弱点を洗い出す診断

⑴一言でいうと何をするものか

Webアプリケーション脆弱性診断とは、一言でいえば「Webサイトやサービスのプログラム（アプリケーション）部分に潜む弱点を、擬似的な攻撃を通じて洗い出す診断」です。

ログイン機能や問い合わせフォーム、検索機能、会員ページなど、ユーザーが実際に操作する画面や機能を対象に、機密情報の漏えいやなりすまし、データの改ざん、フィッシングへの悪用といった被害の糸口になり得る弱点がないかを確認します。

なお、脆弱性そのものの定義や、放置した場合にどのようなリスクにつながるのかといった基礎的な内容については、本記事では詳しく触れません。

基本から知りたい方は、別記事[脆弱性診断とは？必要性と放置するリスクを初心者向けに解説]をご覧ください。本記事は、依頼を具体的に検討している方に向けて、Webアプリケーション診断特有の実務情報に絞って解説します。

⑵プラットフォーム診断との対象範囲の違い

脆弱性診断を調べていると、「プラットフォーム診断」という言葉も目にすることがあります。両者は対象とする層が異なります。

• Webアプリケーション診断：Webサイトやサービスのアプリケーション層（ログイン処理、フォーム入力、データのやり取りなど）が対象
• プラットフォーム診断：サーバーOS、ミドルウェア、ネットワーク機器など、アプリケーションが動作する土台となるインフラ層が対象

たとえば「入力フォームに不正な文字列を入れたときの挙動」はWebアプリケーション診断の範囲ですが、「サーバーのOSに古いバージョンの脆弱性が残っていないか」はプラットフォーム診断の範囲になります。両方を実施して初めて、Webサービス全体をカバーできると考えるとイメージしやすいでしょう。

2. Webアプリケーション診断で見つかる代表的な脆弱性

⑴SQLインジェクション

SQLインジェクションとは、データベースへの命令文（SQL）を操作する不正な文字列を入力フォームなどから送り込み、データベースを不正に操作されてしまう脆弱性です。入力値のチェックが不十分な場合に発生します。

放置すると、会員情報や決済情報など、データベースに保存された情報が第三者に閲覧・改ざん・削除されるリスクがあります。個人情報の大規模な漏えいにつながった事例も多く、代表的かつ影響の大きい脆弱性のひとつです。

⑵クロスサイトスクリプティング（XSS）

クロスサイトスクリプティング（XSS）とは、Webページに悪意のあるスクリプト（プログラムの命令文）を埋め込まれ、そのページを閲覧した別のユーザーのブラウザ上で不正なスクリプトが実行されてしまう脆弱性です。

放置すると、サイト訪問者のクッキー情報（ログイン状態を保持する情報）が盗まれてなりすましログインされたり、偽の入力画面が表示されて個人情報を騙し取られたりするリスクがあります。掲示板やコメント欄、検索結果表示画面など、ユーザーの入力内容がそのまま画面に表示される機能で特に注意が必要です。

⑶認証・セッション管理の不備

認証（ログイン処理）やセッション管理（ログイン状態を維持する仕組み）に不備があると、パスワードが単純な文字列でも制限なく試行できてしまったり、ログイン中であることを示す情報が第三者に推測・盗用されてしまったりします。

放置すると、他人のアカウントに不正ログインされ、個人情報の閲覧や不正な操作を許してしまうリスクがあります。パスワードの試行回数制限や、ログアウト後のセッション情報の無効化などが適切に実装されているかが確認ポイントです。

⑷アクセス制御の不備

アクセス制御の不備とは、本来その権限を持つユーザーしか見られない・操作できないはずの画面や機能に、権限のないユーザーがアクセスできてしまう不備です。

放置すると、一般ユーザーが管理者専用画面を閲覧できてしまったり、他人の会員情報を不正に閲覧・変更できてしまったりするリスクがあります。特にURLやパラメータを直接書き換えることで到達できてしまうケースが多く、見落とされがちな脆弱性です。

⑸設定不備による情報の露出

サーバーやアプリケーションの設定が不十分なために、本来公開すべきでない情報（エラーメッセージに含まれる内部情報、設定ファイル、バックアップファイルなど）が外部から閲覧可能な状態になっているケースもあります。

放置すると、システムの内部構成やソフトウェアのバージョン情報が攻撃者に把握され、他の脆弱性を突く際の手がかりとして悪用されるリスクがあります。地味に見えて、被害の入り口になりやすい不備です。

3. なぜWebアプリはツール診断だけでは不十分なのか

⑴ツール診断で検出できる範囲

自動ツールによる診断（ツール診断）は、あらかじめ登録された既知のパターンに基づいて機械的に脆弱性を検出する方法です。SQLインジェクションやXSSなど、パターン化しやすい脆弱性については幅広い画面を短時間・低コストでスキャンできる点が強みです。

⑵ビジネスロジックの不備は自動検出が難しい

一方で、そのWebサービス固有の業務ルール（ビジネスロジック）に起因する不備は、自動ツールでは検出が難しいとされています。たとえば「本来は自分の注文情報しか見られないはずが、URLのパラメータの数字を書き換えるだけで他人の注文情報が閲覧できてしまう」といった不備は、ツールにとっては「正常に画面が表示された」だけの結果に見えてしまうため、機械的な判定では発見しにくいのです。

このような不備を見抜くには、診断員が実際に画面を操作しながら、業務の流れやデータの持ち主の関係性を踏まえて手動で確認する必要があります。

⑶実務での組み合わせ方

実務では、ツール診断と手動診断を組み合わせるのが一般的です。ツール診断で既知のパターンに基づく脆弱性を効率的に洗い出したうえで、ログイン後の会員専用機能や決済フローなど、業務ロジックが絡む重要な機能については手動診断で重点的に確認する、という使い分けが行われます。

診断会社に依頼する際は、どこまでを手動で確認してもらえるのかを確認しておくとよいでしょう。

4. 診断範囲はどう決まる？見積もり依頼前に整理すべきこと

⑴画面数・リクエスト数という数え方

Webアプリケーション診断の見積もりは、多くの場合「画面数」や「リクエスト数」を基準に算出されます。画面数とは、診断対象となるページや機能の数です。リクエスト数とは、その画面の中でサーバーとやり取りが発生する処理（フォーム送信、検索実行、データ取得など）の数を指し、1画面の中に複数のリクエストが存在することも珍しくありません。

見積もり依頼前に、対象サイトの画面遷移図やサイトマップを用意し、大まかな画面数を把握しておくと、見積もりの精度が上がりスムーズに話が進みます。

⑵認証の有無で変わる診断範囲

同じ1画面でも、ログイン不要な画面（誰でも見られる公開ページ）とログイン後にしかアクセスできない画面（会員専用ページ）とでは、必要な工数が異なります。ログイン後の画面は、会員種別や権限ごとの見え方の違いを確認する必要があり、確認項目が増える傾向にあります。

見積もり依頼の際は、「一般ユーザー」「管理者」など権限の種類ごとに、どの画面が存在するのかを整理しておくと、診断会社側も適切な見積もりを出しやすくなります。

⑶範囲から外すと危険な箇所

見積もりを抑えたい意図から、一部の画面を診断範囲から外してしまうケースがありますが、以下のような箇所は見落とされがちである一方、攻撃の標的になりやすいため注意が必要です。

• 管理画面：一般ユーザーからは見えにくい分、対策が手薄になりがちで、乗っ取られた場合の被害が大きい
• 外部連携API：決済代行サービスや外部システムとのデータ連携部分。想定外のデータが送られたときの挙動が確認されていないことが多い
• 会員登録・パスワード再設定機能：個人情報や認証情報を直接扱う機能でありながら、後回しにされやすい

これらを範囲から除外する場合は、その分のリスクをどう補うか（別途診断する、監視を強化するなど）を診断会社と相談しておくことをおすすめします。

5. 診断前に準備すべき5つのこと

⑴診断環境の用意（本番環境かステージング環境か）

診断は、実際に稼働している本番環境で行うか、本番同等の構成を持つステージング環境（テスト用の環境）で行うかを事前に決めておく必要があります。本番環境で行う場合は実際のユーザーへの影響（表示の乱れや処理の遅延など）が懸念され、ステージング環境で行う場合は本番環境との差異が診断結果に影響しないよう構成をそろえておく必要があります。どちらを選ぶにせよ、事前にメリット・デメリットを整理しておきましょう。

⑵テストアカウントの発行

会員専用ページや管理画面など、ログインが必要な機能を診断してもらう場合は、診断員が使用するテスト用アカウントを事前に発行しておく必要があります。可能であれば、一般ユーザー・管理者など権限ごとに複数アカウントを用意しておくと、権限差による見え方の違いまで確認してもらいやすくなります。

⑶WAFなど防御機構の扱い

WAF（Web Application Firewall、Webアプリケーションを保護するための防御機構）を導入している場合、稼働させたまま診断すると、擬似的な攻撃通信がWAFにブロックされてしまい、本来検出されるべき脆弱性が見逃される可能性があります。診断中はWAFを一時的に無効化する、または診断員のIPアドレスを許可リストに登録するといった対応を、事前に社内および運用委託先と調整しておく必要があります。

⑷関係先への事前連絡（クラウド事業者・開発委託先）

診断中は擬似的な攻撃に近い通信が短時間に大量発生するため、事前に連絡をしていないと、クラウド事業者（AWSやさくらインターネットなど）から不審なアクセスとして検知され、通信を遮断されたりアカウントを一時停止されたりするトラブルにつながることがあります。開発を外部委託している場合は、委託先にも診断日時と内容を共有し、当日問い合わせが来た際に対応できる体制を整えておくと安心です。

⑸バックアップとスケジュールの調整

診断中の操作によって、意図せずデータが変更・削除される可能性はゼロではありません。診断前には必ずデータベースやファイルのバックアップを取得しておきましょう。また、アクセスの多い時間帯を避けて診断のスケジュールを組む、社内の繁忙期と重ならないよう調整するといった配慮も、トラブルを避けるうえで重要です。

6. よくある質問（FAQ）

⑴本番環境で診断しても問題ないか

本番環境での診断は可能ですが、擬似的な攻撃通信によって処理が重くなったり、想定外の挙動が発生したりするリスクはゼロではありません。アクセスの少ない深夜・休日など時間帯を調整すること、事前に社内外の関係先へ連絡しておくことをセットで対応すれば、リスクを抑えて実施できます。

⑵改修のたびに診断が必要か

大規模な機能追加や、ログイン・決済まわりなど重要な機能を改修した場合は、その都度診断を受けることが推奨されます。軽微な表示崩れの修正など影響範囲が小さい改修であれば、必ずしも毎回診断が必要とは限りません。改修内容ごとに診断会社に相談し、必要性を判断するとよいでしょう。

⑶費用はどれくらいかかるか

費用は画面数・リクエスト数、認証の有無、手動診断の比率などによって変動するため一概には言えませんが、対象範囲を絞った小規模な診断であれば数十万円程度、画面数の多いサービス全体を対象とする場合はそれ以上になる傾向があります。あくまで目安であり、正確な費用は見積もり依頼時に確認する必要があります。

⑷無料のツールで代用できるか

無料のツールでも、既知のパターンに基づく一部の脆弱性は検出できます。ただし、ビジネスロジックの不備など手動での確認が必要な項目は検出が難しく、検出精度や対象範囲にも限界があります。簡易的な自己点検には活用できますが、依頼を具体的に検討している段階であれば、専門の診断会社による診断と組み合わせることをおすすめします。

7. まとめ

Webアプリケーション脆弱性診断では、SQLインジェクションやクロスサイトスクリプティングをはじめとする代表的な脆弱性を、ツール診断と手動診断を組み合わせて洗い出します。

診断範囲は画面数・リクエスト数や認証の有無で変わり、管理画面や外部連携APIなど見落としがちな箇所には特に注意が必要です。診断環境の選定やテストアカウントの発行、関係先への事前連絡といった準備を整えたうえで依頼することで、スムーズかつ効果的な診断につながります。