令和5年度 春期 情報処理安全確保支援士試験 午後 問1｜「診断ツールを買えば安心」の落とし穴——情報処理安全確保支援士で学ぶ脆弱性診断の内製化事例

この記事で扱うセキュリティ事例

• 試験区分: 情報処理安全確保支援士

• 出典: 令和5年度 春期 情報処理安全確保支援士試験 午後Ⅱ 問1

• 主なテーマ: Webサイトの脆弱性診断、DAST（動的アプリケーションセキュリティテスト）、診断ツールの限界、SQLインジェクション検出、XSS、アクセス制御の回避、委託先管理、グループ全体のセキュリティ品質均一化

この記事は「情報処理安全確保支援士 午後問題 全70問」シリーズの1本です。→ 全70問の一覧・テーマ別索引はこちら

導入: なぜこの事例が重要なのか

「脆弱性診断ツールを導入したので、Webサイトの安全は機械が自動でチェックしてくれます」——もしあなたの会社でこう報告されたら、安心してよいでしょうか。

情報処理安全確保支援士試験の令和5年度春期 午後Ⅱ 問1は、まさにその「自動診断への過信」に潜む落とし穴を、ひとつの長い物語として描いた事例です。舞台は、外部の専門業者に任せていた脆弱性診断を自社グループ内で内製化しようとする製造業グループ。診断ツールを買い、手順を作り、実際にWebサイトを診断していく——その一つひとつの工程で、「ツールに任せただけでは脆弱性を見落とす」という現実が次々と顔を出します。

この記事を読むと、診断ツール（DAST）がどんな仕組みで脆弱性を見つけるのか、なぜ同じツールを使っても「検出できる人」と「できない人」に分かれるのか、そして脆弱性診断を自社でやろうとすると技術以外にどんな壁にぶつかるのかが見えてきます。受験者にとっては、SQLインジェクションやXSS、アクセス制御の回避といった頻出論点を「ツールの操作」という具体的な文脈で理解できる教材です。経営者にとっては、グループ会社が増え続けるなかで「セキュリティ品質をどう均一に保つか」「委託コストをどう管理するか」という、極めて現実的な経営課題を考える材料になります。

インシデントの概要

舞台は、全体で従業員2万名を抱える製造業グループ、A社グループです。中心となるA社は技術開発や新製品の製造・販売を行い、その周りに特定型の製品を手がける複数の子会社（以下、グループ各社）がぶら下がっています。A社にもグループ各社にも、それぞれ多数のWebサイトがありました。

A社には、CISO（最高情報セキュリティ責任者）が率いるセキュリティ推進部があります。この部門は、A社の情報セキュリティマネジメントを統括し、重要なWebサイトの脆弱性診断（以下、診断）を管理し、グループ各社には情報セキュリティポリシーやセキュアコーディング規約（プログラムを安全に書くための社内ルール）を配布していました。ただし、A社自身の重要なWebサイトの診断は、セキュリティ専門業者であるB社に委託していました。新規リリース前に診断し、その後も年1回診断する——その実務はすべてB社頼みだったのです。一方、グループ各社が診断をするかどうか、何を診断するかは、各社の判断に任されていました。

ここに、経営陣がざわつき始める変化が訪れます。IoT製品（インターネットにつながる機器）の市場拡大により、グループ各社が新しいWebサイトを次々と立ち上げるようになったのです。A社の経営陣は、「グループ各社のWebサイトのセキュリティは十分なのか」と懸念し始めました。そこで、グループ各社の重要なWebサイトも、A社のセキュリティ推進部がグループ各社と協議しながら診断を管理することになりました。

ところが、診断を委託していたB社に相談すると、思わぬ答えが返ってきます。「同じ時期にたくさんの診断を一度に依頼されても、対応しきれない可能性があります」——。グループ全社のWebサイトを外部1社に投げるには、もはや量が多すぎたのです。

そこでA社は、グループ各社の一部のWebサイトの診断を、自社グループ内で実施できるようにする「内製化推進プロジェクト」（以下、Sプロジェクト）を立ち上げます。担当に選ばれたのは、これまでもB社への診断依頼を担い、診断の準備から結果報告までをおおむね把握していたセキュリティ推進部のZさん。支援役として、B社のセキュリティコンサルタントで情報処理安全確保支援士（登録セキスペ）であるY氏が付きました。

つまりこれは、攻撃を受けて情報が漏れたという「事故」の物語ではありません。「診断を外注から内製に切り替える過程で、自動診断ツールの落とし穴に次々と気づいていく」——いわば、見えていなかったリスクが工程ごとに姿を現していく物語なのです。

何が起きたのか

Sプロジェクトは、6つのフェーズで進められました。診断項目を決め（フェーズ1）、診断ツールを選び（フェーズ2）、ZさんとB社で同じサイトを診断して結果を比べ（フェーズ3）、A社グループ向けの診断手順案を作り（フェーズ4）、その手順案に従って実際に診断し（フェーズ5）、最後に正式な診断手順を制定する（フェーズ6）。一見すると、きれいに整理された段取りです。しかし、その各段階で「ツール任せの落とし穴」が顔を出します。

選ばれた診断ツールは、B社も使っている「ツールV」でした。ツールVはDAST（Dynamic Application Security Testing。動的アプリケーションセキュリティテスト。実際にHTTPリクエストを送り、その応答を見て脆弱性の有無を判定する方式）のツールです。パラメータ（Webサイトに送る入力値）を初期値からいろいろな値に変えてリクエストを送り、返ってきた応答を見て脆弱性を判定します。

物語が最初の壁にぶつかったのは、フェーズ3でした。Zさんは、グループ会社K社のアンケートサイト（以下、サイトM）を診断し、その結果をB社の診断結果と突き合わせます。すると、Zさんの診断は脆弱性の一部を検出できていませんでした。見落とした脆弱性は二つ。アンケート入力画面の入力値に起因するクロスサイトスクリプティング（以下、XSS。Webページに悪意あるスクリプトを埋め込む攻撃）と、トピック検索画面の入力値に起因するSQLインジェクション（データベースへの命令文を不正に注入する攻撃）です。

同じツールVを使っているのに、なぜB社は検出できてZさんは検出できなかったのか。ここに、自動診断の核心があります。

まずSQLインジェクションの方を見てみましょう。トピック検索画面では、入力した検索ワードが「keyword」というパラメータに入ります。ツールVは、このkeywordの値を細工して送り、返ってくる検索結果の件数の違いから脆弱性を見抜こうとします。

B社は、keywordの初期値を「manual」に設定していました。普通に `keyword=manual` を送ると、検索結果は10件返ってきます。そこにSQLの構文を壊す細工——シングルクォート1個だけ——を加えて `keyword=manual'` を送ると、結果は0件。SQL文がエラーになった証拠です。さらにツールVは、検索結果が「真（正しい条件）」になる細工と「偽（成り立たない条件）」になる細工を送り分けます。「常に真」になる条件を加えると10件、「常に偽」になる条件を加えると0件。この 【10件と0件という応答の差】 こそが、「入力値がそのままSQL文に組み込まれている＝SQLインジェクションの脆弱性がある」という決定的な証拠でした。

ところがZさんは、keywordの初期値を「xyz」に設定していました。`keyword=xyz` をそのまま送っても、検索結果は最初から0件。そこに真の条件を加えても0件、偽の条件を加えても0件——何をしても0件のまま、差が出ません。応答に差が出なければ、ツールVは「ここは大丈夫」と判定してしまう。Zさんが脆弱性を見落とした理由は、ツールの性能ではなく、【与えた初期値が悪かった】 からだったのです。Y氏は「ツールVは、Webサイトに応じた初期値を設定する必要があるのです」と指摘しました。検索すれば1件以上ヒットする「manual」のような値を初期値にしなければ、真と偽の差が現れず、診断が成立しないわけです。

もう一つのXSSの見落としは、画面遷移が絡む厄介なものでした。サイトMでは、アンケート入力1→アンケート入力2→アンケート確認→送信完了、と画面が進みます。入力したスクリプトは、入力したその画面ではなく「二つ先の画面」でエスケープ処理（記号を無害な文字列に変換する処理）されずに出力されていました。ツールVは原則として、リクエストを送った診断対象URLの応答だけを見て判定します。入力した画面の応答だけ見ても、二つ先の画面に現れる問題は見つからない。ここを検出するには、ツールVの「診断対象URL拡張機能」を設定し、入力画面のURLだけでなく、出力先である確認画面のURLも判定対象に含めてやる必要がありました。具体的には、アンケート入力1からアンケート入力2へ遷移するURLの拡張機能に、アンケート確認のURLを登録するのです。

こうしてZさんは、「ツールは魔法の箱ではない。サイトの構造を理解して正しく設定して初めて、本当の脆弱性が見える」ことを学びます。

フェーズ5では、舞台が会員サイト（以下、サイトN）に移り、新たな落とし穴が現れます。サイトNは既にリリース済みで、会員はいくつかのグループに分けられ、申し込めるキャンペーンが所属グループによって異なる、という複雑なサイトでした。

まずZさんは、診断に必要な情報（診断対象URL、アカウントなど）をK社に確認しようとしますが、サイトNの情報が一元管理されていなかったため、回答を得るまでに1週間もかかってしまいます。「診断を始めるまでに、こんなに時間がかかるのか」——これが一つ目の課題として残りました。

次に、ツールVの自動登録機能を使い、トップページから自動探査で診断対象URLを集めようとしますが、ここでも一部のURLが登録されませんでした。自動登録は作業者の手間がほぼ不要で便利な反面、遷移先URLがJavaScriptで動的に生成されるような場合や、必須入力項目に適切な値を入れられず正常に画面遷移できない場合に、登録が漏れることがあるのです。漏れたURLは、手動で一つずつ登録するしかありませんでした。

さらにY氏は、診断実施前に重要な注意点を指摘します。「特定のパラメータが同じ値であるリクエストを複数回送信するとエラーになり、遷移できない箇所があるので注意してください」。サイトNには、同じアカウントでパスワードを連続5回間違えるとアカウントがロックされる仕組みや、1会員につき1回しか申し込めないキャンペーンがありました。診断ツールは同じパラメータで何度もリクエストを送るため、放っておくとアカウントがロックされたり、申込み済みでエラーになったりして、その先を診断できなくなります。そこでツールVの「拒否回避機能」を設定し、これらの箇所をうまく回避しながら診断を進めました。

そして診断の結果、サイトNからは二つの脆弱性が検出されます。XSSと、アクセス制御の回避です。

XSSについては、検出された脆弱性をサイトNの開発部門（以下、開発部N）に通知したところ、開発部Nから「cookieにHttpOnly属性（スクリプトからcookieを読み取れなくする設定）が付いているので、HTMLの中のスクリプトからcookieへアクセスすることが禁止される。だからcookieが漏えいすることはなく、修正は不要だ」という回答が返ってきます。Zさんはこの回答をY氏に相談し、こう開発部Nに伝え直しました。「XSSを悪用してもcookieを盗めないのは確かです。しかし、XSSを悪用してcookie以外の情報を盗む攻撃があるので、修正は必要です」。XSSの危険性をcookie漏えいだけに限定する見方は、危ういのです。

アクセス制御の回避は、もっと生々しい問題でした。サイトNにログインすると、その会員が所属するグループを識別するための「group_code」というパラメータがリクエストに追加されます。ある会員Nが、このgroup_codeを削除したリクエスト——アクセス制御を回避するように細工されたリクエスト——を送ると、本来その会員は見られないはずのキャンペーンへのリンクが表示され、しかもリンクをたどってそのキャンペーンに申し込めてしまったのです。正常なリクエストには `group_code=0001&keyword=new` のように所属を示す値が入っていましたが、それを抜くだけで、全グループ向けのキャンペーン一覧（A社・B社・C社・Z社向けまで）が丸見えになりました。

開発部Nは、この穴をふさぐため、リクエスト中のJSESSIONID（ログイン時に発行されるセッションID。誰がアクセスしているかを識別する値）からログイン中の会員Nを特定し、その会員が本当に所属しているグループがgroup_codeの値と一致するかをサーバ側で検証するよう、ソースコードを修正することにしました。クライアントから来たgroup_codeを鵜呑みにせず、サーバが管理する「本当の所属」と突き合わせる——これがアクセス制御の正しい姿です。

開発部Nは無事に対応を終えましたが、ここでもう一つの課題が浮上します。診断結果について開発部NがB社へ頻繁に問い合わせた結果、B社のサポート費用が高額になってしまったのです。B社のサポートは問合せ件数に比例するチケット制で、グループ各社が個別に問い合わせれば、その分だけ費用がかさみます。「内製化したのに、結局B社への問合せでコストが膨らむ」——この費用の課題が、最後まで残りました。

最終のフェーズ6で、Zさんはフェーズ5で残った二つの課題（診断開始までの時間と、B社サポート費用）への対策を検討し、グループ各社の同意を得たうえで、A社グループの診断手順を正式に制定します。セキュリティ推進部は、その手順をグループ各社に展開していきました。