この記事では，令和７年度 春期 情報処理安全確保支援士試験 午後問題 問３を解説します！
各解説につきましては，独自の見解です．正確性を保証するものではありませんので，ご了承ください．
情報処理安全確保支援士試験に向けて勉強されている方の参考になれば幸いです．
本記事における出典：令和７年度 春期 情報処理安全確保支援士試験 午後 問３
IPA（問題冊子・解答例・採点講評）のリンク
本記事内の解答例については，全てIPA公式からの引用になります．
設問１ 〔Fアプリの脆弱性診断結果〕について
スマートフォン用アプリケーションプログラム（WebViewを活用するため，実質的にはWebアプリケーション＋WebView特有）に関する問題です．
（１） 下線①について，アクセスキーを取得する方法
下線①は，問題冊子25ページの表1中にあります．
（前略）HTTPS通信の内容が盗聴されたり，改ざんされたりするおそれがある。盗聴されると，① 盗聴した内容からアクセスキーとストレージ名を攻撃者が取得するおそれがある．
解答例
Cサービスに送られたHTTPリクエストのAuthorizationヘッダーから取り出す。
解説
一見すると，知識問題のようにも感じますが，実は解答の肝となる文章が問題冊子22ページの図5
「Cサービスの仕様（抜粋）」中に記載されています．
（前略）
2. 方式 a
(1) 説明
アクセスキーをHTTPリクエストのAuthorizationヘッダーに指定する方式である．
従って，HTTPリクエストを盗聴できた場合，HTTPリクエスト中のヘッダーフィールドのAuthorizationから取り出されてしまうことが想定されます．
（２） 下線②について，アクセスキーを取得する方法
下線②も同じく，問題冊子25ページの表1中にあります．
② 攻撃者がFアプリから平文のアクセスキーとストレージ名を取得できる。（後略）
解答例
Fアプリを解析し，暗号化されたアクセスキー並びに共通鍵及び初期ベクトルを入手し，暗号化されたアクセスキーをAES-CBCで復号する。
解説
解答の根拠となるのは，問題冊子23ページ下部にある以下の記述です．
アクセスキーは，鍵長256ビットの共通鍵とAES-CBCアルゴリズムで暗号化し，Fアプリ内にリソースとして保存する。Cサービスのストレージ名並びにAES-CBCの共通鍵及び初期ベクトルは，Fアプリのコード中に定数として定義する。
Fアプリのコード中に定数として記述するということは，リバースエンジニアリング（ソースコードの解析）によって，AES-CBCの共通鍵及び初期ベクトルを不正に取得されるリスクがあります．
このことに気付いたら，完答も同然です．後は，解析によって得られたAES-CBCの共通鍵と初期ベクトルを用いて，アクセスキーを復号すれば良いということになります．
（３） 下線③について，ダウンロードする方法
下線③も同じく，問題冊子25ページの表1中にあります．
③ 攻撃者がEサービスの全利用者の写真を不正にダウンロードするおそれがある。
解答例
ファイル名に含まれる注文番号を00000001から順に増やしてダウンロードを試行する。
解説
解答の根拠は，問題冊子22ページ 図4 「フォトグッズの注文処理の流れ」とその下の注記にあります．
（う） 写真を“nnnnnnnn.zip”というファイル名でZIP形式に圧縮
（え） nnnnnnnn.zipをアップロード
注記 “nnnnnnnn.zip”は注文番号であり，000000001から始まる十進数の連番である。
連番というのがこの問題におけるキーポイントで，この注記は他のユーザがアップロードした写真のファイル名を容易に類推できることを示唆しています．
ちなみに，この連番系（IDを用意に推測できる系）の問題は複数回出題が確認されています．
直近では，令和6年度秋期 情報処理安全確保支援士試験 午後 問４で出題されています．
（４） 表１中の下線④について，細工したURLの例
F-URLのurlクエリパラメータに，④ 細工したURLが指定されることによって，攻撃者のWebサイトにアクセスしてしまうおそれがある。
また，攻撃者が取得したドメイン名を k-sha.co.jp とした場合で答える必要があります．
解答例
・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/
から１つ
解説
解答例にある3つのURLのうち，特に上2つについてはURLを偽装する巧妙な手口になります．
1番上のURLは，一見すると正規のドメイン（a-sha.co.jp）であるように見えますが，
「www.a-sha.co.jp」の部分は，主となるドメイン「k-sha.co.jp」に対するサブドメインという位置付けになります．
注意深く見ると見抜けるのですが，パッと見は正規ドメインのように見せながら，実際は攻撃者が用意したドメイン（k-sha.co.jp）のサーバに接続させるという巧妙なURLになっています．
このようなURLは，本問に限らず昨今のフィッシングサイトでもよく用いられる手口になっており，注意が必要です．
設問２ 〔脆弱性１〕について
設問２は，知識問題が中心となります．特に，(2) はネットワーク寄りの問題で完答難易度は高いです．一方，(3) は類題も含めれば比較的頻出の問題となっています．
（１） 下線⑤について，サーバ証明書のSubject Alternative Name の値
下線⑤は，問題冊子26ページの図9 「通信解析ツールを利用した際の通信フローの例（抜粋）」中にあります．
解答例
www.a-sha.co.jp
解説
この問題で肝になるのは，問題冊子25ページ下部の説明「この通信解析ツールはプロキシサーバとして動作する．」以降の文章です．
HTTPS 通信では，証明書の Common Name (CN) だけでなく，Subject Alternative Name (SAN) に含まれる DNS 名と接続先ホスト名が一致していなければ，ブラウザやアプリ側で検証エラーが発生します．
従って，Fアプリに「自分は，正規のA社Webサーバに接続している」と思わせるには，SANにもA社Webサーバのホスト名を登録しておく必要があります．
以上の理由から，設定すべき値は www.a-sha.co.jp となります．
（２） 図9中の a～h に入れる適切な字句（記号選択）
TLSハンドシェイクを含む通信の順序を記号で解答する問題です．ネットワーク寄りのかなり専門性の高い問題と言えます．
問題と解答例は，IPA（問題冊子・解答例・採点講評）のリンクからご確認ください．
解説
全てを暗記するのは骨が折れますが，いくつか覚えておくべきポイントがあります．
・クライアントからサーバに送られる通信は，リクエストと呼ばれる．
リクエストの形式：メソッド APIエンドポイント（ファイルパス） 通信プロトコル
例） POST /users/register HTTP/1.1
・サーバは，リクエストに対し，レスポンスをクライアントに返す．
レスポンスの形式：HTTPステータスコード（基本的に3桁の数字）
例）200（OK），403（Forbidden），404（Not found），
500（内部エラー） など
以上の知識があれば，例えば，解答群のキは左から右に向かう矢印（図9における a, c, h のいずれか）に入ると絞り込めます．
同様に，解答群のケは右から左に向かう矢印（図9における b）に入ると分かります．
TLSハンドシェイクについては，以下のように覚えておきましょう．
・Client Hello：クライアントです．こんにちは！（クライアント→サーバ）
・Server Hello：サーバです．こんにちは！（サーバ→クライアント）
（３） 下線⑥について，設定の内容
下線⑥は，問題冊子27ページの上部にあります．
Uさんは，通信解析ツールを利用してテストを行う際も通信を正常に続行させる方法をチーム内で話し合った．その結果，今後，開発用のスマホに⑥必要な設定を行うことにした。
解答例
通信解析ツールのプライベート認証局のルート証明書をインストールし，信頼設定を行う。
解説
出題方法に微妙な差は見られるものの，「証明書の信頼設定」に関する問題は，頻出なのでぜひ押さえておきたい問題の１つです．
解答の根拠は，問題冊子26ページの注釈にあります．
注１） 通信解析ツールは，自身のプライベート認証局機能を用いる。
たった1行の目立たない注釈ですが，この1文こそが全てです．
プライベート認証局と言えば，自己署名証明書
自己署名証明書と言えば，信頼設定！（OSやアプリは通常、公開されている認証局(CA)のルート証明書しか信頼しません．）
マジカルバナナのようになってしまいましたが，このような連想ができると，自ずと解答が導けます．
設問３ 本文中の i に入れる記号
空欄 i は，問題冊子27ページにあります．
（前略）署名付きURLの生成を図４中の i の時点で行ってはどうか（後略）
解答
（い）
解説
IPA公式の採点講評でも言及されていましたが，攻撃者による解析が容易なスマホアプリ上でのURL生成は不適切です．従って，この時点で解答は（あ） or （い）の2択になります．
そして，流れとしては注文内容のデータベース登録，採番後にURL生成というのが自然ですので，（い）が正答であると導くことができます．
設問４ 〔脆弱性３〕について
WebView特有の問題です．
（２）での根本的な考え方（ホワイトリスト；事前に登録されたサイト・通信のみ許可する）は，情報処理安全確保支援士試験で非常に重要（頻出）となりますので，ぜひ押さえてください．
（１） 下線⑦について，問題点（20字以内）
下線⑦は，問題冊子27ページにあります．
（前略）しかし，Webブラウザと比べると，⑦フィッシングサイトにアクセスしてしまっても気付くことができないというFアプリの仕様上の問題点が残ります。
解答例
URLを確認する手段がない。（14字）
解説
皆さんは，スマホアプリを使っている時に，「あれ？ これスマホアプリだけど，画面はWebサイトっぽいな．．．」と思った経験はありませんか？
このように思ったアプリがあれば，それはWebViewである可能性が高いです．
WebViewは，一度開発したWebアプリをほぼそのままネイティブアプリ（スマホアプリ等）に落とし込むことができるという開発メリットがあります．
一方で，ブラウザからWebアプリにアクセスする場合は，当然ブラウザのアドレスバーに接続先のURLが表示されますが，WebViewを用いたスマホアプリでは基本的にURLが表示されません．
従って，フィッシングサイトにアクセスしていることに気付きにくいため，別の対策が必要になります．
（２） 下線⑧について，実装する機能
⑧ フィッシングサイトにアクセスできないようにする機能とあります．
解答例
WebViewを呼び出す前に，URLの先頭がhttps://a-sha.co.jp/であるかを検証する．
解説
フィッシングサイトにアクセスできないようにする機能ですので，ホワイトリスト方式（事前に登録したURLのみ許可）と考えるのが自然です．
ここで，注意すべきポイントは「URLの先頭がhttps://a-sha.co.jp/」の末尾のスラッシュです．
これを「URLの先頭がhttps://a-sha.co.jp（スラッシュが無い）」で止めてしまうと，設問１ー（４）にあるようなURL細工の事例（https://www.a-sha.co.jp.k-sha.co.jp）を防げないため，減点（最悪の場合不正解に）される可能性があります．
