情報処理安全確保支援士の勉強中にstateパラメータやPKCEについて躓いてしまったので、ここら辺の知識を体系的にまとめようと思います。
目次
- stateパラメータとは
- PKCEとは
- nonceパラメータとは
1. stateパラメータとは
stateパラメータとは、OAuthのCSRF対策の機能です。
まずは、OAuthの通常の認可コードフローを以下に示します。
このフローでは、CSRF脆弱性を悪用して、攻撃者が用意した認可コードをある標的に仕込む「脅威1」が潜んでいます。
具体的には、ある利用者（標的）が上記の認可コードフローでAPI連携をしようとしています。
このとき、認可リクエストのリダイレクトを攻撃者がインターセプトします。
そして、標的が発行した認可コードを、攻撃者が用意した認可コードに置き換えて、リダイレクトを送信します。
すると、攻撃者が用意した認可コードで標的がトークンリクエストを行います。
その結果、攻撃者が認可したスコープでAPIを呼び出すことになります。
これによりどのような被害が起こるのかというと、例えば、ストレージサービスとAPI連携をして何かしらのファイルのアップロードを行うようなサービスの場合、攻撃者のストレージに標的がファイルをアップロードをしてしまうことになります。
つまり、標的がアップロードしたファイルなどを攻撃者が不正に閲覧できるリスクがあるということです。
このようなCSRF脆弱性への対策として、「state」というパラメータを用いた認可コードフローを以下に示します。!
具体的にどのような処理を行っているかというと、
まず、サービス要求の後にクライアントがstateというランダムな値を生成します。
更に、クライアントはリソースオーナーとのセッションに紐づけてstateの値を保存します。
次に、認可リクエストの際にstateも一緒に送信します。
最後に、認可サーバが認可コードを含むリダイレクトをする際に、stateも送信します。
そして、クライアントが生成したstateと、認可サーバからリダイレクトで送られたstateが等しいことを検証します。
これにより、攻撃者が仕込んだ認可コードがクライアントに返ってきたとしても、stateの値が一致しないため、CSRF脆弱性を悪用した攻撃ができなくなります。
このように、OAuthのCSRF脆弱性への対策というのが、stateパラメータの役割です。
2. PKCEとは
PKCEとは、攻撃者に認可コードが窃取された際の対策の機能です。
まずは、OAuthの通常の認可コードフローを改めて以下に示します。
このフローでは、標的から窃取した認可コードを不正に利用して攻撃者がトークンリクエストを行うという「脅威2 」が潜んでいます。
具体的には、ある利用者（標的）が認可コードを受け取った際に、攻撃者のクライアントにリダイレクトさせるなどの方法で、認可コードを窃取します。
攻撃者がその認可コードを利用してトークンリクエストをすると、標的が認可したスコープで攻撃者がAPIを呼び出すことができます。
これにより、標的のAPIから、個人情報や機密情報を攻撃者が入手することができます。
このような脆弱性の対策として、「PKCE（Proof Key for Code Exchange）」という機能を用いた認可コードフローを以下に示します。
具体的にどのような処理を行っているかというと、
はじめに、サービス要求の後にクライアントがcode_verifierというランダムな値を生成します。
次に、code_challenge_methodという値に、あらかじめ定めたハッシュ関数の名前を格納します。
そして、code_challenge_methodのハッシュ関数でcode_verifierをハッシュ化した値をcode_challengeというパラメータに代入します。
続いて、クライアントは認可サーバに認可リクエストを送信する際に、code_challengeとcode_challenge_methodを送信します。
更に、認可サーバが認可コードを発行する際に、認可コードとcode_challengeを紐づけます。
最後に、クライアントがトークンリクエストを送信する際に、code_challengeをハッシュ化する前の値、すなわちcode_challengeの「元ネタ」であるcode_verifierを送信します。
このcode_verifierを受け取った認可サーバは、受け取ったcode_verifierをcode_challenge_methodでハッシュ化した値と、認可コードに紐づいているcode_challengeが一致していることを検証します。
code_veriferの値を知っているのは、最初にcode_challengeを計算したクライアントだけです。
したがって、サービス要求をリソースオーナーから受けとったクライアントと、トークンリクエスト送信したクライアントが同一であることを、認可サーバが検証できるということです。
このように、攻撃者が不正に窃取した認可コードを使ったとしても、不正なクライアントからのリクエストであることを確認できる機能が、「PKCE」です。
3. nonceパラメータとは
nonceパラメータとは、OIDC(OpenID Connect）のリプレイ攻撃の対策の機能です。
まずは、OIDCの通常の認可コードフローを以下に示します。
OIDCには、リプレイ攻撃の脆弱性があります。
リプレイ攻撃を悪用したフローを以下に示します。
このように、あるユーザー（標的）のIDトークンを窃取します。
そして、RPと攻撃者のログインセッション確立の際に窃取したIDトークンを送信することで、不正ログインします。
このようなリプレイ攻撃への対策として、「nonce」というパラメータを用いた認可コードフローを以下に示します。
具体的にどのような処理を行っているかというと、
まず、サービス要求の後にrpがnonceというセッションごとに変わるランダムな値を生成します。
更に、RPはユーザーとのセッションに紐づけてnonceの値を保存します。
次に、認可リクエストの際にnonceも一緒に送信します。
最後に、OPがトークンレスポンスを送信する際に、nonceを含むIDトークンを送信します。
そして、RPがIDトークンの検証と同時に、RPが生成したnonceと、OPからトークンレスポンスで送られたnonceが等しいことを検証します。
これにより、攻撃者がIDトークンを再送しても、最早下nonceの値とセッションに紐づいているnonceの値が一致しないため、攻撃が失敗します。
このように、OIDChのリプレイ攻撃への対策というのが、nonceパラメータの役割です。
参考文献
- 中村雄一、和田広之、田村広平、田畑義之、青柳隆、渡辺竜二、奥浦航 、相田洋志、『認可と認証 KeyCloak入門』、リックテレコム、2023.
- 情報処理安全確保支援士試験委員会、『令和4年春 情報処理安全確保支援士 午後II』、IPA、2022.
- 『OpenID Connectで使われるnonceパラメーターについて』、https://tech-lab.sios.jp/archives/13087