令和6年度 秋期 情報処理安全確保支援士試験 午後 問4｜情報処理安全確保支援士に学ぶ：軽微な脆弱性の連鎖が個人情報大量漏えいを招くWebサイト診断事例【令和6年秋 午後問4】

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

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

• 出典: 令和6年度 秋期 情報処理安全確保支援士試験 午後 問4

• 主なテーマ: セキュリティ診断、複数脆弱性の連鎖、WebAPIの認可不備、推測可能な識別子、セッションフィクセーション、メールヘッダーインジェクション、HTTPセキュリティヘッダー、多要素認証

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

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

セキュリティの世界では「単体では大したことのない不備」が、組み合わさった瞬間に「会社の屋台骨を揺るがす大事故」へと姿を変えることがあります。脆弱性診断（システムに潜むセキュリティ上の弱点を専門家やツールで洗い出す作業）の報告書を見て、「重要度が低いものばかりだから、後回しでいい」と判断してしまう。そんな現場の油断が、実は最も危険です。

情報処理安全確保支援士試験の令和6年度秋期 午後問4は、まさにこのテーマを正面から扱っています。転職支援Webサイトをリリース前に診断したところ、見つかったのは「推測しやすいID」「ログイン後にセッションIDが変わらない」「ある画面で通知メールが送られない」といった、一見地味な不備ばかり。ところが、それらをパズルのように組み合わせると、攻撃者は求人企業になりすまし、最終的に大量の求職者の個人情報を抜き取れてしまうのです。

この記事では、この事例を一つのセキュリティインシデントの物語として読み解きながら、なぜその攻撃が成立するのか、そして公式解答例がなぜその答えになるのかを丁寧に説明します。試験対策としてはもちろん、リリース前診断にどれだけの価値があるのかを経営判断の視点でも捉え直せる内容にしました。

インシデントの概要

舞台となるのは、転職支援サービスを運営するM社の「Mサイト」です。Mサイトは、転職を考える求職者と、人材を探す求人企業の双方が利用します。

求職者は、氏名・自宅住所・電話番号・勤務先といった「求職者属性情報」と、希望職種や希望条件などの「求職情報」を入力します。一方の求人企業は、会社情報・求人情報・採用担当者の氏名や所属部署などを登録します。これらの情報はすべてMサイトのデータベースに蓄積され、その内容をもとにMサイトが求職者と求人企業のマッチングを行います。求職者は、提案された企業へ問合せや応募ができる仕組みです。

ここで重要なのは、Mサイトが扱う情報の中身です。求職者属性情報には、自宅住所や電話番号、現在の勤務先まで含まれます。これは漏えいすれば一発で深刻な被害につながる、極めてセンシティブな個人情報です。

M社は今回、機能を追加した新バージョンのWebアプリケーションプログラム（以下、Webアプリ）と、求人企業が自社のシステムからHTTPS（通信内容を暗号化するWebのセキュアなプロトコルHTTPS）経由で呼び出すことを想定した新しいインタフェース「WebAPI」（プログラム同士が決められた手順でデータをやり取りするための窓口）を開発し終えたところでした。まだ一般公開していない、リリース前のタイミングです。

そこでM社は、セキュリティ診断サービスを手がけるB社に、Mサイトの診断を依頼しました。診断対象はあえて本番環境ではなく、本番と同じ構成でテスト用の疑似データを入れた「検証用サイト」です。B社の診断員は、自社内の診断用PCからインターネット越しに、Webアプリの脆弱性とWebサーバ基盤（プラットフォーム）の脆弱性を調べました。Webアプリの診断は、診断ツールによる自動検査と、診断員の手作業の両方で行われた点が、この事例のポイントになります。

何が起きたのか

診断が始まると、B社の診断員はまずWebアプリの作りを丁寧に追いかけました。やがて報告書には三つの脆弱性が並びます。「セッションフィクセーション」「メールヘッダーインジェクション」「HTTPヘッダーの不備」。どれも単独で見れば「すぐに会社が潰れる」ような派手なものではありません。むしろ、診断の現場では日常的に見かける顔ぶれです。

しかし診断員は、これらを一つずつ報告して終わりにはしませんでした。「これらを順番につなげたら、攻撃者はどこまで行けるのか」を、攻撃者の視点で組み立てていったのです。ここからが、この物語の本番です。

最初の入口は、セッションフィクセーション（攻撃者があらかじめ用意したセッションIDを被害者に使わせ、被害者がそのIDのままログインした後に乗っ取る攻撃）でした。セッションIDとは、ログイン状態を保つためにサーバが利用者へ割り当てる「整理番号」のようなものです。本来は、ログインに成功した瞬間に新しい番号へ振り直すのが鉄則です。ところがMサイトは、画面遷移を重ねてもセッションIDの値が同じままでした。つまり、攻撃者が事前に知っている番号のまま、被害者がログインしてしまうのです。

攻撃者の段取りはこうです。まず、ある求人企業の登録メールアドレスを何らかの方法で入手します。次にログイン画面のURLへアクセスし、自分用のセッションIDを一つ手に入れます。そして、そのセッションIDを埋め込んだ罠のページを用意し、「読み込んだ瞬間に被害者のブラウザからログイン画面へ送信される」仕掛けを仕込みます。この罠ページへのリンクをメールで送り、被害者が踏むのを待つ。被害者が罠を踏んでログインすれば、その認証済みセッションは攻撃者が知っている番号と結びつきます。あとは攻撃者が同じ番号で乗り込むだけ。こうして攻撃者は、求人企業になりすましてMサイトに不正ログインできてしまいました。

この時点でも、攻撃者は応募者確認や問合せ確認の画面から、その企業に応募・問合せした求職者の属性情報をのぞき見できます。十分に深刻です。しかし診断員が描いた攻撃シナリオは、ここで止まりません。「もっと多くの求職者情報を、しかも気付かれずに抜き取る」道筋が見えていたのです。

次に攻撃者が使ったのが、メールヘッダーインジェクション（メール本文や件名の入力欄に改行コードなどを紛れ込ませ、宛先や追加ヘッダーを不正に差し込む攻撃）です。Mサイトの求人企業プロパティ変更画面には、会社名・部署名・メールアドレスなどの入力欄があります。攻撃者は会社名の欄に、改行コードを使って「宛先（To）を攻撃者のメールアドレスにする」細工文字列を入力しました。

ここで効いてくるのが、Mサイトの通知メールの仕様です。本来、登録メールアドレスを変更すると、Mサイトは変更前のメールアドレス宛てに確認用URLを記したメールを送り、確認後には変更前・変更後の両方へ通知メールを送ります。これは「勝手に書き換えられたら気付けるように」という安全装置です。ところが会社名に仕込まれた細工のせいで、この確認メールは本来の宛先である正規の企業ではなく、攻撃者のメールアドレスにだけ届くようになってしまいました。正規の企業は、自分の登録情報が書き換えられようとしていることに、まったく気付けません。

攻撃者は確認用URLを自分で受け取って踏み、登録メールアドレスを自分のものへ変更します。そして別の端末からログイン画面の「パスワード再設定」を実行。パスワード再設定用のURLは登録メールアドレス、つまりもう攻撃者の手元に送られてきます。攻撃者は新しいパスワードを設定し、正々堂々と（しかし不正に）ログインし直しました。これで、セッション乗っ取りという「借り物」の状態ではなく、パスワードまで握った「完全な乗っ取り」が完成します。

仕上げはWebAPIです。攻撃者はAPIkey管理画面から、新しく握ったパスワードを使ってAPIkey（WebAPIを呼び出すときに正規利用者であることを示す鍵）を確認、あるいは発行します。さらにMサイトの求職者IDが「登録年月日8桁＋当日の連番6桁」という、誰でも推測できる規則で作られていたことが致命傷でした。WebAPIには「任意の求職者IDを指定すれば、その求職者の属性情報を取得できる」機能があります。推測でIDを次々に作り出せるなら、攻撃者は自社に応募・問合せした求職者だけでなく、無関係な多数の求職者の個人情報まで根こそぎ抜き取れてしまうのです。

一つ一つは軽微だった不備が、入口から出口まで一本の線でつながった瞬間、被害は「ある企業の応募者情報の盗み見」から「サイト全体の求職者個人情報の大量漏えい」へと膨れ上がりました。これがB社の報告書が突き付けた、最も重い警告でした。