令和7年度 春期 情報処理安全確保支援士試験 午後 問3 スマホアプリの脆弱性と証明書検証

テクノロジセキュリティ技術

この問題は2025(R7)春 情報処理安全確保支援士 午後に出題されたものです。出題時点の法令・制度に基づく内容のため、現行の内容と一致しない場合があります。

本ページの問題文・選択肢は、原本の体裁を Web 表示用に正規化しています(改行・記号・数式・図表参照の調整)。設問の趣旨および正解に影響する変更は加えていません。

学習ガイド

写真注文サービスのスマートフォンアプリを題材に、モバイルアプリ特有の脆弱性と対策を問う問題です。アプリに埋め込まれたアクセスキーの取得方法、TLSのサーバ証明書検証の不備、細工したURLによる攻撃など、JVNで実際に公表されてきた脆弱性の類型が登場します。本試験では正答率がやや低く、この記事では「アプリは攻撃者の手元で自由に解析できる」という前提から各脆弱性の成立条件を導いて解説します。

この記事で押さえる論点

  • アプリ内の秘密情報(アクセスキー)が取得される経路を説明する
  • サーバ証明書の検証不備とその修正(SAN・検証処理)を理解する
  • カスタムURLスキームなどアプリ特有の攻撃経路への対策を検討する

問題本文

問3 スマートフォン用アプリケーションプログラムの開発に関する次の記述を読んで,設問に答えよ。

A社は,撮影機器の販売や写真のプリントサービスを全国に200店舗で展開する従業員2,000名の企業である。実店舗の運営に加え,インターネットを介して撮影機器の販売を行うECサイト事業を有している。このたび,会員がスマートフォン(以下,スマホという)用アプリケーションプログラム(以下,スマホ用アプリケーションプログラムをスマホアプリという)を通じて,写真入りのカレンダーなどのグッズ(以下,フォトグッズという)を注文できるサービス(以下,Eサービスという)を新規に開始することになった。Eサービス用スマホアプリ(以下,Fアプリという)は国内で流通する主要なスマホOSであるOS-αとOS-βの過去5年以内に正式リリースされたバージョンをサポートする。

〔Eサービスの説明〕

Eサービスは,Fアプリとサーバサイドのシステム群で構成される。Fアプリは,インターネットを介してEサービス用Webサーバ(以下,A社Webサーバといい,FQDNはwww.a-sha.co.jpとする)及び大手クラウドサービスプロバイダC社のクラウドストレージサービス(以下,Cサービスという)との間でHTTPSを使用して通信する。フォトグッズの作成に使う写真は,FアプリからCサービスにアップロードする。Eサービスのネットワーク構成を図1に,機能概要を図2に,Fアプリの画面構成を図3に,フォトグッズの注文処理の流れを図4に,Cサービスの仕様を図5に示す。

図1 Eサービスのネットワーク構成(概要)
図の説明テキスト

構成要素と接続関係は以下の通り:

  • 「スマホ」枠内の「Fアプリ」から「インターネット」へ接続される。
  • 「インターネット」から「A社」枠内の「FW」へ接続される。
  • 「インターネット」から「Cサービス」へ接続される。
  • 「A社」枠内では、「FW」から「A社Webサーバ」へ接続され、「A社Webサーバ」から「DBサーバ」へ接続される。
    図の下部には注記として「FW:ファイアウォール DBサーバ:データベースサーバ」と記載されている。
図2 Eサービスの機能概要(抜粋)
図の説明テキスト
  1. 新規会員登録機能
    Eサービスを利用するための新規会員登録を行う。
  2. ログイン機能
    会員IDとパスワードでログインする。ログインした会員には、認証トークンが払い出され、ログアウトするまでの間、Fアプリに保存される。認証トークンは、A社Webサーバ上で会員のセッションを識別するために使用する推測困難な値である。
  3. フォトグッズ注文機能
    Fアプリ上でフォトグッズを注文する。ログイン済み会員だけが利用できる。なお、フォトグッズは、指定したA社の実店舗で受け取ることができる。
  4. キャンペーン案内機能
    キャンペーンのWebページ(以下、キャンペーンページという)を表示する。ログイン済み会員だけが利用できる。なお、キャンペーンに応募することによって、フォトグッズの割引などに利用可能なクーポンを入手できる。会員には、電子メール(以下、メールという)などを通じて、期間限定のキャンペーンを案内する。キャンペーンの内容は、2週間ごとに更新される。
    注1) 認証トークンは、ログイン後にFアプリがA社WebサーバにHTTPリクエストを送信する際、Authorizationヘッダーに指定される。
図3 Fアプリの画面構成(抜粋)
図の説明テキスト

初期画面、ログイン画面、ホーム画面、キャンペーン案内画面の4つの画面枠と、それらの間の遷移が示されている。
・初期画面: 「新規会員登録へ」ボタンと「ログイン画面へ」ボタンがあり、「ログイン画面へ」からログイン画面への実線矢印がある。
・ログイン画面: 会員ID・パスワード入力欄と「ログイン」ボタンがあり、「ログイン」ボタンからホーム画面への破線矢印がある。
・ホーム画面: 「フォトグッズ注文」「キャンペーン案内」「ログアウト」ボタンがあり、「キャンペーン案内」ボタンからキャンペーン案内画面への実線矢印がある。
・キャンペーン案内画面: 破線の枠で囲まれ「キャンペーンページ」と記載。
凡例: 実線矢印(→)はボタンが押下されたときの画面遷移、破線矢印(-→)は適切な値を入力してボタンが押下されたときの画面遷移。
注記: キャンペーンページはHTML形式で作成し、A社Webサーバにアップロードしておく。

図4 フォトグッズの注文処理の流れ
図の説明テキスト

Fアプリ、A社Webサーバ、Cサービスの3つのライフライン間のやり取りを示すシーケンス図。

  • FアプリからA社Webサーバへ「フォトグッズを注文」メッセージを送信。
  • A社Webサーバで処理が開始され、「注文内容をDBサーバに登録し、注文番号を採番」して処理へ移行。
  • A社WebサーバのからFアプリへ「注文番号を通知」メッセージを送信し、Fアプリで処理が開始。
  • Fアプリ内で「写真を "nnnnnnnn.zip" というファイル名でZIP形式に圧縮」し、処理へ移行。
  • FアプリのからCサービスへ「nnnnnnnn.zipをアップロード」メッセージを送信し、Cサービスで処理が開始。
  • CサービスのからFアプリへ「アップロード成功を通知」メッセージを送信。
    下部に「注記 "nnnnnnnn" は注文番号であり,00000001から始まる十進数の連番である。」というテキストがある。
図5 Cサービスの仕様(抜粋)
図の説明テキスト
  1. サービスの概要
    (1) Cサービスはマルチテナントのストレージサービスである。テナントの管理権限をもつ利用者(以下、管理者という)が作成したストレージに対し、テナントの作成したシステム(以下、利用システムという)からファイルのアップロードやダウンロード(以下、アップロード、ダウンロードを併せてファイル操作という)を行う。
    (2) 管理者は、ストレージの作成時に任意のストレージ名を設定する。ストレージを作成すると、Cサービスからアクセスキーが発行される。アクセスキーはストレージごとに異なる40字の英数字である。
    (3) 利用システムは、ストレージ上のファイルをURLのパスで指定する。例えば、ストレージ“●●●”上のファイル“▲▲▲”をファイル操作する際は、“/●●●/▲▲▲”を指定する。ファイルのアップロードにはHTTPのPUTメソッドを、ファイルのダウンロードにはGETメソッドを用いる。
    (4) 利用システムは、次の方式a又は方式bでファイル操作を行う。

  2. 方式a
    (1) 説明
    アクセスキーをHTTPリクエストのAuthorizationヘッダーに指定する方式である。利用システムは、Cサービスから発行されたアクセスキーを用いることによって、アクセスキーに対応するストレージに格納された全てのファイルに対するファイル操作が可能となる。Authorizationヘッダーに正しいアクセスキーが指定されていない場合、ファイル操作は拒否される。

図5 Cサービスの仕様(抜粋)(続き)
図の説明テキスト
  1. 方式a (続き)
    (2) 使用例
    アクセスキー“○○○”を指定して、ストレージ“abc”上のファイル“xyz”をダウンロードする際に送信するHTTPリクエストの例を次に示す。
    リクエストライン : GET /abc/xyz HTTP/1.1
    ヘッダーフィールド : Host: storage.c-sha.jp
    Authorization: Bearer ○○○

  2. 方式b
    (1) 説明
    有効期限 (Expires) と署名値 (Signature) をクエリパラメータとして付加したURL(以下、署名付きURLという)を用いて、特定のファイルに対するファイル操作を一時的に可能とする方式である。ここで、Expiresパラメータに指定する有効期限はUNIXタイムスタンプ形式である。署名値の生成は次のように行う。
    (i) GET又はPUTから始まり、パス中の“/●●●/▲▲▲?Expires={有効期限}”で終わる文字列を署名対象文字列とする。
    (ii) アクセスキーを秘密鍵とする。
    (iii) 署名対象文字列と秘密鍵からHMAC-SHA256値を求める。
    (iv) (iii)で求めた値をbase64urlエンコードする。
    利用システムは、署名付きURLを生成し、ファイル操作を許可する利用者に伝える。伝えられた利用者は、署名付きURLを指定してHTTPリクエストを送ることによって、ファイル操作ができる。有効期限が切れた場合やサーバ側で署名値の検証が失敗した場合は、ファイル操作が拒否される。

(2) 使用例
ストレージ“abc”上のファイル“xyz”をダウンロードする場合で、かつ、署名値が“△△△”の場合のHTTPリクエストの例を次に示す。xyzは、日本時間の2025年5月30日0時0分0秒、つまりUNIXタイムスタンプで1748530800までの間、ダウンロードが許可されている。
リクエストライン : GET /abc/xyz?Expires=1748530800&Signature=△△△ HTTP/1.1
ヘッダーフィールド : Host: storage.c-sha.jp

Eサービスで使うCサービスのストレージ名は,e-serviceである。Fアプリでは,方式aを利用する。アクセスキーは,鍵長256ビットの共通鍵とAES-CBCアルゴリズムで暗号化し,Fアプリ内にリソースとして保存する。Cサービスのストレージ名並びにAES-CBCの共通鍵及び初期ベクトルは,Fアプリのコード中に定数として定義する。

〔キャンペーン案内機能の実装方法〕

Fアプリでのキャンペーンページの表示には,WebViewという仕組みを用いる。WebViewは,スマホOSの提供する仕組みであり,スマホアプリの画面の一部にWebページを表示させることができる。キャンペーンページのHTMLは, WebViewを用いて, Fアプリの画面上に表示させる。

会員に送るキャンペーン案巨大的メール本文中には, Fアプリでキャンペーンページを表示するためのURL(以下, F-URLという)を含める。会員がメールアプリからF-URLを開くと, Fアプリが起動し, WebView上にキャンペーンページが表示される。キャンペーンページからキャンペーンに応募する際の会員のセッションの識別には, Fアプリに保存されている認証トークンを用いる。OS-αでは, キャンペーンページが表示された後に, WebViewの機能によってキャンペーンページ上のECMAScriptコードがFアプリのgetToken関数を呼び出す。これによって, 認証トークンがFアプリからキャンペーンページに引き渡される。OS-βでは別の方式で同様の機能を実現する。キャンペーンページ上のECMAScriptコードを図6に示す。

図6 キャンペーンページ上のECMAScriptコード
図の説明テキスト

const token = f_app.getToken();

キャンペーンページ以外からgetToken関数を悪用されないように, getToken関数の内部では, 図7のように呼出し元のWebページのURLを確認する。

図7 getToken関数の処理の流れ
図の説明テキスト
  • 開始から条件判定「呼出し元のWebページのURLの先頭は "https://www.a-sha.co.jp" か。」へ。
  • Yesの場合: 「認証トークンを返す。」へ遷移。
  • Noの場合: 「空文字列、つまり長さ0の文字列を返す。」へ遷移。
  • 両方から終了へ遷移。

F-URLの例を図8に示す。

図8 F-URLの例
図の説明テキスト

f-app://campaign?url=https://www.a-sha.co.jp/campaign/□□□
注記1 "f-app" はカスタム URL スキームである。
注記2 "□□□" はキャンペーンページの URL のパスである。

〔Fアプリの脆弱性診断結果〕

A社は,セキュリティ専門会社のD社に依頼してFアプリの脆弱性診断を実施した。

その結果,表1に示す脆弱性が検出された。

表1 脆弱性診断結果(抜粋)
図の説明テキスト
脆弱性 脆弱性の概要 解説
1 サーバ証明書の検証不備がある。 F アプリは,HTTPS でサーバと接続する際,サーバ証明書の検証エラーがあっても無視し,通信を続行する。そのため,HTTPS 通信の内容が盗聴されたり,改ざんされたりするおそれがある。盗聴されると,盗聴した内容からアクセスキーとストレージ名を攻撃者が取得するおそれがある。
(省略)
2 C サービスのアクセスキーの保護に不備がある。 攻撃者が F アプリから平文のアクセスキーとストレージ名を取得できる。そのアクセスキーを用いて,攻撃者が E サービスの全利用者の写真を不正にダウンロードするおそれがある。
(省略)
3 F-URL の処理にアクセス制御の不備がある。 F-URL の url クエリパラメータに,細工した URL が指定されることによって,攻撃者の Web サイトにアクセスしてしまうおそれがある。また,攻撃者が会員の認証トークンを取得するおそれがある。
(省略)

〔脆弱性1〕

Fアプリの開発チームに所属するUさんは,D社のSさんが開催する診断結果報告会に参加した。

Uさんは,脆弱性1が作り込まれた経緯を説明した。Uさんによると,FアプリとA社Webサーバとの間の通信内容に異常がないかどうかを調査するために,開発用PCで通信解析ツールを利用した。この通信解析ツールはプロキシサーバとして動作する。このツールを利用すると,Fアプリでは,サーバ証明書の検証エラーが発生し,FアプリとA社Webサーバとの間の通信が中断されてしまった。そこで,インターネット上のある記事でエラーが発生しても通信を続行する方法が紹介されていたのを参考にして,Fアプリのコードを変更したということであった。
この通信解析ツールを利用し,“https://www.a-sha.co.jp/campaign/□□□”にアクセスした際のレイヤー4〜7の通信フローの例を図9に示す。

図9 通信解析ツールを利用した際の通信フローの例(抜粋)
図の説明テキスト

「スマホ」「通信解析ツール」「A社Webサーバ」の3者間の通信シーケンス図。
・スマホと通信解析ツール間で「TCPの3ウェイハンドシェイク」
・スマホから通信解析ツールへaを送信
・通信解析ツールからスマホへbを送信
・スマホから通信解析ツールへcを送信
・スマホと通信解析ツール間で「TLSハンドシェイク」
 ・通信解析ツール側で「サーバ証明書を生成 1)」
 ・通信解析ツールからスマホへ次の順にまとめて送信: (1)d、(2)Encrypted Extensions、(3)e、(4)f、(5)g
 ・スマホから通信解析ツールへgを送信
 ・スマホから通信解析ツールへhを送信
・通信解析ツールとA社Webサーバ間で「TCPの3ウェイハンドシェイク」
・通信解析ツールとA社Webサーバ間で「左記のTLSハンドシェイクと同様のフロー」
・通信解析ツールからA社Webサーバへhを送信
・A社Webサーバから通信解析ツールへbを送信
・通信解析ツールからスマホへbを送信

注記: 通信解析ツールのプライベートIPアドレスは、○○○.○○○.○○○.○○○とする。
注1) 通信解析ツールは、自身のプライベート認証局機能を用いる。

Uさんは,通信解析ツールを利用してテストを行う際も通信を正常に続行させる方法をチーム内で話し合った。その結果,今後,開発用のスマホに必要な設定を行うことにした。加えて,OS-αではテストを行う際だけその設定を有効化するように,Fアプリの中にも設定を追加した。

〔脆弱性2〕

脆弱性2への対応について,Sさんからは方式bを利用し,その際に署名付きURLの生成を図4中の i の時点で行ってはどうかとの提案があった。UさんはSさんの提案を了承した。

〔脆弱性3〕

次は,脆弱性3についてのUさんとSさんの会話である。

Uさん:対策として,図7の処理を修正します。
Sさん:図7の処理を修正すれば,認証トークンを盗まれるリスクは回避できます。しかし,Webブラウザと比べると,フィッシングサイトにアクセスしてしまっても気付くことができないというFアプリの仕様上の問題点が残ります。フィッシングサイトに気付くことができるようにするための機能か,そもそもフィッシングサイトにアクセスできないようにする機能が必要です。
Uさん:はい。図7の処理の修正に加えて,フィッシングサイトにアクセスできないようにする機能を実装します。

A社は,検出された脆弱性を修正し,Eサービスの提供を開始した。

設問と解答・解説

設問1

(1)

表1中の下線①について,アクセスキーを取得する方法を,具体的に答えよ。

模範解答

Cサービスに送られたHTTPリクエストのAuthorizationヘッダーから取り出す。

採点基準(配点 4点)

知識・理解度(内容)(2点)

  • 2: CサービスへのHTTPリクエストに含まれるAuthorizationヘッダーから取得することが正確に記述されている。
  • 1: HTTPリクエストやヘッダーから取得することに言及しているが、CサービスやAuthorizationヘッダーの特定が不十分である。
  • 0: 無回答、または内容が不適切である。

論理性(構造)(2点)

  • 2: アクセスキーを取得する流れが論理的かつ具体的に説明されている。
  • 1: 取得の流れがやや抽象的であるが、文意は通じる。
  • 0: 論理性がなく、意味が通じない。

解説

対象となる脆弱性と攻撃手法を理解し、通信経路上からどのように取得するかを答える問題です。

Cサービスとの通信に用いられるHTTPリクエストのヘッダー情報、特に Authorizationヘッダー に着目します。

高得点のポイント

  • どの通信から取得するか(CサービスへのHTTPリクエスト)

  • どのヘッダーから取得するか(Authorizationヘッダー)

(2)

表1中の下線②について,アクセスキーを取得する方法を,具体的に答えよ。

模範解答

Fアプリを解析し,暗号化されたアクセスキー並びに共通鍵及び初期ベクトルを入手し,暗号化されたアクセスキーをAES-CBCで復号する。

採点基準(配点 4点)

知識・理解度(内容)(2点)

  • 2: アプリを解析して共通鍵等を抽出し、AES-CBCで復号することが正確に記述されている。
  • 1: アプリの解析や復号に言及しているが、必要な情報や復号アルゴリズムの記載が不足している。
  • 0: 内容が不適切である。

論理性(構造)(2点)

  • 2: 情報の抽出から復号までの手順が論理的かつ明確に説明されている。
  • 1: 手順の説明がやや曖昧であるが、大枠の流れは読み取れる。
  • 0: 手順が論理的に破綻している。

解説

スマホアプリ内に保存された暗号化データの復号手法を問う問題です。

Fアプリのリバースエンジニアリング等の解析を通して、必要な情報を抽出する必要があります。

高得点のポイント

  • アプリを解析し、暗号化されたアクセスキー、共通鍵、初期ベクトルを入手すること

  • 入手した情報を用いて、暗号化されたアクセスキーを AES-CBC で復号すること

(3)

表1中の下線③について,ダウンロードする方法を,具体的に答えよ。

模範解答

ファイル名に含まれる注文番号を00000001から順に増やしてダウンロードを試行する。

採点基準(配点 4点)

知識・理解度(内容)(2点)

  • 2: ファイル名に含まれる注文番号を利用し、連番でダウンロードを試行することが正確に記述されている。
  • 1: 推測を用いたダウンロードに言及しているが、注文番号や連番を利用する具体的な方法が不足している。
  • 0: 内容が不適切である。

論理性(構造)(2点)

  • 2: 攻撃者が総当たりで試行するプロセスが論理的かつ具体的に記述されている。
  • 1: プロセスがやや抽象的であるが、試行の流れは読み取れる。
  • 0: 論理性がなく、意味が通じない。

解説

推測可能なファイル名に対する攻撃(IDORの一種)の方法を問う問題です。

注文番号が連番であることを悪用し、総当たり的にファイルへのアクセスを試みるプロセスを説明します。

高得点のポイント

  • ファイル名に含まれる注文番号を利用すること

  • 注文番号を連番(00000001から順に)で増やしてダウンロードを試行すること

(4)

表1中の下線④について,攻撃者のWebサイトにアクセスさせることができるように細工したURLの例を,攻撃者が取得したドメイン名を k-sha.co.jp とした場合で答えよ。

採点基準(配点 4点)

知識・理解度(内容)(2点)

  • 2: 正規のドメイン名と攻撃者のドメイン名(k-sha.co.jp)を組み合わせた細工されたURLの例が正確に記述されている。
  • 1: ドメインの組み合わせに言及しているが、URLの例としての記述が不完全である。
  • 0: 内容が不適切である。

論理性(構造)(2点)

  • 2: 利用者が正規サイトと誤認するようなURL構造として論理的に妥当である。
  • 1: 誤認させる意図は読み取れるが、URL構造の妥当性にやや欠ける。
  • 0: URLとしての構造を満たしていない。

解説

フィッシングにおいて利用者を騙すために細工されたURLの例を作成する問題です。

攻撃者のドメイン k-sha.co.jp を用いながら、正規のドメイン www.a-sha.co.jp と誤認させる構成を考えます。

高得点のポイント

  • 正規のドメインと攻撃者のドメインを組み合わせたURLの構造となっていること(サブドメインの悪用や @ の利用など)

設問1(3)は,正答率が低かった。クラウドストレージサービスのアクセスキーを不正利用することによって,ストレージ上の全利用者の写真をダウンロードする具体的な方法を問う問題であったが,抽象的な解答が散見された。設問文をよく読んで解答してほしい。

設問2

〔脆弱性1〕について答えよ。

(1)

図9中の下線⑤について,サーバ証明書の Subject Alternative Name の値を,具体的に答えよ。

模範解答

www.a-sha.co.jp

採点基準(配点 4点)

知識・理解度(内容)(2点)

  • 2: Subject Alternative Nameの値として「www.a-sha.co.jp」が正確に記述されている。
  • 1: 該当のドメイン名を含んでいるが、余分な文字が含まれているなど不正確である。
  • 0: 内容が不適切である。

論理性(構造)(2点)

  • 2: 指定された値を適切に提示している。
  • 0: 解答の形式をなしていない。

解説

サーバ証明書の検証メカニズムにおいて、どの値をチェックするかを問う問題です。

通信解析ツール(中間者)がクライアントを騙すためには、クライアントが本来接続しようとしているホスト名(FQDN)を証明書の SAN に記載する必要があります。

高得点のポイント

  • 対象となるFQDN www.a-sha.co.jp が正確に記載されていること

(2)

図9中の a に入れる適切な字句を,解答群の中から選び,記号で答えよ。

  1. Certificate
  2. Certificate Verify
  3. Client Hello
  4. CONNECT 〇〇〇.〇〇〇.〇〇〇.〇〇〇:443 HTTP/1.1
  5. CONNECT www.a-sha.co.jp:443 HTTP/1.1
  6. Finished
  7. GET /campaign/□□□ HTTP/1.1
  8. HTTPステータスコード 101 (Switching Protocols)
  9. HTTPステータスコード 200 (OK)
  10. Server Hello

模範解答

選択肢オ: CONNECT www.a-sha.co.jp:443 HTTP/1.1

配点 2

解説

TLSインスペクション(HTTPS通信の傍受)時のシーケンスに関する問題です。

HTTPプロキシ経由でのHTTPS通信では、まず CONNECT メソッドでプロキシにトンネルの確立を要求します。

各選択肢の解説

  • オ (CONNECT www.a-sha.co.jp:443 HTTP/1.1): クライアントがプロキシに対して正規サーバへの接続要求を行うため、これが正解です。

  • その他の選択肢: TLSハンドシェイクの一部や通常のHTTPリクエストであり、この段階でのトンネル確立要求としては不適切です。

(3)

図9中の b に入れる適切な字句を,解答群の中から選び,記号で答えよ。

  1. Certificate
  2. Certificate Verify
  3. Client Hello
  4. CONNECT 〇〇〇.〇〇〇.〇〇〇.〇〇〇:443 HTTP/1.1
  5. CONNECT www.a-sha.co.jp:443 HTTP/1.1
  6. Finished
  7. GET /campaign/□□□ HTTP/1.1
  8. HTTPステータスコード 101 (Switching Protocols)
  9. HTTPステータスコード 200 (OK)
  10. Server Hello

模範解答

選択肢ケ: HTTPステータスコード 200 (OK)

配点 2

解説

CONNECTメソッドに対するプロキシからの応答に関する問題です。

トンネルの確立に成功した場合、プロキシは成功を示すステータスコードを返します。

各選択肢の解説

  • ケ (HTTPステータスコード 200 (OK)): 接続が確立されたことを示すため正解です。

  • ク (HTTPステータスコード 101): プロトコルの切り替えに用いられますが、CONNECTメソッドの成功応答としては200が適切です。

  • その他の選択肢: 応答コードではなくリクエストやTLSのメッセージであるため不適切です。

(4)

図9中の c に入れる適切な字句を,解答群の中から選び,記号で答えよ。

  1. Certificate
  2. Certificate Verify
  3. Client Hello
  4. CONNECT 〇〇〇.〇〇〇.〇〇〇.〇〇〇:443 HTTP/1.1
  5. CONNECT www.a-sha.co.jp:443 HTTP/1.1
  6. Finished
  7. GET /campaign/□□□ HTTP/1.1
  8. HTTPステータスコード 101 (Switching Protocols)
  9. HTTPステータスコード 200 (OK)
  10. Server Hello

模範解答

選択肢ウ: Client Hello

配点 2

解説

トンネル確立後のTLSハンドシェイクの開始に関する問題です。

クライアント側から暗号化通信の開始を要求するメッセージが送信されます。

各選択肢の解説

  • ウ (Client Hello): TLSハンドシェイクの開始を宣言するクライアントからのメッセージであり正解です。

  • コ (Server Hello): サーバ側からの応答メッセージです。

  • その他の選択肢: ハンドシェイクの他のステップやHTTPリクエストであるため不適切です。

(5)

図9中の d に入れる適切な字句を,解答群の中から選び,記号で答えよ。

  1. Certificate
  2. Certificate Verify
  3. Client Hello
  4. CONNECT 〇〇〇.〇〇〇.〇〇〇.〇〇〇:443 HTTP/1.1
  5. CONNECT www.a-sha.co.jp:443 HTTP/1.1
  6. Finished
  7. GET /campaign/□□□ HTTP/1.1
  8. HTTPステータスコード 101 (Switching Protocols)
  9. HTTPステータスコード 200 (OK)
  10. Server Hello

模範解答

選択肢コ: Server Hello

配点 2

解説

TLSハンドシェイクにおいて、クライアントの要求に対するサーバ(ここでは通信解析ツール)の応答です。

暗号化方式の合意などを伝えるメッセージが送信されます。

各選択肢の解説

  • コ (Server Hello): Client Helloに対するサーバ側の応答メッセージであり正解です。

  • ウ (Client Hello): クライアントからのメッセージです。

  • その他の選択肢: 証明書の提示など他のフェーズのメッセージであるため不適切です。

(6)

図9中の e に入れる適切な字句を,解答群の中から選び,記号で答えよ。

  1. Certificate
  2. Certificate Verify
  3. Client Hello
  4. CONNECT 〇〇〇.〇〇〇.〇〇〇.〇〇〇:443 HTTP/1.1
  5. CONNECT www.a-sha.co.jp:443 HTTP/1.1
  6. Finished
  7. GET /campaign/□□□ HTTP/1.1
  8. HTTPステータスコード 101 (Switching Protocols)
  9. HTTPステータスコード 200 (OK)
  10. Server Hello

模範解答

選択肢ア: Certificate

配点 2

解説

TLSハンドシェイクにおいて、サーバの身元を証明するフェーズです。

サーバ側は自身の公開鍵を含んだ証明書をクライアントに提示します。

各選択肢の解説

  • ア (Certificate): サーバ証明書を提示するメッセージであり正解です。

  • イ (Certificate Verify): 証明書の所有を証明するための別のメッセージです。

  • その他の選択肢: 役割が異なるため不適切です。

(7)

図9中の f に入れる適切な字句を,解答群の中から選び,記号で答えよ。

  1. Certificate
  2. Certificate Verify
  3. Client Hello
  4. CONNECT 〇〇〇.〇〇〇.〇〇〇.〇〇〇:443 HTTP/1.1
  5. CONNECT www.a-sha.co.jp:443 HTTP/1.1
  6. Finished
  7. GET /campaign/□□□ HTTP/1.1
  8. HTTPステータスコード 101 (Switching Protocols)
  9. HTTPステータスコード 200 (OK)
  10. Server Hello

模範解答

選択肢イ: Certificate Verify

配点 2

解説

証明書の提示に付随して行われる署名の検証フェーズです。

各選択肢の解説

  • イ (Certificate Verify): 提示した証明書に対応する秘密鍵を持っていることを証明するメッセージであり正解です。

  • ア (Certificate): 証明書そのものの提示です。

  • その他の選択肢: ハンドシェイクの他のフェーズであるため不適切です。

(8)

図9中の g に入れる適切な字句を,解答群の中から選び,記号で答えよ。

  1. Certificate
  2. Certificate Verify
  3. Client Hello
  4. CONNECT 〇〇〇.〇〇〇.〇〇〇.〇〇〇:443 HTTP/1.1
  5. CONNECT www.a-sha.co.jp:443 HTTP/1.1
  6. Finished
  7. GET /campaign/□□□ HTTP/1.1
  8. HTTPステータスコード 101 (Switching Protocols)
  9. HTTPステータスコード 200 (OK)
  10. Server Hello

模範解答

選択肢カ: Finished

配点 2

解説

TLSハンドシェイクの最終段階に関する問題です。

鍵交換と検証が完了し、以降の通信が暗号化されることを確認します。

各選択肢の解説

  • カ (Finished): ハンドシェイクが正常に完了したことを示すメッセージであり正解です。

  • その他の選択肢: ハンドシェイク完了前のメッセージやアプリケーションデータであるため不適切です。

(9)

図9中の h に入れる適切な字句を,解答群の中から選び,記号で答えよ。

  1. Certificate
  2. Certificate Verify
  3. Client Hello
  4. CONNECT 〇〇〇.〇〇〇.〇〇〇.〇〇〇:443 HTTP/1.1
  5. CONNECT www.a-sha.co.jp:443 HTTP/1.1
  6. Finished
  7. GET /campaign/□□□ HTTP/1.1
  8. HTTPステータスコード 101 (Switching Protocols)
  9. HTTPステータスコード 200 (OK)
  10. Server Hello

模範解答

選択肢キ: GET /campaign/□□□ HTTP/1.1

配点 2

解説

TLSハンドシェイク完了後に行われる実際のアプリケーションレイヤの通信です。

暗号化されたトンネル内でHTTPリクエストが送信されます。

各選択肢の解説

  • キ (GET /campaign/□□□ HTTP/1.1): 実際のWebコンテンツを取得するためのHTTPリクエストであり正解です。

  • その他の選択肢: トンネルの確立やTLSのメッセージであり、暗号化通信路確立後のアプリケーションデータとしては不適切です。

(10)

本文中の下線⑥について,設定の内容を,具体的に答えよ。

模範解答

通信解析ツールのプライベート認証局のルート証明書をインストールし,信頼設定を行う。

採点基準(配点 4点)

知識・理解度(内容)(2点)

  • 2: 通信解析ツールのプライベート認証局のルート証明書をインストールし、信頼設定を行うことが正確に記述されている。
  • 1: 証明書のインストールに言及しているが、対象の証明書の特定や信頼設定の記述が不足している。
  • 0: 内容が不適切である。

論理性(構造)(2点)

  • 2: 設定を行う手順と対象が論理的かつ明確に説明されている。
  • 1: 設定の手順がやや抽象的であるが、意図は読み取れる。
  • 0: 設定の論理性が破綻している。

解説

TLSインスペクションにおいて、端末側で証明書エラーを回避するための設定を問う問題です。

通信解析ツールが発行する偽の証明書を端末に信頼させる必要があります。

高得点のポイント

  • 通信解析ツールのプライベート認証局のルート証明書をインストールすること

  • 端末でその証明書を信頼する設定を行うこと

設問2(3)は,正答率が低かった。プライベート認証局のルート証明書を端末にインストールすることによって,サーバ証明書の検証エラーを解消させる方法を問う問題であった。同様の方法は,ネットワーク機器のTLSインスペクション機能などでも利用されるので,理解してほしい。

設問3

本文中の i に入れる記号を,図4中の(あ)〜(お)から選び,答えよ。

模範解答

選択肢イ: い

配点 2

解説

署名付きURLを用いた安全なアクセス制御のアーキテクチャ設計を問う問題です。

署名を生成するためには秘密鍵が必要であり、これをクライアント(スマホアプリ)側に持たせることは解析・漏洩のリスクが高くなります。

各選択肢の解説

  • イ (い): 秘密鍵を安全に管理できるサーバ側(A社Webサーバ)で生成し、クライアントに渡す設計が正しいため正解です。

  • ア, ウ, エ, オ: アプリや不適切な経路上での生成は、秘密鍵の漏洩や攻撃者による改ざんリスクを伴うため不適切です。

設問3は,正答率が平均的であった。署名付きURLの適切な生成場所を解答させる問題であったが,攻撃者による解析が容易なスマホアプリ上という解答が散見された。秘密情報の処理をサーバ上で完結させ安全を確保する実装は,クライアントサーバ型でも採用される基本的な方法なので,理解してほしい。

設問4

〔脆弱性3〕について答えよ。

(1)

本文中の下線⑦について,問題点を,20字以内で答えよ。

模範解答

URLを確認する手段がない。

採点基準(配点 4点)

知識・理解度(内容)(2点)

  • 2: 利用者が現在のURLを確認する手段がないという問題点が的確に記述されている。
  • 1: アドレスバーやURLの表示について言及しているが、問題の核心がやや曖昧である。
  • 0: 内容が不適切である。

論理性(構造)(2点)

  • 2: 指定文字数内で簡潔かつ論理的に意味が通じる文章で構成されている。
  • 1: 意味は通じるが、やや冗長または不自然な表現が含まれる。
  • 0: 文章として成立していない。

解説

スマホアプリ内のWebViewを用いる際のセキュリティ上の課題を問う問題です。

WebViewは標準のブラウザアプリとは異なり、アドレスバーが表示されないことが多く、フィッシングサイトに気づきにくいという問題があります。

高得点のポイント

  • URLを確認できないという事実を20字以内で簡潔に表現すること

(2)

本文中の下線⑧について,実装する機能を,具体的に答えよ。

模範解答

WebViewを呼び出す前に,URLの先頭がhttps://www.a-sha.co.jp/であるかを検証する。

採点基準(配点 4点)

知識・理解度(内容)(2点)

  • 2: WebView呼び出し前に、URLの先頭が正規のもの(https://www.a-sha.co.jp/)であるかを検証することが正確に記述されている。
  • 1: URLの検証に言及しているが、検証のタイミングや対象とする正規URLの記述が不足している。
  • 0: 内容が不適切である。

論理性(構造)(2点)

  • 2: 実装すべき機能の動作フローが論理的かつ具体的に説明されている。
  • 1: 動作フローがやや抽象的であるが、対策の意図は読み取れる。
  • 0: 論理性が破綻している。

解説

カスタムURLスキームの悪用を防ぐための実装上の対策を問う問題です。

外部から渡されたURLをそのままWebViewで開くのではなく、アクセス先が正規のドメインに限定されているかを事前に検証する必要があります。

高得点のポイント