A 社は，従業員 1,500 名の中堅システム開発会社である。A 社では，セキュリティ品質の高い Web サイトを開発するために，表 1 に示す Web セキュリティ管理基準を定めて運用している。
表1 Web セキュリティ管理基準（抜粋）
〔A 社による B 社の子会社化〕
B 社は，従業員 200 名の新興の IT サービス会社であり，各種 SaaS を提供している。アジャイル開発の能力が高く，機能の追加や性能の改善を頻繁に行っている。B 社と A 社とは協業関係にあったが，両社の経営陣は，双方の強みを生かせると判断し，A 社による B 社の子会社化について合意した。
B 社のクラウド環境には，コーポレートサイト（以下，サイト B という），及び B 社が提供中の三つの SaaS それぞれの Web サイト（以下，サイト X，サイト Y，サイト Z という）がある。それらの概要を表 2 に示す。
表2 B 社の Web サイトの概要
子会社化に当たって，B 社の Web サイトのセキュリティ水準を確認することになり，A 社の品質管理部でセキュリティ技術を担当している R さんが対応することになった。
〔B 社の Web サイトのセキュリティ水準の確認〕
R さんは，サイト B，サイト X，サイト Y 及びサイト Z に対する脆弱性診断を D 社に依頼した。診断の結果，検出された脆弱性を表 3 に示す。
表3 検出された脆弱性（抜粋）
〔サイト B の XSS 脆弱性〕
D 社は，サイト B に①診断用リクエストを送ることで，XSS 脆弱性があることを確認した。このリクエストは，ライブラリ M を使ってプログラム C が処理する。ライブラリ M のコードを図 1 に示す。
図1 ライブラリ M のコード
ライブラリ M は，SEO のためのライブラリである。
B 社では，開発部のメンバそれぞれが，開発時に利用可能なライブラリを収集している。使用するライブラリは，マルウェアが含まれていない，既知の脆弱性が修正された，安全性が確認できているライブラリを公開している Web サイトから，ファイルサーバにダウンロードし，利用している。ファイルサーバは，開発部のメンバであればアクセス可能である。
今回使われていたライブラリ M は，既知の XSS 脆弱性の対策をしていないバージョンであった。その結果，ライブラリ M を使っているサイト B，サイト X，サイト Y 及びサイト Z において，同じ XSS 脆弱性が検出された。
これを受けて，B 社における②再発防止策について検討した。
〔サイト X の CSRF 脆弱性〕
サイト X は，セッション ID を JSESSIONID という cookie に格納している。D 社は，サイト X のキャンペーン応募ページで CSRF 脆弱性を検出した。
CSRF 脆弱性を確認した手順は，次のとおりであった。
(1) 診断用利用者（以下，利用者 A という）の利用者 ID でサイト X にログインし，キャンペーン応募ページで送信されるリクエストの内容をツールを使って確認した。リクエストの内容を図 2 に示す。
表 4 の手順によって，V 氏は，Authorization ヘッダの値を受け取ることができた。P 社の協力の下，この値を用いることで，本来許可なしではアクセスできない P 社宿泊サイトや同じ Authorization ヘッダの値を利用する P 社保有のサーバへのアクセスが可能になることを確認した。
D 社からは，P 社宿泊サイトからのレスポンスに含まれる URL が想定されたものかを調べて想定外の値の場合はその URL にはアクセスしないようにするという，SSRF 脆弱性への対策が提案された。加えて，④別の対策も実施することが望ましいとのことであった。
R さんは，D 社の脆弱性診断で検出された脆弱性について，B 社の開発部の E 課長に報告した。その後，B 社の開発部によって対策が実施され，D 社による再度の脆弱性診断で問題が修正されたことが確認された。
〔開発プロセスの見直し〕
B 社の Web サイトのセキュリティ水準について，R さんは，開発プロセスの観点からも調査を進めた。
B 社では，顧客に機能の追加要望や性能の改善要望をヒアリングしながら，開発部内で目標を設定し，アジャイル開発を行っている。また，社外の研修などでセキュアプログラミングの知識を習得し，その知識を生かして Web サイトを開発している。
B 社の開発プロセスの概要を図 7 に示す。
図7 B 社の開発プロセスの概要
R さんは，B 社の Web サイトのセキュリティ水準を十分なものにするためには，A 社のような Web セキュリティ管理基準を B 社に導入する必要があると考えた。次は，B 社の開発プロセスについての R さんと E 課長の会話である。
R さん：B 社でも表 1 のとおりに実施できますか。
E 課長：開発フェーズにおいてはできると思います。しかし，改良リリースの周期は 2 週間程度です。専門技術者による脆弱性診断には，その周期の大半を費やしてしまうので，省略できないでしょうか。
R さん：⑤ソースコードレビューやツールによる脆弱性診断では発見できないが，専門技術者による脆弱性診断では発見できる脆弱性が多くあります。専門技術者による脆弱性診断を改良リリースにおいて毎回実施できない場合でも，当該診断が長期間行われないことを避けるために，⑥時期を決めて実施することや，⑦開発プロセスを見直すことを検討してみてください。
E 課長：分かりました。そのほかに，アジャイル開発に合った脆弱性対策はないでしょうか。
R さん：Web サイトの実装に必要となる一般的な機能や定型コードを，ライブラリとしてあらかじめ用意したフレームワークには，⑧脆弱性対策が組み込まれていて，それがデフォルトで有効になっているものもあるので，利用を検討してみてください。
イは先頭の " が無いので属性が閉じず，注入した文字列が content の値の一部になるだけで，タグを挿入できない。リクエストラインが GET か POST かと，属性を閉じる " の有無の両方を見る点が，間違えやすい。
設問1(2)35字以内
本文中の下線②について，考えられる再発防止策を，35 字以内で述べよ。
解答例（2通り）
ダウンロードするライブラリに既知の脆弱性がないかを確認する。
特定のWebサイトからの入手をルール化し，明文化する。
解説
本文の根拠
〔サイト B の XSS 脆弱性〕
使用するライブラリは，マルウェアが含まれていない，既知の脆弱性が修正された，安全性が確認できているライブラリを公開している Web サイトから，ファイルサーバにダウンロードし，利用している。
〔サイト B の XSS 脆弱性〕
今回使われていたライブラリ M は，既知の XSS 脆弱性の対策をしていないバージョンであった。
〔サイト B の XSS 脆弱性〕
ファイルサーバは，開発部のメンバであればアクセス可能である。
B 社の方針は，“既知の脆弱性が修正された，安全性が確認できているライブラリ”だけを使うことである。それにもかかわらず，既知の XSS 脆弱性が残るバージョンのライブラリ M が使われた。つまり，方針はあっても，開発部のメンバ一人一人が収集する運用で，ダウンロードのたびに脆弱性の有無を確かめる手順や，入手元の取り決めが無かったと読める。
再発防止策は，この運用の抜けを塞ぐものになる。一つは，ダウンロードするライブラリに既知の脆弱性がないかを確認すること。もう一つは，入手してよい Web サイトを特定し，それをルールとして明文化することである。解答例は，どちらか一方で正解となる別解である。
利用者 B でログインしたまま，リクエストの csrftoken だけを利用者 A のものに差し替えても，処理は成功し，利用者 B として扱われた。サーバは csrftoken が“発行された有効な値か”だけを見ており，“今ログインしている利用者のものか”を確かめていないことになる。これでは，攻撃者が自分のアカウントで取得したトークンを，罠のリクエストに付けて使えてしまう。
CSRF 対策のトークンは，発行した相手（利用者）に結び付けて検証する。ひも付ける先は，利用者を特定する値であるセッションオブジェクト（サーバ側のセッションにトークンを保存して比較する形）か，利用者 ID である。解答例の a と b は順不同なので，この二つが入っていればよい。この方式は OWASP の CSRF Prevention Cheat Sheet でも，セッションに結び付けたトークンを使う方法として説明されている。
セッション ID（JSESSIONID の cookie）そのものも，利用者に固有の値だが，今回の問いでは“ひも付けられていない”ことを，利用者 ID かセッションオブジェクトで答える点に注意する。
GET /news?topic=https://www.a-sha.co.jp/news/20220417.html HTTP/1.1
表2 サイト Y，Z の注 1)
サイト Y の DB サーバ：https://db-y.b-sha.co.jp/
〔サイト Y の SSRF 脆弱性〕
サイト Y の DB サーバのメンテナンス用の Web インタフェースにアクセスできることを確認した。
サイト Y は，topic パラメタに指定された URL へ，サイト Y 自身がリクエストを送って内容を取得し，表示する。この URL を検証していないのが SSRF 脆弱性である。値を，外部から直接は届かないが，サイト Y（の Web サーバ）からは到達できる内部の URL に変えれば，サイト Y を踏み台にして内部のサーバにアクセスできる。
確認できたのは“サイト Y の DB サーバのメンテナンス用の Web インタフェース”なので，その URL である https://db-y.b-sha.co.jp/ に変えたことになる。DB サーバには，それぞれのサイトの Web サーバがアクセスできると，表 2 の注 1) に書かれている。
45 字以内で，“どの値を”（topic の値），“どのような値に”（https://db-y.b-sha.co.jp/）を，具体的に書く。解答例は 39 字である。サイト X やサイト Z の DB サーバの URL は答えにならない点に注意する。
設問5(1)解答欄1つ
表 4 中の k に入れる適切な字句を，15 字以内で答えよ。
〔k〕解答例
V氏が用意したサイト
解説
本文の根拠
表4 順序1
Host ヘッダの値を，V 氏が用意したサイトの FQDN に変更して，サイト Z にリクエストを送る。
X 社は，従業員 500 名の情報サービス会社であり，5 年前から動画投稿配信サービス（以下，動画サービスという）を提供している。動画サービスは，アカウント登録した会員が動画を投稿したり，投稿された動画を閲覧して評価したりすることができるサービスである。動画サービスは，Web サーバ（以下，動画サービスを提供する Web サーバを X 社動画サーバという）を用いて提供されている。X 社のシステム部は，X 社のシステム全てを管理している。X 社のシステム構成を図 1 に示す。
X 社のシステムでは，動画サービスの人気上昇による会員の増加に伴い，X 社動画サーバの負荷が高くなっており，インターネット回線もひっ迫している。
X 社の経営陣は，この問題への対策と併せて，セキュリティを強化するための抜本的な対策を検討するようシステム部に指示した。システム部の C さんが担当に指名され，セキュリティサービスを提供する W 社から情報処理安全確保支援士（登録セキスペ）の F 氏を招き，助言を受けることになった。
〔抜本的な対策の検討〕
F 氏は，X 社動画サーバをクラウドサービスへ移行し，さらに，Content Delivery Network（CDN）を利用する案を図 2 のように提案した。
図2 X 社動画サーバのクラウドサービスへの移行及び CDN の利用案（抜粋）
次は，図 2 の 2 についての C さんと F 氏の会話である。
C さん：X 社動画サーバでの動画配信に CDN を利用すると，どのように動画が配信されるようになりますか。
F 氏：CDN では，インターネット上に a サーバというサーバを分散配置して，動画配信を要求した端末に最も近い a サーバから動画を配信するようにします。a サーバは，動画配信を要求されたとき，要求された動画を保持していれば代理応答し，保持していなければ動画を保持している X 社動画サーバにアクセスして動画を取得し，応答します。多くの動画配信が代理応答されるので，X 社動画サーバの負荷が軽減されます。
C さん：その仕組みによって，b 攻撃への耐性も向上しますね。X 社動画サーバでの動画配信に CDN を利用するには，どのようにすればよいでしょうか。
F 氏：例えば，M 社が提供している CDN を採用した場合の利用手順は図 3 のようになり，動画配信時の動作は図 4 のようになります。
F 氏：攻撃者サーバに割り当てられた IP アドレスを宛先とする通信を FW で拒否しても，Z-FQDN をプロキシサーバの拒否リストに登録しても，図 5 の(5)の通信は遮断できません。①Y-CDN-U-FQDN を名前解決した IP アドレスを宛先とする通信を FW で拒否すると，複数の Web サイトが閲覧できなくなる影響があります。通信内容を監視して遮断するなどセキュリティ強化を進めている CDN 事業者もありますが，進めていない事業者もあります。X 社では，FW 又はプロキシサーバを，アウトバウンド通信の復号及び高機能な通信解析ができるものに替え，d と HTTP リクエスト中の c ヘッダの値が一致していることを検証して，一致していなければ遮断するという対策を検討してもよいでしょう。
F 氏：幾つかあります。二つ説明しましょう。一つ目は，TGT，ST の偽造攻撃です。TGT 又は ST が偽造されると，サーバが不正アクセスされて危険です。現在，TGT の偽造については，認証サーバ側での対策が進んでいます。一方，②ST の偽造については，認証サーバ側で検知することができません。
C さん：リスクがありますね。
F 氏：二つ目は，サーバ管理者アカウントのパスワードを解読して不正にログインする攻撃です。XPC から ST が奪取され，不正アクセスに悪用されても，不正アクセスされる範囲は限定されます。しかし，奪取された ST に対してサーバ管理者アカウントのパスワードの総当たり攻撃が行われ，それが成功すると，当該サーバ管理者アカウントでアクセスできるサーバが乗っ取られてしまいます。この総当たり攻撃は，③サーバ側でログイン連続失敗時のアカウントロックを有効にしていても対策になりません。
C さん：分かりました。
〔SaaS での SSO の実現〕
C さんは，GrW 及びメールの SaaS への移行後の SSO の実現方法を F 氏に尋ねた。次は，その際の F 氏と C さんの会話である。
F 氏：二つあります。一つ目は，クロスサイトリクエストフォージェリ（以下，CSRF という）攻撃についてです。標的となる利用者が重要な秘密を扱う会議の主催者として日程を決定する場合を考えてみましょう。攻撃者は，GrW-G に攻撃者のアカウントを登録し，当該 GrW-G にアクセスするための認可コードを利用者に送付します。そのときに，図 9 の実装に CSRF 脆弱性があり，かつ，利用者の Web ブラウザが攻撃者によって生成された認可コードを受け付けてしまう実装となっている場合，利用者が気付かないうちに攻撃者のアカウントで会議日程が登録されてしまいます。対策として，state パラメタの実装が求められています。適切な実装であれば，図 9 中の o において，state パラメタを付与して送信し，図 9 中の p で送られてきたものと比較することで，攻撃を検知しているはずです。
二つ目は，利用者が S サービスへのアクセスに S サービスのスマホアプリを使う場合についてです。S サービスのスマホアプリをインストールしたスマートフォンに，攻撃者が用意した不正なスマホアプリをインストールしてしまうと，GrW-G にアクセスするための認可コードを，攻撃者のスマホアプリが横取りしてしまうという攻撃があります。
C さん：二つ目の攻撃への対策にはどのようなものがありますか。
F 氏：S サービスのスマホアプリでランダムな検証コードとその値を基にしたチャレンジコードを作成して，そのチャレンジコードを認可要求に追加し，検証コードをトークン要求に追加します。二つのコードを検証することで，検証コードを知らない攻撃者からのトークン要求を排除できます。この仕組みは，q として標準化されています。
C さん：分かりました。
〔企画チームからの要望〕
C さんは，企画チームから要望を受けた。要望は，T 社が運営しているメッセージ投稿サイト（以下，T 社投稿サイトという）と X 社動画サーバとを連携させ，T 社投稿サイトの認証サーバを用いた認証機能，及び T 社投稿サイトの投稿サーバへの自動投稿機能を X 社動画サーバに追加したいというものだった。この要望に対応することで，T 社投稿サイトのアカウントをもつ動画サービスの会員は，T 社投稿サイトにログインすれば X 社動画サーバも利用できる。また，X 社動画サーバに動画を投稿すると，“動画の概要”が T 社投稿サイトに自動で投稿されるようにもできる。C さんは，T 社投稿サイトと X 社動画サーバの連携方法について，F 氏に助言を求めた。次は，その際の F 氏と C さんの会話である。
F 氏：OpenID Connect（以下，OIDC という）を用いれば，T 社投稿サイトと X 社動画サーバを連携できます。例えば，図 10 のような流れです。
図10 OIDC を用いた T 社投稿サイトと X 社動画サーバの連携の流れ
F 氏：認可コードフローの場合，ID トークンは，図 10 中の u で送付されます。ID トークンは，JSON Web Token 形式で表現され，ヘッダ，ペイロード，署名の三つの部分で構成されます。署名は，ヘッダとペイロードに対して，T 社投稿サイトの認証サーバの秘密鍵を使って作成します。署名アルゴリズムは，ヘッダにおいて指定します。ヘッダ，ペイロード，署名は，それぞれ v でエンコードされます。
C さん：T 社投稿サイトでのセキュリティ対策について確認することはありますか。
F 氏：ハイブリッドフローを用いる場合，state パラメタのほか，nonce 値を実装しているかを確認すべきです。まず，nonce 値を生成し，w に含めて送信します。次に，送られてきた x に含まれる nonce 値を検証することで，攻撃者による ID トークンの不正利用を防ぐことができます。
要求された動画を保持していれば代理応答し，保持していなければ動画を保持している X 社動画サーバにアクセスして動画を取得し，応答します。
CDN は，インターネット上にコンテンツのコピーを置くサーバを分散配置し，利用者に近いサーバから配信する仕組みである。そのサーバは，動画を保持していれば代理応答し，無ければ元の X 社動画サーバから取得して応答する，という動きをする。保持した内容を再利用する動作なので，この分散配置するサーバはキャッシュサーバである。
CDN のキャッシュサーバは世界中に分散していて，多数のサーバで要求を受け止める。動画の配信要求が大量に来ても，多くは代理応答で済み，元の X 社動画サーバには届かない。多数の機器から大量の通信を送りつけてサービスを停止させる攻撃は，DDoS 攻撃である。分散した多数のキャッシュサーバで受け止められるので，この攻撃への耐性が高まる。
図 9 では，利用者の端末が最初にサービス要求を送り，リダイレクトの起点となる k がクライアントの S サービス（ウ）。認可要求を受け付け，認可コードを出し，トークンを発行する l が認可サーバの IDaaS-G（イ）。(9) で利用者情報の問合せを受ける m が，リソースサーバの GrW-G（ア）である。
間違えやすいのは，IDaaS-G を“SSO の認証サーバ”と見て k に置くことである。(1) のサービス要求を受けるのは S サービスである。
設問4(2)解答欄1つ
図 9 中の n に入れる適切な流れを解答群の中から選び，記号で答えよ。 解答群 ア～エ（本文末尾の図に示されている）
〔n〕解答例
エ
解説
本文の根拠
表3 項番2
S サービスは，GrW-G から主催者のスケジュールを取得し，空き時間を表示する。
図9
(9) k から m へ利用者情報の問合せ。
(10) までで，S サービス（k）はトークンを得ている。その後，S サービスは，そのトークンを使って GrW-G（m）に主催者のスケジュールの取得を要求し，GrW-G が返す。つまり，(11) スケジュール取得要求は k から m へ，(12) スケジュール情報は m から k へ流れる。これはエである。
ア・イは，利用者の端末が直接 IDaaS-G 又は GrW-G とやり取りする形で，スケジュールの取得は S サービスが行うという表 3 と合わない。ウは，スケジュール情報を持たない認可サーバ（l）にスケジュールを要求する形で，誤りである。
選択肢の矢印の向きと，どのサーバ間の通信かを読む点が要である。
設問4(3)解答欄2つ
本文中の o，p に入れる適切な通信を，図 9 中の(1)～(10)から選び，番号で答えよ。
〔o〕解答例
(2)
〔p〕解答例
(6)
解説
本文の根拠
〔従業員からの要望〕
適切な実装であれば，図 9 中の o において，state パラメタを付与して送信し，図 9 中の p で送られてきたものと比較することで，攻撃を検知しているはずです。
図9
(6) 端末から k へ認可コード。
state パラメタは，OAuth 2.0 の CSRF 対策である（RFC 6749 が，認可要求と認可応答を結び付ける値として説明している）。クライアントは，利用者ごとに推測困難な state を作り，利用者のセッションに保存したうえで，認可要求に付けて送る。認可サーバは，認可コードを返す応答にその値をそのまま付けて返す。クライアントは，受け取った値を，保存しておいた値と比較する。
認可要求は，クライアント（k）がリダイレクトで利用者の端末を認可サーバに向かわせる (2) で作られるので，o は (2) である。認可コードが端末から k に届く (6) で，認可サーバからの応答の state が戻ってくるので，p は (6) である。(3) は利用者の端末からの送信で，k が state を付けて送る通信ではない。
本文中の q に入れる適切な字句を解答群の中から選び，記号で答えよ。 解答群 ア ASLR（Address Space Layout Randomization） イ EIAM（Enterprise Identity and Access Management） ウ PKCE（Proof Key for Code Exchange） エ SCIM（System for Cross-domain Identity Management）
〔q〕解答例
ウ
解説
本文の根拠
〔従業員からの要望〕
S サービスのスマホアプリでランダムな検証コードとその値を基にしたチャレンジコードを作成して，そのチャレンジコードを認可要求に追加し，検証コードをトークン要求に追加します。
検証コード（code verifier）から作ったチャレンジコード（code challenge）を認可要求に付け，検証コードをトークン要求で示す仕組みは，PKCE（Proof Key for Code Exchange，RFC 7636）である。認可コードを横取りした攻撃者は，検証コードを知らないので，トークンを得られない。
アの ASLR はメモリ配置のランダム化，イの EIAM は企業内の ID・アクセス管理，エの SCIM は ID 情報を自動プロビジョニングで同期するための仕様であり，認可コードの横取り対策ではない。
会話文の“検証コード”“チャレンジコード”から PKCE の名前を引けるかが問われている。
設問5(1)解答欄3つ
図 10 中の r～t に入れる適切な字句を解答群の中から選び，記号で答えよ。 解答群 ア IDaaS-G イ S サービス ウ T 社投稿サイトの投稿サーバ エ T 社投稿サイトの認証サーバ オ X 社動画サーバ
〔r〕解答例
オ
〔s〕解答例
エ
〔t〕解答例
ウ
解説
本文の根拠
〔企画チームからの要望〕
T 社投稿サイトの認証サーバを用いた認証機能，及び T 社投稿サイトの投稿サーバへの自動投稿機能を X 社動画サーバに追加したい
図10
r から t へ，API を使った“動画の概要”の投稿。
要望は，X 社動画サーバに，T 社投稿サイトの認証サーバを使った認証と，T 社投稿サイトの投稿サーバへの自動投稿を追加することである。OIDC では，認証を依頼する側（RP）が X 社動画サーバ，認証を行う側（OP）が T 社投稿サイトの認証サーバである。
図 10 では，利用者が最初にサービス要求を送り，リダイレクトの起点となる r が X 社動画サーバ（オ）。認証要求を受け，認可コード・トークン応答を返す s が T 社投稿サイトの認証サーバ（エ）。最後に r から API で“動画の概要”の投稿を受ける t が，T 社投稿サイトの投稿サーバ（ウ）である。
IDaaS-G や S サービスは，図 9 の OAuth 2.0 の登場者で，この要望には出てこない。選択肢のうち使わないものがある点に注意する。
設問5(2)解答欄1つ
本文中の u に入れる適切な通信を，図 10 中の(1)～(8)から選び，番号で答えよ。
〔u〕解答例
(8)
解説
本文の根拠
図10
(7) r から s へトークン要求。(8) s から r へトークン応答。
〔企画チームからの要望〕 F 氏の発言
認可コードフローの場合，ID トークンは，図 10 中の u で送付されます。
OpenID Connect の認可コードフローでは，認可コードを受け取ったクライアントが，トークンエンドポイントにトークン要求を送り，そのレスポンス（トークン応答）で，アクセストークンと ID トークンが返る（OpenID Connect Core）。認可コードを受け取る (6) の時点では，ID トークンはまだ届かない。
