令和7年度春期情報処理安全確保支援士（午後試験問3）解説

Last updated at 2026-10-30Posted at 2026-10-29

令和7年度春期情報処理安全確保支援士（午後試験問3）解説

テーマ: スマートフォンアプリ・クラウドストレージ・アクセスキー・署名付きURL・AES-CBC・HMAC-SHA256・TLS・プロキシ・サーバ証明書検証・WebView・カスタムURLスキーム・フィッシング対策

この問題の全体像
本問は、写真をクラウドストレージへアップロードするスマートフォンアプリ「Fアプリ」を題材に、秘密情報の保護、クラウドストレージのアクセス制御、TLS通信の検証、WebViewとカスタムURLスキームの安全な実装を問う問題です。個別の暗号技術を暗記するだけでなく、「攻撃者がどの情報を、どこから入手し、どの権限で何を実行できるか」を通信経路と処理順序に沿って整理することが重要です。

表記について
「問題文からの引用」は、問題冊子の本文、表又は図から、解答根拠となる箇所を引用形式で示しています。引用後の「着眼点・注目ポイント」で読み方を整理し、その後に正解と解説を示します。

設問1 〔Fアプリの脆弱性診断結果〕について

1. (1) 下線①のアクセスキーを取得する方法について

問題文からの引用

「Fアプリは，HTTPSでサーバと接続する際，サーバ証明書の検証エラーがあっても無視し，通信を続行する。」

「盗聴されると，盗聴した内容からアクセスキーとストレージ名を攻撃者が取得するおそれがある。」

「アクセスキーをHTTPリクエストのAuthorizationヘッダーに指定する方式である。」

着眼点・注目ポイント
方式aでは、アクセスキーがAuthorizationヘッダーでCサービスへ送信されます。サーバ証明書の検証エラーを無視すると、攻撃者が偽のサーバ証明書を使って通信を中継し、Fアプリが送信したHTTPリクエストの内容を取得できる可能性があります。

正解: Cサービスに送られたHTTPリクエストのAuthorizationヘッダーから取り出す。
解説: FアプリがCサービスへ写真をアップロードする際、方式aではアクセスキーをAuthorizationヘッダーに入れます。サーバ証明書を正しく検証しない実装では、攻撃者が通信を中継して偽の証明書を提示してもFアプリが通信を継続します。その結果、攻撃者はFアプリとCサービスの間の通信内容を読み取り、Authorizationヘッダーにあるアクセスキーを取得できます。

重要: HTTPSを使用しているだけでは安全とは限りません。接続先が正規のサーバであることを確認するサーバ証明書検証が不可欠です。

2. (2) 下線②のアクセスキーを取得する方法について

問題文からの引用

「アクセスキーは，鍵長256ビットの共通鍵とAES-CBCアルゴリズムで暗号化し，Fアプリ内にリソースとして保存する。」

「Cサービスのストレージ名並びにAES-CBCの共通鍵及び初期ベクトルは，Fアプリのコード中に定数として定義する。」

着眼点・注目ポイント
暗号化済みアクセスキーだけでなく、その復号に必要な共通鍵と初期ベクトルもFアプリ内にあります。攻撃者はアプリを解析して、三つの情報を取得できます。

正解: Fアプリを解析し，暗号化されたアクセスキー並びに共通鍵及び初期ベクトルを入手し，暗号化されたアクセスキーをAES-CBCで復号する。
解説: スマートフォンアプリは利用者の端末へ配布されるため、攻撃者はアプリのコードやリソースを解析できます。本問では、暗号文、共通鍵、初期ベクトルの全てがFアプリ内に存在します。そのため、アクセスキーを暗号化して保存しても、攻撃者は必要な情報を取り出し、Fアプリと同じAES-CBCの復号処理を再現できます。

対策上の教訓: アプリ内へ固定の秘密鍵やアクセスキーを埋め込んでも、端末利用者から完全に秘匿することは困難です。固定の長期秘密情報を配布アプリへ持たせない設計が重要です。

3. (3) 下線③で全利用者の写真をダウンロードする方法について

問題文からの引用

「“nnnnnnnn”は注文番号であり，00000001から始まる十進数の連番である。」

「利用システムは，Cサービスから発行されたアクセスキーを用いることによって，アクセスキーに対応するストレージに格納された全てのファイルに対するファイル操作が可能となる。」

着眼点・注目ポイント
攻撃者はアクセスキーとストレージ名を取得済みです。写真のZIPファイル名は推測可能な連番なので、ファイル名を順番に変えてGETを繰り返せます。

正解: ファイル名に含まれる注文番号を00000001から順に増やしてダウンロードを試行する。
解説: ストレージ名はe-service、ファイル名は注文番号に.zipを付けた形式です。方式aのアクセスキーは、対応するストレージ内の全ファイルを操作できるため、攻撃者は00000001.zip、00000002.zipのようにファイル名を順番に変えながらGETを試行できます。注文番号が連番であることが、大量取得を容易にしています。

複合的な問題: 被害の原因は一つではありません。長期アクセスキーがアプリから取得可能であること、同じキーでストレージ全体を操作できること、ファイル名が推測可能な連番であることが組み合わさっています。

攻撃の流れを整理すると: ①Fアプリ又は通信からアクセスキーとストレージ名を取得する、②方式aのAuthorizationヘッダーへアクセスキーを指定する、③/e-service/00000001.zipから番号を増やしてGETを送る、④存在するファイルを順次取得する、という流れです。

4. (4) 下線④の細工したURLについて

問題文からの引用

図7：「呼出し元のWebページのURLの先頭は“https://www.a-sha.co.jp”か。」

「攻撃者が取得したドメイン名をk-sha.co.jpとした場合で答えよ。」

着眼点・注目ポイント
図7はURL全体を厳密に解析せず、文字列の先頭だけを確認しています。https://www.a-sha.co.jpで始まりながら、実際の接続先ホストがk-sha.co.jpになるURLを作ります。

正解例:
- https://www.a-sha.co.jp.k-sha.co.jp/
- https://www.a-sha.co.jp@k-sha.co.jp/
- https://k-sha.co.jp/
解説: 一つ目は、実際のホスト名がwww.a-sha.co.jp.k-sha.co.jpであり、攻撃者が管理するk-sha.co.jp配下のサブドメインです。先頭文字列だけを見ると正規サイトのように見えますが、DNS上の管理主体はk-sha.co.jp側です。二つ目は、URL構文上、@より前がユーザー情報として扱われ、実際の接続先ホストはk-sha.co.jpです。三つ目は、F-URLのurlパラメータへ攻撃者サイトを直接指定する最も単純な例です。FアプリがそのURLをWebViewへ渡すと、攻撃者サイトへアクセスします。

補足: 図7の不十分な前方一致判定をすり抜けて認証トークンを取得できるのは、最初の二つです。三つ目は図7ではトークンを返しませんが、Fアプリが攻撃者サイトを表示してしまう問題を示します。設問は「攻撃者のWebサイトにアクセスさせるURL例」を求めるため、公式解答例では三つとも示されています。

設問2 〔サーバ証明書検証と通信解析〕について

1. (1) 下線⑤のSubject Alternative Nameについて

問題文からの引用

「通信解析ツールは，自身のプライベート認証局機能を用いる。」

「“https://www.a-sha.co.jp/campaign/…”にアクセスした際の…通信フロー」

着眼点・注目ポイント
Fアプリがアクセスしようとしているホスト名と、通信解析ツールが生成するサーバ証明書のSANを一致させます。

正解: www.a-sha.co.jp
解説: 通信解析ツールは、FアプリとのTLS接続を終端するため、アクセス先であるwww.a-sha.co.jp用のサーバ証明書を動的に生成します。ホスト名検証を通すには、証明書のSubject Alternative Nameへwww.a-sha.co.jpを含める必要があります。

2. (2) 図9の空欄a～hについて

問題文からの引用

図9は、スマホ、通信解析ツール、A社Webサーバ間のプロキシ通信とTLSハンドシェイクを示している。

着眼点・注目ポイント
まずHTTPSプロキシへCONNECTを送り、200応答後にTLSハンドシェイクを開始します。TLS 1.3のサーバ側メッセージは、Server Hello、Encrypted Extensions、Certificate、Certificate Verify、Finishedの順です。

正解: a：オ、b：ケ、c：ウ、d：コ、e：ア、f：イ、g：カ、h：キ

空欄	正解	内容
a	オ	`CONNECT www.a-sha.co.jp:443 HTTP/1.1`
b	ケ	HTTPステータスコード200（OK）
c	ウ	Client Hello
d	コ	Server Hello
e	ア	Certificate
f	イ	Certificate Verify
g	カ	Finished
h	キ	`GET /campaign/... HTTP/1.1`

選択肢の解説

ア（Certificate）: eの正解です。サーバ証明書を送信します。
イ（Certificate Verify）: fの正解です。ハンドシェイクメッセージへ署名し、証明書に対応する秘密鍵を保有していることを示します。
ウ（Client Hello）: cの正解です。クライアント側からTLSハンドシェイクを開始します。
エ（通信解析ツール自身へのCONNECT）: 不適切です。CONNECTの宛先には、最終的な接続先www.a-sha.co.jp:443を指定します。
オ（CONNECT www.a-sha.co.jp:443 HTTP/1.1）: aの正解です。HTTPSプロキシへトンネル確立を要求します。
カ（Finished）: gの正解です。それまでのハンドシェイクメッセージが改ざんされていないことを確認し、鍵共有が完了したことを示します。
キ（GETリクエスト）: hの正解です。TLS確立後にWebコンテンツを要求します。
ク（101 Switching Protocols）: 不適切です。CONNECT成功時の応答ではありません。
ケ（200 OK）: bの正解です。CONNECT要求を受け付けたことを示します。
コ（Server Hello）: dの正解です。サーバ側がTLSパラメータを応答します。

3. (3) 下線⑥の開発用スマホの設定について

問題文からの引用

「今後，開発用のスマホに必要な設定を行うことにした。加えて，OS-αではテストを行う際だけその設定を有効化するように，Fアプリの中にも設定を追加した。」

着眼点・注目ポイント
通信解析ツールが生成する証明書を、開発用スマホが信頼できるようにします。サーバ証明書の検証を無効化するのではありません。

正解: 通信解析ツールのプライベート認証局のルート証明書をインストールし，信頼設定を行う。
解説: 通信解析ツールは、自身のプライベート認証局でwww.a-sha.co.jp用の証明書を発行します。開発用スマホへそのルート証明書をインストールし、テスト時に信頼するよう設定すれば、Fアプリは証明書検証を有効にしたまま、通信解析ツールとのTLS接続を確立できます。通信解析ツールは、スマホとのTLS接続とA社WebサーバとのTLS接続を別々に確立し、その間でHTTP通信を解析します。

安全なテスト方法: 本番コードで証明書エラーを無視するのではなく、テスト環境だけで専用認証局を信頼します。問題文では、OS-αについてFアプリ側にもテスト時だけ有効化する設定を追加しています。

設問3 〔署名付きURLの生成時点〕について

1. 空欄iについて

問題文からの引用

「方式bを利用し，その際に署名付きURLの生成を図4中の [ i ] の時点で行ってはどうか」

図4の（い）は、A社Webサーバが注文番号を採番した後、Fアプリへ注文番号を通知する直前に位置する。

着眼点・注目ポイント
署名付きURLには、アップロード対象のパス、すなわち注文番号を含むファイル名が必要です。したがって、注文番号の採番後に生成します。さらに、秘密であるアクセスキーはA社Webサーバ側で保持し、Fアプリへ渡さない構成にします。

正解: （い）
解説: A社Webサーバは、注文内容を登録して注文番号を採番した後、その注文番号を含むファイル名に対するPUT用の署名付きURLを生成できます。（い）で生成した署名付きURLを注文番号とともにFアプリへ返せば、Fアプリは有効期限内に、その特定ファイルだけをアップロードできます。ストレージ全体へアクセスできる長期アクセスキーをFアプリへ持たせる必要がなくなります。

方式aから方式bへ変更する効果: 権限の対象を「ストレージ内の全ファイル」から「特定ファイルの特定操作」へ狭め、さらに有効期限を設定できます。これは最小権限と権限の短期化に当たります。

観点	方式a	方式b
Fアプリへ渡す情報	長期のアクセスキー	一時的な署名付きURL
操作対象	ストレージ内の全ファイル	URLで指定した特定ファイル
操作の種類	ファイル操作全般	署名対象のGET又はPUT
有効期限	問題文上は設定なし	Expiresで制限
キー漏えい時の影響	ストレージ全体に及ぶ	当該URLの範囲に限定される

設問4 〔WebViewとフィッシング対策〕について

1. (1) 下線⑦の仕様上の問題点について

問題文からの引用

「Webブラウザと比べると，フィッシングサイトにアクセスしてしまっても気付くことができないというFアプリの仕様上の問題点が残ります。」

着眼点・注目ポイント
通常のWebブラウザにはアドレスバーがありますが、図3のWebView表示には接続先URLを確認する手段が示されていません。20字以内で答えます。

正解: URLを確認する手段がない。
解説: WebView内に表示されたページは、見た目だけでは正規のキャンペーンページか攻撃者サイトかを利用者が判断しにくい状態です。アドレスバーなど、現在のURLを確認する手段がないため、フィッシングサイトへ誘導されても気付きにくくなります。

2. (2) 下線⑧で実装する機能について

問題文からの引用

「図7の処理の修正に加えて，フィッシングサイトにアクセスできないようにする機能を実装します。」

図8では、F-URLのurlクエリパラメータにWebViewで表示するURLを指定している。

着眼点・注目ポイント
WebViewを開いてからトークンを返すか判断するだけでは、攻撃者サイト自体は表示されます。WebViewを呼び出す前に、遷移先URLを検証します。

正解: WebViewを呼び出す前に，URLの先頭がhttps://www.a-sha.co.jp/であるかを検証する。
解説: F-URLを処理するとき、urlパラメータの値を検証し、正規のA社Webサーバ配下だけを許可します。末尾の/まで含めたhttps://www.a-sha.co.jp/を確認することで、https://www.a-sha.co.jp.k-sha.co.jp/やhttps://www.a-sha.co.jp@k-sha.co.jp/は一致しなくなり、設問1（4）のようなURLを排除できます。検証に失敗したURLはWebViewへ渡しません。

より堅牢な実装上の考え方: 文字列の前方一致だけに頼らず、URLを構文解析し、スキームがhttps、ホスト名がwww.a-sha.co.jpであることを個別に確認する方法が安全です。ただし、試験の正解は問題文に沿ったhttps://www.a-sha.co.jp/の先頭検証です。

攻撃と対策の対応関係

脆弱性	攻撃の成立要因	主な対策
サーバ証明書の検証不備	証明書エラーを無視して通信を継続	正常な証明書検証を行い、テスト時だけ専用認証局を信頼する
アクセスキーの保護不備	暗号文・共通鍵・初期ベクトルが全てアプリ内に存在	サーバ側で短時間・特定ファイル用の署名付きURLを生成する
推測可能なファイル名	注文番号が連番で、長期キーが全ファイルへ有効	ファイルごと・操作ごとの権限へ限定する
F-URLのアクセス制御不備	任意URLをWebViewへ渡せる	WebViewを開く前に遷移先URLを検証する
getTokenのURL判定不備	不十分な先頭一致で別ドメインを許可	正規のスキーム・ホスト名・パス境界を厳密に検証する

学習上の重要ポイント

1. アプリ内に埋め込んだ秘密情報は解析される前提で考える

暗号化して保存しても、復号鍵と初期ベクトルを同じアプリへ入れれば、攻撃者はアプリ解析によって復号できます。

2. 長期・広範囲の権限を短期・限定的な権限へ置き換える

方式aのアクセスキーは、対応するストレージ内の全ファイル操作に使用できます。方式bの署名付きURLなら、対象ファイル、HTTPメソッド、期限を限定できます。

3. HTTPSではサーバ証明書検証まで含めて安全性を考える

TLS暗号化を使用していても、サーバ証明書を検証しなければ、攻撃者との通信を暗号化しているだけになる可能性があります。

4. URLは見た目ではなく構造で検証する

www.a-sha.co.jp.k-sha.co.jpの実際の管理ドメインはk-sha.co.jpです。@を含むURLでは、@より後ろがホスト名です。URLを正しく解析し、スキームとホスト名を検証します。

5. WebViewは接続先を利用者が確認しにくい

アドレスバーがないWebViewでは、フィッシングサイトが表示されても利用者が気付きにくいため、アプリ側で許可する遷移先を制御する必要があります。

記述式設問の解答作成ポイント

設問1 (1): 「CサービスへのHTTPリクエスト」「Authorizationヘッダー」「アクセスキー」の三要素を入れます。
設問1 (2): アプリ解析だけで終わらず、暗号化アクセスキー、共通鍵、初期ベクトルの入手とAES-CBCによる復号まで書きます。
設問1 (3): 推測可能な注文番号を00000001から順に増やすことを明記します。
設問2 (3): ルート証明書のインストールだけでなく、信頼設定まで書きます。
設問4 (2): WebViewを呼び出した後ではなく、呼び出す前にURLを検証することが重要です。

解答一覧

設問1 (1): Cサービスに送られたHTTPリクエストのAuthorizationヘッダーから取り出す。
設問1 (2): Fアプリを解析し、暗号化されたアクセスキー並びに共通鍵及び初期ベクトルを入手し、AES-CBCで復号する。
設問1 (3): ファイル名の注文番号を00000001から順に増やしてダウンロードを試行する。
設問1 (4): https://www.a-sha.co.jp.k-sha.co.jp/、https://www.a-sha.co.jp@k-sha.co.jp/、https://k-sha.co.jp/
設問2 (1): www.a-sha.co.jp
設問2 (2): a オ、b ケ、c ウ、d コ、e ア、f イ、g カ、h キ
設問2 (3): 通信解析ツールのプライベート認証局のルート証明書をインストールし、信頼設定を行う。
設問3: i （い）
設問4 (1): URLを確認する手段がない。
設問4 (2): WebViewを呼び出す前に、URLの先頭がhttps://www.a-sha.co.jp/であるかを検証する。

参照資料

IPA「令和7年度春期情報処理安全確保支援士試験午後試験問3」（問題文）
IPA「令和7年度春期情報処理安全確保支援士試験解答例」（問3の解答例・出題趣旨）

You get articles that match your needs
You can efficiently read back useful information
You can use dark theme

What you can do with signing up

令和7年度春期 情報処理安全確保支援士（午後試験 問3）解説