情報処理安全確保支援士 2012年 秋期 午後1 問01
インターネットWebサイトの刷新に関する次の記述を読んで、設問1～4に答えよ。
A社は、従業員数700名の外食サービス会社であり、地方都市で事業を展開している。A社グループ傘下には、レストラン、ピザ店及びハンバーガー店がある。A社では、これまで、様々な業務のシステム化を行ってきたが、今年末の宅配すし事業の立上げを契機に、販売促進システムの一部であるインターネットWebサイトにおけるサービス向上を検討することになった。
〔A社のインターネットWebサイトの概要〕
A社のインターネットWebサイトには、一般公開用のもの（以下、一般サイトという。ドメインはa-sha.co.jp）と、事前に登録した会員向けのもの（以下、会員サイトという。ドメインはa-sha-kaiin.com）がある。
一般サイトでは、会社情報及び商品情報を提供しており、誰でも閲覧できる。一般サイトは、コンテンツの更新も含めてB社に運用管理を委託している。会員サイトは、一般サイトにあるリンクで示されたWebページでログインでき、登録した届け先住所を用いた手軽な注文が可能で、注文履歴に基づいてお勧め商品に関する情報を表示するといったサービスを提供している。会員の誕生日には割引券も発行しており、評判が良い。
会員サイトは個人情報を扱うことから、①サーバ認証によるHTTPSを採用し、その上でのフォームを用いた利用者認証を行っている。例えば、ある会員がブラウザで会員サイトにアクセスしようとすると、利用者IDとパスワードによる利用者認証が求められ、認証に成功すると、会員サイトにアクセスできるようになる。クッキーの有効期限が切れるか、利用者がログアウトした後は、当該ブラウザから会員サイトにアクセスできなくなり、再び利用者認証を求められる。
会員サイトは、D社に運用管理を委託しており、A社情報セキュリティポリシ上、個人情報を扱う会員サイトから一般サイトへのデータの転送といった機密データの連携は一切行わないことになっている。
〔インターネットWebサイトのサービス向上策の検討〕
会員が一般サイトにアクセスした際に、当該会員の獲得ポイント状況、最近の注文状況のほか、近隣のグループ店からのお知らせなどの情報を表示するサービス（以下、ターゲット型広告サービスという）を検討することにした。そこで、最近話題になっているマッシュアップ技術を有効活用したサービス（以下、マッシュアップサービスという）が実現可能かどうかを調査することになった。
マッシュアップサービスの実現に関しては、まず、Ajax（Asynchronous JavaScript + XML）という技術を用いることを検討した。
Ajaxを用いると、Webページ全体を再描画することなく、現在表示されているWebページの表示の一部だけを更新することができる。例えば、aを利用するHTMLファイル群をブラウザがダウンロードして実行すると、非同期的又は同期的にWebサーバにアクセスし、そのレスポンスデータを用いてWebページを更新することができる。
しかし、通常、ブラウザではセキュリティ確保のためのbポリシが採用されているので、aを利用するHTMLファイル群をダウンロードして実行する際、FQDN、プロトコル又はポート番号のいずれかが、ダウンロードしたものと異なるURIにはアクセスできず、A社が想定するターゲット型広告サービスを実現できない。そこで、次に、JSONP（JavaScript Object Notation with Padding）という技術を用いて、マッシュアップサービスを実現することを検討した。JSONPを用いて上記の3要素のいずれかが異なるURIからでもデータを取得することが可能なJavaScript（以下、JSONP呼出しスクリプトという）を記述できる。
A社ではJSONPを用いてターゲット型広告サービスを実現する仕組みを検討した。図1はその案である。この案では、会員のポイントの獲得状況を表示するサービス（以下、ポイント表示サービスという）用のJSONP呼出しスクリプト（図2）を呼び出すページを、一般サイトのトップページに用意しておく。例えば、利用者IDをuser1としてログインした会員が、一般サイトのトップページを閲覧した際、会員サイトから送られてくる図3に例示したようなJSONP型データを用いて、その月の獲得ポイントとトータルの獲得ポイントを表示する。
A社ではポイント表示サービスのほかにも、会員の誕生月にポイントを2倍付与するサービスと、会員が住む地域のグループ店からのお得情報を提供するサービスを検討している。
〔セキュリティに関する検討〕
A社では、マッシュアップサービスを初めて導入することもあり、ターゲット型広告サービスの仕組みについて、セキュリティ専門家のZ氏にレビューを受けた。すると、ポイント表示サービスの仕組みには、次に示すようにJSONP呼出しスクリプトを悪用する攻撃で会員の個人情報が漏えいする可能性があるとの指摘を受けた。
A社のポイント表示サービスの仕組みの場合、cから送られるdが、会員の個人情報を含む。しかし、②ある条件が成立しているとき、悪意あるWebサイトにアクセスし、図4のように動作するJSONP呼出しスクリプトをeが実行すると、dに含まれる会員の個人情報を奪われる可能性がある。
Z氏からは、このような攻撃に対する一般的な対策として図5が示され、対応をA社関係者で検討した。
ポイント表示サービスの実現においては、会員が一般サイトのトップページにアクセスした際、JSONP呼出しスクリプトが会員サイトにアクセスする。そのため、図5の(1)の対策をとるには、一般サイトで“トップページへのアクセスのリクエストがfからのアクセス”という情報が必要になる。しかし、一般サイトと会員サイトの運用管理会社が違うこともあり実現方法の検討に期間を要してしまうので、この対策方法は見送ることにした。
図5の(2)の対策については、A社のWebサイトは様々な環境の利用者を想定していることから、Refererヘッダの情報がサーバにgというケースもあり得るので、Refererヘッダの情報の利用を前提としてポイント表示サービスを実現すると、正規のリクエストか否かを区別できないケースがある。そのため、この対策方法も見送ることにした。
Z氏との検討の結果、ポイント表示サービスを含むターゲット型広告サービスは、将来普及が見込まれるaの新規格を用いることも含めて検討課題とし、最終的には、ターゲット型広告サービスを除いてA社のWebサイトを刷新することとした。
設問1：
本文中のa、bに入れる適切な字句を解答群の中から選び、記号で答えよ。
解答群
ア：APT
イ：ATM
ウ：Same-Origin
エ：XMLHttpRequest
オ：アノニマス
カ：プライバシ
模範解答
a：エ
b：ウ
解説
解答の論理構成
- 問題文はまず、Ajax の仕組みについて
「例えば、aを利用するHTMLファイル群をブラウザがダウンロードして実行すると、非同期的又は同期的にWebサーバにアクセスし、そのレスポンスデータを用いてWebページを更新することができる。」
と説明しています。Ajax でブラウザと Web サーバを非同期通信させる代表的 API は “XMLHttpRequest” であるため、a には 「XMLHttpRequest」 が入ります。 - 次にブラウザ側の制限について
「しかし、通常、ブラウザではセキュリティ確保のためのbポリシが採用されているので、aを利用するHTMLファイル群をダウンロードして実行する際、FQDN、プロトコル又はポート番号のいずれかが、ダウンロードしたものと異なるURIにはアクセスできず…」
とあります。ここで複数の URI 要素（ドメイン・プロトコル・ポート）が一致しない場合に通信を禁止するブラウザの標準的仕組みは “Same-Origin Policy” です。したがって b には 「Same-Origin」 が入ります。 - 解答群との対応
- エ：XMLHttpRequest
- ウ：Same-Origin
以上より、 a＝「エ」、b＝「ウ」 が正解です。
誤りやすいポイント
- Ajax の説明文に “XML” の語があるため a を「XML」とだけ読み取り、API 名である “XMLHttpRequest” を書き漏らす。
- “Same-Origin Policy” を「同一生成元ポリシー」と和訳して覚えており、選択肢に和訳表記が無いことで迷う。
- APT や プライバシ保護関連語の選択肢に目を取られ、本問がブラウザ制御の基本原則を問う問題であることを見落とす。
FAQ
Q: Ajax と XMLHttpRequest は同義ですか?
A: Ajax は技術の総称で、実装の中心にある API が “XMLHttpRequest” です。Ajax = XMLHttpRequest ではありませんが、本問の文脈では Ajax を実現する具体的手段として XMLHttpRequest が問われています。
A: Ajax は技術の総称で、実装の中心にある API が “XMLHttpRequest” です。Ajax = XMLHttpRequest ではありませんが、本問の文脈では Ajax を実現する具体的手段として XMLHttpRequest が問われています。
Q: Same-Origin Policy があると JSONP で別ドメインから取得できるのはなぜ?
A: JSONP は
A: JSONP は
Q: XMLHttpRequest 以外に Ajax を実装する方法はありますか?
A: 近年は fetch API や WebSocket も広く利用されますが、問題文が説明している伝統的 Ajax の非同期通信手段は XMLHttpRequest です。
A: 近年は fetch API や WebSocket も広く利用されますが、問題文が説明している伝統的 Ajax の非同期通信手段は XMLHttpRequest です。
関連キーワード: Ajax, XMLHttpRequest, Same-Origin Policy, JSONP
設問2：
本文中の下線①について、SSLのクライアント認証と比較した場合の、サーバ認証によるHTTPS通信上でフォームを用いた利用者認証を行う利点を、25字以内で述べよ。
模範解答
利用者がクライアント証明書を用意する必要がない。
解説
解答の論理構成
- 本文では、会員サイトについて「①サーバ認証によるHTTPSを採用し、その上でのフォームを用いた利用者認証」と記述されています。
- サーバ認証付き HTTPS とは、Webサーバが証明書を提示して通信を暗号化・真正性を保証する方式です。利用者側はブラウザに標準搭載された CA 証明書でサーバ証明書を検証するだけで済みます。
- これに対し SSL クライアント認証では、利用者が自分の端末にクライアント証明書をインストールし、秘密鍵を安全に保管する必要があります。
- したがって、サーバ認証＋フォーム認証方式の利点は「利用者にクライアント証明書を準備・管理させなくてもよい」点です。
誤りやすいポイント
- 「サーバ認証なら暗号強度が高い」と書いてしまう
→ 暗号強度自体はクライアント認証の有無とは無関係です。 - 「フォーム認証は HTTPS がなくても安全」と考える
→ HTTPS なしではパスワードが平文送信されるため不可。 - 「クライアント証明書はブラウザが自動生成する」と誤解する
→ 実際は発行・配布・管理コストがかかります。
FAQ
Q: サーバ認証だけでパスワード漏えいを完全に防げますか？
A: 送信経路上の盗聴は防げますが、サーバ側での保管方法や XSS 等の対策は別途必要です。
A: 送信経路上の盗聴は防げますが、サーバ側での保管方法や XSS 等の対策は別途必要です。
Q: フォーム認証をワンタイムパスワードに置き換えればクライアント証明書と同等ですか？
A: 認証強度は高まりますが、証明書ベースの双方向認証とは性質が異なります。利用者負担や管理コストとのバランスを考慮する必要があります。
A: 認証強度は高まりますが、証明書ベースの双方向認証とは性質が異なります。利用者負担や管理コストとのバランスを考慮する必要があります。
Q: スマートフォン利用者にもクライアント証明書を配布できますか？
A: 技術的には可能ですが、端末買替え時の再発行や OS 間の手続き差など運用負荷が大きくなります。
A: 技術的には可能ですが、端末買替え時の再発行や OS 間の手続き差など運用負荷が大きくなります。
関連キーワード: HTTPS, サーバ証明書、クライアント証明書、フォーム認証、双方向認証
設問3：悪意あるJSONP呼出しスクリプトについて(1)〜(3)に答えよ。
（1）本文及び図4中のc並びに本文中のeに入れる適切な字句を答えよ。
模範解答
c：会員サイト
e：ブラウザ
解説
解答の論理構成
-
【問題文】には
“会員サイトから送られてくる図3に例示したようなJSONP型データを用いて…”
とあり、JSONP型データ（＝d）を送信しているのは「会員サイト」です。
したがって “cから送られる” という条件を満たす語句は
“会員サイト” となります。 -
次に、【問題文】の指摘部分を引用します。
“悪意あるWebサイトにアクセスし、図4のように動作するJSONP呼出しスクリプトをeが実行すると…”
Webページ内の JavaScript を実行する主体は利用者端末の “ブラウザ” です。
したがって e に入る語句は “ブラウザ” となります。 -
まとめ
• c：会員サイト
• e：ブラウザ
誤りやすいポイント
- “JSONP型データを送るのはどのサーバか” を一般サイトと取り違える。図1では一般サイトはスクリプトを配信するだけで、データ源は会員サイトです。
- “e” を “攻撃者” と書いてしまう。攻撃を仕掛けたのは悪意あるWebサイトですが、実際にスクリプトを実行するのは利用者のブラウザであることに注意しましょう。
- “JSONP＝安全” と早合点して対策を忘れる。JSONP は同一生成元ポリシーを回避する仕組みであり、適切な検証がないと情報漏えいのリスクがあります。
FAQ
Q: JSONP型データと通常のJSONの違いは？
A: JSONPは
A: JSONPは
Q: もしブラウザ側でスクリプトを無効化したら本攻撃は成立しますか？
A: JavaScript が無効であれば JSONP 呼出しスクリプトも実行されず、攻撃は成立しません。ただしサービス本体も動作しなくなるため現実的な対策とは言えません。
A: JavaScript が無効であれば JSONP 呼出しスクリプトも実行されず、攻撃は成立しません。ただしサービス本体も動作しなくなるため現実的な対策とは言えません。
Q: 対策(1)で示された「認証情報」とは具体的に何を指すのですか？
A: クッキーのセッショントークンやHTTPヘッダに付与するAPIキーなど、そのリクエストが正規利用者のものであることを確認できる情報を指します。
A: クッキーのセッショントークンやHTTPヘッダに付与するAPIキーなど、そのリクエストが正規利用者のものであることを確認できる情報を指します。
関連キーワード: JSONP, 同一生成元ポリシ、HTTPS, クッキー、クロスサイトスクリプティング
設問3：悪意あるJSONP呼出しスクリプトについて(1)〜(3)に答えよ。
（2）本文中の下線②における条件を、本文に即して、50字以内で述べよ。
模範解答
悪意あるJSONP呼出しスクリプトを実行するブラウザが、会員サイトにログインした状態である場合
解説
解答の論理構成
- 本文では、会員サイトの閲覧には「①サーバ認証によるHTTPS…利用者IDとパスワードによる利用者認証」が必須であると記述されています。
- さらに「クッキーの有効期限が切れるか、利用者がログアウトした後は、当該ブラウザから会員サイトにアクセスできなくなり、再び利用者認証を求められる。」とあります。つまり、クッキーが有効でログイン中であれば再認証なしで会員サイトへアクセスできます。
- 悪意あるJSONP呼出しスクリプトは「ステップ1) c にアクセスし、目的とする d を取得する。」と動作します。ここで c は会員サイトのURLを指し、d は個人情報を含むJSONP型データです。
- したがってブラウザがログイン中であれば、攻撃スクリプトも会員サイトに対して正規のセッションを用いてアクセスでき、d を取得できます。
- 以上より、下線「②ある条件が成立しているとき」とは、「ブラウザが会員サイトにログインした状態」、すなわち有効なセッション・クッキーを保持している状態を指します。
誤りやすいポイント
- 「HTTPS通信中であること」と誤解しやすいですが、HTTPSだけではログイン中かどうかは判断できません。
- 「JSONP呼出しスクリプトの格納先ドメインが同じかどうか」と混同しがちですが、同一生成元規則の回避はJSONPの前提であり、条件②とは別概念です。
- 有効クッキーの存在＝ログイン中である、というセッション管理の基本を見落とすと誤答につながります。
FAQ
Q: HTTPSを使っていれば個人情報は守られるのでは？
A: 通信経路は暗号化されても、ログイン中セッションが悪用されれば攻撃スクリプトも正規のレスポンスを取得できます。
A: 通信経路は暗号化されても、ログイン中セッションが悪用されれば攻撃スクリプトも正規のレスポンスを取得できます。
Q: 「Same-Origin Policy」が働くのでは？
A: JSONPは
A: JSONPは
Q: ログアウトリンクを用意するだけで十分？
A: 利用者が手動でログアウトしなければクッキーは有効なままなので、追加のCSRFトークンなど根本対策が必要です。
A: 利用者が手動でログアウトしなければクッキーは有効なままなので、追加のCSRFトークンなど根本対策が必要です。
関連キーワード: JSONP, Same-Origin-Policy, セッション管理、CSRF, クッキー
設問3：悪意あるJSONP呼出しスクリプトについて(1)〜(3)に答えよ。
（3）本文及び図4中のdに入れる適切な字句を、10字以内で具体的に答えよ。
模範解答
d：JSONP型データ
解説
解答の論理構成
- 問題文では、個人情報が含まれるデータを「会員サイトから送られてくる図3に例示したようなJSONP型データ」と明言しています。
──「例えば、…会員サイトから送られてくる図3に例示したようなJSONP型データを用いて、…表示する。」 - また図3のキャプションも「会員サイトから送られてくるJSONP型データの例」と記載されています。
- さらにセキュリティ専門家Ｚ氏の指摘部分でも「dが、会員の個人情報を含む」とあり、個人情報を運ぶ媒体はこのデータだけです。
- 以上より、d に該当する具体的な字句は「JSONP型データ」と判断できます。
誤りやすいポイント
- 「会員情報」や「ポイント情報」と回答してしまう
→ 個人情報を含むとはいえ、問題が求めているのは“データ形式”であり、図3に示された正式名称をそのまま記述する必要があります。 - 「JSON データ」と省略してしまう
→ 問題文は Ajax ではなく JSONP を強調しており、同一生成元ポリシー回避の仕組みが肝です。 - キャッシュやクッキーと取り違える
→ どちらも個人情報を保持し得ますが、今回の漏えい対象はブラウザに挿入され実行されるスクリプト呼出し結果です。
FAQ
Q: JSON と JSONP の違いは何ですか？
A: JSON は純粋なデータ形式、JSONP は
A: JSON は純粋なデータ形式、JSONP は
Q: なぜ JSONP 型データが個人情報漏えいの原因になるのですか？
A: <script> として読み込まれるため、悪意あるサイトでも自由に実行可能です。返ってきた JSONP には個人情報が含まれ、それを攻撃者の JavaScript がそのまま抜き取って外部送信できるためです。
A: <script> として読み込まれるため、悪意あるサイトでも自由に実行可能です。返ってきた JSONP には個人情報が含まれ、それを攻撃者の JavaScript がそのまま抜き取って外部送信できるためです。
Q: Referer ヘッダ確認が避けられた理由は？
A: 「Referer ヘッダの情報がサーバに<span class="choice-box">g</span>というケースもあり得る」と問題文にあるように、環境によってヘッダが送信されない場合があるため、正規・不正の判定が不能になるからです。
A: 「Referer ヘッダの情報がサーバに<span class="choice-box">g</span>というケースもあり得る」と問題文にあるように、環境によってヘッダが送信されない場合があるため、正規・不正の判定が不能になるからです。
関連キーワード: JSONP, 同一生成元ポリシ、クロスサイトスクリプティング、Referer, HTTPS
設問4：JSONPを用いて、個人情報を扱う際の対策の検討について、(1)、(2)に答えよ。
（1）本文及び図5中のfに入れる適切な字句を、10字以内で答えよ。
模範解答
f：認証された利用者
解説
解答の論理構成
- 問題文では、JSONP を悪用した不正リクエストをブロックする一般的対策として図5が示されています。
- 図5(1) の説明を引用すると、 「リクエストの HTTP ヘッダに埋め込んである認証情報を確認する。認証情報とは、そのリクエストが f からのアクセスであることを確認できるものである。」
- ここで“確認できるもの”が示す対象は、会員サイトで既に本人確認を済ませトークンやクッキーを持つユーザであると読み取れます。
- つまり、HTTP ヘッダに含める認証情報は「そのリクエストを発行したブラウザが、会員サイトで正当に認証を通過した利用者である」ことを保証する役割を担います。
- 以上より f には「認証された利用者」を入れるのが適切です。
誤りやすいポイント
- 「会員サイト」や「A社利用者」などサイトや企業名で答えてしまう。図5の記述は利用者の認証状態を示しており、サイトや企業名では意味が合いません。
- 「ログイン済みユーザ」と言い換えてしまう。設問は原文の“認証”を含む表現を想定しています。
- 認証手段を答えてしまう例（例：セッションID、クッキー）。f は“情報”ではなく“誰からのアクセスか”を表す語句です。
FAQ
Q: 認証トークン自体の名称（例: セッションID）を答えてはいけませんか？
A: 設問は「そのリクエストが誰からのアクセスか」を説明する主語を求めています。したがって利用者を指す語句が適切です。
A: 設問は「そのリクエストが誰からのアクセスか」を説明する主語を求めています。したがって利用者を指す語句が適切です。
Q: 「正規利用者」と「認証された利用者」の違いは？
A: 正規でも未認証の可能性があります。図5(1) では“認証情報”を前提にしているため、認証済みであることを強調する必要があります。
A: 正規でも未認証の可能性があります。図5(1) では“認証情報”を前提にしているため、認証済みであることを強調する必要があります。
Q: 認証ヘッダとしてはどのような例がありますか？
A: クッキーのセッションID、Bearer トークン、Basic 認証の Authorization ヘッダなどが代表的です。
A: クッキーのセッションID、Bearer トークン、Basic 認証の Authorization ヘッダなどが代表的です。
関連キーワード: JSONP, Same Origin Policy, クッキー、Refererヘッダ、認証トークン
設問4：JSONPを用いて、個人情報を扱う際の対策の検討について、(1)、(2)に答えよ。
（2）本文中のgに入れる適切な字句を、10字以内で答えよ。
模範解答
g：送信されない
解説
解答の論理構成
- 問題文では「Refererヘッダの情報がサーバにgというケースもあり得る」と記述されています。
- HTTP リクエストヘッダの Referer は、
① ブラウザやセキュリティソフトの設定、
② HTTPS→HTTP への遷移、
③ プライバシー保護拡張機能の利用
などの理由で空にされる、あるいは付与されないことがあります。 - その結果、サーバ側が参照元ページを確認できないため、Referer に依存したアクセス制御は信頼性を欠くと判断されます。
- したがって g には「送信されない」を入れることで、「Refererヘッダがサーバに送信されないケース」を明示し、Referer 依存方式を採用しない判断理由を説明できます。
誤りやすいポイント
- Referer ヘッダは「常に空」「必ず消える」と誤解しがちですが、実際には利用環境により送信されたりされなかったりします。
- 「取得できない」「空になる」など別表現を入れると原文引用要件を満たせなくなります。
- Referer による検証だけで CSRF や JSONP 乱用を防げると短絡的に判断しやすい点にも注意が必要です。
FAQ
Q: Referer が削除される具体的な例はありますか？
A: HTTPS サイトから HTTP サイトへ遷移するとき、ブラウザは機密情報漏えい防止のため Referer を送信しない場合があります。また、プライバシー保護機能を有効にしたブラウザも送信しないことがあります。
A: HTTPS サイトから HTTP サイトへ遷移するとき、ブラウザは機密情報漏えい防止のため Referer を送信しない場合があります。また、プライバシー保護機能を有効にしたブラウザも送信しないことがあります。
Q: Referer を使わないならどのような対策が有効ですか？
A: 認証付き API キーやトークンを発行し、JSONP リクエストに必須パラメータとして付与させ、サーバ側で検証する方法が代表的です。
A: 認証付き API キーやトークンを発行し、JSONP リクエストに必須パラメータとして付与させ、サーバ側で検証する方法が代表的です。
Q: 送信されない場合でもヘッダ自体は届きますか？
A: ブラウザが Referer を送信しない設定の場合、ヘッダそのものが欠落します。空文字列として届くケースと、ヘッダ行が存在しないケースの両方があります。
A: ブラウザが Referer を送信しない設定の場合、ヘッダそのものが欠落します。空文字列として届くケースと、ヘッダ行が存在しないケースの両方があります。
関連キーワード: Refererヘッダ、JSONP, Same-Origin-Policy, CSRF
