情報処理安全確保支援士の令和7年度 春季試験 午後問題 問3の解説を行っていきます。
令和5年度 秋季試験より、これまでの試験構成が午後Ⅰ・午後Ⅱから午後問題へと変更になっています。
試験構成の変更や受験者への影響については『こちら』にまとめていますので、まだ確認されていない方は試験前までにご覧ください。
出題テーマ：スマートフォン用アプリケーションプログラム
スマートフォン用アプリケーションプログラムを題材に、脆弱性や脆弱性を利用した攻撃手法・対策について出題されていました。
初期ベクトルの暗号化に関する内容やドメイン、FQDN、証明書やTLSのシーケンス、署名付きURLを正しく理解している必要がありました。
一部の問題では文章中のヒントから回答することができましたが、基本的には知識が必要な問題でした。
ただ、証明書やTLSのシーケンスなどの重要なことが問われている問題でもあるので、練習としてはぜひ解いてみて欲しい問題です。
設問1 (1)
下線①として、『盗聴されると、盗聴した内容からアクセスキーとストレージ名を攻撃者が取得する』とあります。
重要な部分として、『Fアプリでは方式aを使用する。』とあります。
方式aで、『アクセスキーをHTTPリクエストのAuthorizationヘッダーに指定する方式である。』とあります。
盗聴すれば通信の中身が見れるわけですので、HTTPリクエストのAuthorizationヘッダーからアクセスキーを取得することができます。
ということで、解答例は『HTTPリクエストのAuthorizationヘッダーからアクセスキーを取得する』と考えることができます。
設問1 (2)
下線②として、『攻撃者がFアプリから平文のアクセスキーとストレージ名を取得できる。』とあります。
重要な部分として、『アクセスキーは、鍵長256ビットの共通鍵とAES-CBCアルゴリズムで暗号化し、Fアプリ内にリソースとして保存する。Cサービスのストレージ名並びにAES-CBCの共通鍵及び初期ベクトルは、Fアプリのコード中に定数として定義する。』とあります。
まずは初期ベクトルについて説明をします。
同じデータをそのまま暗号化したら、毎回同じ暗号化したデータが出来上がります。
それを繰り返すと、暗号前の元のデータが推測されてしまう可能性が高まります。
そこで用いるのが初期（化）ベクトルです。
初期ベクトルはランダムな値ですが、初期ベクトルを用いて暗号化することで、同じデータでも異なる暗号したデータを作成することができ、元のデータの推測が困難な状態となります。
暗号化の際には鍵と初期ベクトルを用いて、初期ベクトルは相手に渡し、復号化の際に用いて元のデータを復元します。
今回の場合はアクセスキーは暗号化した状態ではありますが、アプリ内に保存している状態となります。
そして共通鍵、初期ベクトルもコード内に存在しているわけですので、アプリを解析しこれらを入手すればアクセスキーを復号化してアクセスキーの値を入手することができます。
ということで、解答例は『Fアプリを解析し、暗号化されたアクセスキーと共通鍵、初期ベクトルを入手し、共通鍵と初期ベクトルからアクセスキーを復号化して値を取得する』と考えることができます。
設問1 (3)
下線③として、『攻撃者がEサービスの全利用者の写真を不正にダウンロードする』とあります。
重要な部分として、『利用システムは、ストレージ上のファイルをURLのパスで指定する。例えば、ストレージ”●●●”上のファイル”▲▲▲”をファイル操作する際は、”/●●●/▲▲▲”を指定する。ファイルのアップロードにはHTTPのPUTメソッドを、ファイルのダウンロードにはGETメソッドを用いる。』とあります。
図4はアップロードの流れを示していますが、先ほど見たようにダウンロードも可能です。
そして、注記の部分に『“nnnnnnnn”は注文番号であり、00000001から始まる十進数の連番である。』とあります。
つまりファイル名は注文番号000000001.zip、00000002.zipという連番で記載されています。
ブルートフォース攻撃のように順番に増やしていけば、すべてのファイルをダウンロードすることができてしまいます。
ということで解答例は、『ファイル名を00000001、00000002のように順番に増やしてダウンロードを試みる』と考えることができます。
設問1 (4)
下線④として、『F-URLのurlクエリパラメータに細工したURLが指定されることによって、攻撃者のWebサイトにアクセスしてしまうおそれがある。』とあります。
図7を見ますと、『キャンペーンページ以外からgetToken関数を悪用されないように、getToken関数の内部では、図7のように呼び出し元のWebページのURLを確認する』とあり、条件として『呼出し元のWebページのURLの先頭は”https://www.a-sha.co.jp”か。』とあります。
例えば、『https://www.a-sha.co.jp.k-sha.co.jp』のようにサブドメインとして指定されるとこの条件では認証トークンを発行しアクセスをしてしまいます。
ちなみに公式の解答例には『https://k-sha.co.jp』と先頭が”https://www.a-sha.co.jp”から始まらないものも含まれていますが、こちらは認証トークンは発行されませんが、あくまで確認のみなのでアクセスは行われてしまいます。
設問はWebサイトへのアクセスまでのなので、こちらも正解であると考えることができます。
設問2 (1)
下線⑤として、『サーバ証明書を生成』とあります。
スマホからA社Webサーバ宛の通信はHTTPS（TLS）で暗号化された状態で通信が行われますので、ただ単にスマホ→通信解析ツール→A社Webサーバと通信解析ツールを通信経路途中に入れても通信の内容を解析することはできません。
スマホ←（TLS）→通信解析ツール←（TLS）→A社Webサーバというように、スマホ⇔通信解析ツールでTLS通信を行い通信内容を復号化して解析を行います。
その後通信解析ツール⇔A社WebサーバとTLS通信を行い、暗号化してA社Webサーバに送信することで、HTTPSでも通信の中身を確認することができます。
これはSSLの可視化やSSLインスペクションと呼ばれます。
ちなみにUTMなどのセキュリティアプライアンスではこの処理を行うことができたりしますが、復号&再暗号化は処理としては重たい部類に入りますので、この機能を使用する場合はCPUやメモリの使用率などの性能面の検証や機器のサイジングをしっかりと行う必要があります。
証明書の検証の一つにCN（コモンネーム）の確認があります。
CNにはサイト自身のFQDNやIPアドレスを入れることが一般的です。
図9の注釈に『通信解析ツールのプライベートIPアドレスは〇〇〇.〇〇〇.〇〇〇.〇〇〇とする。』とありますので、おそらくCNにはこのプライベートIPアドレスが入っていると予想されます。
これと実際にアクセスしようとしているFQDNとの比較を行います。
アプリがアクセスするのは『https://www.a-sha.co.jp/campaign/□□□』とあります。
CNにはプライベートIPアドレスが登録されていると考えられ、アクセスしようとしているFQDNはwww.a-sha.co.jpなので不一致となり証明書エラーが発生してしまいます。
CNには1つのFQDN、IPしか登録することができませんので、CN：www.a-sha.co.jpドメインやサブドメインごとに証明書を作成する必要あり面倒です。
そこで登場するのがSubject Alternative Name(SAN)：証明書のサブジェクトの代替名です。
CNがプライベートIPアドレスだとしてもSANにwww.a-sha.co.jpのようにサブドメインやwww.a-sha.comのような別ドメインも含めて複数のFQDN、IPを登録することができ、検証の際にはSANも含めて確認が行われますので、証明書1つだけで運用をすることができます。
CNにはプライベートIPアドレスが登録されていると考えられるので、FアプリがアクセスしようとしているFQDN（www.a-sha.co.jp）をSANに登録したあげれば証明書エラーが発生することなく通信を行うことができおます。
ということで解答は『www.a-sha.co.jp』となります。
設問中に具体的にと記載がありますので、サブドメインにwwwを記載していますが、実際は*.a-sha.co.jpのように*（アスタリスク、ワイルドカード）を使用するケースが多いかと思います。
そうすることで、wwwやmailなど複数のサブドメインを一度に設定したことになります。
設問2 (2)
プロキシおよびTLSのシーケンスの問題です。
重要な部分として『この通信解析ツールはプロキシサーバとして動作する。』とあります。
プロキシサーバ経由でHTTPS通信する場合は3wayハンドシェイク後に、CONNECT METHODを送信します。
通信を復号しないプロキシサーバを経由する場合、HTTPSの中身は閲覧することができないので、どこに通信したらよいかがわかりません。
CONNECT METHODはここの宛先にSSL/TLS通信を行いたいという宛先を示しており、これによりプロキシサーバはどこに通信したらよいかがわかります。
図9の通信フロー図としては『https://www.a-sha.co.jp/campaign/□□□にアクセスした際』のものですので、『a：オ CONNECT www.a-sha.co,jp:443 HTTP/1.1』が入ります。
CONNECT METHODを受信したプロキシサーバは要求が成功したことを示す200OKを返答しますので、『b：ケ HTTPステータスコード 200(OK)』が入ります。
ここからはTLSのシーケンスに入っていきます。
まず最初に行われるのはクライアントからサーバに対して行われる『c：ウ Client Hello』です。
それに対してサーバは『d：コ Server Hello』を返答します。
つづいて、サーバ証明書『e：ア Certificate』、証明書が検証済（本物）であることを証明する『f：イ Certificate Verify』、『g：カ Finished』を互いに送信してTLSのハンドシェイクが完了をします。
TLSのハンドシェイクが完了したので、ようやく本来のリクエストである『h：キ GET /campaign/□□□ HTTP/1.1』が送信されます。
プロキシサーバを利用時にHTTPSの通信をする際にCONNECT METHODが送信されること、TLSのシーケンスはServer Helloで送られるものは問われているもの以外もありますが、重要なのでぜひこれを機会に覚えて欲しいです。
設問2 (3)
下線⑥として、『開発用のスマホに必要な設定』とあります。
重要な部分として、図9の注釈に『通信解析ツールは、自身のプライベート認証局機能を用いる。』とあります。
今回のTLS/SSL証明書に関してですが、認証局（CA）に依頼して証明書を発行してもらいます。
サーバ証明書とはサーバの公開鍵に認証局の秘密鍵で電子署名を付与したものです。
認証局にはパブリックとプライベートがあります。
パブリックの代表例はVeriSign（ベリサイン）などが挙げられ、電子証明書の発行にお金がかかりますが、第三者的に証明書が発行されるのでセキュリティが高く、一般的に公開されているサービスにはパブリック認証局によって発行された証明書が使用されています。
そして、発行した証明書を検証する際には、認証局（CA）の公開鍵であるルート証明書で検証を行います。
一般的なブラウザには代表的なパブリック認証局のCA証明書があらかじめインストールされています。
一般的にサービスにはパブリック認証局から発行された証明書を用いますので、我々は証明書の問題を気にすることなくインターネット通信などが行えます。
今回のプライベート認証局は第三者ではなく自分自身が認証局となり、自身で証明書の発行を行います。
そのようにして発行された証明書を自己証明書やオレオレ証明書と言ったりします。
自分自身で発行した証明書はブラウザなどに事前に登録されていませんので、この証明書を用いて通信を行った際には証明書エラーが発生してしまいます。
ではどうすればよいかですが、ブラウザにルート証明書として事前に登録しておくことで、証明書エラーが発生することなく通信を行うことができます。
今回はブラウザではなくスマホのアプリ上で行うわけですが、スマホの場合はインストールという言い方が正しいかと思います。
ということで解答例は『通信解析ツールのプライベート認証局から発行されたルート証明書を事前に開発用のスマホにインストールしておくこと』と考えることができます。
設問3
【i】の部分として、『脆弱性2への対応について、Sさんからは方式bを利用し、その際に署名付きURLの生成を図4中の【i】の時点で行ってはどうかとの提案があった。』とあります。
脆弱性2は『Cサービスのアクセスキーの保護に不備がある。』という内容で、設問1 （2）でも見ましたが、『攻撃者がFアプリから平文のアクセスキーとストレージ名を取得できる。』とあるようにアプリ内にアクセスキーが保管されてしまっていることが問題でした。
これまでは方式aを用いていましたが、今後は方式bを用いようとしており、『有効期限（Expires）と署名値（Signature）をクエリパラメータとして付加したURL（以下、署名付きURLという）を用いて、特定のファイル操作を一時的に可能とする方式である。』とあります。
署名付きURLについてですが、『利用システムは、署名付きURLを生成し、ファイル操作を許可する利用者に伝える。伝えられた利用者は、署名付きURLを指定してHTTPリクエストを送ることによって、ファイル操作ができる。有効期限が切れた場合やサーバ側の署名値の検証が失敗した場合は、ファイル操作が拒否される。』とあります。
一般的な署名付きURL発行からアクセスまでの流れを図示するとこのようになります。
利用者はストレージにアクセスするFアプリ、ファイル操作が行われるストレージはCサービス、となるとWebサーバ、利用システムはA社Webサーバと考えることができます。
URL発行のためにはファイル名が決まっている必要があり、ファイル名は注文番号であるため、注文番号が決まった後の『（い）』が適切であると考えられます。
設問4 (1)
下線⑦として、『Webブラウザと比べるとフィッシングサイトにアクセスしてしまっても気付くことができないというFアプリの仕様上の問題点が残ります。』とあります。
スマホのアプリ上でWebページを表示する場合（WebView）、URLを確認することができません。
URLを確認することができれば、見た目は本物のサイトっぽくてもURLがおかしかったりすればフィッシングサイトであると気付くことができます。
ということで解答例は、『アプリ上ではURLが確認できないこと（18文字）』と考えることができます。
設問4 (2)
下線⑧として、『フィッシングサイトにアクセスできないようにする機能を実装します。』とあります。
重要な部分として、『キャンペーンページのHTMLは、WebViewを用いて、Fアプリの画面上に表示させる。』とあります。
そして、『会員がメールアプリからF-URLを開くと、Fアプリが起動し、WebView上にキャンペーンページが表示される。』とあります。
現状はメールアプリからF-URLを開く→Fアプリ起動→WebView起動という流れです。
設問1 (4)で解答しましたが、F-URLが細工されていた場合、現状では攻撃者が用意したサイトにアクセスしてしまいます。
Fアプリ上でF-URLが正規のものか確認をした上でWebViewで表示させるという流れにすれば、フィッシングサイトにアクセスできないようにできるかと思います。
WebViewの起動前に正規のF-URLであること、つまりはURLが『https://www.a-sha.co.jp/（スラッシュあり）』かを確認することが重要です。
getToken関数上では『https://www.a-sha.co.jp（スラッシュなし）』でしたので、www.a-sha.co.jp.k-sha.co.jpのような場合でも該当してしまい認証トークンの発行が行われてしまいましたが、しっかりと/（スラッシュ）で区切ることでドメインの偽装を行うことができなすることができます。
ということで、解答例は『WebView起動前にURLがhttps://www.a-sha.co.jp/から始まるかの確認をし、異なる場合はWebViewを起動しない』と考えることができます。
WebViewはご自身のスマホ内のアプリで広告をクリックしてみたりすれば実際の動作を確認できるかと思います。
公式解答例との比較
私の解答と公式解答を比較してみました。
満点ではないにせよ、少なくとも7割～8割程度は取れているかと思います。
予想配点はあくまで予想ですので参考程度でお願いします。
出題テーマはスマートフォン用アプリケーションプログラムで、これらを題材に初期ベクトルの暗号化に関する内容やドメイン、FQDN、証明書やTLSのシーケンス、署名付きURLなどが出題されました。
基本的に知識がないと回答することができない問題が多かったので、知識がない方は避けるべき問題でしたが、証明書やTLSのシーケンスなど覚えておいてほしい内容も出題されていましたので、練習としては解いてみて欲しい問題でした。
総じて、難易度としては難しいだったかと思います。
配点 |
|||
| 設問1 (1) | HTTPリクエストのAuthorizationヘッダーからアクセスキーを取得する | Cサービスに送られたHTTPリクエストのAuthorizationヘッダーから取り出す。 | |
| 設問1 (2) | Fアプリを解析し、暗号化されたアクセスキーと共通鍵、初期ベクトルを入手し、共通鍵と初期ベクトルからアクセスキーを復号化して値を取得する | Fアプリを解析し、暗号化されたアクセスキー並びに共通鍵及び初期ベクトルを入手し、暗号化されたアクセスキーをAES-CBCで復号する。 | |
| 設問1 (3) | ファイル名を00000001、00000002のように順番に増やしてダウンロードを試みる | ファイル名に含まれる注文番号を00000001から順に増やしてダウンロードを試行する。 | |
| 設問1 (4) | https://www.a-sha.co.jp.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”(ブログの仕様上”を記載していますが試験では不要です) |
|
| 設問2 (1) | www.a-sha.co.jp | www.a-sha.co.jp | |
| 設問2 (2) | オ ケ ウ コ ア イ カ キ |
オ ケ ウ コ ア イ カ キ |
|
| 設問2 (3) | 通信解析ツールのプライベート認証局から発行されたルート証明書を事前に開発用のスマホにインストールしておくこと | 通信解析ツールのプライベート認証局のルート証明書をインストールし、信頼設定を行う。 | |
| 設問3 | （い） | （い） | |
| 設問4 (1) | アプリ上ではURLが確認できないこと（18文字） | URLを確認する手段がない。 | |
| 設問4 (2) | WebView起動前にURLがhttps://www.a-sha.co.jp/から始まるかの確認をし、異なる場合はWebViewを起動しない | SPF：SPFレコードにYサービスの情報が登録されていないのに、メールがYサービスから送られる。 DKIM：DKIMレコードのhタグにSubjectが含まれているのに、YサービスでメールのSubjectが変わる。 |
引用元
問題および解答例に関しては、『独立行政法人 情報処理推進機構（IPA）』より引用しています。
YouTube解説動画
情報処理安全確保支援士の問題解説
その他の年度、問題解説は『以下のページ』にまとめております。
