令和7年度 秋期 情報処理安全確保支援士試験 午後 問1｜タスク名に仕込まれた権限昇格——情報処理安全確保支援士で学ぶCSPと蓄積型XSSのSaaS侵害事例

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

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

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

• 主なテーマ: 蓄積型（格納型）XSS、CSP（コンテンツセキュリティポリシー）、同一オリジンを悪用したスクリプト読み込み、CSRFトークン窃取、権限昇格、ファイルアップロード検証、出力エスケープ、脆弱性検査

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

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

「CSPを入れたから、外部サイトからのスクリプト読み込みは防げている」——SaaS（インターネット経由でソフトウェア機能を提供するサービス）を運営する企業では、こうした安心感を口にすることがあります。ところが情報処理安全確保支援士試験の令和7年度秋期・午後 問1が示すのは、防御の焦点が外に向いているとき、攻撃は内側——自社ドメイン上に置かれたファイルと、エスケープされていない画面出力——へと移る、という現実です。

退職者のPCに残った未参加プロジェクトのファイル、タスク名というごく小さな入力欄、管理者が日常のように開く進捗管理画面。バラバラに見える要素が、蓄積型XSS（サーバに保存されたスクリプトが、後から画面を開いた利用者のブラウザで実行される攻撃）と権限変更APIをつないで、一気に「管理者権限の奪取」へと進みます。

この記事では、H社のSaaS「Sサービス」を舞台に、なぜCSPだけでは足りなかったのか、攻撃者がどの経路で管理者のブラウザを乗っ取り、一般利用者を管理者ロールに昇格させたのか、そして拡張子と中身の整合チェック・出力エスケープ・専門家による脆弱性検査という三層の対策が試験でどう問われたかを、一つのインシデント事例として読み解きます。

インシデントの概要

舞台は、クラウド上で業務支援SaaSを提供するH社と、その利用企業であるB社です。H社の主力サービス「Sサービス」は、プロジェクト管理やファイル共有、タスク管理などをブラウザ上で行える業務アプリケーションです。利用企業はテナント（契約単位の利用区画）ごとにプロジェクトを作成し、メンバーを割り当てて共同作業します。

B社では、情報システム部がSサービスの導入・運用を担当していました。ある時期、退職した社員ZのPCを処分する前の確認作業のなかで、セキュリティ担当者はふと気づきます。Zが参加していないはずのプロジェクトのファイルが、ZのPCのローカルに残っている——。本来アクセス権のないプロジェクトのデータが、端末にコピーされた形跡があるのです。これはSサービス側の権限管理や端末管理の話として別途検討が必要な問題でしたが、本問の主戦場は、その後に顕在化するWebアプリケーションの脆弱性にあります。

H社はSサービスに対し、コンテンツセキュリティポリシー（CSP。ブラウザに「どの出所のコンテンツだけを読み込んでよいか」を指示するセキュリティヘッダ）を設定していました。ポリシーの `default-src 'self'` は、原則として自サービスのドメイン（同一オリジン）以外からのスクリプトや画像などの読み込みを拒否します。攻撃者が外部の悪意あるサイトにスクリプトを置いて誘導する、いわゆる外部ホスティング型のXSS対策としては有効です。しかし同時に、「自社ドメイン上にファイルを置き、そこから読み込ませる」という別ルートの防御は、別の対策がなければ残ってしまいます。

何が起きたのか

攻撃の準備は、一見するとごく当たり前の操作から始まります。攻撃者は、Sサービスが提供するファイルアップロード機能を使い、拡張子が `.xlsx` のファイルをサーバにアップロードします。表計算ソフト向けの形式に見えるこのファイル（例として問題文では `F1234567890.xlsx`）の中身には、実際にはJavaScript（ブラウザ上で動くプログラム）が埋め込まれていました。サーバはファイル名の拡張子だけを見て「Excelファイル」として受け入れ、同一オリジンの `/files/` 配下などに保存したのです。

次の一手が、この事例の肝です。攻撃者はタスク登録機能を使い、タスク名の入力欄に次のような文字列を仕込みます。

`<script src=/files/F1234567890.xlsx></script>`

タスク名は、利用者がプロジェクトの作業項目を識別するための短いラベルです。普通は「設計レビュー」「障害対応」といった平文が入る場所です。ところがSサービスは、この文字列を後から画面に出力するとき、HTML（Webページの構造を記述する言語）としてそのまま解釈してしまう脆弱性——いわゆる蓄積型XSS——を抱えていました。`script` 要素（外部ファイルを読み込んで実行するHTMLタグ）がタスク名として保存され、エスケープ（`<` や `>` などを無害な文字列に変換する処理）されずに管理者画面へ流れ込むのです。

ここでCSPの `default-src 'self'` が効いてくる、というより「効かない側面」が問われます。外部ドメインの `https://攻撃者.example/evil.js` のような読み込みは拒否されます。しかし `src=/files/F1234567890.xlsx` は、あくまでSサービス自身のオリジンからの読み込みです。CSPの視点では「自サイトのリソース」であり、ブロックの対象になりません。だから試験の設問1では、外部サイトに攻撃用スクリプトを置いて誘導する対策案（空欄a・b）は「できない」と判断されるのです。防御の前提が「外部からの混入を防ぐ」に寄っているとき、内部に置かれたファイル＋同一オリジン読み込みという筋道は、別の穴になります。

被害が決定的になるのは、管理者の日常業務です。B社の管理者は、プロジェクトの進捗を確認するため、Sサービスの「プロジェクト進捗管理」画面を開きます。画面には各タスクの名前が一覧表示されます。タスク名に仕込まれた `script` タグがHTMLとして出力された瞬間、管理者のブラウザ上で `/files/F1234567890.xlsx` がスクリプトとして解釈・実行されます。管理者は何もクリックしていないのに、自分のセッション（ログイン状態を表す一時的な識別子）のもとでスクリプトが動き始める——これが蓄積型XSSの怖ろしさです。

ファイルの中に書かれていたJavaScriptは、まず画面内に埋め込まれているCSRFトークン（クロスサイトリクエストフォージェリ対策用の、一度限りの引換券のような値）を読み取ります。続けて、管理者権限が必要なAPIである `/management/roleset` へPOSTリクエスト（データを送信する通信）を送ります。パラメータには `is_admin=1` と、昇格させたい利用者ID `user_id=U00331001` が含まれます。トークンが正しく付与されたリクエストは、サーバから見れば「今画面を開いている管理者本人が承認した操作」に見える。結果として、一般利用者だった `U00331001` のロール（権限の種類）が管理者に書き換えられてしまうのです。

攻撃の流れを問題文の図4に沿って言い換えると、次の六段階になります。ファイルのアップロード、タスク名（文字列項目）への登録、管理者による進捗管理画面の閲覧、HTMLとしての出力、スクリプトの実行、そしてロール変更——入力から権限昇格までが一本の鎖としてつながっています。締切日を過ぎたタスクであっても、一覧に表示されれば閲覧のトリガーにはなる、という運用上の細部も設問2の空欄fで押さえどころになっています。