OAuth2.0 Security Best Current Practiceを読んでみる（７）

こんにちは、富士榮です。

すこし空きましたがこちらも続けていきます。

引き続き攻撃パターンと緩和策です。前回は307リダイレクトまで行きましたので続き13個目/18個のTLSを終端するリバースプロキシから行きたいと思います。

攻撃パターンと緩和策

• TLSを終端するリバースプロキシ
• 一般的なWebサーバの構成だとリバースプロキシ（と言うよりもロードバランサーでやることが多いかと）でTLSの終端処理をした上で実際のWebサーバへリクエストをディスパッチすることが多いと思います
• その際にhttpヘッダーにIPアドレスや証明書とのバインディングの情報などさまざまな情報を付与することがありますが、不正にヘッダを改竄することが攻撃につながる可能性があります（典型的にはX-Forwarded-Forなど）
• と言うことでちゃんとhttpヘッダのサニタイズをしましょう（MUST）ということです
• また、リバースプロキシと実際のWebサーバの間のネットワークに攻撃者がアクセスできてしまった場合を仮定して内部ネットワークにおいてもアクセス制御をちゃんとしましょう
• リフレッシュトークンの保護
• リフレッシュトークンを使うとアクセストークンが発行できるので、攻撃者にとってはリフレッシュトークンは確かに魅力的な攻撃対象です
• RFC6749でも転送中や保存中の保護やクライアント認証の実施などの対策を示していますが、ここでは更に高度な保護の方法について考えます
• クライアントのリスク評価を行った上でリフレッシュトークンの発行の可否を判断する必要があります（MUST）。リフレッシュトークンを発行しない場合は認可コードフローなどでアクセストークンを発行するように構成することができます
• リフレッシュトークンを発行する際はユーザの同意に基づき、特定のスコープ・リソースサーバへ紐付けられる必要があります（MUST）
• コンフィデンシャルクライアントの場合はクライアント認証を必須としていますが、パブリッククライアントの場合はmTLS（RFC8705）やDPoP（RFC9449）を使ってリフレッシュトークンとクライアントのインスタンスを紐づける必要があります
• ローテーションを行って無効にされたリフレッシュトークンも認可サーバは保持しておき、万一不正なクライアントが古いリフレッシュトークンを使おうと試みた場合は古いリフレッシュトークンだけでなく、アクティブなリフレッシュトークンについても無効化するなど予防措置を講じることもできます
• リフレッシュトークンに紐づくスコープの情報をトークンに埋め込むことで認可サーバは取消対象となるリフレッシュトークンの判別をしやすくなる可能性もあります
• その場合はデジタル署名を施すなどトークン自体の改竄を防ぐメカニズムも導入する必要があります（MUST）
• また、パスワード変更やログアウトなどのイベントをトリガーにリフレッシュトークンを無効化することも検討しても良いと思います
• 通常リフレッシュトークンには有効期限をつけますが、一律で設定しても良いですし、リスクレベルに応じて変更するなどの工夫をしても良いと思います
• リソースオーナーになりすましたクライアント
• 認可サーバがclient_credentialsフローをサポートする場合、アクセストークンの発行対象がユーザなのかクライアントなのかを判別することが難しくなるケースがあります
• 具体的にはクライアント登録を行う際にクライアントIDを任意に決定できる場合、ユーザの識別子（sub）と同じ値をクライアントIDとして登録することで、リソースサーバが当該のアクセストークンがユーザに対して発行されたのかクライアントに対して発行されたのかを混同してしまい、望まぬクライアントがユーザのリソースにアクセスできてしまう可能性があります
• このことを避けるためにはユーザの識別子とクライアントIDの名前空間を分離して識別可能にしたり、他のプロパティを使ってトークンの発行対象がユーザなのかクライアントなのかを判別できるようにしないといけません

ということで今回はここまでです。

しかし読めば読むほど本当にそんな実装してる認可サーバあるの？？って思いますが、こういう形でちゃんと文章として出すことが大切なんだろうなぁ、、と思っています。