「マイクロソフト系技術情報 Wiki」は、「Open棟梁Project」,「OSSコンソーシアム .NET開発基盤部会」によって運営されています。
目次 †
概要 †
OAuth 2.0 Threat Model and Security Considerationsの
各種役割に適用されるセキュリティ考慮事項。
Authorization Server †
code †
対象 †
codeを使用したアクセストークン・リクエスト
脅威 †
codeの不正使用（オンライン推測などによる）
対策 †
refresh_token †
対象 †
refresh_tokenを使用したアクセストークン・リクエスト
脅威 †
refresh_tokenの不正使用
- refresh_tokenの漏洩/盗難
- Deviceの盗難
- 脆弱な、侵害されたClient
- クリック・ジャッキング攻撃
- Resource Ownerの偽装
対策 †
- 制限付き発行
- ポリシー
- クライアントのタイプ
パブリック or コンフェデンシャル
- サービスのタイプ
- Resource Owner設定
- ポリシー＋選好
- ローテーション処理の実装
- リフレッシュ要求ごとにrefresh_token値を変更する。
- これにより、以下の試みを自動的に検出して防止できる。
- refresh_tokenを並行して使用
- 古いrefresh_tokenを使用
- バインド
- Client識別（ClientID）
- Device識別（DeviceID）
- X-FRAME-OPTIONSヘッダ
IFRAME防止によるクリックジャック攻撃の防止
Client †
Client認証 †
対象 †
- Clientの認証
- Client ( ---> Authorization Server・Resource Serverの各Endpoint )
脅威 †
- 悪意のあるClient、
パブリック・クライアント偽装
- XSS攻撃
- codeフィッシング攻撃
- オープンリダイレクタ
対策 †
クライアント認証により、Authorization Server・Resource ServerがClientを識別する。
- 脆弱なClientにclient_secretを発行しない。
- パブリック・クライアントの自動認可を許可すべきでない。
- client_id/(client_secret/)redirect_uriを要求。
- 要件
- インストール固有のclient_secretを使用する。
（DeviceにインストールするClientの場合、インストール毎に変える）
- redirect_uriのフルパス登録・検証
- 取り消し可能なclient_id/client_secret
Clientセキュリティ †
対象 †
- Clientのセキュリティ
- Client ( ---> Authorization Serverの各Endpoint )
脅威 †
対策 †
- Clientパッケージ内にclient_secretを保存しない（デプロイごとに変更）。
- refresh_tokenストレージを信頼できるバックエンドにスワップ
- サーバ：セキュリティ対策を実施
- システムのセキュリティ対策を実施
- 標準のSQLインジェクション対策を実施
- モバイル：
- Deviceロック（パスワード、PIN、指紋認証、顔認証）
- 安全なローカル・ストレージに保存
- パーソナル分離ストレージ
- アプリケーション固有ストレージ
- ClientはUserAgent?セッションにstateパラメタを追加
ClientとResource Owner間のやり取り †
対象 †
ユーザ操作
脅威 †
- 一般ユーザ（Resource Owner）にとって、認可画面の意味が不明
- 認可画面で「はい」と回答した結果を理解する専門知識を持たない。
- 要求の文言に微妙な違いを見ることができない。
- Device上でのソフトウェア脆弱性の脅威は強く、緩和も困難。
- WWWブラウザの脆弱性
- 人気のあるClientの脆弱性
- インストールしたClientソフトウェアの使用を制限
- 一部の限定的な環境では実用的。
- しかし、一般的な環境では実用的ではなく、
事実回復後のメカニズムが整備されているべき（？
- 自動再認証、認可画面非表示により、認証認可プロセスを隠す。
- 攻撃者は、侵害されたまたは悪意のある役割上で資格情報を盗む可能性がある。
対策 †
- 自動再認証、認可画面非表示の問題に解決策はなく、
UXとセキュリティ間のトレード・オフを考慮して決定する必要がある。
- DeviceにインストールしたClientプロパティのアサート
- 検証できないプロパティを明示的に指摘
- 特定のClientへのアクセス許可に関連するリスクをエンド・ユーザーに示す。
Resource Server †
Authorization: Bearer JWTで、大方、解決する。
Authorization Headers †
対象 †
Authenticated Requests
Authorization: Bearer XXXXX
脅威 †
未認証アクセス
対策 †
Authorizationヘッダを利用し認証アクセス
- HTTPプロキシとサーバによって認識され、特別に扱われる。
- これにより、漏洩または意図しない永続化の可能性が低減される。
認証されたリクエスト †
対象 †
トークン乱用
脅威 †
トークン乱用の防止。
対策 †
以下のような方法で、Client認証を行う。
- client_idにaccess_tokenをバインドする。
- Resource Serverはclient_idをクライアント証明書で検証する。
オプションとして、リクエストを署名するケースもある。
署名されたリクエスト †
対象 †
ユーザーデータの変更/破棄
脅威 †
キャプチャ＆リプレイ
対策 †
リクエストは
- 一意に識別可能にする。
- 2回処理されないようにする。
Resource Owner †
End-User許可 †
対象 †
- Resource OwnerによるClientの許可
- Client ( ---> Authorization Serverの各Endpoint )
脅威 †
対策 †
- インフォームド・デシジョン
認証・認可画面の表示
- Clientに何のscopeをどの期間許可するか？
- Clientプロパティ検証
- client_id/(client_secret/)redirect_uriへのバインディング
Tags: :IT国際標準, :認証基盤, :クレームベース認証, :OAuth
![[PukiWiki]](image/pukiwiki.png "[PukiWiki]")
