平成31年度 春期 情報処理安全確保支援士試験 午後Ⅰ 問1
問題文
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ブラウザを経由して行う方式を採用することにした。
（図1は省略）
〔情報連携機能の実装についての検討〕 スクリプトZは、 a ポリシによって、 b 、 c 、 d のいずれかが異なるリソースへのアクセスが制限される。そこで、Cさんは、この制限をう回するためにJSONP（JavaScript Object Notation with Padding）を用いることを開発部のD課長に提案した。次は、その時の会話である。
Cさん：API-Yからの会員情報の取得にJSONPを用いるつもりです。 D課長：JSONPは、アクセス先を制限する機能をもたない ので、その実装では問題がある。例えば、まず、会員情報を窃取しようとする攻撃者がスクリプトZを変更して、攻撃者のWebサイトのページに置く。次に、被害者に①特定の操作をさせた上で、そのページにアクセスさせると、攻撃者が被害者の会員情報を窃取できてしまう。
（中略）
D課長：CORS（Cross-Origin Resource Sharing）を用いるのがよいだろう。
〔CORSの概要〕 CORSとは、あるWebサイトから他のWebサイトへのアクセスを制御することができる仕組みである。XMLHttpRequestを使って “https://test2.example.com/test” にリクエストを送るスクリプトの例を図2に示す。
（図2は省略）
Webブラウザが “https://test1.example.com/” にアクセスし、図2のスクリプトを含むページを読み込んだとする。図2のスクリプトが実行されると、最初にWebブラウザは “https://test2.example.com/test” にプリフライトリクエストと呼ばれるリクエストを送る。そうすると、実際のリクエスト（以下、メインリクエストという）で許可されるメソッド名やヘッダフィールド名などがレスポンスとして返る。その後、メインリクエストを送り、レスポンスが返る。この一連の動作を図3に、また、図3中の（ⅲ）～（ⅵ）のリクエストとレスポンスの先頭部分の例を図4～図7に示す。
（図3～7は省略）
また、CORSでは通常、Webブラウザは、スクリプトを読み込んだページのオリジンだけにCookieや、ベーシック認証の情報を送る。図2では設定していないが、XMLHttpRequestのプロパティのwithCredentialsの値がtrueに設定されている場合、図3であれば、 e の動作の際に、test2.example.comから発行されたCookieが送られる。
〔CORSを利用した実装〕 Cさんは、スクリプトZの実装にCORSを用いたときの一連の動作を検討し、表1にまとめた。
表1 スクリプトZの実装にCORSを用いたときの一連の動作 | No. | 内容 | | :-- | :--- | | 1 | Webブラウザは、WebサイトAの売れ筋商品情報配信の申込ページにアクセスする。 | | 2 | WebサイトAは、WebサイトBのAPI-Yを呼び出すスクリプトZを含むページをレスポンスとして返す。 | | 3 | Webブラウザは、会員が申込みを行うと、WebサイトBにプリフライトリクエストを送信する。プリフライトリクエストは、OPTIONSメソッドの呼出しであり、Originヘッダフィールドには“ f ”が設定されている。 | | 4 | API-Yは、送られてきたリクエストにOriginヘッダフィールドが存在する場合、Access-Control-Allow-Originヘッダフィールドを付加し、レスポンスを返す。Access-Control-Allow-Originヘッダフィールドの値は、“ f ”である。Originヘッダフィールドが存在しない場合、エラーを返す。 | | 5 | Webブラウザは、 g とAccess-Control-Allow-Originヘッダフィールドの値を照合し、アクセスが許可されていることを確認する。許可されている場合は、次の処理に進む。確認できない場合は、メインリクエストを送らずに終了する。 | | … | … | | 9 | スクリプトZは、受け取ったJSON形式の値を変数に格納し、表示する。さらに、受け取った値はWebサイトAに送られ、保存される。 |
D課長：今後、他のシステムでもCORSを利用することが考えられるので、コーディング規約も併せてまとめておきたい。Access-Control-Allow-Originヘッダフィールドに指定できるオリジンは一つだけなので、複数のオリジンからのアクセスを許可するような仕様であった場合に、No.4の内容では不十分である。Web APIのプログラム内に、許可するオリジンのリストを用意しておく必要がある。プリフライトリクエスト又はメインリクエストがWeb APIに送られてきたときに、そのリクエスト中の h を、 i と照合し、 j した値があればその値をAccess-Control-Allow-Originヘッダフィールドに設定するという内容もコーディング規約に含めればよいだろう。
（後略）
設問
設問1 〔情報連携機能の実装についての検討〕について、(1)～(3)に答えよ。 (1) 本文中の a に入れる適切な字句を答えよ。 (2) 本文中の b ～ d に入れる適切な字句を解答群の中から選び、記号で答えよ。 解答群 ア Cookie イ FQDN ウ Location ヘッダフィールド エ Referer ヘッダフィールド オ User-Agent ヘッダフィールド カ 時刻 キ スキーム ク ポート番号 (3) 本文中の下線①について、操作の具体的な内容を、20字以内で答えよ。
設問2 本文中の e に入れる適切な記号を、（ⅲ）～（ⅵ）の中から選び、答えよ。
設問3 〔CORS を利用した実装〕について、(1)～(3)に答えよ。 (1) 表1中の f に入れる適切なURLを答えよ。 (2) 表1中の g に入れる適切な字句を、30字以内で答えよ。 (3) 本文中の h 、 i に入れる適切な字句を、それぞれ20字以内で、本文中の j に入れる適切な字句を、5字以内で答えよ。
解答
設問1 (1) a：Same-Origin (2) b：イ c：キ d：ク (b～dは順不同) (3) Webサイト Bへのログイン
設問2 e：(ⅴ)
設問3 (1) f：https://site-a.m-sha.co.jp (2) g：売れ筋商品情報配信の申込ページのオリジン (3) h：Originヘッダフィールドの値 i：許可するオリジンのリスト j：一致
解説
設問1
(1) ブラウザには、セキュリティ上の理由から、FQDN、スキーム（http、httpsなど）、ポート番号のいずれかが異なるサイトへのリクエスト（クロスドメインリクエスト）を制限する標準的な仕様があります。これを**「Same-Originポリシ」**あるいは「同一生成元ポリシ」と呼びます。
(2) 上記の通り、Same-Originポリシでは、リソースへのアクセスを制限する際に比較される要素として、FQDN (イ)、スキーム (キ)、ポート番号 (ク) があります。
(3) 攻撃者が会員情報を盗むシナリオとして、まず被害者を正規のWebサイトBにログインさせる必要があります。その後、被害者を攻撃者が用意したWebサイトのページにアクセスさせることで、会員情報を窃取することが可能になります。したがって、下線①の「特定の操作」とは、被害者をWebサイトBにログインさせる操作を指します。
設問2
CORSの仕組みにおいて、XMLHttpRequestプロパティのwithCredentialsの値がtrueに設定されている場合、クロスドメインリクエストでCookieを送信できます。 この場合、図3の動作では、
- (ⅲ)のプリフライトリクエストが送信されます。
- (ⅳ)のレスポンスでCookieの送信許可が返されます。
- その後の**(ⅴ)のメインリクエストの際に、test2.example.comから発行されたCookieが送信されます**。
設問3
(1) 表1のNo.3では、WebブラウザがWebサイトBにプリフライトリクエストを送信しています。このリクエストのOriginヘッダフィールドには、リクエスト元のオリジンが設定されます。この場合、リクエスト元はWebサイトA (https://site-a.m-sha.co.jp) です。したがって、No.4でWebサイトBが返すAccess-Control-Allow-Originヘッダフィールドの値も、許可するオリジンである「https://site-a.m-sha.co.jp」となります。
(2) 表1のNo.5では、Webブラウザはクロスドメインリクエストが許可されているかを確認します。具体的には、WebサイトBからのレスポンスに含まれるAccess-Control-Allow-Originヘッダの値と、現在ブラウザが表示しているページ、つまり**「売れ筋商品情報配信の申込ページのオリジン」とを照合します**。
(3) 複数のオリジンからのアクセスを許可する場合、サーバ側では以下の処理を行います。
• リクエストに含まれる h: Originヘッダフィールドの値 を取得します。
• サーバ側であらかじめ用意しておいた i: 許可するオリジンのリスト と照合します。
• リストに j: 一致 する値があれば、その値をAccess-Control-Allow-Originヘッダフィールドに設定してレスポンスを返します。
要点
Webサイト間の安全な情報連携について（午後I問1の解説）
この問題は、ある会社（M社）が運営する複数のWebサイト間で、安全に情報をやり取りする方法について扱っています。登場するシステムやサービスの関係性を理解し、どのようなセキュリティ課題があり、どう解決していくのかを見ていきましょう。
登場するシステム・サービス
• M社: 複数のWebサイトを自社（開発部）で開発・運営している会社です。
• WebサイトA: M社の顔となるポータルサイトです。URLは https://site-a.m-sha.co.jp/ です。
• WebサイトB: 商品を販売するECサイトで、10万人の会員情報を持っています。URLは https://site-b.m-sha.co.jp/ です。
• 情報連携機能: WebサイトBの情報をWebサイトAに表示するための新しいシステム（Web API）です。
① 現状：実現したいこと
M社は、**「WebサイトA（ポータルサイト）から、WebサイトB（ECサイト）の会員情報を取得して、メール配信サービスに利用したい」**と考えています。
そのために、WebサイトBに会員情報を外部から取得できる「API-Y」という窓口を設置し、WebサイトAのページに埋め込まれたプログラム（スクリプトZ）からその窓口を呼び出す、という仕組みを開発しています。
しかし、これにはWebブラウザのセキュリティ上の制約が関係してきます。
(この画像は、ソースには含まれていない、内容の理解を助けるための参考イメージです。)
② 課題・問題点：なぜ単純にはいかないのか？
ここで大きな壁となるのが、Webブラウザが標準で持つセキュリティ機能です。
- 「出身地が違う」と通信できない原則（Same-Originポリシ）
Webブラウザには、**「異なるサーバー（オリジン）からのデータを安易に読み込ませない」**という、**Same-Originポリシ（同一生成元ポリシー）**という大事なルールがあります。
• オリジンとは？: URLの「スキーム（httpsなど）」「FQDN（ドメイン名）」「ポート番号」の3点セットで決まる、いわばWebサイトの「出身地」です。
• 今回の問題: WebサイトA (site-a.m-sha.co.jp) とWebサイトB (site-b.m-sha.co.jp) はドメイン名が異なるため、「出身地が違う」と判断されます。そのため、WebサイトAのプログラムがWebサイトBの情報を直接取得しようとしても、ブラウザが通信をブロックしてしまいます。 - 最初の解決策案（JSONP）の危険性
開発担当のCさんは、この制約を回避するために「JSONP」という技術を提案しました。しかし、上司のD課長は「その方法にはセキュリティ上の問題がある」と指摘します。
• JSONPの問題点: **「誰からのアクセスかを制限する機能がない」**ことです。
• 具体的なリスク:- 攻撃者が、会員情報を盗むための悪意あるWebサイトを用意します。
- 被害者が、正規のWebサイトBにログインした状態で、その悪意あるサイトにアクセスしてしまいます。
- すると、悪意あるサイトのプログラムがWebサイトBの会員情報を要求し、被害者の情報が攻撃者に盗まれてしまう危険性があります。
③ 今後の対策：安全に連携するための解決策
D課長は、より安全な**「CORS（Cross-Origin Resource Sharing）」という仕組みを使うことを提案しました。
CORSとは？
CORSは、情報を渡す側のサーバーが「このサイトからのアクセスなら許可しますよ」というお墨付きを与える**ことで、Same-Originポリシの制約を安全に乗り越えるための仕組みです。
CORSの仕組み（やりとりのイメージ）
- ブラウザからの事前確認（プリフライトリクエスト）
◦ WebサイトAがWebサイトBにデータを要求する前に、ブラウザが「WebサイトAからアクセスしたいのですが、大丈夫ですか？」という事前確認のリクエストをWebサイトBに送ります。このリクエストには「私は https://site-a.m-sha.co.jp です」という出身地情報（Originヘッダ）が含まれています。 - サーバー側（WebサイトB）での許可判断
◦ リクエストを受け取ったWebサイトBは、あらかじめ用意しておいた**「許可するサイトのリスト」**と、送られてきた出身地情報を照合します。 - 許可証の発行
◦ リストに名前があれば、「OKです」という意味で、レスポンスに「Access-Control-Allow-Origin: https://site-a.m-sha.co.jp」という許可証を付けて返します。 - ブラウザによる最終確認と通信実行
◦ ブラウザはこの許可証を見て、アクセス元（WebサイトA）と許可されたサイトが一致することを確認します。一致すれば、本番のデータ取得リクエストを送信し、安全に情報を連携できます。
コーディング規約の整備
今後、他のシステムでも安全に連携できるように、**「アクセスを許可するサイトのリストをきちんと管理し、リクエストの出身地と必ず照合する」**というルールを社内のコーディング規約として定めることになりました。これにより、個人の判断ミスを防ぎ、組織全体でセキュリティレベルを維持することができます。
まとめ Webサイト間で連携機能を実装する際は、ブラウザのセキュリティ機能（Same-Originポリシ）を正しく理解することが重要です。安易な回避策（JSONPなど）は情報漏えいのリスクを伴うため、CORSのようにアクセス元をきちんと検証できる仕組みを採用し、安全なシステムを構築する必要があります。