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を使うべきではありません

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

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

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つ紹介しました。

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

Azure Identity Protection for B2CがPublic Preview

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

ずっと出ると言われていて待っていたAzure Identity Protection（リスク判定と条件付きアクセス）のAzure AD B2C対応版がようやくPublic Previewになりました。

公式Blogでのアナウンス

　Azure Active Directory External Identities goes premium with advanced security for B2C

　https://techcommunity.microsoft.com/t5/azure-active-directory-identity/azure-active-directory-external-identities-goes-premium-with/ba-p/1604572

ポイントをまとめるとこんな感じです。

• Identity Protection
• 基本は普通のAzure AD版のIdentity Protectionのサブセット
• 以下の制限あり
• B2Cテナントでのセキュリティ・センターは使えない
• ROPCフローでは使えない
• ローカルアカウントでしか使えない
• 条件付きアクセス
• 基本は普通のAzure AD版の条件付きアクセスのサブセット
• 以下の制限あり
• デバイス状態をベースとして条件判定は使えない（設定はできちゃいますが）
• ビルトインのユーザ・フローでもカスタム・ポリシーでも使える
• ライセンス
• Premium P2 Tierが必要

一番気になるP2ライセンスの価格表ですが、月間アクティブユーザー課金で通常の利用料＋1.8円程度かかるみたいですね。（契約形態などにも依存するはずなので正確にはちゃんと調べてくださいね）

https://azure.microsoft.com/en-us/pricing/details/active-directory/external-identities/

徐々に全テナントにロールアウトされるみたいですが、私のテナントではすでに使えているのでFirst Lookをとりあえず。

何はともあれPricing TierをPremium P2へ。

ビルトインフローは面倒なのでカスタム・ポリシーで。

基本的な考え方としては、①リスク評価をして、②結果によっては多要素認証などによりユーザに対応をさせて、③結果OKであればリスクを緩和する、というプロセスでUserJourneyを汲みます。

全部は紹介しませんが、とりあえずこんな感じですね。

ConditionalAccessProtocolProviderを使ったTechnicalProfileを作ってOperationTypeでリスク評価なのか緩和なのかを切り替える、という感じです。

リスク評価の結果のアクションをどうするか、については通常の条件付きアクセスと同じように設定します。

とりあえず評価だけですが、ポリシーを実行するとカスタム属性に評価結果が出てきます。

ざっとですが、こんな感じです。

サードパーティのソリューションとの連携のエコシステムもできつつある中、純正機能もどんどんリリースされるので、全体として成長していくようにキャッチアップを続けていかないといけませんね。