「[[マイクロソフト系技術情報 Wiki>http://techinfoofmicrosofttech.osscons.jp/]]」は、「[[Open棟梁Project>https://github.com/OpenTouryoProject/]]」,「[[OSSコンソーシアム .NET開発基盤部会>https://www.osscons.jp/dotNetDevelopmentInfrastructure/]]」によって運営されています。 -[[戻る>OAuth 2.0 セキュリティ関連トピック]] * 目次 [#rbd091b1] #contents *概要 [#gf898076] [[OAuth]]2, [[OIDC>OpenID Connect]]のを実装するクライアントおよびサーバの~ セキュリティ要件およびその他の推奨事項について説明 *詳細 [#a5e58ed4] **クレデンシャル漏洩 [#hf75bf1f] ***Redirect URI 検証 [#b285fb18] 完全一致でない場合、漏れる。 -オープンリダイレクタ~ 部分一致ではQueryStringのReturnURL等を悪用される事がある。 -攻撃者のPublicクライアントへクレデンシャル送る。 --Authorization Codeであればcodeを盗むことができる。 --Implicitであれば直接Tokenを盗むことができる。 -推奨事項 --Redirect URIの完全一致 --追加の推奨事項 ---コールバックがあるドメインは、オープンリダイレクタを実装しない。 ---中間URLを介して意図しないフラグメントをドロップする。 ---[[JAR(Request Object)>JWT Secured Authorization Request (JAR)]]を使用する。 ***HTTPリファラからのcode漏洩 [#j9eb69ee] -response_mode=queryの場合、HTTPリファラからのcode漏洩 -response_mode=fragmentが既定のモノはqueryに変更できないので漏れない。 -対策 --HTMLリンク属性「rel="noreferrer"」の使用 --"referrer"メタリンク属性の使用 --中間ページにリダイレクト(履歴をサニタイズ) ***ブラウザ履歴からのcode漏洩 [#lc2361aa] -HTTPリファラと「≒」だが、より対策が難しい。 -対策 --1回限りの使用 --期間の制限 --機密Clientのみ ***ブラウザ履歴からのtoken漏洩 [#h648f755] -response_mode=fragmentが既定のモノは~ queryに変更できないので漏れない。 -...コレを破ると、こんな事態に陥る。 ***Clientが悪意のあるResourceServerにTokenを渡す。 [#pb47fb61] -記名式トークン(PoP、Token Binding) -AS(Authorization Server)のメタデータ ***ミックスアップ攻撃によるcodeやtokenの漏洩 [#hca90119] -ミックスアップ攻撃とは、攻撃者のプロキシが、~ 攻撃者のIdPを使用してログインするように書き換える攻撃らしい。 -これにより以下の様な動作になる。 --Clientは攻撃者のIdPを使用するものと考える。 --しかし、Resource Ownerは正規のIdPに対してログオンする。 --リダイレクト後、Clientは正規のIdPが発行したcodeやtokenを攻撃者のIdPに送付してしまう。 -対策~ そもそも、攻撃者のプロシキに書き換えられないようにHTTP使えという話。 -緩和策 --issを検証する。 --IdP毎にredirect_uriを分ける。 -参考 --OAuth IdP Mix-Up Attack とは? - OAuth.jp~ https://oauth.jp/blog/2016/01/12/oauth-idp-mix-up-attack/ **クレデンシャル注入 [#w10ab452] ***codeの注入 [#sf091a9c] -codeの注入の場合、攻撃者のcodeか他人のcodeかで攻撃の内容が異なる。 --他人に自分のアカウントで処理させる。 --自分が他人のアカウントで処理できるようにする。 -対策 --codeとredirect_uriのバインド --state, nonce, verifierの適切な使用 --Token BindingによるAuthorization ServerとClientのバインド ***tokenの注入 [#h73fdd75] -攻撃者のcodeか他人のcodeかで攻撃の内容が異なる。 --他人に自分のアカウントで処理させる。 --自分が他人のアカウントで処理できるようにする。 -対策~ codeと違って、code → token変換処理でのガードは不可 --Token Bindingによるtoken自体への記名 --Hybrid Flow + nonce(OIDC) --暗号バインディング ***XSRF [#va62ba33] Private-Use URI Scheme上書き攻撃的な。 **その他の攻撃 [#we5e3de7] ...。 *参考 [#i5c7c5da] -draft-ietf-oauth-security-topics - OAuth 2.0 Security Best Current Practice~ https://tools.ietf.org/html/draft-lodderstedt-oauth-security-topics **[[AppAuth]] [#ce350f35] **[[OAuth 2.0 for Browser-Based Apps]] [#h89bbc29] ---- Tags: [[:IT国際標準]], [[:認証基盤]], [[:クレームベース認証]], [[:OAuth]]