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

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

【出典：情報処理安全確保支援士試験令和4年度春期午後2 問2（一部、加工あり）】

[従業員からの要望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

まずは、図9に出てくる項目を整理して行きましょう。

「GrW-G、メール-G及びIDaaS-Gへの移行及びSSOの準備が完了し、利用が開始された・・・」
「S社が提供しているスケジュール調整サービス（以下、Sサービスという）を導入し、GrW-Gと連携させることで、その要望に応えることができる」
「Sサービス、GrW-G及びIDaaS-Gは、OAuth 2.0をサポートしています。OAuth 2.0を利用したサービス要求からスケジュール情報の取得までの流れは、図9のようになります。」

1項のSSOの認証では、前の問題文からSAMLを使っていました。
2項のとおり新たにSサービスを導入してGrW-Gと連携させる必要がありますが、その方法として3項のOAuth 2.0を使うとしています。
OAuth（Open Authorization）は認可のことであり、SAMLで認証後にOAuthで認可する仕組みとなります。
さて、図9の流れは以下のとおりです。

⑴（利用者の端末からのサービス要求）のアクセス先は、表3（Sサービスの内容（抜粋））の項番2⑴にある「主催者は、Sサービスにアクセスする。」とあることから、kはSサービスになる。
⑵⑶ではSサービスがGrW-Gへのアクセスを認可してもらうために、まずはIDaaS-Gにリダイレクトで認可要求を行う。（lはIDaaS-Gになる）
⑷⑸で利用者が同意処理を行って、IDaaS-GからGrW-G向けの認可コードを含むリダイレクトが応答され、⑹でSサービスに認可コードが渡る。
⑺でSサービスがIDaaS-Gに認可コードを送信して、⑻でIDaaS-Gが認可コードが⑸で送信したものと同じであればGrW-Gにアクセスするためのトークンを応答する。
⑻でSサービスがトークンを使ってGrW-Gに利用者情報（スケジュール）の問合せを行い、GrW-Gでトークンが正しいことを確認して利用者情報を応答する。（mはGrW-Gになる）

n：エ

図9での認可処理に続くシーケンスになります。
表3（Sサービスの内容（抜粋））を確認すると、項番2⑵に「Sサービスは、GrW-Gから主催者のスケジュールを取得し、空き時間を表示する。」とあります。
したがって、Sサービス（k）とGrW-G（m）との間でスケジュール情報のやり取りがされている「エ」が正解です。

o：⑵、p：⑹

「適切な実装であれば、図9中の（o）において、stateパラメタを付与して送信し、図9中の（p）で送られてきたものと比較することで、攻撃を検知しているはずです。」
セキュリティ対策として挙げられた一つ目として、クロスサイトリクエストフォージェリ（CSRF）攻撃に関する内容です。
CSRF攻撃とは、WebサービスやSNSにログインしたユーザに対して、ログイン状態でしか実行できない行為（決済など）を不正に実行させる攻撃です。
「標的となる利用者が重要な秘密を扱う会議の主催者として日程を決定する場合を考えてみましょう。」とう説明を図9に照らし合わせて確認しましょう。

「攻撃者は、GrW-Gに攻撃者のアカウントを登録し、当該GrW-Gにアクセスするための認可コードを利用者に送付します。そのときに、図9の実装にCSRF脆弱性があり、かつ、利用者のWebブラウザが攻撃者によって生成された認可コードを受け付けてしまう実装となっている場合、利用者が気付かないうちに攻撃者のアカウントで会議日程が登録されてしまいます。」
この内容から分かることは、攻撃者の認可コードを利用者が気付かないうちに使ってしまうというところが脆弱性となっているということでしょう。
この認可コードを正規の利用者のものであることを確認する処理を追加すれば、対策になりそうです。
そこで「対策として、stateパラメタの実装が求められています。」とあるように、図9の流れの中にstateパラメタの実装を考えます。
認可コードを処理しているのは、⑸リダイレクトでIDaaS-GがGrW-G向けの認可コードを利用者に渡し、⑹認可コードで利用者がSサービスに送信している部分です。
最終的にSサービスで認可コードが正規のものかどうかを確認すればいいので、利用者とSサービスがやり取りしている、⑵リダイレクトにおいて、stateパラメタを付与して送信し、⑹認可コードで送られてきたものと比較することで攻撃を検知することができます。

q：PKCE（Proof Key for Code Exchange）

「この仕組みは、（q）として標準化されています。」
完全に知識問題ですので、ここで理解するくらいで臨みましょう。
ここでの攻撃は、「Sサービスのスマホアプリをインストールしたスマートフォンに、攻撃者が用意した不正なスマホアプリをインストールしてしまうと、GrW-Gにアクセスするための認可コードを、攻撃者のスマホアプリが横取りしてしまうという攻撃があります。」というものです。
この攻撃への対策として、「Sサービスのスマホアプリでランダムな検証コードとその値を基にしたチャレンジコードを作成して、そのチャレンジコードを認可要求に追加し、検証コードをトークン要求に追加します。二つのコードを検証することで、検証コードを知らない攻撃者からのトークン要求を排除できます。」ということで、ランダムの検証コードとそのチャレンジコード（←検証コードを基に作成）という攻撃者の知らない情報を付加することで、認可コードを横取りされても認可の検証に失敗することになります。
この仕組みのことをPKCE（Proof Key for Code Exchange）といいます。