「マイクロソフト系技術情報 Wiki」は、「Open棟梁Project」,「OSSコンソーシアム .NET開発基盤部会」によって運営されています。
目次 †
概要 †
OAuth 2.0 Threat Model and Security ConsiderationsのRoleに着目した脅威モデル。
Client †
Clientに対する攻撃
client_secretの入手 †
概要 †
client_secretの漏洩により、Authorization Serverに対して、
クライアント認証をバイパスしたアクセストークン・リクエストが可能になる。
影響 †
- アクセストークン・リクエストによるaccess_token, refresh_tokenの開示
- Client Credentialsグラント種別によるアクセストークン・リクエスト。
- リプレイ攻撃によるアクセストークン・リクエスト。
- codeによるaccess_tokenの取得
- refresh_tokenによるaccess_token取得
- access_tokenの漏洩により、
Resource Ownerの、そのscopeのリソースにアクセス可能になる。
攻撃 †
リバース・エンジニアリングによって、
- （難読化したとしても、）ソースコード（リポジトリ）またはバイナリから取得
- インストール（デプロイ済みClient）から取得
- web site (web server)
- device (native application)
対策 †
- インストール（デプロイ済みClient）から
デプロイメント固有のclient_secretを取得（ただし、以下を考慮）
- Clientが「Webサーバ」の場合
システムのセキュリティ対策を実施する。
- Clientが「ネイティブアプリ」の場合
安全なローカル・ストレージに保存
- Client側の要件
- パブリック・クライアント、脆弱 or 悪意のあるClientに公開しない。
- Clientの自動認可を許可しない（ユーザの同意を要求する）。
refresh_tokenの入手 †
概要 †
refresh_tokenの漏洩により、Authorization Serverに対して、
アクセストークン・リクエストが可能になる（クライアント認証にリプレイ攻撃）。
影響 †
- アクセストークン・リクエストによるaccess_token, refresh_tokenの開示
攻撃 †
- Web applicationから
- device (native application)
- ファイルシステムから
- deviceを盗難してから
- deviceを複製してから
対策 †
- device (native application)の場合、
- 秘密を安全な記憶域に保管する。
- デバイスロックを使用する。
- 共通
- refresh_tokenのscope制限
- refresh_tokenのローテーション
- Webの場合
- 強力なクライアント認証を使用
- 標準的なWebサーバ保護対策
- device (native application)の場合、
- ユーザやデバイスを特定できるようにして、
・client_idにトークンをバインド
・トークンにデバイス識別子を同梱
- 以下の取り消し処理の実装する。
・refresh_token
・client_secret
access_tokenの入手 †
概要 †
単純な、access_tokenの漏洩は、そのまま、リソースにアクセスが可能になる。
影響 †
- 単一のResource Ownerへの影響
- そのスコープのリソースにアクセスが可能になる。
攻撃 †
refresh_tokenの入手と同じ攻撃。
対策 †
- AuthZ側の要件
- access_tokenのscope制限
- access_tokenの有効期間を短くする。
WebView?などの組込ブラウザによるフィッシング †
概要 †
OAuthではClientに認証情報を渡さないが、
WebView?などの組込ブラウザの場合、
悪意のあるClientの場合、Clientが認証情報を取得し得る。
影響 †
ユーザ・アカウントを含めたあらゆる情報が取得され、それが悪用される可能性がある。
攻撃 †
ブラウザによる、認証情報を中心にした、あらゆる情報のフィッシング
対策 †
- ResourceOwner?側の要件
- Client（アプリケーション）の検証
- 信頼できるシステム・コンポーネント（システム・ブラウザなど）に委任
- Client側の要件
- 信頼できるシステム・コンポーネント（システム・ブラウザなど）に委任
- AuthZ側の要件
- Clientタイプの検証（例えば、GoogleはWebView?をブロックしている）
オープン・リダイレクタ †
redirect_uriの登録は、Client側にも関係があるが、
基本的には、Authorization ServerのAuthorization Endpoint側を参照。
（フルパス要求 ＝ 完全一致のため）
Authorization Endpoint (Authorization Server) †
Authorization ServerのAuthorization Endpointに対する攻撃
偽造Authorization Serverによるフィッシング †
概要 †
単純、且つ古典的な、偽造Authorization Serverによるフィッシング。
影響 †
ユーザ・アカウントを含めたあらゆる情報が取得され、それが悪用される可能性がある。
攻撃 †
ブラウザによる、認証情報を中心にした、あらゆる情報のフィッシング
- DNSまたはアドレス解決プロトコル（ARP）のなりすまし
- 偽造Clientのスターターで、誤った、偽造Authorization Serverに飛ぶ。
- 偽造Authorization Serverによりユーザ・アカウントがフィッシングされる。
対策 †
- SSL/TLS（サーバ証明）の利用
- ユーザの教育（偽造Authorization Serverの識別）
悪意のあるClientに大きなアクセス権を与えてしまう †
概要 †
認可画面の意味を理解していない場合に発生し得る。
影響 †
悪意のあるClientが、不要に大きなscopeを持ったトークンを取得できる。
攻撃 †
悪意のあるClientが、
- 動的に登録される。
- 不用意に大きなscopeの設定でスターターを起動。
対策 †
- Resource Owner側の要件
Resource Ownerは、認可画面を理解する。
- Resource Server側の要件
- scopeが広くても、Resource Serverがaudをチェックしていれば影響は絞られる。
- Resource ServerがClientに限定されない共用のリソースを開示するケースは問題。
- client_idに対して
- 認可画面を表示する（promptパラメタによらず）。
- 許可するscopeをチェックする。
- ClientのTypeよって許可するscopeをチェックする。
- code : 認可画面を表示。
- token : （通常、）認可画面が表示しない。
悪意のあるClientに既存ログイン・セッションで権限を与えてしまう †
概要 †
既存ログイン・セッション＋認可画面＝非表示の場合の問題。
影響 †
- ログイン・セッションが生きている場合、ログイン画面が表示されない。
- また、認可画面が非表示の場合、なにも表示されずに権限を与えてしまう。
攻撃 †
悪意のあるClientが、
- 動的に登録される。
- Clientが認可画面＝非表示の設定でスターターを起動。
対策 †
- Resource Server側の要件
- 漏れても、Resource Serverがaudをチェックしていれば影響は絞られる。
- Resource ServerがClientに限定されない共用のリソースを開示するケースは問題。
- AuthZ側の要件
- 自動再認証の抑止
- 認可画面＝非表示の抑止
- 上記の場合のscopeを制限する。
オープン・リダイレクタ †
概要 †
client_idさえ知っていれば、codeやaccess_tokenを盗める。
影響 †
codeやaccess_tokenが漏洩する。
- code : Authorization Codeグラント種別
攻撃 †
client_idさえ知っていれば、redirect_uriのインジェクションで、
攻撃者のサイトにcodeや、access_tokenを返却させることが出来る。
対策 †
- AuthZ側の要件
- redirect_uriのフルパス登録
- redirect_uriのフルパス検証
Token Endpoint (Authorization Server) †
Authorization ServerのToken Endpointに対する攻撃
access_tokenの盗聴 †
影響 †
影響は、コチラと同じ。
攻撃 †
盗聴
対策 †
- SSL/TLSの利用できない場合。
- access_tokenのscope制限
- access_tokenの有効期間を短くする。
client_secretのオンライン推測 †
影響 †
影響は、コチラと同じ。
攻撃 †
有効な client_id / client_secretのオンライン推測
対策 †
- client_secretに高いエントロピーを使用
- 強力なクライアント認証
- （クライアント認証の）アカウント・ロック
client_id, client_secretの盗聴 †
影響 †
影響は、コチラと同じ。
攻撃 †
盗聴
対策 †
- SSL/TLSを利用する。
- 平文認証を使用しない代替認証を使用する。
DBからaccess_tokenを盗難 †
影響 †
すべてのaccess_tokenが開示される。
（１人のResource Ownerのaccess_token漏洩より影響が大きい）
攻撃 †
- データベースへのアクセス権を取得
- SQLインジェクション攻撃
対策 †
- access_tokenハッシュのみを格納
（JWTの場合、DBに保存しないので対策になる）
DBからclient_secretを盗難 †
影響 †
すべてのclient_id / client_secretが開示される。
１つのClientのclient_id / client_secret漏洩より影響が大きい）
攻撃 †
- データベースへのアクセス権を取得
- SQLインジェクション攻撃
対策 †
- システムのセキュリティ対策を実施
- 標準のSQLインジェクション対策を実施
Tags: :IT国際標準, :認証基盤, :クレームベース認証, :OAuth
![[PukiWiki]](image/pukiwiki.png "[PukiWiki]")
