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