[[FrontPage]]
後で書く。
「[[マイクロソフト系技術情報 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

----
Tags: [[:IT国際標準]], [[:認証基盤]], [[:クレームベース認証]], [[:OAuth]]


トップ   新規 一覧 単語検索 最終更新   ヘルプ   最終更新のRSS