Webセキュリティに関する次の記述を読んで，設問に答えよ。

　D社は，従業員 1,000 名の小売業である。自社のホームページや ECサイトなどの Webサイトについては，Webアプリケーションプログラム（以下，Webアプリという）に対する診断（以下，Webアプリ診断という）を専門会社の Z社に委託して実施している。Webアプリ診断は，Webサイトのリリース前だけではなく，リリース後も定期的に実施している。Z社の Webアプリ診断は，脆弱性診断ツールによるスキャンだけではなく，手動による高度な分析も行う。

〔新たなWebサイトの構築〕

　D社では，新たに ECサイト X（以下，サイトXという）と商品企画サイト Y（以下，サイトYという）を W社が提供するクラウドサービス（以下，クラウドWという）上に構築することになった。
　サイトXでは，D社が取り扱う商品をインターネットを介して会員に販売する予定である。取引は毎月 10,000 件ほどを見込んでいる。サイトYでは，サイトXで販売する新商品の企画・開発を顧客参加型で行う。サイトXとサイトYは，いずれも Webサーバとデータベースサーバ（以下，DBサーバという）で構成する。WebサーバについてはクラウドWの仮想 Webサーバサービスを利用し，DBサーバについてはクラウドWのリレーショナルデータベースサービスを利用する。サイトXとサイトYはいずれも，コンテンツマネジメントシステム（以下，CMSという）を使って構築される。サイトXとサイトYにはいずれも，Webアプリ，HTMLによる静的コンテンツ，DBサーバに格納したデータを使った動的コンテンツなどを用意する。
　D社は，V大学と新商品開発の共同研究を行っている。新商品開発の共同研究では，V大学が運用する情報交換サイト（以下，サイトPという）を利用している。サイトYは，サイトPで取り扱っている情報などを表示する。
　D社は，Webサイト構築に関連するデータやドキュメントの保存場所として，クラウドWのストレージサービス（以下，ストレージWという）を利用する。
　D社は，サイトX及びサイトYの設計書を作成した。設計書のうち，サイトX，サイトY及びサイトPのネットワーク構成を図1に，サーバやサービスの説明を図2に示す。

〔サイトX〕

サイトXには，会員用の利用者アカウントとD社管理者用の利用者アカウントがある。サイトXのログインセッション管理は，cookieパラメータのSESSIONIDで行う。SESSIONIDには，値とSecure属性だけがセットされる。なお，サーバ側のセッションの有効期間は24時間である。設計書のうち，サイトXの機能一覧を表1に示す。

サイト管理機能は，D社の内部ネットワーク以外からも利用する可能性があり，サイトXでは，接続元の制限は行わない。

サイトXとサイトYの構築は順調に進み，D社はリリース前のWebアプリ診断をZ社に委託した。Z社は，サイトXとサイトYそれぞれに対してWebアプリ診断を実施した。

〔サイトXに対するWebアプリ診断〕

サイトXに対するWebアプリ診断では，次の三つの脆弱性が検出された。

• クロスサイトスクリプティング（以下，XSSという）
• クロスサイトリクエストフォージェリ（以下，CSRFという）
• 認可制御の不備

〔XSSについて〕

Z社がXSSを検出した経緯は，次のとおりであった。
(1) 問合せ機能で，脆弱性診断ツールによるリクエストとレスポンスを確認した。
このときのリクエストとレスポンスは，図3のとおりであった。

(2) 図3中のレスポンスボディには，問合せ機能で入力した値は出力されていない。
しかし，Z社は，①設計書を調査した上で手動による分析を行い，図3中のリクエスト内のスクリプトが別の機能の画面に出力されることを確認した。

Z社は，②攻撃者がこのXSSを悪用してサイトX内の全会員の利用者情報を取得する可能性があると説明した。

〔CSRFについて〕

Z社がCSRFを検出した経緯は，次のとおりであった。
(1) 会員機能（編集）において，図4に示すリクエストを送ってその応答を確認した。リクエストは正常に処理された。

(2) リクエスト内のメッセージボディの一部を変更して送り，その応答を確認した。
リクエスト内のメッセージボディと応答は表2のとおりであった。

(3) Z社は，手順1，2の応答が“エラー”であることから一定のCSRF対策ができているが，手順3の応答が“正常に処理”であることから③利用者に被害を与える可能性があると判断した。

Z社は，対策には二つの方法があることを説明した。

• csrf_tokenの処理の修正
• cookieへのSameSite属性の追加

サイトXの構成次第では，SameSite属性をcookieに付与することも有効な対策となり得る。SameSite属性は，Strict，Lax，Noneの三つの値のうちのいずれかを取る。サイトXにログインした利用者のWebブラウザにおいて，サイトX内で遷移する場合と外部WebサイトからサイトXに遷移する場合では，SameSite属性の値によってサイトXのcookie送信の有無が表3のように異なる。

〔認可制御の不備について〕

Z社が認可制御の不備を検出した経緯は，次のとおりであった。
(1) Z社は，利用者α，利用者βという二つの利用者アカウントを用いて，注文履歴を閲覧した際のリクエストを確認した。注文履歴を閲覧した際のリクエストを図5及び図6に示す。

(2) 図5のリクエストのパラメータ order-code の値を図6中の値に改変してリクエストを送った。

(3) 利用者 α が，本来は閲覧できないはずの利用者 β の注文履歴を閲覧できるという攻撃が成功することを確認した。

(4) さらに，ある利用者がほかの利用者が注文した際の order-code を知らなくても，④ある攻撃手法を用いれば攻撃が成功することを確認した。

Z社は，⑤サイトXのWebアプリに追加すべき処理を説明した。

〔サイトYに対するWebアプリ診断〕

サイトYに対するWebアプリ診断では，次の脆弱性が検出された。

• サーバサイドリクエストフォージェリ（以下，SSRFという）

〔SSRFについて〕

Z社がSSRFを検出した経緯は，次のとおりであった。

(1) サイトPの新着情報を取得する際に，利用者のWebブラウザがWebサーバYに送るリクエストを確認したところ，図7のとおりであった。

(2) ⑥図7のリクエストのパラメータの値をWebサーバYのCMSの管理ログイン画面のURLに変更することで，その画面にアクセスできるが，ログインはできないことを確認した。

(3) ⑦図7のリクエストのパラメータの値を別のURLに変更するという方法（以下，方法Fという）でSSRFを悪用して，クレデンシャル情報を取得し，ストレージWから情報を盗み出すことができることを確認した。

(4) IMDSにアクセスする方式を方式1から方式2に変更すると，方法Fではクレデンシャル情報を取得できないので，ストレージWから情報を盗み出すことができない。しかし，図7のリクエストのパラメータの値を変更することで，WebサーバYから送られるリクエストに任意のメソッドの指定及び任意のヘッダの追加ができる方法（以下，方法Gという）がある。方法Gを用いれば，方式2に変更しても，⑧クレデンシャル情報を取得し，ストレージWから情報を盗み出すことができることを確認した。

Z社は，クラウドW上のネットワークでのアクセス制御の設定，及び⑨サイトYのWebアプリに追加すべき処理を提案した。

リリース前の脆弱性診断で検出された脆弱性の対策が全て完了し，サイトXとサイトYは稼働を開始した。