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

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

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

引き続き攻撃パターンと緩和策です。前回はアクセストークンインジェクションまで行きましたので続き７個目/18個のクロスサイトリクエストの偽造から行きたいと思います。

攻撃パターンと緩和策

• CSRF（クロスサイトリクエストフォージェリ）
• 攻撃者としては正規のクライアントが攻撃者の制御下にあるリソースにアクセスさせたいので、redirect_uriに不正にリクエストをインジェクションしようとします
• 緩和策
• 基本はstate/nonce/PKCEを正しくセッションに紐づけた形で利用することにつきます
• しかしながら例えば、クライアントがPKCEを使う場合は当然のことながら認可サーバがPKCEをサポートしていることを確認しないといけません
• 同じくstateを使う場合はstateの改ざんやスワッピングに対する耐性を持つような実装にしないと意味がありません
• 認可サーバは自身がPKCEをサポートしていることをクライアントが検知するための仕組みを提供する必要があります（MUST）
• 基本はメタデータを使うことになりますが、別のメカニズムで検知方法を提供しても問題はありません（MAY）
• stateやnonce（response_typeがid_tokenの場合）は認可レスポンスやトークンレスポンスを攻撃者が読み取れる環境においてはリプレイアタックなどに使われる可能性がありますが、その点はPKCEを使うことで対応ができます
• PKCEダウングレード攻撃
• PKCEをサポートしているものの、全てのフローがPKCE対応しているわけではない認可サーバはPKCEダウングレード攻撃を受ける可能性があります
• 例えばこんな実装です
• 認可リクエストにcode_challengeがあったらPKCEを有効にする、という判定ロジックが認可サーバに組み込まれている（逆にいうとcode_challengeが指定されない場合はPKCE対応しない）
• 上記の前提があるにも関わらずCSRF対策としてstateを使わない（PKCEを使うことを前提としてしまっている）
• まぁ、当然ですがこうなるとCSRF対策をしていないのと同じです
• 攻撃者はクライアントと認可サーバの間に入り、code_challengeを丸ごと削除してしまいセッションを乗っ取るわけです
• 緩和策
• この攻撃を受けている際の特徴は、認可リクエストにcode_challengeがない（削除されている）にも関わらずトークンエンドポイントへのアクセス時はcode_verifierが指定されることにあります
• code_challengeが削除されていることを検知するために認可サーバは認可コードとcode_challengeを紐づけて管理しないといけません。このことによりトークンエンドポイントに認可コードがPOSTされたタイミングでcode_challengeとの紐付けが有効かどうかを検証することが可能となります
• 加えて認可サーバは、認可エンドポイントへのリクエストにcode_challengeが指定されなかったにも関わらずトークンエンドポイントへcode_verifierが指定された場合はリクエストを拒否しないといけません（MUST）
• リソースサーバでのアクセストークンの漏洩
• リソースサーバが偽造されている場合（アクセストークンフィッシング）
• 基本はredirect_uri（リソースサーバ）とクライアントの紐付きがゆるいケースにおいて発生します
• リソースサーバが侵害されている場合
• ログの盗難やシステムの完全な掌握までさまざまなパターンがありますが、リソースサーバが侵害されるとアクセストークンが盗難されてしまいます。当たり前ですが
• 緩和策
• 基本的にSender Contraintトークンを使うという対策に尽きます
• 同じくAudience Restrictionも大切な対策です
• またこれも原則ですがリソースサーバでアクセストークンは他の機密情報と同じようにPlain textで保存したり他のシステムへ転送するなどは避け厳重に扱う必要があります

今回も3つ紹介しました。

まだあと半分くらいありますね。。