https://www.ipa.go.jp/shiken/mondai-kaiotu/gmcbt80000009sgk-att/2022r04h_sc_pm2_qs.pdf
以下のおすすめ問題の解説となります。
良書。
[従業員からの要望1]
GrW-G、メール-G及びIDaaS-Gへの移行及び SSOの準備が完了し、利用が開始された3か月後に、システム部は、X社の従業員に対して、GrW-G及びメール-Gについてのヒアリングを実施した。その回答に、GrW-Gでスケジュールを管理しているが、会議の主催者が会議日程の調整をもっと簡単にできるようにしてほしいという要望があった。Cさんは、S社が提供しているスケジュール調整サービス（以下、Sサービスという）を導入し、GrW-Gと連携させることで、その要望に応えることができると考えた。Sサービスの内容を表3に示す。
Cさんは、Sサービスの導入検討を進める中で、Sサービス、GrW-G及びIDaaS-Gの間の連携についてF氏に相談した。次は、その際のF氏とCさんの会話である。
F氏：Sサービス、GrW-G及びIDaaS-Gは、OAuth 2.0をサポートしています。OAuth 2.0を利用したサービス要求からスケジュール情報の取得までの流れは、図9のようになります。
Cさん： セキュリティ対策について確認すべきことはありますか。
F氏：二つあります。一つ目は、クロスサイトリクエストフォージェリ（以下、CSRFという）攻撃についてです。標的となる利用者が重要な秘密を扱う会議の主催者として日程を決定する場合を考えてみましょう。攻撃者は、GrW-Gに攻撃者のアカウントを登録し、当該GrW-Gにアクセスするための 認可コードを利用者に送付します。そのときに、図9の実装にCSRF脆弱性があり、かつ、利用者のWebブラウザが攻撃者によって生成された認可コードを受け付けてしまう実装となっている場合、利用者が気付かないうちに攻撃者のアカウントで会議日程が登録されてしまいます。対策として、stateパラメタの実装が求められています。適切な実装であれば、図9中の（o）において、stateパラメタを付与して送信し、図9中の（p）で送られてきたものと比較することで、攻撃を検知しているはずです。
二つ目は、利用者がSサービスへのアクセスにSサービスのスマホアプリを使う場合についてです。Sサービスのスマホアプリをインストールしたスマートフォンに、攻撃者が用意した不正なスマホアプリをインストールしてしまうと、GrW-Gにアクセスするための認可コードを、攻撃者のスマホアプリが横取りしてしまうという攻撃があります。
Cさん：二つ目の攻撃への対策にはどのようなものがありますか。
F氏：Sサービスのスマホアプリでランダムな検証コードとその値を基にしたチャレンジコードを作成して、そのチャレンジコードを認可要求に追加し、検証コードをトークン要求に追加します。二つのコードを検証することで、検証コードを知らない攻撃者からのトークン要求を排除できます。この仕組みは、（q）として標準化されています。
Cさん：分かりました。
k：Sサービス L IDaaS-G M GrW-G
この２つの読解問題である。SSO認証をかませるということは、
ユーザーからアクセス対象に行きその後認証動作を行った後目当てのデータにたどり着く流れが想定できる。解答は自然と埋まる。
n：エ
Sサービスは、GrW-Gから主催者のスケジュールを取得し、空き時間を表示する
という表現からエが該当する
o：(2),(6)
この脆弱性の対策は、同じ人が送ってきたどうかを確認することがポイントになります
Sサービスはリダイレクトのときに印をうっておいて、再度認可ｺｰﾄﾞが飛んできた際に、印が入ってるかどうか確認することで検証が可能です。
これは過去の問題でも出ているポイントですね。
q：
Sサービスのスマホアプリでランダムな検証コードとその値を基にしたチャレンジコードを作成して、そのチャレンジコードを認可要求に追加し、検証コードをトークン要求に追加します。二つのコードを検証することで、検証コードを知らない攻撃者からのトークン要求を排除できます。この仕組みは、（q）として標準化されています。
PKCE（Proof Key for Code Exchange）です
ここは知識問題なので、知らないと答えれません。。
身近な事例を読んでおくと記憶に残るでしょう。
