令和3年度 秋期 情報処理安全確保支援士試験 午後Ⅱ 問1｜XSSフィルタからCSPへ、そしてSaaS移行へ——情報処理安全確保支援士で学ぶファイル交換システムのセキュリティインシデント事例

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

• 試験区分: 情報処理安全確保支援士
• 出典: 令和3年度 秋期 情報処理安全確保支援士試験 午後Ⅱ 問1
• 主なテーマ: クロスサイトスクリプティング（XSS）対策、CSP（Content-Security-Policy）、SaaS移行のリスク分析、クラウドのデータ主権、ログによる不正アクセス検知、多要素認証、FIDO認証、生体認証

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

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

「自社で作ったWebアプリを、そろそろクラウドサービス（SaaS）に置き換えたい」——多くの企業が直面している、ごくありふれた検討課題です。情報処理安全確保支援士試験の午後Ⅱで出題されたこのセキュリティインシデント事例は、まさにその「移行の意思決定」を、現場のセキュリティ担当者の目線で丁寧に追いかけています。

舞台は、協力会社とのファイルのやり取りを支える社内システム。ある日、トップページが書き換えられるという改ざん事件が起き、調べていくうちに「そもそも誰がどこからアクセスしているのかを誰も確認していなかった」という運用の穴が次々に明らかになります。さらに脆弱性診断を受けるとXSS（クロスサイトスクリプティング。詳しくは後述します）の弱点が見つかり、その対策として、かつての主流だった「XSSフィルタ」ではなく、より新しいCSP（Content-Security-Policy）という仕組みへ移行していく流れが描かれます。

そして物語は、SaaSへの乗り換え検討へと進みます。便利そうに見えるクラウドサービスを採用する前に、何をどこまで確認すべきか。海外のデータセンタに保存されたファイルは、本当に自社の支配下にあると言えるのか。パスワードだけの認証で不正アクセスを見抜けるのか。この記事を読むと、XSS対策の考え方、SaaS移行で見落としがちなリスク、そして多要素認証や生体認証をどう組み合わせるかが、ひとつながりのストーリーとして理解できるはずです。受験対策としてはもちろん、クラウド移行を判断する立場の方にとっても、実務に直結する判断軸が得られます。

インシデントの概要

舞台となるのは、従業員1万人を抱える半導体製造業のU社です。国内に工場を持ち、いくつかの製造工程を国内40社の協力会社に委託しています。協力会社とは、生産計画や設計書類のファイルを日常的にやり取りする必要がありました。受渡し件数は協力会社によって異なり、1日あたり1件から10件ほど。決して大量ではありませんが、止まると生産に直結する、地味で重要な業務です。

このファイルのやり取りを担っていたのが、「Dシステム」と呼ばれるWebベースのファイル交換システムでした。Dシステムは、HTTPサーバ（Webページを配信するサーバ）と、U社が自社開発したWebアプリケーションプログラム（以下、Uアプリ）から構成されています。U社の生産管理課と、各協力会社に置かれた「ファイル受渡し用PC」から、HTTPS（通信内容を暗号化したWebアクセス）でアクセスする仕組みです。

セキュリティ面の建て付けとしては、U社ネットワーク内からDシステムにアクセスできる端末は、ファイアウォール（FW。通信を許可・遮断する関所のような機器）の設定で生産管理課のファイル受渡し用PCだけに絞られていました。アカウントは協力会社の拠点ごとに一つ、U社が発行します。利用者認証は、利用者IDとパスワードによるものでした。

ここまで読むと、それなりに守られているように見えます。ところが、この「見えている対策」の裏側に、誰も確認していなかった大きな空白が潜んでいました。

何が起きたのか

ある日のことです。Dシステムのトップページが、何者かによって改ざんされました。本来表示されるべき画面が、別の内容に書き換えられていたのです。U社が調査を進めると、原因はHTTPサーバの「既知の脆弱性」でした。つまり、すでに世の中に知られていて、修正プログラム（パッチ）も出ていた弱点を、放置していたところを突かれたのです。U社は脆弱性修正プログラムを適用し、ひとまずトップページは復旧しました。

しかし、本当に怖いのはここからでした。インシデントの調査を進める過程で、担当者はHTTPサーバのアクセスログ（誰がいつどこからアクセスしたかの記録）を丹念に洗っていきます。すると、協力会社であるP社に発行したアカウントを使って、海外のIPアドレス（インターネット上の住所にあたる番号）からアクセスした履歴が見つかったのです。

国内の協力会社のアカウントが、なぜ海外から使われているのか。利用規約や法令に違反しているおそれがある——担当者の背筋に緊張が走ります。すぐにP社へ問い合わせると、答えは拍子抜けするほど単純でした。P社の従業員の一人が、海外出張先からDシステムにアクセスしていたのです。悪意のある第三者による乗っ取りではありませんでした。

それでも、これは見過ごせない問題でした。Dシステムの利用規約では、ファイル受渡し用PCについて、各協力会社の社内に設置すること、盗難対策・マルウェア対策・ファイルの不正持出し対策を施すことを求めていました。さらに、Dシステムへは「ファイル受渡し用PCからだけ」アクセスすることも求めていたのです。ところがU社は、これらの遵守状況を、一度も確認していませんでした。ルールはあったが、守られているかを誰も見ていなかった——典型的な「運用の形骸化」です。

P社の従業員は出張先のPCから、本来許されない経路でアクセスできてしまった。それは、規約を破ろうという強い悪意があったというより、「技術的に止められていなかったから、できてしまった」という性質のものでした。もしこのアカウント情報が出張先の不特定のPCに残っていたら、あるいは本物の攻撃者に渡っていたら、と考えると、肝が冷える話です。

U社はこの利用規約違反への対策として、まず海外からのアクセスをFWで禁止しました。そして、協力会社以外からのアクセスを検知するために、SIEM（Security Information and Event Management。各種機器のログを一カ所に集めて相関分析し、不審な動きを見つけ出す仕組み）を導入します。事後にログを眺めるのではなく、おかしなアクセスを能動的に見つけにいく体制へと舵を切ったのです。

ここでU社は立ち止まります。トップページ改ざんは既知の脆弱性が原因でした。では、Dシステムには他にも危険な脆弱性が眠っているのではないか。そこでセキュリティ専門会社のN社に脆弱性診断を依頼しました。診断の結果、浮かび上がってきたのが、XSS（Cross-Site Scripting。クロスサイトスクリプティング。攻撃者が用意した不正なスクリプトを、利用者のWebブラウザ上で実行させてしまう脆弱性）でした。

N社の診断は、地味ですが本質を突いた手順で進みます。診断員は、Dシステムの「備考などの入力画面（画面A）」と「入力後の確認画面（画面B）」に注目しました。画面Aでは、フォルダ名やファイル名に加えて「備考」と「参考URL」を入力できます。入力後、画面Bでその内容が確認用に表示され、参考URLはクリックできるリンクとして出力されます。

診断員はまず、備考欄に当たる`description`というパラメタ（Webアプリに渡す入力値）に`<script>alert('XSS!')</script>`という、いかにもXSSを狙った文字列を含むURLを入力しました。もしこの文字列がそのままHTMLとして画面に出力されれば、ブラウザはそれをスクリプトとして解釈し、`alert`（画面に小さなダイアログを出す命令）が実行されてしまいます。攻撃が成立すれば「XSS!」という文字が書かれたダイアログボックスが現れるはずです。

ところが、サーバからの応答（HTTPレスポンスのボディ部）を見ると、`<`や`>`といった記号が、そのままの形ではなく別の表記に変換されていました。具体的には、HTMLで特別な意味を持つ「より小さい記号」と「より大きい記号」が、ブラウザにタグとして解釈されない安全な文字列に置き換えられていたのです。これを「エスケープ処理」と呼びます。備考欄の出力については、エスケープ処理が正しく行われており、XSS脆弱性は認められませんでした。一カ所目は、シロ。

しかし、参考URL（`refURL`パラメタ）の方は違いました。診断員が別の値を入力し、画面Bに表示された参考URLのリンクをクリックすると——「XSS!」のダイアログボックスが、ぽんと表示されたのです。リンクのクリックという、利用者がごく自然に行う操作によって、不正なスクリプトが動いてしまった。`refURL`の値をリンクとして出力する処理に、明確な欠陥がありました。

N社はさらに踏み込みます。この脆弱性の原因は、二つの誤りのどちらかだろうと見立てました。一つは「XSSを防ぐ処理を一切していない」というケース。もう一つは「基本的なエスケープ処理はしているが、HTMLタグの属性値（たとえばリンクの飛び先を指定する`href`の中身）を出力するときに必要な処理が抜けている」というケースです。どちらなのかを切り分けるため、診断員はさらに巧妙な診断用の入力を送り込み、応答を分析していきました。結論として、Uアプリは記号のエスケープ自体はしているものの、リンクの飛び先として「`javascript:`で始まる、スクリプトを実行するための特殊な飛び先」をそのまま受け入れて出力してしまう、という弱点を抱えていたのです。エスケープしていても、危険なURL自体を弾いていなければ、クリック一発でスクリプトが走ってしまう。これがこの事例のXSSの正体でした。