情報処理安全確保支援士試験 令和6年度 春期 午後 問1
前回は、設問1でRESTful APIの基本原則「ステートレス」について学びました。今回はその続きとして、いよいよ本丸の【設問2】に挑戦します。ここでは、脆弱性診断で発見された具体的な問題点に対して、その原因を分析し、的確な対策を立案する能力が問われます。
【採点講評】でも触れられているように、特に(2)のJWT改ざんに関する問題は差がつきやすいポイントです。一つ一つの脆弱性を丁寧に読み解き、合格に繋がる思考プロセスを身につけていきましょう！
【出典：情報処理安全確保支援士試験 令和6年度 春期 午後 問1（一部、加工あり）】
[脆弱性診断の結果]
Sシステムの構築が進み全ての機能を動作確認できたので、G社でSシステムのセキュリティを担当するRさんが、セキュリティベンダーであるU社に脆弱性診断（以下、診断という）を依頼した。U社による診断レポートを表3に示す。
表3の項番1について、U社のセキュリティコンサルタントで情報処理安全確保支援士（登録席スペ）のZ氏は、次のように説明した。
- 認証APIで、利用者ID”user01”での認証が成功した後、診断中に発行されたJWTのデコード結果は、表4のとおりであった。
- ここで、表4中の”RS256”の代わりに”NONE”を指定し、”user01”を他の利用者IDに改ざんしたJWTを送信したところ、改ざんしたJWTの検証が成功し、他の利用者へのなりすましができた。
項番2〜4についても説明を受けた後、G社は、表3の脆弱性を分析し、対策について、F社、U社を交えて検討した。
Rさんが取りまとめた脆弱性の分析と対策案を表5に示す。
全ての対応が完了した後、試用モニターを対象に、サービスYの提供を開始した。
【設問2】脆弱性診断結果を分析し、対策を立てよ！
Sシステムのリリース前に実施された脆弱性診断で、4つの重大な問題が発見されました。 ここでは、それぞれの脆弱性の原因を解き明かし、適切な対策を考えていきます。
(1)2要素認証の突破リスクを計算せよ！
【設問2 】 表3中の (b) に入れる適切な数値を、小数点以下を四捨五入して、整数で答えよ。
問題文の該当箇所
- 脆弱性: 総当たり攻撃によって、文字列Xを使った認証メカニズムを突破できる。
- 文字列Xの仕様: 毎回ランダムに生成される数字4桁の文字列。
- 攻撃の条件: 1秒間に10回試行する総当たり攻撃。
- 問われていること: 平均的な認証成功までの時間 b 秒。
解答
(b) 500
思考プロセス
これは、総当たり攻撃（ブルートフォースアタック）の成功確率に関する計算問題です。落ち着いて条件を整理しましょう。
- 全パターンの数を計算する
文字列Xは「数字4桁」なので、0000 から 9999 までの 10,000通り のパターンがあります。 - 平均試行回数を求める
総当たり攻撃で「平均的に」何回で成功するかを考える場合、全パターンの半分の試行で成功すると考えます。（運が良ければ1回目、最悪の場合は10,000回目なので、その平均は (1 + 10,000) / 2 ≒ 5,000 となります） よって、平均試行回数は 10,000 / 2 = 5,000 回です。 - 成功までの時間を計算する
攻撃者は1秒間に10回試行できます。 したがって、5,000回試行するのに必要な時間は、 平均試行回数 ÷ 1秒あたりの試行回数 = 5,000回 ÷ 10回/秒 = 500秒 となります。
計算結果が整数なので、小数点以下の四捨五入は不要ですね。答えは 500 秒となります。約8分で突破されてしまう可能性があり、非常に危険な状態であることが分かります。
(2) JWT改ざんの根本原因を断つ！
【設問2 (2)】 表5中の下線①について、修正後のライブラリQで行うJWTの検証では、どのようなデータに対してどのような検証を行うか。検証対象となるデータと検証の内容を、それぞれ20字以内で答えよ。
問題文の該当箇所
- 脆弱性: ヘッダとペイロードを改ざんしたJWTで、他の利用者になりすましが可能。
- 攻撃手法: JWTヘッダのアルゴリズム指定(alg)を “RS256” から “NONE” に書き換えることで、署名検証を回避し、改ざんしたペイロード（利用者ID）を正当なものとして誤認させた。
- 既存の仕様: ライブラリは、JWT内のヘッダに指定されたアルゴリズムに基づいてJWTを検証する。
解答
- 検証対象となるデータ: JWTヘッダ内のalgに指定された値
- 検証の内容: NONEでないことを検証する。
思考プロセス：【採点講評】で差がついた重要問題！
この問題は【採点講評】で「正答率がやや低かった」と指摘されています。脆弱性の本質を正確に理解できているかが問われました。
脆弱性の根本原因は、「ライブラリが、ヘッダで指定されたアルゴリズム(alg)を無条件に信用してしまっていた」 点にあります。
攻撃者は、algフィールドに”NONE”を指定しました。 これは「このJWTは署名されていませんよ」と宣言するようなものです。脆弱なライブラリは、この”NONE”という指定を見て、「なるほど、署名がないんだな。じゃあ署名検証はスキップしよう」と解釈してしまい、改ざんされたペイロードを素通ししてしまったのです。
したがって、対策は署名検証を行う前に、そもそも危険なアルゴリズムが指定されていないかをチェックすることです。
- 何を検証すべきか？(検証対象)
問題を引き起こしているのは、JWTのヘッダ部分にあるalgフィールドの値です。よって検証対象は「JWTヘッダ内のalgに指定された値」となります。 - どう検証すべきか？(検証の内容)
攻撃に使われた”NONE”という値を許可しないようにしなければなりません。つまり、「NONEでないこと」を検証する必要があります。本来であれば、システムが想定しているアルゴリズム（この場合は”RS256″）のみを許可するホワイトリスト方式がより安全ですが、脆弱性を直接防ぐという観点では「NONEを拒否する」ことが最低限の対策となります。
(3) 他人になりすませるアクセス制御の不備
【設問2 (3)】 表5中の下線②について、P呼出し処理に追加すべき処理を、40字以内で具体的に答えよ。
問題文の該当箇所
- 脆弱性: パラメータ mid に他の利用者IDを指定すると、その利用者の情報を取得・改変できてしまう。
- 認証の仕組み: 利用者はJWTを使って認証され、SシステムはJWT内の利用者IDで本人を識別する。
解答
JWTに含まれる利用者IDがmidの値と一致するかどうかを検証する処理
思考プロセス
これは、IDOR（Insecure Direct Object Reference: 不安全なダイレクトオブジェクト参照） と呼ばれる典型的なアクセス制御の脆弱性です。
現在のシステムは、
- リクエストが誰からのものか（アクセス主体）をJWTで確認している。
- どの利用者の情報を操作したいか（操作対象）をパラメータmidで受け取っている。
しかし、この「アクセス主体」と「操作対象」が同一人物であるかという最も重要なチェックが漏れていたのです。 その結果、攻撃者は自分の有効なJWTを使いながら、パラメータmidだけを他人のIDに書き換えることで、他人になりすまして情報を操作できてしまいました。
対策は非常にシンプルで、このチェック処理を追加することです。 P呼出し処理において、「JWTから取り出した利用者ID」と「パラメータで送られてきたmidの値」を比較し、両者が一致する場合にのみ処理を続行するように修正すれば、この脆弱性は防げます。
(4) 想定外のパラメータが通ってしまう脆弱性
【設問2 (4)】 表5中の (c) に入れる適切な字句を、表2中の用語で答えよ。
問題文の該当箇所
- 脆弱性: API仕様にない status パラメータを追加して送信すると、利用者ステータスを無償から有償に改変できてしまう。
- 原因分析: 実装は、指定されたパラメータを検証せず全て c に送信していた。
- 利用者APIの処理: 利用者APIは、共通モジュールPを呼び出して利用者情報を更新する。
解答
(c) 共通モジュールP
思考プロセス
これは、マスアサインメント（Mass Assignment）脆弱性に関連する問題です。 APIの仕様書（表2）にはstatusというパラメータは定義されていません。 しかし、バックエンドの処理（共通モジュールP）では、このstatusパラメータを受け付けてしまう実装になっていたようです。問題は、その中間に位置する利用者APIのP呼出し処理にあります。この処理が、APIの仕様で許可されているパラメータ（例：name, age）だけを選ぶのではなく、リクエストで送られてきたパラメータを無差別に（検証せず全て）、バックエンドの共通モジュールPに渡してしまっていたのです。
そのため、攻撃者が意図的にstatus=paidというパラメータをリクエストに含めると、それがそのまま共通モジュールPに渡され、権限昇格ができてしまいました。 文脈から、検証されていないパラメータが送信される先
c は、「共通モジュールP」であることが分かります。
(5) 総当たり攻撃への基本的な対策
【設問2 (5)】 表5中の(d) に入れる適切な処理内容を、30字以内で答えよ。
問題文の該当箇所
- 脆弱性: 総当たり攻撃で認証が突破できる。
- 対策案: d を実装する。そのしきい値は10とする。
解答
連続失敗回数がしきい値を超えたらアカウントをロックする処理
思考プロセス
現在の仕様では総当たり攻撃に対して脆弱です。その対策として「しきい値を10とするd を実装する」とあります。
認証における総当たり攻撃への対策で、「しきい値」という言葉が出てきたら、まずアカウントロックアウトを疑いましょう。これは、認証の失敗回数をカウントし、決められた回数（しきい値）に達したアカウントを一定時間、あるいは管理者が解除するまで利用できなくする仕組みです。
- 何をする処理か: アカウントをロックする処理。
- いつ発動するか: 認証の連続失敗回数がしきい値（10回）に達したとき。
これらをまとめて「連続失敗回数がしきい値を超えたらアカウントをロックする処理」という解答を導き出すことができます。これにより、攻撃者は短時間に何度も試行することができなくなり、総当たり攻撃は非常に困難になります。
まとめ：APIセキュリティの典型的な脆弱性をマスターしよう！
設問2では、APIセキュリティで頻出する以下の脆弱性と対策が問われました。
- 総当たり攻撃: 試行回数を計算し、アカウントロックアウトで対策する。
- JWTのalg:none攻撃: algヘッダの値を無条件に信用せず、危険な値が指定されていないか検証する。
- IDOR（アクセス制御不備）: アクセス主体（JWTの利用者）と操作対象（パラメータの利用者）が一致するかを必ず検証する。
- マスアサインメント: 受け取ったパラメータを無差別にバックエンドに渡さず、許可されたものだけを渡す（ホワイトリスト方式）。
これらの脆弱性は、机上の知識だけでなく、実際のシステム開発の現場でも頻繁に見つかるものです。原理と対策をセットでしっかり理解しておくことが、安全なシステムを構築し、情報処理安全確保支援士として活躍するための重要な一歩となります。
次回は、新たな脅威に対してWAFを使ってどう立ち向かうか、【設問3】を解説していきます！