情報処理安全確保支援士 2016年 春期 午後1 問03
スマートフォンアプリケーションの試験に関する次の記述を読んで、設問1、2に答えよ。
S社は、従業員数100名のECサービス会社である。今回、新たにショッピングサイト（以下、Sサイトという）とSサイト専用のスマートフォンアプリケーション（以下、Sアプリという）から構成されるシステム（以下、Sシステムという）の開発プロジェクトを立ち上げた。プロジェクトリーダには、サービス開発部のRさんが任命され、Sシステムのセキュリティについては、セキュリティ専門業者のA氏の支援を受けることになった。
〔Sシステムの概要〕
Sシステムの構成を図1に、Sアプリの機能概要を図2に示す。
〔Sアプリでのサーバ証明書の検証試験〕
開発がテスト工程に入り、Rさんは、A氏と共同で、Sシステムのセキュリティに関する試験を検討し、Sサーバの認証を行うためのサーバ証明書の検証がSアプリで適切に行われていることの確認を試験に含めた。
Rさんは、図3に示すサーバ証明書の検証試験環境をS社内に設置し、スマートフォンからは無線LAN機能でこの検証試験環境に接続することにした。また、サーバ証明書の検証試験環境で用いる機器と設定を表1に、不正なサーバ証明書の検出についての試験項目を表2にまとめた。
なお、Sアプリと試験用Webサーバ間でHTTPS通信が確立することは、サーバ証明書の検証試験を実施する前に、試験用WebサーバにSサイト用サーバ証明書を登録して確認している。
A氏は、図3、表1及び表2のレビューを行い、問題がないことを確認した。Rさんが試験を実施した結果、Sアプリでのサーバ証明書の検証に不備は見つからなかった。
〔Sアプリでのサーバ証明書の検証不備による影響の検討〕
Rさんは、Sアプリでのサーバ証明書の検証に不備がある場合に、どのような攻撃が行われると影響を受けるのかを、A氏に質問した。A氏は、中間者攻撃に用いられる環境の例を図4に示した。
図4では、攻撃者が中間者サーバを含む機器を準備し、その先でインターネットを介してSサイトに接続している。中間者サーバは、Sアプリとの間、及びSサイトとの間で、独立した二つのHTTPS通信を確立し、中継する。
RさんはA氏に、例えば、表3に示す攻撃者が準備するサーバ証明書のうち、どれを使用すると中間者攻撃が成功するのかを質問した。A氏は、もしSアプリにサーバ証明書の検証不備があると、表4のとおり攻撃が成功すると答えた。
A氏は、サーバ証明書の検証不備がある場合に、①Sアプリの利用者が、図4中のW-APに接続すると、中間者攻撃を受けることを説明した。説明を受けたRさんは、表2の試験において、Sアプリに不備が見つからなかったことから、中間者攻撃を受けた場合には利用者が気付くことができると判断した。
その後、残りの工程も完了し、S社ではSシステムを無事リリースした。
設問1：〔Sアプリでのサーバ証明書の検証試験〕について、(1)〜(4)に答えよ。
問題文を見る模範解答
a：Sサーバ
解説
解答の論理構成
- 設問は「aに入れる適切な字句を図1中又は図3中の構成要素から選び、答えよ。」と求めています。
- 該当箇所は表1の「試験用DNSサーバ」設定欄にある、 “「aのFQDNからbのIPアドレスに名前解決するためのAレコードを設定する。」”
- 名前解決の目的は、スマートフォンのSアプリがアクセスしようとするサーバ証明書検証用Webサーバを、あたかも本番サイトと同一FQDNであるかのように見せ掛けることです。
- Sアプリは図2の仕様により“「Sアプリ内に、SサーバのFQDNが組み込まれている。」”ため、本番と同じFQDNしか参照しません。
- したがって、試験用DNSサーバにはその“本番と同じFQDN”、すなわち図1に登場する「Sサーバ」のFQDNを登録し、試験用WebサーバのIPアドレスへ向ける必要があります。
- よって a に入る語は「Sサーバ」となります。
誤りやすいポイント
- DNSのAレコードを設定する対象を「試験用Webサーバ」と誤解しがちですが、設問が要求しているのは “FQDNの主体” であり、図2に明示された「SサーバのFQDN」である点に注意が必要です。
- 図3にも試験用Webサーバが登場するため、試験用機器名と本番機器名を混同しやすいことが失点パターンです。
- “図1中又は図3中の構成要素から選ぶ” という条件を読み飛ばし、表1だけを見て推測すると誤答しやすくなります。
FAQ
Q: 「Sサイト」や「Sサーバ」など似た名称がありますが、FQDNを持つのはどれですか？
A: 図2に示されているとおり、Sアプリが接続先としてハードコードしているのは「Sサーバ」のFQDNです。
A: 図2に示されているとおり、Sアプリが接続先としてハードコードしているのは「Sサーバ」のFQDNです。
Q: なぜ試験用Webサーバ自身のホスト名をDNSに登録しないのですか？
A: Sアプリは本番FQDNでしか通信しない設計になっているため、試験用環境では同じFQDNを試験用WebサーバのIPアドレスへ解決させる必要があります。
A: Sアプリは本番FQDNでしか通信しない設計になっているため、試験用環境では同じFQDNを試験用WebサーバのIPアドレスへ解決させる必要があります。
Q: b には何が入るのですか？
A: b には「試験用Webサーバ」が入ります。FQDNが「Sサーバ」を示し、IPアドレスが試験用機器になることで名前解決を“偽装”します。
A: b には「試験用Webサーバ」が入ります。FQDNが「Sサーバ」を示し、IPアドレスが試験用機器になることで名前解決を“偽装”します。
関連キーワード: DNS Aレコード、FQDN, サーバ証明書、検証試験、ホスト名偽装
設問1：〔Sアプリでのサーバ証明書の検証試験〕について、(1)〜(4)に答えよ。
問題文を見る模範解答
b：試験用Webサーバ
解説
解答の論理構成
- 【問題文】表1の“試験用DNSサーバ”設定欄には
「aのFQDNからbのIPアドレスに名前解決するためのAレコードを設定する。」
と記載されています。 - Aレコードは「ホスト名 ➔ IPアドレス」をひも付けるDNSレコードです。したがって、aのFQDN（＝アクセス先ホスト名）を解決すべきIPアドレスは、そのFQDNを実際にホストするサーバのIPアドレスでなければなりません。
- 【問題文】図3 “サーバ証明書の検証試験環境”を確認すると、SアプリがHTTPSで接続する宛先は「試験用Webサーバ」です。Rさんは同サーバにテスト用のサーバ証明書を登録し、通信確立を事前確認しています。
- 以上より、DNSサーバは「Sサーバ（本番）用FQDN ➔ 試験用WebサーバのIPアドレス」という疑似マッピングを作成し、スマートフォンを試験環境へ誘導します。
- よって b に入る字句は【問題文】の構成要素「試験用Webサーバ」となります。
誤りやすいポイント
- Aレコードに設定するのは“名前”ではなく“IPアドレス”であるため、bに「FQDN」を入れてしまうミス。
- 図1の「Sサーバ」と図3の「試験用Webサーバ」を混同し、実環境のホスト名やIPを記述してしまう誤認。
- DHCPサーバとDNSサーバの役割を取り違え、「DHCPがDNS情報を返すからDNS側の設定は不要」と勘違いするパターン。
FAQ
Q: なぜ本番FQDNのまま試験を行い、IPアドレスだけを変えるのですか？
A: クライアント側（Sアプリ）はFQDNを固定で持つ設計です。【問題文】図2に「Sアプリ内に、SサーバのFQDNが組み込まれている。」とあるため、FQDNを変えるとアプリ改修が必要になります。DNSでIP先だけを切り替えることで試験環境へ誘導できます。
A: クライアント側（Sアプリ）はFQDNを固定で持つ設計です。【問題文】図2に「Sアプリ内に、SサーバのFQDNが組み込まれている。」とあるため、FQDNを変えるとアプリ改修が必要になります。DNSでIP先だけを切り替えることで試験環境へ誘導できます。
Q: “試験用Webサーバ”以外のサーバを登録すると何が問題ですか？
A: HTTPS通信はサーバ証明書とFQDNの一致が必須です。本来のFQDNを指すIPが他サーバだった場合、証明書のCNとホスト名が不一致となり、表2「サブジェクトのコモンネームが不正であることの検出」試験が常に失敗し、正しい試験結果を得られません。
A: HTTPS通信はサーバ証明書とFQDNの一致が必須です。本来のFQDNを指すIPが他サーバだった場合、証明書のCNとホスト名が不一致となり、表2「サブジェクトのコモンネームが不正であることの検出」試験が常に失敗し、正しい試験結果を得られません。
Q: Aレコード設定後、スマートフォン側で追加作業は必要ですか？
A: いいえ。表1「試験用DHCPサーバ」がDNSサーバのIPアドレスを配布するため、スマートフォンは自動的に試験用DNSを参照します。
A: いいえ。表1「試験用DHCPサーバ」がDNSサーバのIPアドレスを配布するため、スマートフォンは自動的に試験用DNSを参照します。
関連キーワード: Aレコード、DNSキャッシュ、サーバ証明書、HTTPS, コモンネーム
設問1：〔Sアプリでのサーバ証明書の検証試験〕について、(1)〜(4)に答えよ。
問題文を見る（3）表2中のcに入れる適切な字句を、15字以内で答えよ。
模範解答
c：試験の実施よりも前の日時
解説
解答の論理構成
- 【問題文】では、表2項番2の試験項目を
「有効期間内でないことの検出」
と明示しています。 - 同じく試験方法に
「有効期間の終了：c」
とあり、ここだけが可変項目です。 - サーバ証明書が“有効期間内でない”状態を作るには、現在より前に期限切れにしておくか、まだ開始していない日時に設定する必要があります。
- しかし表2では
「有効期間の開始：Sサイト用サーバ証明書と同一の値」
とあるため、開始日時を動かして“未開始”にすることはできません。結果として“不正”を生じさせる唯一の手段は、終了日時を現在より前に設定し“期限切れ”にすることです。 - 以上より c には
「試験の実施よりも前の日時」
を入れることで意図した不正状態を再現できます。
誤りやすいポイント
- 開始日時を未来にずらしてしまい「未開始証明書」を作ると、試験方法の条件（開始は同一値）を満たせなくなる点。
- 直前の日時（例：1分前）を設定すると、環境によってスマートフォンの時計誤差で検証結果が不定になること。
- 有効期間終了だけでなく発行者やコモンネームも同時に変更してしまい、どの検証エラーか判別できなくなるケース。
FAQ
Q: 開始日時を変えずに終了日時だけを過去にする理由は？
A: 【問題文】は“有効期間の終了”のみを c として可変にしており、開始日時は固定です。開始日時をいじると別の検証（未開始）になり、試験項目の主旨と合致しなくなります。
A: 【問題文】は“有効期間の終了”のみを c として可変にしており、開始日時は固定です。開始日時をいじると別の検証（未開始）になり、試験項目の主旨と合致しなくなります。
Q: 端末の時計がずれていたら試験は成立しませんか？
A: 証明書検証では端末時刻を基準に有効期間を判定します。実環境でも同様の判定が行われるため、試験では端末時刻を正確に合わせた上で実施します。
A: 証明書検証では端末時刻を基準に有効期間を判定します。実環境でも同様の判定が行われるため、試験では端末時刻を正確に合わせた上で実施します。
Q: ルート証明書を登録しているのにエラー画面が出るのはなぜ？
A: ルート証明書が正しくても、有効期間外であれば検証は失敗します。発行者の信頼と有効期間判定は独立してチェックされるためです。
A: ルート証明書が正しくても、有効期間外であれば検証は失敗します。発行者の信頼と有効期間判定は独立してチェックされるためです。
関連キーワード: 有効期限、証明書失効、HTTPS, 時刻検証
設問1：〔Sアプリでのサーバ証明書の検証試験〕について、(1)〜(4)に答えよ。
問題文を見る（4）表2の試験で、Sアプリが試験項目どおりに動作している場合に、どのような結果となるか。dに入れる適切な結果を、本文中又は図表中の字句を用いて、30字以内で具体的に述べよ。
模範解答
d：Sアプリがサーバ認証エラー画面を表示する。
解説
解答の論理構成
- 表2では、項番「1」「2」「3」のいずれも“発行者・有効期間・サブジェクトのコモンネーム”に不正を仕込んだサーバ証明書を試験用Webサーバへ登録します。
- これに対し、図2の機能概要には
「Sサーバと通信ができなかった場合は通信エラー画面を表示し、Sサーバを認証できなかった場合はサーバ認証エラー画面を表示する。」
と記述されています。 - 不正なサーバ証明書は“通信は成立しても認証は失敗する”ケースに該当するため、Sアプリは「Sサーバを認証できなかった」状態になります。
- 従って、表2「期待される結果」欄 d には
「Sアプリがサーバ認証エラー画面を表示する。」
と記入するのが論理的帰結です。
誤りやすいポイント
- “通信エラー画面”と“サーバ認証エラー画面”の取り違え
DNS設定ミスやWebサーバ停止など“接続不可”の場合は前者、不正証明書のように“接続は可能でも認証失敗”の場合は後者です。 - “スマートフォンにプライベート認証局のルート証明書を登録”の有無を結果と結び付けてしまう
登録の有無は発行者検証の合否を変える要因ですが、いずれにせよ不備が仕込まれているため認証は失敗します。 - “有効期間の終了”など数値を答えとして書いてしまう
期待される挙動を問われており、証明書の属性値そのものを入れる設問ではありません。
FAQ
Q: 証明書チェーンが切れている場合も「サーバ認証エラー画面」ですか？
A: はい。“Sサーバを認証できなかった”状況なので同じ画面を表示します。
A: はい。“Sサーバを認証できなかった”状況なので同じ画面を表示します。
Q: DNSが誤っていて別IPへ接続した場合はどうなりますか？
A: 接続自体ができなければ“通信エラー画面”、接続先でHTTPSが成立してもFQDN不一致なら“サーバ認証エラー画面”となります。
A: 接続自体ができなければ“通信エラー画面”、接続先でHTTPSが成立してもFQDN不一致なら“サーバ認証エラー画面”となります。
Q: 中間者攻撃を完全に防ぐには証明書検証だけで十分ですか？
A: 証明書検証は必須条件ですが、証明書ピンニングやHTTP Strict Transport Securityといった追加対策も有効です。
A: 証明書検証は必須条件ですが、証明書ピンニングやHTTP Strict Transport Securityといった追加対策も有効です。
関連キーワード: HTTPS, サーバ証明書、ルート証明書、コモンネーム、中間者攻撃
設問2：〔Sアプリでのサーバ証明書の検証不備による影響の検討〕について、(1)、(2)に答えよ。
問題文を見る模範解答
e：1、2、3、4
f：3
g：1
解説
解答の論理構成
-
表4の前提整理
- 発行者の検証不備 が「あり」のときは、発行者（CA）を問わずサーバ証明書を受け入れる。
- サブジェクトのコモンネームの検証不備 が「あり」のときは、FQDNを問わずサーバ証明書を受け入れる。
- 逆に「なし」の列は、該当項目を正しく検証する。
-
表3の証明書特徴を確認
- 証明書番号1 ：スマートフォンに対応している商用認証局 が発行し、攻撃者が所有しているドメインを使用したFQDNを持つ。
- 証明書番号2 ：発行者欄が空欄、FQDNも未記載（どちらも要件を満たさないとみなす）。
- 証明書番号3 ：攻撃者が準備するプライベート認証局 が発行し、SサーバのFQDNを持つ。
- 証明書番号4 ：発行者欄が空欄、上記二つ以外のFQDNを持つ。
-
表4各行に当てはめる
(1) 行1 e- 発行者検証・コモンネーム検証ともに不備がある (あり、あり)。
- どちらもチェックしないため、証明書番号1, 2, 3, 4のいずれでも通信成立。
- よって e = 1、2、3、4。
(2) 行2 f- 発行者検証は不備 (あり) だが、コモンネーム検証は実施 (なし)。
- FQDNがSサーバのFQDNである証明書だけが通過。
- 発行者は問わないので、条件を満たすのは 証明書番号3。
- よって f = 3。
(3) 行3 g- 発行者検証は実施 (なし)、コモンネーム検証は不備 (あり)。
- スマートフォンに信頼されたCAが発行していれば、FQDNは問わない。
- 条件を満たすのは 証明書番号1のみ。
- よって g = 1。
誤りやすいポイント
- 「商用認証局＝必ず安全」と早合点し、コモンネーム の照合を忘れると失点します。
- 証明書番号2と 証明書番号4は発行者欄が空欄のため、発行者検証を実施するケースでは当然失敗します。
- 発行者検証とコモンネーム検証を“両方無効化”すると、自己署名証明書でも通ってしまうことを見落としがちです。
FAQ
Q: 証明書番号3はプライベート認証局なので、スマートフォン側で失敗しませんか？
A: 表4行2は「発行者の検証不備＝あり」です。発行者を信頼するかどうかのチェック自体を行わないので、プライベート認証局発行でも通過します。
A: 表4行2は「発行者の検証不備＝あり」です。発行者を信頼するかどうかのチェック自体を行わないので、プライベート認証局発行でも通過します。
Q: 証明書番号1と 証明書番号4はどちらもFQDNが正しくありませんが、なぜ行3で1だけが採用されるのですか？
A: 行3では発行者検証を実施しているため、スマートフォンに信頼されていない証明書番号4は拒否されます。証明書番号1は信頼された商用認証局が発行しているため通過します。
A: 行3では発行者検証を実施しているため、スマートフォンに信頼されていない証明書番号4は拒否されます。証明書番号1は信頼された商用認証局が発行しているため通過します。
Q: 発行者検証もコモンネーム検証も両方行えば完全に安全ですか？
A: 通信経路上の中間者対策としては有効ですが、有効期限・失効情報 (CRL/OCSP) など他の項目も正しく検証しなければ完全とは言えません。
A: 通信経路上の中間者対策としては有効ですが、有効期限・失効情報 (CRL/OCSP) など他の項目も正しく検証しなければ完全とは言えません。
関連キーワード: HTTPS, 中間者攻撃、サーバ証明書、コモンネーム、認証局
設問2：〔Sアプリでのサーバ証明書の検証不備による影響の検討〕について、(1)、(2)に答えよ。
問題文を見る（2）本文中の下線①について、攻撃者が、W-APの設定をどのように細工すると、Sアプリの利用者のうち、公衆無線LANの利用者のスマートフォンを自動的にW-APに接続させることができてしまうか。W-APの設定上の細工を45字以内で具体的に述べよ。
模範解答
SSID、暗号化方式と事前共有鍵に、公衆無線LANで使用されているものを設定する。
解説
解答の導き方
- 問題の攻撃成功条件は「Sアプリの利用者が、図4中のW-APに接続する」であることを押さえます。図4は攻撃者がW-APやDNS/DHCPを準備できることを示しており、利用者端末が攻撃側のW-APに自動的に接続すれば中間者攻撃が成立します。
- スマートフォンがどのアクセスポイントに自動接続するかは端末側の無線LAN判定ルールで決まります。一般に端末は保存済みの接続情報と照合して接続先を決めます。端末は主にSSID・暗号方式・PSKで既知ネットワークを判定するが、BSSIDも識別情報として使われ得る。
- 攻撃者はW-APの周波数や電波強度、ビーコン内容（SSIDや暗号化方式の情報）を自由に設定でき、さらにDHCP/DNSで端末にIPや名前解決先を与えられます（図4の構成）。したがって、端末が「既知の公衆無線LAN」と判定して自動接続するように、W-AP側で認識要素を偽装すればよいことが分かります。
- 以上から、攻撃者がW-APのSSID、暗号化方式と事前共有鍵に、公衆無線LANで使用されているものを設定することで、該当する利用者のスマートフォンを自動的にW-APに接続させることができます。
誤りやすいポイント
- SSIDだけ同一にすれば自動接続されると考える誤り：端末は暗号化方式や事前共有鍵（PSK）との照合も行うため、これらが一致しないと自動接続しないことが多いです。
- BSSID（APのMAC）に関する誤認：ビーコンにはBSSIDが含まれ、端末は場合によってBSSIDで接続先を限定することがあるため、BSSIDの有無や差異で挙動が変わる点に注意が必要です。
- 公衆無線LAN＝常に暗号化なし（オープン）と決めつける誤り：オープン＋キャプティブポータルやWPA系のものなど種類があり、攻撃手法が変わります（キャプティブポータルはDHCP/DNSやHTTP誘導が必要）。
- アプリのTLS証明書検証と混同する誤り：今回の設問は端末の無線接続（W-APへの自動接続）について問われており、TLSの検証不備の有無は別の評価軸です。
FAQ
Q: SSIDのみを偽装しただけではダメですか？
A: 多くの場合は不十分です。端末はSSIDに加え暗号化方式と保存済みの事前共有鍵（PSK）を照合するため、これらも一致させる必要があります。
A: 多くの場合は不十分です。端末はSSIDに加え暗号化方式と保存済みの事前共有鍵（PSK）を照合するため、これらも一致させる必要があります。
Q: BSSIDを完全にコピー（MACクローン）する必要はありますか？
A: 場合によります。BSSIDを一致させれば一部の端末で成功率が上がりますが、SSID＋暗号化方式＋PSKが一致すれば多くの端末は接続します。BSSIDクローンは追加の手段です。
A: 場合によります。BSSIDを一致させれば一部の端末で成功率が上がりますが、SSID＋暗号化方式＋PSKが一致すれば多くの端末は接続します。BSSIDクローンは追加の手段です。
Q: 公衆無線LANがキャプティブポータルの場合、どう誘導しますか？
A: 攻撃側でDHCP/DNSを提供してHTTPの誘導先（偽ポータル）を返すことで、ユーザをログイン画面に誘導できます。ただし自動接続の成立は端末の設定依存です。
A: 攻撃側でDHCP/DNSを提供してHTTPの誘導先（偽ポータル）を返すことで、ユーザをログイン画面に誘導できます。ただし自動接続の成立は端末の設定依存です。
関連キーワード: SSID、暗号化方式、事前共有鍵、BSSID、自動接続
