情報処理安全確保支援士試験 令和5年度 春期 午後2 問2
【出典：情報処理安全確保支援士試験 令和5年度 春期 午後2 問2（一部、加工あり）】
[F社の開発環境]
F社では、Rモジュールの開発は、取りまとめる開発リーダー1名と、実装から単体テストまでを行う開発者3名のチームで行う。システム開発において、顧客から開発を委託されたプログラムのソースコードのリポジトリと外部に公開されているOSSリポジトリを利用している。二つのリポジトリは、サービスEというソースコードリポジトリサービスを利用して管理している。
サービスEの仕様と、RモジュールについてのF社のソースコード管理プロセスは、表9のとおりである。
[悪意のある不正なプログラムコードの混入]
F社は、Rモジュールの実装について単体テストまでを完了して、ソースコードをW社に納品した。その後、W社とT社は結合テストを開始した。
結合テスト時、外部のホストに対する通信がRモジュールから発生していることが分かった。調べたところ、不正なプログラムコード（以下、不正コードMという）がソースコードに含まれていたことが分かった。不正コードMは、OSの環境変数の一覧を取得し、外部のホストに送信する。新日記サービスでは、エンコード値GがOSの環境変数に設定されていたので、その値が外部のホストに送信されていた。
W社は、漏えいした情報が悪用されるリスクの分析と評価を行うことにした。それと並行して、不正コードMの混入の原因調査と、プログラムの修正をF社に依頼した。
[W社によるリスク評価]
W社は、リスクを分析し、評価した。評価結果は次のとおりであった。
- エンコード値Gを攻撃者が入手した場合、（m）のWebサーバであると偽ってリクエストを送信できる。しかし、図3のシーケンスでは、③攻撃者が特定の会員のアクセストークンを取得するリクエストを送信し、アクセストークンの取得に成功することは困難である。
次に、W社は、近い将来に要件2を実装する場合におけるリスクについても、リスクへの対応を検討した。
そのリスクのうちの一つは、スマホアプリのリダイレクトにカスタムURLスキームを利用する場合に発生する可能性がある。W社が提供するスマホアプリと攻撃者が用意した偽のスマホアプリの両方を会員が自分の端末にインストールしてしまうと、正規のスマホアプリとサーバとのやり取りが偽のスマホアプリに横取りされ、攻撃者がアクセストークンを不正に取得できるというものである。この対策として、PKCE（Proof Key for Code Exchange）を利用すると、偽のスマホアプリにやり取りが横取りされても、アクセストークンの取得を防ぐことができる。
要件2を実装する場合のサービス要求から記事投稿結果取得までの流れを図4に示す。
PKCEの実装では、乱数を基に、チャレンジコードと検証コードを生成する。（3）のリクエストにチャレンジコードとcode_challenge_methodパラメータを追加し、（7）のリクエストに検証コードパラメータを追加する。最後に、④認可サーバが二つのコードの関係を検証することで、攻撃者からのアクセストークン要求を排除できる。
下線③について、アクセストークンの取得に成功することが困難である理由を、表8中のパラメータ名を含めて、40字以内で具体的に答えよ。：アクセストークン要求に必要なcodeパラメータを不正に取得できないから
「エンコード値Gを攻撃者が入手した場合、（m）のWebサーバであると偽ってリクエストを送信できる。しかし、図3のシーケンスでは、③攻撃者が特定の会員のアクセストークンを取得するリクエストを送信し、アクセストークンの取得に成功することは困難である。」
図3において会員のアクセストークンを取得するリクエストは（7）アクセストークン要求であり、具体的に送信されるデータは表8の（q：（7））のPOSTメソッドになります。
POSTメソッドの各パラメータについて、攻撃者が準備できる内容かを確認します。
- POST /oauth/token HTTP/1.1
サービスTが認証連携用に公開しているURIと想定できるため、攻撃者は準備できます。 - Authorization:Basic YWJjZDEyMzQ6UEBzc3dvcmQ=
注2)にあるように、エンコード値Gであり、攻撃者が入手している情報になります。 - grant_type=authorization_code
OAuth2.0でトークン要求する場合の指定方法のため、攻撃者は準備可能です。 - &code=5810f68ad195469d85f59a6d06e51e90
認可コードであり、（3）認可要求〜（6）認可コードのやり取りで取得できる情報のため、攻撃者は準備できません。 - &redirect_uri=https://△△△.com/callback
（1）サービス要求〜（3）認可要求のやり取りで取得できる情報ですが、攻撃者が利用者としてアクセスすれば入手可能な内容です。
下線④について、認可サーバがチャレンジコードと検証コードの関係を検証する方法を、”ハッシュ値をbase64urlエンコードした値”という字句を含めて、70字以内で具体的に答えよ。ここで、code_challenge_methodの値はS256とする。：検証コードのSHA-256によるハッシュ値をbase64urlエンコードした値と、チャレンジコードの値との一致を確認する。
「最後に、④認可サーバが二つのコードの関係を検証することで、攻撃者からのアクセストークン要求を排除できる。」
ちょっと理解が難しいので順番に整理していきます。
問題となるのは、「そのリスクのうちの一つは、スマホアプリのリダイレクトにカスタムURLスキームを利用する場合に発生する可能性がある。W社が提供するスマホアプリと攻撃者が用意した偽のスマホアプリの両方を会員が自分の端末にインストールしてしまうと、正規のスマホアプリとサーバとのやり取りが偽のスマホアプリに横取りされ、攻撃者がアクセストークンを不正に取得できるというものである。」という記述にあります。
図4のスマホアプリから認可サーバへの通信である（7）アクセストークン要求において、攻撃者がアクセストークンを不正に取得できるということは、正規のスマホアプリの（1）〜（6）をやり取りを偽のスマホアプリが横取りして取得するということです。
この対策として、「この対策として、PKCE（Proof Key for Code Exchange）を利用すると、偽のスマホアプリにやり取りが横取りされても、アクセストークンの取得を防ぐことができる。」「PKCEの実装では、乱数を基に、チャレンジコードと検証コードを生成する。（3）のリクエストにチャレンジコードとcode_challenge_methodパラメータを追加し、（7）のリクエストに検証コードパラメータを追加する。」という記述があります。
PKCEで生成するチャレンジコードと検証コードのうち、（3）認可要求に含まれるのはチャレンジコードとcode_challenge_methodとあり、検証コードはありません。
そして、（7）アクセストークン要求で検証コードパラメータを追加するとあり、ここで初めて検証コードが出てきます。
つまり、偽のスマホアプリが横取りできるのはチャレンジコードとcode_challenge_methodのみで、検証コードは取得できないことで、攻撃者によるアクセストークン要求を排除することができるということです。
もう少し深掘りすると、設問の「ハッシュ値をbase64urlエンコードした値」「code_challenge_methodの値はS256」という記述から、PKCEでは、検証コードを生成し、その検証コードをSHA-256でハッシュ化したものをbase64url方式でエンコードしたチャレンジコードを生成するということです。
そして、認可サーバでは、受信した検証コードをSHA-256でハッシュ化したものをbase64url方式でエンコードした値と、チャレンジコードの値が一致するかどうかで正規のスマホアプリであることを検証します。