【情報処理安全確保支援士試験 令和6年度 春期 午後 問1 No.2】

情報処理安全確保支援士試験 令和6年度 春期 午後 問1

【出典：情報処理安全確保支援士試験 令和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の提供を開始した。

（b）に入れる適切な数値を、小数点以下を四捨五入して、整数で答えよ。：500

「総当たり攻撃によって、文字列Xを使った認証メカニズムを突破できる。1秒間に10回試行する総当たり攻撃を行った場合、文字列Xの検証において、平均的な認証成功までの時間は（b）秒になり、突破される可能性が高い。」
 文字列Xについては、表2に「毎回ランダムに生成される数字4桁の文字列」とありました。
 数字4桁（0000〜9999）の1万通り分に対し、1秒間に10回試行する総当たり攻撃するということは、認証成功するまでには最短で0.1秒、最長で1000秒かかります。
 したがって、平均時間は（0.1+0.2+〜+999.9+1000）/1000から500秒となります。（最大1000秒の半分と想定できます）

下線①について、修正後のライブラリQで行うJWTの検証では、どのようなデータに対してどのような検証を行うか。検証対象となるデータと検証の内容を、それぞれ20字以内で答えよ。：（データ）JWTヘッダ内のalgに指定された値/（内容）NONEでないことを検証する。

「①ライブラリQを修正する。」
ライブラリQ、JWTについて、改めて問題文を確認します。

• JWT（JSON Web Token）
  • S-APIの認証APIが認証成功時に発行する（表2より）
    →JSON（Java Script Object Notation）フォーマットで生成された認証トークン
  • ”ヘッダ”（署名時のアルゴリズムを指定）、”ペイロード”（利用者ID、有効期限など）、”署名”（ヘッダとペイロードに対する署名）から構成され、各要素はbase64urlでエンコードされ、”.”で結合される（図4より）

• ライブラリQ
  • Sシステムで利用するF社が開発したJWT管理ライブラリである（図4より）
  • G社アプリから受信したJWTを、JWT内のヘッダに指定されたアルゴリズムに基づいて検証する（図4より）

 対策案「ライブラリQを修正する。」の対象となる脆弱性は、表3の項番1に「ヘッダとペイロードを改ざんしたJWTを送信すると、他の利用者へのなりすましが可能である。」になります。

 この脆弱性の説明として問題文の続きに「認証APIで、利用者ID”user01”での認証が成功した後、診断中に発行されたJWTのデコード結果は、表4のとおりであった。」とあります。
 補足すると、利用者ID”user01”は、SシステムからG社スマホアプリに発行されたJWTを認証トークンとしてSシステムに送信することで、認証済みの利用者であることを通知します。
 また、JWTはbase64urlでエンコードされて暗号化はされていないため、base64urlでデコードが可能です。

 そして、表4について、「ここで、表4中の”RS256”の代わりに”NONE”を指定し、”user01”を他の利用者IDに改ざんしたJWTを送信したところ、改ざんしたJWTの検証が成功し、他の利用者へのなりすましができた。」とあります。
 ヘッダの”alg”について、図4に「署名：ヘッダに指定されたアルゴリズムとシステムが生成したシークレットを使用し、ヘッダとペイロードに対する署名が作成される。」とあります。
 ここではアルゴリズムにRS256とありSHA-256でハッシュ化しますが、NONEが指定された場合には署名が作成されず、Sシステム側でJWTの署名の検証もされなくなります。
 したがって、JWTの検証が適切に行われず、他の利用者へのなりすましができてしまうことになります。
 ライブラリQの修正後では、JWTヘッダ内のalgに指定された値に対して、NONEでないことを検証するようにする必要があります。
 なお、IPAの採点講評では「正答率がやや低かった。JSON Web Token（JWT）改ざんにおける検証方法を問うたが、既に実装されている対策を解答するなど、脆弱性を正しく理解していないと思われる解答が散見された。図4に示す仕様と表3に示す脆弱性を正しく理解してほしい。」とあります。

下線②について、P呼出し処理に追加すべき処理を、40字以内で具体的に答えよ。：JWTに含まれる利用者IDがmidの値と一致するかどうかを検証する処理

「②P呼出し処理に処理を追加する。」
 対策案「P呼出し処理に処理を追加する。」の対象となる脆弱性は、表3の項番2に利用者APIとして「パラメータmidに他の利用者IDを指定すると、他の利用者IDにひも付く利用者情報を取得、改変できてしまう。」になります。
 改めて利用者APIを表2で確認すると、利用者IDについては、認証APIで指定するものとは別に利用者APIでも指定できてしまうようです。
 つまり、認証成功した利用者IDとは別の利用者IDを指定できてしまうことが問題です。
 したがって、追加する処理としては、JWTに含まれる利用者IDとmidで指定する利用者IDが一致することを検証する処理が必要になります。

（c）に入れる適切な字句を、表2中の用語で答えよ。：共通モジュールP

「利用者APIの仕様には、パラメータ”status”の指定について定義されていない。一方、実装は、指定されたパラメータを検証せず全て（c）に送信していた。ここで、送信内容を改ざんしてパラメータ”status”を追加してリクエストを送信すると、（c）は利用者ステータスを変更できる。」
 対策案「プログラムの修正で対応する。」の対象となる脆弱性は、表3の項番3に利用者APIとして「利用者APIで利用者情報を更新する場合、”paid”という値を設定したパラメータ”status”を追加して送信すると、利用者ステータスを無償利用者から有償利用者に改変できてしまう。」になります。
 改めて利用者APIを表2で確認すると、利用者情報の取得・更新ができ、その流れはサービスLのP呼出し処理が利用者からのパラーメータを共通モジュールPに渡し、共通モジュールPがサービスMを呼び出して、GETおよびPUTの各処理を行うとあります。
 利用者ステータスを含む利用者情報は、表1からサービスMのデータベースにあり、サービスMを呼び出す共通モジュールPが利用者ステータスを変更できることになります。

（d）に入れる適切な処理内容を、30字以内で答えよ。：連続失敗回数がしきい値を超えたらアカウントをロックする処理

「（d）を実装する。そのしきい値は10とする。」
 対策案「しきい値を10とする」の対象となる脆弱性は、表3の項番4に認証APIとして「総当たり攻撃によって、文字列Xを使った認証メカニズムを突破できる。1秒間に10回試行する総当たり攻撃を行った場合、文字列Xの検証において、平均的な認証成功までの時間は（b：500）秒になり、突破される可能性が高い。」になります。
 しきい値を10回とすることから、短時間での試行回数に対する当該アカウントをロックする処理であることが想定できます。
 連続失敗回数が10回でアカウントをロックして、11回目の攻撃はできなくなります。