マイクロソフト系技術情報 Wiki」は、「Open棟梁Project」,「OSSコンソーシアム .NET開発基盤部会」によって運営されています。

目次

概要

OAuth 2.0 Threat Model and Security Considerationsの
各種役割に適用されるセキュリティ考慮事項。

Authorization Server

code

対象

codeを使用したアクセストークン・リクエスト

脅威

codeの不正使用(オンライン推測などによる)

対策

  • 不正使用が検出された場合、トークンを自動失効する。
  • jtiで、トークンを識別してOAuth 2.0 Token Revocationで失効。

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、
    パブリック・クライアント
    • client_secret漏洩
  • 悪意のある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の脆弱性に対する攻撃

対策

  • 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
  • 悪意のあるClient
  • オンライン推測
  • オープンリダイレクタ

対策

  • インフォームド・デシジョン
    認証・認可画面の表示
    • Clientに何のscopeをどの期間許可するか?
    • Clientプロパティ検証
      • Webサイト名
      • アプリケーション名
  • client_id/(client_secret/)redirect_uriへのバインディング
    • code

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


トップ   編集 凍結 差分 バックアップ 添付 複製 名前変更 リロード   新規 一覧 単語検索 最終更新   ヘルプ   最終更新のRSS
Last-modified: 2018-10-26 (金) 21:35:03 (53d)