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

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

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

引き続き攻撃パターンと緩和策です。前回はリソースサーバでのアクセストークンの漏洩まで行きましたので続き10個目/18個の盗まれたアクセストークンの悪用から行きたいと思います。

攻撃パターンと緩和策

• 盗まれたアクセストークンの悪用
• これはすでに手遅れ？そもそも攻撃なのか？という感じもしますが、万一アクセストークンが盗まれてしまったとしても被害を最小限に食い止める努力は必要です
• 基本は送信者制限（Sender Constraint Token）と対象者制限（Audience Restriction）をすべきであるっていう話です
• 送信者制限（Sender Constraint Token）はその名前の通り、特定の送信者から送信されたアクセストークンのみをリソースサーバが受け付けるようにする、ということです。これはいわゆるべアラ（Bearer）トークンとは対称となる概念ですね
• 参考）Bearer Tokenとは？
• 方式としてはmTLS（RFC8705）とDPoP（RFC9449）があります
• どちらの方式にしても鍵を使ったトークンとのバインディングをするので当たり前ですが秘密鍵の保護は大切です
• 対象者制限（Audience Restriction）もその名前の通り、特定のリソースサーバでのみアクセストークンが利用できるように制限を行います
• こちらもアクセストークンが万一漏洩したとしても影響範囲を最小化するための対策です
• 対象となるリソースサーバを表現するためにはURLなどを利用し、アクセストークン要求時のURLと実際のリソースサーバのURLの値が異なることを検知することによりフィッシング等で作成されたアクセストークンが利用されることを防ぎます
• リソースを指定するにはRFC8707のresourceパラメータを使ったり、scopeにリソースに関する情報を埋め込むことも可能です
• そしてこちらもmTLS（RFC8705）による対策も有効です
• なお、対象者制限付きのアクセストークンを使うと、リソースサーバ単位で特化したアクセストークンを生成することができるので、機能的にもプライバシーの面でもメリットがあります。
• なお、追加の議論として認可サーバがアクセストークンをどこであれば安全に利用できるのか？という情報を提供することもできますが注意しなければならないことが指摘されています
• 一つはメタデータで公開する方法ですが、既知のリソースサーバの情報を公開してしまうことになりますし、メタデータの標準ではありません
• もう一つはトークンレスポンスの中でリソースサーバのURIを合わせて送信するパターンがありますが、正規のリソースサーバへのレスポンスならそれでいいですが、偽造されたリソースサーバへ正規のリソースサーバのURIを送っても何の検証も期待できない面で微妙です
• オープンリダイレクト
• クライアント、認可サーバの両方の構成要素がオープンリダイレクトを引き起こしてしまう可能性があるので注意が必要です
• クライアントがアクセス元となっている画面やページを記憶しておいてトークン取得後にコールバックURIから元のページへ戻す、という実装は一般的ですが、このリダイレクト機能の実装を行う際にオープンリダイレクトを許可してしまう実装にならないように注意する必要があります
• 認可サーバは仕組み上リダイレクトを行うので、こちらも実装する上でオープンリダイレクトにならないように注意が必要です
• 基本的にはRFC6749で正しいredirect_uriのみを受け付けてオープンリダイレクトを行わないことがMUSTとして規定されていますが、正しいredirect_uriを使った攻撃パターンも存在するので十分に注意が必要です
• 例えば、動的クライアント登録を行う際の攻撃パターンとしてこのようなものが紹介されています
• 無効なスコープを指定するなどしてフィッシングサイト等にリダイレクトさせるように誘導（エラーの際にどこに戻すのか？が結構重要なポイントになりますね。変なリクエストが来たからと言って指定されたredirect_uriに戻しちゃうとこう言うことが起きるのかと）
• 有効な認可リクエストを送信、この際にredirect_uriは攻撃者の制御の元にあるURLを利用する。ユーザ認証の後、属性提供同意画面でユーザが拒否をしたとしてもredirect_uri（フィッシングサイト）へ戻される
• この状態でprompt=noneでサイレントログインをするとフィッシングサイトへリダイレクトされてしまう
• 難しい問題だと思いますが、ユーザをリダイレクトする前にちゃんとユーザを認証する、redirect_uriをちゃんと信頼できるかどうか検証する、など考えないといけません
• 307 リダイレクト
• 通常のリダイレクトはGETリクエストのみについてリダイレクトする302を使うと思いますが、代わりに307を使ってしまうとPOSTリクエストについてもリダイレクトしてしまいます。
• 通常認可サーバに対するリクエストを受けるとユーザは認証行為を行うわけですが、その際クレデンシャル情報をPOSTすることになることが多いと思います。ここで307を使ってしまうと意図せずにクレデンシャル情報が別のサーバへ転送されてしまうので307を使うべきではありません

まだまだ続きます（長い）。

とは言え、実装していかないとここの対策についてイメージがわかないと思うので、一通り眺めたら実装にしつつ確認していきたいと思います。