情報処理安全確保支援士 2019年 春期 午後1 問01
Webサイトのセキュリティに関する次の記述を読んで、設問1～3に答えよ。
M社は、従業員数200名の小売業である。コーポレートサイトであるWebサイトA（URLは、https://site-a.m-sha.co.jp/）と、自社の特定のブランドを取り扱うECサイト（以下、ブランドサイトという）を複数運営している。現在運営しているブランドサイトは、WebサイトBからWebサイトFの五つである。Webサイトの開発や運用は自社の開発部で行っている。
WebサイトAは、ブランドサイト全体のポータルサイトでもあり、各ブランドのキャンペーン情報などを掲載している。会員専用の機能は有していない。
WebサイトB（URLは、https://site-b.m-sha.co.jp/）は、ブランドBの商品を扱うECサイトで、会員数は10万名である。WebサイトBでは、Cookieを利用したセッション管理を行っている。
会員情報は、各ブランドサイトで個別に管理している。
〔各ブランドサイトからWebサイトAへの情報連携〕
今回、各ブランドサイトの売上数を基にした、ブランド別の売れ筋商品情報を、WebサイトA上で表示するとともに、希望があれば、各ブランドサイトの会員に電子メールでも定期的に配信することにし、そのために売れ筋商品情報及び会員情報を取得する機能（以下、情報連携機能という）を実装することにした。具体的な機能は次のとおりである。
機能1 WebサイトAが各ブランドサイトの売れ筋商品情報を取得する。
機能2 希望する会員に電子メールを配信するために、WebサイトAは、当該会員の会員情報を取得する。
なお、配信の申込みは、WebサイトA上で行う。
情報連携機能の実装は、開発部のCさんが中心になって進めることになった。まず初めにWebサイトBからWebサイトAへの情報連携を行うために、次の二つのWeb APIをWebサイトBに実装することにした。
・WebサイトBの売れ筋商品情報を取得可能とするためのWeb API（以下、API-Xという）
・WebサイトBの会員情報を取得可能とするためのWeb API（以下、API-Yという）
なお、Web APIで受け渡されるデータは、JSON（JavaScript Object Notation）形式にする。Cさんは、API-Yからブランドサイトの会員情報を取得する際、配信を希望する会員の同意を得たいと考えた。そこで、会員情報の取得には、会員のWebブラウザを経由して行う方式を採用することにした。
WebサイトBからWebサイトAへの情報連携機能を図1に示す。
〔情報連携機能の実装についての検討〕
スクリプトZは、aポリシによって、b、c、dのいずれかが異なるリソースへのアクセスが制限される。そこで、Cさんは、この制限をう回するためにJSONP（JavaScript Object Notation with Padding）を用いることを開発部のD課長に提案した。次は、その時の会話である。
Cさん：API-Yからの会員情報の取得にJSONPを用いるつもりです。
D課長：JSONPは、アクセス先を制限する機能をもたないので、その実装では問題がある。例えば、まず、会員情報を窃取するように攻撃者がスクリプトZを変更して、攻撃者のWebサイトのページに置く。次に、被害者に①特定の操作をさせた上で、そのページにアクセスさせると、攻撃者が被害者の会員情報を窃取できてしまう。
Cさん：JSONPの代わりに何の技術を用いればよいでしょうか。
D課長：CORS（Cross-Origin Resource Sharing）を用いるのがよいだろう。
〔CORSの概要〕
CORSとは、あるWebサイトから他のWebサイトへのアクセスを制御することができる仕組みである。XMLHttpRequestを使って“https://test2.example.com/test”にリクエストを送るスクリプトの例を図2に示す。
また、CORSでは通常、Webブラウザは、スクリプトを読み込んだページのオリジンだけにCookieや、ベーシック認証の情報を送る。図2では設定していないが、XMLHttpRequestのプロパティのwithCredentialsの値がtrueに設定されている場合、図3であれば、eの動作の際に、test2.example.comから発行されたCookieが送られる。
〔CORSを利用した実装〕
Cさんは、スクリプトZの実装にCORSを用いたときの一連の動作を検討し、表1にまとめた。
Cさんは、表1についてD課長に確認した。次は、その時のD課長とCさんの会話である。
D課長：今後、他のシステムでもCORSを利用することが考えられるので、コーディング規約も併せてまとめておきたい。Access-Control-Allow-Originヘッダフィールドに指定できるオリジンは一つだけなので、複数のオリジンからのアクセスを許可するような仕様であった場合に、No.4の内容では不十分である。Web APIのプログラム内に、許可するオリジンのリストを用意しておく必要がある。プリフライトリクエスト又はメインリクエストがWeb APIに送られてきたときに、そのリクエスト中の h を、i と突合し、j した値があればその値をAccess-Control-Allow-Originヘッダフィールドに設定するという内容もコーディング規約に含めればよいだろう。
Cさん：分かりました。
Cさんは、CORSの利用に関するコーディング規約をまとめ、表1をこれに合うように修正し、D課長に再度確認した。修正後の内容で問題ないということだったので、Cさんは実装を行った。
その後、セキュリティ専門業者に脆弱性診断を依頼し、脆弱性が検出されないことを確認した上で、情報連携機能をリリースした。その後、同様に残り四つのブランドサイトからWebサイトAへの情報連携機能も実装した。
設問1：〔情報連携機能の実装についての検討〕について、(1)〜(3)に答えよ。
（1）本文中のaに入れる適切な字句を答えよ。
模範解答
a：Same-Origin
解説
解答の論理構成
- 【問題文】には
“スクリプトZは、aポリシによって、…”
とあります。ここでブラウザ上のスクリプトに対し“ポリシ”と付けてアクセス元を制限する代表的な仕組みは1つしかありません。 - それは“Same-Origin Policy”です。同ポリシは
・スキーム（プロトコル）
・ホスト（ドメイン）
・ポート番号
の3要素のいずれかが異なるときに、スクリプトからのアクセスを禁止します。 - 【問題文】に続く記述でも“この制限をう回するためにJSONP（…）を用いる”とあり、JSONPはまさにSame-Origin制限を回避するために古くから使われてきた技術です。ここからも該当するのがSame-Origin Policyであると論理的に確定できます。
- 以上より、aに入る語は
“Same-Origin”
となります。
誤りやすいポイント
- “CORSポリシ”と誤答するケースが多いですが、CORSは制御ヘッダを用いてアクセスを許可“する”仕組みであり、基底にある制限自体はSame-Origin Policyです。
- “同一生成元ポリシ”と日本語で書いてしまうと【出力仕様】「数字・固有名詞は必ず原文を正確に引用」に反します。問題文では英語表記を想定しています。
- JSONPを見て“クロスドメイン対策”の文脈で思考が先走り、“Cross-Domain Policy”と書く誤りも散見されます。
FAQ
Q: Same-Origin Policy はいつからブラウザに実装されていますか？
A: 初期の Netscape Navigator から導入されており、現行主要ブラウザでも必須のセキュリティモデルです。
A: 初期の Netscape Navigator から導入されており、現行主要ブラウザでも必須のセキュリティモデルです。
Q: Same-Origin Policy はページ間でのリンクや画像読み込みも禁止しますか？
A: 表示読み込み（![]()
やなど）は許可されますが、DOM へ直接アクセスしたり、XMLHttpRequest などでレスポンスの内容を取得することは同一オリジンでなければ制限されます。
A: 表示読み込み（
Q: CORS を使えば Same-Origin Policy を無効化できるのですか？
A: 無効化するのではなく、“Access-Control-Allow-*” ヘッダで許可された範囲だけ Same-Origin Policy の例外を認める仕組みです。ブラウザ側の制限が基盤にある点は変わりません。
A: 無効化するのではなく、“Access-Control-Allow-*” ヘッダで許可された範囲だけ Same-Origin Policy の例外を認める仕組みです。ブラウザ側の制限が基盤にある点は変わりません。
関連キーワード: Same-Origin Policy, CORS, JSONP, オリジン、XMLHttpRequest
設問1：〔情報連携機能の実装についての検討〕について、(1)〜(3)に答えよ。
（2）本文中のb〜dに入れる適切な字句を解答群の中から選び、記号で答えよ。
（b, c, dは順不同）
解答群
ア：Cookie
イ：FQDN
ウ：Locationヘッダフィールド
エ：Refererヘッダフィールド
オ：User-Agentヘッダフィールド
カ：時刻
キ：スキーム
ク：ポート番号
模範解答
b：イ
c：キ
d：ク
解説
解答の論理構成
- 問題文では
“スクリプトZは、aポリシによって、b、c、dのいずれかが異なるリソースへのアクセスが制限される。”
とあります。ここで “aポリシ” は同一生成元ポリシ（Same-Origin Policy）のことです。 - 同一生成元ポリシが比較する 3 要素は
• スキーム（例：https / http）
• ホスト名（FQDN）
• ポート番号
です。いずれかが異なると“オリジンが異なる”と判定され、スクリプトはアクセスできません。 - 解答群を対応させると
• FQDN ⇒ “イ：FQDN”
• スキーム ⇒ “キ：スキーム”
• ポート番号 ⇒ “ク：ポート番号”
となります。したがって
b：イ、c：キ、d：ク が正解です。
誤りやすいポイント
- “パス”や“クエリ文字列”を同一生成元判定に含めてしまう。実際にはスキーム・FQDN・ポート番号のみが対象です。
- “Cookie”や“Refererヘッダフィールド”は同一生成元ポリシに直接関係しません。
- “ホスト名”という言葉を“ドメイン名だけ”と誤解し、サブドメインを区別しないケース。FQDN 全体が比較対象です。
FAQ
Q: 同一生成元ポリシは JavaScript だけに適用されますか？
A: 主にスクリプトによる DOM へのアクセスや XMLHttpRequest などに適用されますが、Cookie 送信制御などブラウザの他機能にも関連します。
A: 主にスクリプトによる DOM へのアクセスや XMLHttpRequest などに適用されますが、Cookie 送信制御などブラウザの他機能にも関連します。
Q: ポート番号が省略されている場合はどう判断されますか？
A: 省略時は既定ポート（http は 80、https は 443）として比較します。既定値が違えばオリジンも異なります。
A: 省略時は既定ポート（http は 80、https は 443）として比較します。既定値が違えばオリジンも異なります。
関連キーワード: 同一生成元ポリシ、クロスオリジン、FQDN, スキーム、ポート番号
設問1：〔情報連携機能の実装についての検討〕について、(1)〜(3)に答えよ。
（3）本文中の下線①について、操作の具体的な内容を、20字以内で答えよ。
模範解答
WebサイトBへのログイン
解説
解答の論理構成
- 【問題文】の会話には「攻撃者がスクリプトZを変更…次に、被害者に①特定の操作をさせた上で、そのページにアクセスさせると、攻撃者が被害者の会員情報を窃取できてしまう。」とあります。
- API-Yは会員の情報を返すため、正規のセッションが確立していることが前提です。
- そのセッションは【問題文】の「WebサイトBでは、Cookieを利用したセッション管理を行っている。」という記述から、Cookieによって識別されることが分かります。
- したがって、攻撃者が情報を盗むには、被害者のWebブラウザに「WebサイトBのセッションCookie」が載った状態にする必要があります。
- セッションCookieを取得するために被害者が行う“特定の操作”とは、WebサイトBへ正規のログインを行い、Cookieを受け取ることです。
- 以上より、下線①の具体的内容は「WebサイトBへのログイン」となります。
誤りやすいポイント
- 「申込ページのボタンを押させる」と誤解しがちですが、申込みはWebサイトA側でありAPI-Yの呼出し条件ではありません。
- 「スクリプトZの実行開始」が操作だと考えがちですが、スクリプトはページ読込み時に自動で動きます。利用者が能動的に行う操作とは区別してください。
- 「別サイト閲覧」など前段階を考慮せず答えると、Cookieによる認証が成立しない点を見落とします。
FAQ
Q: なぜログイン操作だと断定できるのですか？
A: API-Yは会員情報を返しますが、【問題文】に「Cookieを利用したセッション管理」とあるため、Cookieを得るためのログインが不可欠だからです。
A: API-Yは会員情報を返しますが、【問題文】に「Cookieを利用したセッション管理」とあるため、Cookieを得るためのログインが不可欠だからです。
Q: “ブラウザ経由で同意を取る”と書かれていますが、ログインとは無関係ですか？
A: 同意取得は別の要件で、API呼出し時に本人セッションが有効である必要がある点とは切り分けて考えます。
A: 同意取得は別の要件で、API呼出し時に本人セッションが有効である必要がある点とは切り分けて考えます。
Q: JSONPを用いるとなぜ危険なのですか？
A: JSONPはオリジン制御を持たず、ログイン済みCookieが付いたまま攻撃者サイトへAPI-Yを呼び出せるため、会員情報が漏えいします。
A: JSONPはオリジン制御を持たず、ログイン済みCookieが付いたまま攻撃者サイトへAPI-Yを呼び出せるため、会員情報が漏えいします。
関連キーワード: CORS, JSONP, Cookie, セッション管理、同一生成元ポリシ
設問2：
本文中のeに入れる適切な記号を、(iii)〜(vi)の中から選び、答えよ。
模範解答
e：（v）
解説
解答の論理構成
- 問題文は次のように述べています。
――「XMLHttpRequestのプロパティのwithCredentialsの値がtrueに設定されている場合、図3であれば、eの動作の際に、test2.example.comから発行されたCookieが送られる。」
ここで鍵となるのは「Cookieが送られる」タイミングです。 - 図3の一連の動作で、(iii) はプリフライトリクエスト（OPTIONS）、(iv) はそのレスポンス、(v) はメインリクエスト（GET などの本処理）、(vi) はメインリクエストのレスポンスです。
Webブラウザは安全確認のために送るプリフライトリクエストには通常 Cookie を付与しません。Cookie を付けるのは実データを取得・送信する「本番の HTTP 要求」であるメインリクエスト時です。 - したがって、Cookie が送られるのはメインリクエストである (v) のタイミングになり、e に入る記号は「(v)」となります。
誤りやすいポイント
- プリフライトリクエスト (iii) にもブラウザ固有情報が付くと勘違いし、Cookie 送信を (iii) と誤答するケース。
- レスポンス方向 (iv)・(vi) に Cookie が「返る」と考えてしまい、送信方向と混同するケース。
- CORS を「Origin ヘッダがあれば常に Cookie も付く」と早合点し、メインリクエストであることを見落とすケース。
FAQ
Q: プリフライトリクエストに Cookie を付けてはいけないのはなぜですか？
A: プリフライトは単なる事前確認なので、認証情報を伴うと過剰にセンシティブな情報を送ってしまう恐れがあります。ブラウザ実装がセキュリティの観点で自動的に除外します。
A: プリフライトは単なる事前確認なので、認証情報を伴うと過剰にセンシティブな情報を送ってしまう恐れがあります。ブラウザ実装がセキュリティの観点で自動的に除外します。
Q: withCredentials を true にしてもサーバ側で設定がなければ Cookie は送られませんか？
A: はい。サーバが Access-Control-Allow-Credentials: true を返さない場合、ブラウザは Cookie を送信しませんし、レスポンスの設定も受け取りません。
A: はい。サーバが Access-Control-Allow-Credentials: true を返さない場合、ブラウザは Cookie を送信しませんし、レスポンスの設定も受け取りません。
Q: 同一オリジンでもプリフライトは発生しますか？
A: 同一オリジンでは発生しません。プリフライトは「オリジンが異なる」場合の安全確認ステップです。
A: 同一オリジンでは発生しません。プリフライトは「オリジンが異なる」場合の安全確認ステップです。
関連キーワード: CORS, プリフライトリクエスト、Cookie, XMLHttpRequest, オリジン間リソース共有
設問3：〔CORSを利用した実装〕について、(1)〜(3)に答えよ。
（1）表1中のfに入れる適切なURLを答えよ。
解説
解答の論理構成
- 表1 No.3 には、
「Originヘッダフィールドには “https://site-a.m-sha.co.jp” が設定されている。」
と明示されています。 - 表1 No.4 では、
「Access-Control-Allow-Originヘッダフィールドの値は、“f”である。」
とあり、ここに No.3 の Origin の値をそのまま返すのが CORS の基本動作です。 - さらに No.5 で、
「Webブラウザは、gとAccess-Control-Allow-Originヘッダフィールドの値を照合し…」
と照合処理が行われるため、両者は同一でなければなりません。 - したがって f には Origin と同一の 「https://site-a.m-sha.co.jp」 が入ります。
誤りやすいポイント
- 「*」を指定すればどこからでもアクセス可能と誤解しがちですが、Cookie を伴うリクエストではワイルドカードは利用できません。
- 末尾のスラッシュを付けて「https://site-a.m-sha.co.jp/」と書き、ブラウザ照合に失敗するケースがあります。
- ポート番号やサブドメインの違いも別オリジン扱いになる点を見落とすと誤答になります。
FAQ
Q: Access-Control-Allow-Origin に複数のオリジンをカンマ区切りで設定できますか？
A: いいえ。一度のレスポンスに指定できるオリジンは一つだけです。複数を許可したい場合は、リクエストの Origin をサーバ側で判定し、一致したものを 1 件だけ返します。
A: いいえ。一度のレスポンスに指定できるオリジンは一つだけです。複数を許可したい場合は、リクエストの Origin をサーバ側で判定し、一致したものを 1 件だけ返します。
Q: ワイルドカード「」が使えないのはどのような場合ですか？
A: withCredentials=true で Cookie や認証情報を送信するクロスオリジン通信では「」は使用できません。同一オリジンを明示指定する必要があります。
A: withCredentials=true で Cookie や認証情報を送信するクロスオリジン通信では「」は使用できません。同一オリジンを明示指定する必要があります。
Q: プリフライトリクエストは常に発生しますか？
A: 単純リクエスト（特定メソッド・ヘッダ・MIME 型のみを使用）に該当する場合は発生しません。それ以外のケースで OPTIONS による確認が行われます。
A: 単純リクエスト（特定メソッド・ヘッダ・MIME 型のみを使用）に該当する場合は発生しません。それ以外のケースで OPTIONS による確認が行われます。
関連キーワード: CORS, Origin, プリフライトリクエスト、Access-Control-Allow-Origin, クロスサイト通信
設問3：〔CORSを利用した実装〕について、(1)〜(3)に答えよ。
（2）表1中のgに入れる適切な字句を、30字以内で答えよ。
模範解答
g：売れ筋商品情報配信の申込ページのオリジン
解説
解答の論理構成
- CORS では、アクセス元となるページのオリジンが Origin ヘッダフィールドとして自動送信されます。問題文では、
「プリフライトリクエストは、OPTIONSメソッドの呼び出しであり、Originヘッダフィールドには “https://site-a.m-sha.co.jp” が設定されている。」
と明記されています。 - さらに表1の No.5 には、
「Webブラウザは、gとAccess-Control-Allow-Originヘッダフィールドの値を照合し…」
とあり、ここで照合されるのは ①ブラウザが送った Origin と ②API‐Y が返した Access-Control-Allow-Origin です。 - ブラウザが送る Origin は、「売れ筋商品情報配信の申込ページ」をホストしている https://site-a.m-sha.co.jp のオリジンに他なりません。
- 以上から、g には「売れ筋商品情報配信の申込ページのオリジン」が入ると論理的に導かれます。
誤りやすいポイント
- “Origin ヘッダフィールドの値” とだけ書いてしまい、どのページの Origin なのかを明記しない。
- https://site-a.m-sha.co.jp と具体的な URL を丸写ししてしまい、ヘッダ値とオリジン概念の区別を誤る。
- メインリクエスト時の比較と勘違いし、プリフライトレスポンス以降の流れを取り違える。
FAQ
Q: Access-Control-Allow-Origin にワイルドカード "" を返せば済むのでは？
A: 個人情報を含む API で "" を使うと、悪意あるサイトでもレスポンスを取得できてしまい、情報漏えいのリスクが高まります。許可オリジンを限定するのが鉄則です。
A: 個人情報を含む API で "" を使うと、悪意あるサイトでもレスポンスを取得できてしまい、情報漏えいのリスクが高まります。許可オリジンを限定するのが鉄則です。
Q: “オリジン” と “ドメイン” は同じ意味ですか？
A: オリジンは「スキーム＋ホスト＋ポート」の3要素の組で定義されます。同じドメイン名でもスキームやポートが違えば別オリジンです。
A: オリジンは「スキーム＋ホスト＋ポート」の3要素の組で定義されます。同じドメイン名でもスキームやポートが違えば別オリジンです。
Q: JSONP を避け、CORS に切り替える最大のメリットは？
A: CORS は Access-Control-Allow-Origin などの応答ヘッダでサーバ側がアクセス元を制御でき、スクリプト改ざんや情報窃取のリスクを大幅に低減できる点です。
A: CORS は Access-Control-Allow-Origin などの応答ヘッダでサーバ側がアクセス元を制御でき、スクリプト改ざんや情報窃取のリスクを大幅に低減できる点です。
関連キーワード: CORS, Originヘッダ、プリフライトリクエスト、クロスサイト制御、HTTPレスポンスヘッダ
設問3：〔CORSを利用した実装〕について、(1)〜(3)に答えよ。
（3）本文中のh、iに入れる適切な字句を、それぞれ20字以内で、本文中のjに入れる適切な字句を5字以内で答えよ。
模範解答
h：Originヘッダフィールドの値
i：許可するオリジンのリスト
j：一致
解説
解答の論理構成
- 問題文には、D課長の指示として
「プリフライトリクエスト又はメインリクエストがWeb APIに送られてきたときに、そのリクエスト中の h を、i と突合し、j した値があればその値をAccess-Control-Allow-Originヘッダフィールドに設定する」とあります。 - まず突合せ対象の「リクエスト中の」情報は、CORSの判定に使われる“Origin”であることが文脈から明らかです。CORSではブラウザが送るリクエストに Origin ヘッダフィールドが必ず付きます。したがって h は「Originヘッダフィールドの値」です。
- 次に比較先は、同じ会話の直前にある
「Web APIのプログラム内に、許可するオリジンのリストを用意しておく必要がある」
という一文から導かれます。ゆえに i は「許可するオリジンのリスト」です。 - 突合せ結果として求められる動作は「値があればその値をAccess-Control-Allow-Originヘッダフィールドに設定」することです。“値があれば”とは、比較結果が一致した場合を示します。CORS 処理で用語として自然なのは「一致」ですので j は「一致」となります。
誤りやすいポイント
- CORS 判定は Referer ではなく Origin を使う点を混同しやすい。
- 許可オリジンを列挙せずワイルドカード "*" を返す実装を想起し、i に別の語を入れてしまう。
- j に「存在」「確認」など曖昧語を入れると減点対象。CORS は完全一致で判定する。
FAQ
Q: Access-Control-Allow-Origin: * を返せばリストは不要なのでは？
A: 機能的には動きますが、情報漏えいリスクが高まります。問題文の要件は「複数のオリジンからのアクセスを許可する仕様であった場合」に限定許可する実装です。
A: 機能的には動きますが、情報漏えいリスクが高まります。問題文の要件は「複数のオリジンからのアクセスを許可する仕様であった場合」に限定許可する実装です。
Q: Origin ヘッダは常にブラウザが付けるのですか？
A: Same-Origin 内では付かない場合がありますが、CORS 対象のクロスサイトアクセスでは自動で付与されます。
A: Same-Origin 内では付かない場合がありますが、CORS 対象のクロスサイトアクセスでは自動で付与されます。
Q: リストに無いオリジンだった場合はどのようなレスポンスになりますか？
A: Access-Control-Allow-Origin を付与せずに 200 を返す、あるいは 4xx を返すなど設計次第ですが、ブラウザ側はスクリプトへのアクセスをブロックします。
A: Access-Control-Allow-Origin を付与せずに 200 を返す、あるいは 4xx を返すなど設計次第ですが、ブラウザ側はスクリプトへのアクセスをブロックします。
関連キーワード: CORS, Originヘッダ、プリフライトリクエスト、Access-Control-Allow-Origin, クロスサイト制御
