こんにちは、mokakoです。
今回は情報処理安全確保支援士試験の平成31年度 春期 午後Ⅰ 問1を解説していきたいと思います！
※この解説ブログでは、あくまでも私自身が解いた備忘録となりますので、間違いなどを発見された場合はどうぞ教えていただけますと幸いです。
下記より問題文と解答を引用しております。
問題
出典：平成31年度 春期 情報処理安全確保支援士試験 午後Ⅰ 問1
https://www.jitec.ipa.go.jp/1_04hanni_sukiru/mondai_kaitou_2019h31_1/2019h31h_sc_pm1_qs.pdf
解答
https://www.jitec.ipa.go.jp/1_04hanni_sukiru/mondai_kaitou_2019h31_1/2019h31h_sc_pm1_ans.pdf
では早速解説してまいります！
設問1
(1)a. Same-Origin
解説
前後の文脈を見ると、「スクリプトZは、【a】ポリシによって、【b】、【c】、【d】のいずれかが異なるリソースへのアクセスが制限される」とあります。また前提として、WebサイトBからWebサイトAへの情報連携機能の実装についての検討をしているので、検討を進めるにあたって考慮しなくてはならないポリシが入ると推測できます。
Same-Originポリシ（同一生成元ポリシ）とは、URLを構成する、スキーム、FQDN、ポートの3つがすべて一致した場合のみ、アクセスを許可するというポリシです。問題文冒頭を見ると、WebサイトAのURLは、https://site-a.m-sha.co.jp/、WebサイトBのURLは、https://site-b.m-sha.co.jp/です。二つのURLを見比べると、FQDNが異なることが分かります。つまり、何も処置を施さない場合、スクリプトZにて、WebサイトBからWebサイトAへの情報連携をしたいときに、Same-Originポリシ（同一生成元ポリシ）によってリソースがアクセス制限されてしまいます。
(2)b. イ c. キ d. ク
解説
【b】【c】【d】には、【a】Same-Originポリシが同一のオリジンかそうでないかを判断するための3つの要素が入ります。(1)でも解説したように、Same-Originポリシでは、スキーム、FQDN、ポートの3つが判断するための要素になります。これらのうち一つでも異なっていたら、異なるオリジンと判断され、リソースへのアクセスは制限されます。
なお、スキーム、ホスト、ポートをプー太’s blogのURLに当てはめると以下のようになります。
※ポート番号はウェルノウンポート番号のため省略されています。
(3)WebサイトBへのログイン
解説
前後の文脈を見ると、「被害者に①特定の操作をさせた上で、そのページにアクセスさせると、攻撃者が被害者の会員情報を窃取できてしまう。」とあります。ある状態でWebサイトにアクセスすると会員情報を窃取されてしまうのです。
図1を見ると（Y-6）で会員情報がWebブラウザに表示されています。（Y）の流れを最初から見ると、（Y-1）で会員が売れ筋商品情報配信の申込ページにアクセスしていますが、ここで注2)に注目します。
「会員がWebサイトBにログインした状態の時にアクセスする」という記述より、会員がWebサイトBへログインした状態の時に（Y）のプロセスが進み、（Y-6)で会員情報が表示されてしまうのです。そのため、この問題ではWebサイトBへのログインが正解となります。
設問2
e. （ⅴ）
解説
前後の文脈を見ると、「図3であれば、【e】の動作の際に、test2.example.comから発行されたCookieが送られる。」とあります。これは難しいですが、消去法で考えたいと思います。まず、test2.example.comから発行されたCookieなので、test1.example.comとのやりとりである（ⅰ）と（ⅱ）は消えます。
次にこの段落の一番最初に「また、CORSでは通常、Webブラウザは、スクリプトを読み込んだページのオリジンだけにCookieや、ベーシック認証の情報を送る。」とあります。つまり、Webブラウザからtest2.example.comへ送られていると予想できるので、（ⅳ）と（ⅵ）も消えます。
最後に（ⅲ）か（ⅴ）です。設問3を解いてからだとなんとなく分かるかもしれませんが、プリフライトリクエストは基本的に許可を取るためのリクエストでCookieなどの情報を送信することはありません。そのため、（ⅴ）が正解となります。
設問3
(1)f. https://site-a.m-sha.co.jp
解説
前後の文脈を見ると、「API-Yは、送られてきたリクエストにOriginヘッダフィールドが存在する場合、Access-Control-Allow-Originヘッダフィールドを付加し、レスポンスを返す。Access-Control-Allow-Originヘッダフィールドの値は、”【f】”である。」とあります。これだけでは分からないので、表1のNo.3を読みます。「プリフライトリクエストは、OPTIONSメソッドの呼び出しであり、Originヘッダフィールドには”https://site-a.m-sha.co.jp”が設定されている。」とあります。
よく分からないと思った方も、この問題は、[CORSの概要]を参考に解くことができます。図3のtest1.example.com（略してウェブサイトtest1）がウェブサイトA、test2.example.com（略してウェブサイトtest2）がウェブサイトBに対応しています。
今回の問題で問われている表1のNo.3,4は、プリフライトリクエストをウェブサイトBに送信し、そのレスポンスがブラウザに返ってくる流れなので、図3の（ⅲ）（ⅳ）に対応していることが分かります。
図4からOriginに設定されているのはウェブサイトtest1のオリジンです。（ⅳ）それに対するレスポンスとして図5に注目するとAccess-Control-Allow-Originヘッダには再びウェブサイトtest1のオリジンが設定されています。かなりざっくり理解すると、Same-Originポリシによって異なるリソースへのアクセスを制御していますが、ウェブサイトBに対し（リソースの異なる）ウェブサイトAのアクセスの許可を得ているという感じです。（詳しくは、別記事で説明しようと思います。）
表1のNo.3に戻ると、Originヘッダフィールドには、”https://site-a.m-sha.co.jp”が設定されています。そのため、API-YはAccess-Control-Allow-Originヘッダに、”https://site-a.m-sha.co.jp”を入れてWebブラウザにレスポンスを返すことが分かります。
(2)g. 売れ筋商品情報配信の申込ページのオリジン
解説
前後の文脈を見ると、「Webブラウザは、【g】とAccess-Control-Allow-Originヘッダフィールドの値を照合し、アクセスが許可されていることを確認する。」とあります。今回、プリフライトリクエストのOriginヘッダフィールドに、アクセスしたい売れ筋商品情報配信の申込ページのオリジンをセットしてAPI-Yへ渡し、返ってきたAccess-Control-Allow-Originヘッダフィールドに入っている値と照合した結果、一致したらアクセスできるという流れになっています。そのため、売れ筋商品情報配信の申込ページのオリジンが答えになります。
(3)h. Originヘッダフィールドの値
i. 許可するオリジンのリスト
j. 一致
解説
前後の文脈を見ると、「プリフライトリクエスト又はメインリクエストがWeb APIに送られてきた時に、そのリクエスト中の【h】を、【i】と突合し、【j】した値があればその値をAccess-Control-Allow-Originヘッダフィールドに設定すると言う内容もコーディング規約に含めればよいだろう。」とあります。
(1)や(2)を解いてきたように、Originヘッダフィールドにはアクセスしたいサイトのオリジンが、Access-Control-Allow-Originヘッダフィールドにはアクセス許可されているサイトのオリジンが入っているはずです。Access-Control-Allow-Originヘッダフィールドには1つしかオリジンを指定できません、今回問われている複数のオリジンからのアクセスを許可できる仕様にするには、どうしたらよいのでしょうか。
ヒントとして、D課長の、「Web APIのプログラム内に、許可するオリジンのリストを用意しておく必要がある。」という台詞があります。許可するオリジンのリストをあらかじめ用意しておく、でもAccess-Control-Allow-Originヘッダフィールドには1つしかオリジンを指定できない、ということを頭に入れて考えると、リクエストされてきたサイトがアクセス許可されているかはAPI-Yのプログラムの中で判断。許可されていたら、ブラウザにそのサイトが許可されていることを伝える（その値をAccess-Control-Allow-Originヘッダフィールドに設定する）という仕様であれば、実現できそうです。
API-Yのプログラムの中で判断する部分を整理すると、Originヘッダフィールドの値が許可するオリジンのリストの中のどれかに一致するかを検証することで許可されているか判断ができます。よって解答のようになります。
コメント