https://www.ipa.go.jp/shiken/mondai-kaiotu/ps6vr70000010d6y-att/2023r05h_sc_pm2_qs.pdf
以下のおすすめ問題の解説となります。
良書。
[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）のリクエストに検証コードパラメータを追加する。最後に、④ 認可 サーバが二つのコードの関係を検証することで、攻撃者からのアクセストークン要求を排除できる。
(1)アクセストークン要求に必要なcodeパラメータを不正に取得できないから
認可コードであるこの一行が不正に作ることができない。
答えは、アクセストークン要求に必要なcodeパラメータを不正に取得できないから
(2)検証コードのSHA-256によるハッシュ値をbase64urlエンコードした値と、チャレンジコードの値との一致を確認する。
PKCEの基本的な考え方として、同一人物だよねを認可サーバが確認する方法についての話なんだよね。
問題文の上がヒントになっているので、Code_challenge_methodに検証用の値を入れるこ都が問われている。検証コードは、SHA256でハッシュ値を計算し、Base64でエンコードしたものとチャレンジコードと検証するが答えとなる。
