問題文
問1 APIセキュリティに関する次の記述を読んで、設問に答えよ。
G社は、ヘルスケアサービスY（以下、サービスYという）を提供する健康新興企業である。利用者が食事、体重などを入力して、そのデータを管理したり、健康リスクの判定や食事メニューのアドバイスを受けたりできるサービスを計画している。具体的には、クラウドサービス上にサービスY用のシステム（以下、Sシステムという）を構築して、G社が既に開発しているスマートフォン専用アプリケーションプログラム（以下、G社スマホアプリという）からアクセスする。Sシステムの要件を図1に示す。
【図1 Sシステムの要件（抜粋）】 | 要件 | 内容 | | :--- | :--- | | 要件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を導入しない計画である。
【図2 サービスYのシステム構成】 G社スマホアプリは、インターネットを介してE社クラウドサービス上のSシステム（サービスK、L、M）にアクセスする。Sシステムは外部サービスとも連携する。
【図3 S-API呼び出し時の動作概要（抜粋）】
• 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, PUT | mid（利用者ID）
name（名前）
age（年齢） | 注記：Sシステムは、表中のパラメータのほか、HTTPリクエストのヘッダに含まれる情報を用いて処理を行う。
【JWTを利用したアクセス】 JWTは、“ヘッダ”、“ペイロード”、“署名”の3種類の要素から構成されており、各要素はBase64URLでエンコードされ、“.”（ドット）で結合されている。
• ヘッダ：署名の作成の際に使用するアルゴリズムが指定される。
• ペイロード：利用者ID、有効期限などが含まれる。
• 署名：ヘッダに指定されたアルゴリズムとシステムが生成したシークレットを使用し、ヘッダとペイロードに対する署名が作成される。 Sシステムでは、JWTの管理に、F社が開発したJWT管理ライブラリ（以下、ライブラリQという）を利用する。Sシステムから発行されたJWTは、G社スマホアプリに保存される。G社スマホアプリは、HTTPリクエスト内のAuthorizationヘッダにBearerスキーマとJWTを設定し、Sシステムに送信する。Sシステムは、受信したJWTをライブラリQに渡す。ライブラリQは、JWT内のヘッダに指定されたアルゴリズムに基づいてJWTを検証する。JWT内の署名を検証した後、ペイロードに含まれた利用者IDを確認して利用者を識別し、必要な情報を含めてレスポンスを返す。ペイロードに含まれた有効期限まで許可される。
〔脆弱性診断の結果〕 Sシステムの構築が進み全ての機能が動作確認できたので、G社でSシステムのセキュリティを担当するRさんが、セキュリティベンダーであるU社に脆弱性診断（以下、診断という）を依頼した。U社による診断レポートを表3に示す。
【表3 U社による診断レポート（抜粋）】 | 項番 | 名称 | 対象API | 脆弱性 | | :--- | :--- | :--- | :--- | | 1 | JWT改ざんによるなりすまし | 全体 | JWTに指定された利用者IDを利用してデータが取得、更新されるので、ヘッダとペイロードを改ざんしたJWTを送信すると、他の利用者へのなりすましが可能である。 | | 2 | アクセス コントロールの不備A | 利用者API | IDにひも付く利用者の利用者情報を取得、改変できてしまう。 | | 3 | アクセス コントロールの不備B | 利用者API | 利用者APIで利用者情報を更新する場合、“paid”という値を設定したパラメータ“status”を追加して送信すると、利用者ステータスを無償利用者から有償利用者に改変できてしまう。 | | 4 | 2要素認証の突破 | 認証API | 総当たり攻撃によって、文字列Xを使った認証メカニズムを突破できる。秒間に10回試行する総当たり攻撃を行った場合、文字列Xの検証において、平均的な認証成功までの時間は b 秒になり、突破される可能性が高い。 |
表3の項番1について、U社のセキュリティコンサルタントで情報処理安全確保支援士（登録セキスペ）のZ氏は、次のように説明した。 認証APIで、利用者ID“user01”での認証が成功した後、診断中に発行されたJWTのデコード結果は、表4のとおりであった。
【表4 JWTのデコード結果（抜粋）】 | ヘッダ | ペイロード | | :--- | :--- | | { "alg": "RS256", (省略) } | { "user": "user01", "iat": 1713859329, "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の提供を開始した。
〔新たな脆弱性への対応〕 数週間後、ライブラリHというオープンソースのライブラリに脆弱性Vという脆弱性があることが公表された。Rさんは、脆弱性Vについての関連情報を図6のように取りまとめた。
【図6 脆弱性Vについての関連情報（抜粋）】
• ライブラリ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ファイルが配置されたURL（以下、URL-Jという）を攻撃用LDAPサーバに伝える。
6. 攻撃用LDAPサーバは、URL-JをLDAPレスポンスに記載して攻撃対象サーバに返す。
7. 攻撃対象サーバは、受信したLDAPレスポンスに記載されたURL-Jにアクセスし、Jファイルをダウンロードして、コマンドCを実行する。
• 脆弱性VのCVSS v3.1に基づいた基本値は9.8と高く、早急な対応が推奨されている。しかし、現時点において、ライブラリHの公式Webサイトでは、脆弱性Vを修正したバージョンや暫定対策は提供されていない。
• SシステムではサービスLでライブラリHを利用しているかをF社に問い合わせているが、Sシステムの構成を詳細に分析しなければならず、回答まで時間が掛かるとのことである。
• E社は、脆弱性Vを悪用した攻撃を検知するために、サービスNにおけるWAFルールを現在開発中であるが、悪用パターンが多岐にわたることなどから、網羅性のあるWAFルールの提供には最大で72時間掛かると発表している。
Rさんは、脆弱性Vへの対応方針をZ氏に相談した。Z氏は、F社の回答を待ってからの対応では遅いので、システムに影響を与えない検証コードをSシステムに対して実行し、外部から脆弱性Vを悪用できるか検証するよう提案した。Rさんは、Z氏の協力の下、図7に示す手順で検証を実施した。
【図7 Rさんが実施した検証手順】
- 攻撃用LDAPサーバと攻撃用HTTPサーバを兼ねたサーバ（以下、テストサーバという）を構築する。
- 図8に示す検証コードを作成する。
- ③図8で指定したコマンドが実行されたことを確認する仕組みをテストサーバに実装する。
- 検証コードをHTTPリクエスト中に指定してSシステムに送信する。
Rさんが考えたWAFルールの案を表6に示す。
【表6 WAFルールの案】 | ルール | 検討対象 | パターン | 動作 | | :--- | :--- | :--- | :--- | | 1 | e | ¥Wjndi¥W | 遮断 | | 2 | f | ¥Wldap¥W | 遮断 |
Rさんは、例えば“jNDi”のように大文字・小文字を入れ替える手口によって、ルール1と2それぞれで、案のパターンを回避する方法があることに気付いた。④このような手口にも対処できるように案を変更した。 その後、変更後の案の確認をZ氏に依頼した。 Z氏は、⑤本番運用開始後の一定期間においては、WAFルールの動作には“検知”を設定して、サービスYが今までどおり利用できるかを確認することを助言した。Rさんは、Z氏の助言を踏まえて、WAFルールを設定した。
設問
設問1 本文中の a に入れる適切な字句を答えよ。
設問2 〔脆弱性診断の結果〕について答えよ。 (1) 表3中の b に入れる適切な数値を、小数点以下を四捨五入して、整数で答えよ。 (2) 表5中の下線①について、修正後のライブラリQで行うJWTの検証では、どのようなデータに対してどのような検証を行うか。検証対象となるデータと検証の内容を、それぞれ20字以内で答えよ。 (3) 表5中の下線②について、P呼び出し処理に追加すべき処理を、40字以内で具体的に答えよ。 (4) 表5中の c に入れる適切な字句を、表2中の用語で答えよ。 (5) 表5中の d に入れる適切な処理内容を、30字以内で答えよ。
設問3 〔新たな脆弱性への対応〕について答えよ。 (1) 図7中の下線③について、テストサーバに実装する仕組みを、35字以内で具体的に答えよ。 (2) 表6中の e 、 f に入れる適切な字句を、図5中から選び答えよ。 (3) 本文中の下線④の変更後の案について、表6中のルール1に記述すべきパターンを、図5の記述形式で答えよ。 (4) 本文中の下線⑤について、WAFルールの動作に“遮断”ではなく“検知”を設定することによる利点と、“検知”に設定した際に被害を最小化するために実施すべき内容を、それぞれ25字以内で答えよ。
解答解説
設問1
• 解答: a ステートレス
• 解説: 問題文には「RESTful APIの設計原則の一つにセッション管理を行わないという性質がある」と記述されています。これはRESTにおけるステートレス（Stateless）の原則を指します。クライアントからのリクエストに必要な情報が全て含まれているため、サーバ側でセッション状態を管理する必要がなく、スケーラビリティが向上するという利点があります。
設問2 (1)
• 解答: b 500
• 解説: 文字列Xは数字4桁なので、組み合わせは10,000通りです。秒間10回試行できるため、1回の試行には0.1秒かかります。したがって、全ての組み合わせを試すには 10,000回 × 0.1秒 = 1,000秒 が必要です。平均的な認証成功までの時間は、この半分の500秒となります。
(2)
• 解答:
◦ 検証対象となるデータ： JWTヘッダ内のalgに指定された値（18字）
◦ 検証の内容： NONEでないことを確認する。（15字）
• 解説: 表4のJWTデコード結果のヘッダでは、署名アルゴリズムとして"RS256"が指定されていますが、これを"NONE"に改ざんすることで署名検証を回避し、なりすましが成功しました。この脆弱性への対策として、修正後のライブラリQでは、JWTのヘッダに含まれるalgの値が"NONE"でないことを検証する処理を追加する必要があります。
(3)
• 解答: JWTに含まれる利用者IDがmidの値と一致するかどうかを検証する処理（35字）
• 解説: この脆弱性（アクセス コントロールの不備A）は、利用者APIが、リクエストのパラメータmidで指定された利用者IDと、JWTのペイロードに含まれる利用者IDが一致するかどうかを検証せずに処理を行っていたために発生しました。対策として、P呼び出し処理において、JWTペイロード内の利用者IDと、APIリクエストのパラメータmidで渡された利用者IDが同一であることを確認する処理を追加する必要があります。
(4)
• 解答: c 共通モジュールP
• 解説: 表5の分析には、指定されたパラメータを検証せず全て c に送信していたとあります。表2の利用者APIの概要から、利用者ステータスの管理は「共通モジュールP」が担っていることが分かります。したがって、cには共通モジュールPが入ります。
(5)
• 解答: d 連続失敗回数がしきい値を超えたらアカウントをロックする処理（29字）
• 解説: 表3の項番4にある2要素認証の突破は、総当たり攻撃によるものです。この種の攻撃への一般的な対策は、一定回数認証に失敗したアカウントを一時的にロックすることです。表5の対策案ではしきい値を10とするとあるため、認証の連続失敗回数がしきい値（10回）を超えた場合にアカウントをロックする処理を実装することが適切です。
設問3 (1)
• 解答: テストサーバのindex.htmlへのアクセスを記録し、確認する仕組み（35字）
• 解説: 図8の検証コードは、コマンドCとしてwget http://a2.b2.c2.d2/index.htmlを実行するものです。このコマンドがSシステム上で実行されれば、テストサーバ上のindex.htmlにアクセスが発生します。したがって、テストサーバ側でこのファイルへのアクセスログを監視し、記録が確認できれば、脆弱性を悪用した攻撃が成功したと判断できます。
(2)
• 解答: e Header f jndi[dlnr]i[dlnr]p¥W
• 解説: 図6の攻撃の流れ(3)によると、攻撃コードは「HTTPリクエストのx-api-versionヘッダの値として指定」されます。したがって、eはHeaderです。また、表6のルール1と2は、攻撃コードに含まれる文字列"jndi"と"ldap"をそれぞれ検出しようとしています。大文字・小文字を入れ替える手口（例："jNDi"）に対応するため、図5の正規表現パターン[xyz]（x, y, zのいずれかにマッチ）を使い、jndi[dlnr]i[dlnr]p¥W のように記述することで、"j", "n", "d", "i", "l", "r", "p" の大文字・小文字の組み合わせに対応できます。
(3)
• 解答: ¥Wjndi[dlnr]i[dlnr]p¥W
• 解説: 下線④の「このような手口」とは、大文字・小文字を入れ替える手口を指します。さらに、図5のWAFルール記述形式には、英数字以外の任意の文字にマッチする¥Wがあります。この¥Wをパターンの前後に追加することで、攻撃文字列の前後に他の文字列が付加されている場合にも対応できるようになり、検知の精度が向上します。
(4)
• 解答:
◦ 利点： 正常な通信を誤検知して遮断するのを防ぐため。（22字）
◦ 実施すべき内容： 影響範囲を調査し、原因となったWAFルールを修正する。（27字）
• 解説: WAFのルールを「遮断」に設定すると、正常な通信を攻撃と誤検知（フォールスポジティブ）してしまい、サービス提供に影響を与えるリスクがあります。そのため、導入初期は「検知」（監視モード）に設定し、どのような通信が検知されるかを確認します。これにより、誤検知のリスクを避けつつ、攻撃の可能性を把握できます。そして、検知された通信を分析し、もし攻撃が検知された場合は、その影響範囲を調査し、必要に応じてWAFルールをより適切なものに修正することで、被害を最小限に抑えることができます。
要点
承知いたしました。 情報処理安全確保支援士試験の午後I問1について、ITを学び始めた方にも分かりやすいように、問題文の内容を「①背景情報」「②課題」「③検討・対策」の3つのパートに分けて解説します。
① 背景情報：どんなサービスで、どんな仕組み？
この問題は、あるヘルスケアサービスを安全に提供するための物語です。登場する会社と、彼らが作るシステムの構成を理解することが最初のステップです。
登場する会社と役割
• G社: ヘルスケアサービス「サービスY」を提供する会社です。
• F社: ITベンダー。G社に依頼されて、サービスYのシステム（Sシステム）を開発・構築しました。
• E社: クラウドサービスを提供している会社。Amazon Web Services (AWS) や Google Cloud Platform (GCP) のような存在です。Sシステムは、このE社のクラウド上で動いています。
• U社: セキュリティ専門の会社。完成したSシステムに危険な欠陥（脆弱性）がないか診断しました。
システムと技術の構成
G社が提供したい「サービスY」は、利用者がスマホアプリから食事や体重を記録すると、AIが健康アドバイスをくれるというものです。このサービスを実現するために、E社のクラウド上に「Sシステム」が構築されました。
【Sシステムの構成要素 (E社のサービス)】
• サービスK (APIゲートウェイ):
◦ スマホアプリからの通信（APIリクエスト）を最初に受け取る総合受付のような役割です。
◦ リクエスト内容に応じて、実際の処理を行うサービスLを呼び出します。
• サービスL (コンピューティングサービス):
◦ システムの頭脳や手足にあたる部分です。
◦ サービスKからの指示を受けて、利用者情報の照会やアドバイスの生成といった具体的な処理を実行します。
◦ この処理の中で、F社が開発したプログラム部品（共通モジュールPやライブラリQ）が使われています。
• サービスM (データベース):
◦ 利用者情報や食事の記録などを保存しておくデータの保管庫です。
【システム間の連携の流れ】 利用者がスマホアプリを使うと、システム内部では以下のようなやり取りが行われます。
- スマホアプリからのアクセス:
◦ 利用者のスマホアプリ（G社スマホアプリ）が、インターネットを通じてSシステムのAPI（S-API）を呼び出します。 - Sシステム内の処理:
◦ リクエストはまず**サービスK（受付）に届きます。
◦ サービスKは、リクエストをサービスL（頭脳）に渡します。
◦ サービスLは、必要に応じてサービスM（保管庫）**からデータを読み書きし、処理を実行します。
◦ 処理結果は、サービスL → サービスK → スマホアプリの順で返されます。
【認証の仕組み：JWT】 サービスYでは、利用者が本人であることを確認するためにJWT (JSON Web Token) という電子的な「通行証」を使います。 - ログインと通行証の発行:
◦ 利用者はIDとパスワードでログインします。
◦ 成功すると、登録メールアドレスに**4桁の数字（文字列X）が送られます。
◦ その数字を入力して再度認証すると、システムはJWT（通行証）**を発行してスマホアプリに渡します。 - 通行証を使ったアクセス:
◦ 一度JWTを受け取れば、スマホアプリはその後、APIを呼び出すたびにこのJWTを提示します。
◦ Sシステムは、F社が開発したライブラリQというプログラムでJWTが偽造されていないか検証し、正当な利用者からのアクセスかを判断します。
② 課題：見つかった脆弱性（セキュリティ上の欠陥）
U社のセキュリティ診断により、Sシステムにはいくつかの深刻な脆弱性があることが判明しました。
• 課題1: JWT改ざんによるなりすまし
◦ 内容: JWT（通行証）には「この通行証は"RS256"という方式で暗号化されています」という情報が含まれています。しかし、この部分を「暗号化なし（"NONE"）」に書き換え、利用者IDも他人のものに改ざんすると、システムがチェックを素通りさせてしまい、他人になりすませる状態でした。
• 課題2: アクセスコントロールの不備A
◦ 内容: 利用者APIで自分の情報を更新する際に、リクエストに他人の利用者IDを指定すると、他人の情報を閲覧したり書き換えたりできてしまう欠陥です。通行証（JWT）を持っている本人と、操作対象の人物が一致するかを確認する処理が漏れていました。
• 課題3: アクセスコントロールの不備B
◦ 内容: 本来、利用者のプラン（無償/有償）はシステム側で管理されるべきものです。しかし、APIリクエストに「status="paid"（有償にする）」という本来仕様にないパラメータを追加して送ると、無償利用者が自分を有償利用者に不正に変更できてしまいました。
• 課題4: 2要素認証の突破
◦ 内容: ログイン時にメールで送られてくる4桁の数字は、組み合わせが1万通りしかありません。これをコンピューターで高速に総当たり攻撃すると、平均500秒（約8分）で突破できてしまう弱い仕組みでした。
• 新たな課題: ライブラリHの脆弱性V
◦ サービス開始後、Sシステムで使われているかもしれないオープンソースの部品（ライブラリH）に、外部からPCを乗っ取られるほどの超危険な脆弱性Vが公表されました。
◦ この脆弱性を悪用されると、攻撃者が用意したサーバーにSシステムがアクセスさせられ、最終的にシステム上で任意のコマンドを実行されてしまう恐れがありました。
③ 検討・対策：脆弱性をどう修正したか
見つかった課題に対し、G社はF社やU社と協力して対策を進めました。
初期の4つの脆弱性への対策
• 対策1 (JWT改ざんへ): F社が開発したJWT検証用のライブラリQを修正しました。具体的には、JWTの署名方式に「暗号化なし（NONE）」が指定された場合は、無条件でエラーとする処理を追加しました。
• 対策2 (アクセスコントロール不備Aへ): 利用者情報を操作する処理の前に、「リクエストを投げている本人（JWTの利用者ID）と、操作対象の利用者IDが一致するか」を確認するチェック処理を追加しました。
• 対策3 (アクセスコントロール不備Bへ): プログラムを修正し、APIの仕様で定義されていないパラメータ（statusなど）が送られてきた場合は、それを無視するようにしました。
• 対策4 (2要素認証の突破へ):
1. 認証に何度も失敗したアカウントを一時的に利用できなくする**「アカウントロック」の仕組みを導入しました。
2. 認証に使う数字を4桁から6桁に変更し、総当たり攻撃を困難にしました。
新たな脆弱性Vへの対策（段階的な対応）
この脆弱性への対応は、一刻を争うため、段階的に行われました。
【ステップ1: 暫定対策とシステム構成の変更】
• WAFの導入: まず、E社が提供するサービスN（WAF：Web Application Firewall）を緊急導入しました。WAFは、システムの手前に立つ警備員のように、不正な通信を検知・遮断する役割を担います。
• WAFルールの設定:
1. 脆弱性Vを悪用する攻撃通信に含まれる特徴的な文字列（"jndi", "ldap"など）を検知するルールを作成しました。
2. 最初は「遮断」モードではなく「検知」モードで運用を開始**しました。これは、万が一正常な通信を間違って止めてしまい、サービスに影響が出るのを防ぐためです。まずはいったん様子を見て、攻撃が来た場合にアラートで把握できるようにしました。
【ステップ2: 恒久対策】
• ライブラリの更新: WAFで時間を稼いでいる間に、根本的な原因を解消しました。F社に調査してもらい、Sシステム（サービスL）内で使われていた脆弱なライブラリHを、脆弱性が修正された最新バージョンに更新しました。
この一連の対策により、Sシステムはセキュリティ上の問題を解消し、安全にサービスを提供できる状態になりました。