情報処理安全確保支援士 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. 脆弱性の把握
   表3の項番4には「総当たり攻撃によって、文字列Xを使った認証メカニズムを突破できる」とあり、これは認証APIの「文字列X（OTP）」に対するブルートフォース攻撃が可能であることを示しています。したがって、繰返しの誤入力（試行）を抑止する対策が求められます。
2. 表5の指示の確認
   表5の項番4には「d を実装する。そのしきい値は10とする。」とあります。ここで「しきい値は10」とあることから、試行回数に基づいて何らかの遮断・制限を行う処理を実装することが求められます。
3. 要求される処理の性質の決定
   総当たり攻撃を抑える手段として代表的なのは、（1）IPや送信元単位のレートリミティング、（2）アカウント単位の試行回数制御（閾値超過でロック等）、（3）試行ごとの遅延やCAPTCHA導入、などです。表5が「しきい値は10」と利用者単位（midで識別される）での対策を想定している文脈から、最も直接的に合致するのは「利用者（mid）ごとに連続した失敗試行を数え、閾値を超えたらそのアカウントへの認証試行を止める（ロックする）処理」です。ここで「連続」にする理由は、成功時にカウントをリセットして通常利用者の誤入力と攻撃を区別しやすくするためです。
4. まとめ（解答の根拠）
   ・表3が示す脆弱性＝OTPに対する総当たり攻撃である。
   ・表5が要求するのは試行回数に基づく遮断であり、しきい値が「10」であること。
   以上より、表5のdには「連続失敗回数がしきい値を超えたらアカウントをロックする処理」を入れるのが適切です。

誤りやすいポイント

• 「しきい値は10」を「1秒間に10回試行できること」と混同し、意味を取り違える（ここでは「10回の失敗試行で発動」）。
• 「累積失敗回数」として古い失敗をずっと加算する実装にしてしまい、一定期間後の誤ロックを招く。
• アカウントロックを無期限にする（運用上のDoSを招く）。一時ロックや通知・解除手順を考慮しない。
• ロックのみで防御完結と考え、IPベースのレート制限や監視ログなど他対策を併用しない。
• カウントの対象を特定できない（必ず利用者ID(mid)ごとにカウントすること）。

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