情報処理安全確保支援士試験 令和4年度 春期 午後2 問1
【出典：情報処理安全確保支援士試験 令和4年度 春期 午後2 問1（一部、加工あり）】
[サイトZのSSRF脆弱性]
サイトZでは、最近、新機能が開発された。新機能の一つである、旅行会社P社の宿泊サイト（以下、P社宿泊サイトという）との連携機能でSSRF脆弱性が検出された。その機能は、駅名を入力すると、その駅近辺のホテルの割引クーポンなどの”お得情報”を表示できるというものである。利用者が、P社宿泊サイトに登録されている駅名の一つ、”東京”を入力したときの流れを図5に、登録されていない架空の駅名である”abc”を入力したときの流れを図6に、D社の専門技術者V氏がSSRF脆弱性を検出した手順を表4に示す。
表4の手順によって、V氏は、Authorizationヘッダの値を受け取ることができた。P社の協力の下、この値を用いることで、本来許可なしではアクセスできないP社宿泊サイトや同じAuthorizationヘッダの値を利用するP社保有のサーバへのアクセスが可能になることを確認した。
D社からは、P社宿泊サイトからのレスポンスに含まれるURLが想定されたものかを調べて想定外の値の場合はそのURLにはアクセスしないようにするという、SSRF脆弱性への対策が提案された。加えて、④別の対策も実施することが望ましいとのことであった。
Rさんは、D社の脆弱性診断で検出された脆弱性について、B社の開発部のE課長に報告した。その後、B社の開発部によって対策が実施され、D社による再度の脆弱性診断で問題が修正されたことが確認された。
k：V氏が用意したサイト
「P社宿泊サイトは、Locationヘッダに（k）のURLを含めたレスポンスをサイトZに返す。」
「サイトZは、受け取ったレスポンスを基に、（k）にリクエストを送る。」
表4（SSRF脆弱性を検出した手順）から、V氏が施した手順としては順序1の「P社宿泊サイトに登録されていない駅名、例えば、”abc”を入力し、Hostヘッダの値を、V氏が用意したFQDNに変更して、サイトZにリクエストを送る」になります。
例えばHostヘッダの値を「xxx.co.jp」とした場合、図6（登録されていない駅名である”abc”を入力したときの流れ）の⑴の利用者からサイトZに送信されるデータは、「GET /station/abc HTTP/1.1」「Host:xxx.co.jp」となります。
そして、⑵のサイトZからP社宿泊サイトに送信されるデータは、「GET /station/abc?returnURL=https://xxx.co.jp/error HTTP/1.1」「Authentication:Basic（省略）」となります。
⑶ではP社宿泊サイトからサイトZに、ReturnURLで指定された「https://xxx.co.jp/error」をLocationヘッダにセットして送信され、⑷でLocationヘッダの「https://xxx.co.jp/error」に接続されることになります。
こうして利用者の認証情報がV氏が用意したサイトに送信されることになります。
下線④について、別の対策とは何か。B社で実施することが望ましい対策を、25字以内で述べよ。：returnURLの値を固定値にする。
「D社からは、P社宿泊サイトからのレスポンスに含まれるURLが想定されたものかを調べて想定外の値の場合はそのURLにはアクセスしないようにするという、SSRF脆弱性への対策が提案された。加えて、④別の対策も実施することが望ましいとのことであった。」
この記述の前半部分「P社宿泊サイトからのレスポンスに含まれるURL」は、図5（登録されている駅名である”東京”を入力したときの流れ）の⑵の「returnURL」のことで、それはサイトZ内のホスト（z.b-sha.co.jp）を想定しているにも関わらず、⑴のHostヘッダの値を使用し不正に指定できるものでした。
したがって、このURLが想定外の値の場合はURLにアクセスしないようにするとうことです。
さらに、別の対策として考えられることは、returnURLの値が想定されているのであれば、その値を固定値にするということが考えられます。