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

目次

概要

OAuth 2.0 Threat Model and Security ConsiderationsのRoleに着目した脅威モデル。

Client

Clientに対する攻撃

client_secretの入手

概要

client_secretの漏洩により、Authorization Serverに対して、
クライアント認証をバイパスしたアクセストークン・リクエストが可能になる。

影響

  • Client全体への影響
  • アクセストークン・リクエストによる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の自動認可を許可しない(ユーザの同意を要求する)。
  • AuthZ側の要件
    • client_secret取り消し処理の実装。

refresh_tokenの入手

概要

refresh_tokenの漏洩により、Authorization Serverに対して、
アクセストークン・リクエストが可能になる(クライアント認証にリプレイ攻撃)

影響

  • 単一のResource Ownerへの影響
  • アクセストークン・リクエストによるaccess_token, refresh_tokenの開示
  • 入手したrefresh_tokenを用いる。

攻撃

  • Web applicationから
  • device (native application)
    • ファイルシステムから
    • deviceを盗難してから
    • deviceを複製してから

対策

  • Client側の要件
    • 上記から取得されないようにする。
  • device (native application)の場合、
    • 秘密を安全な記憶域に保管する。
    • デバイスロックを使用する。
  • AuthZ側の要件
  • 共通
    • 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に限定されない共用のリソースを開示するケースは問題。
  • AuthZ側の要件
  • 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が漏洩する。

攻撃

client_idさえ知っていれば、redirect_uriのインジェクションで、
攻撃者のサイトにcodeや、access_tokenを返却させることが出来る。

対策

  • AuthZ側の要件
    • redirect_uriのフルパス登録
    • redirect_uriのフルパス検証

Token Endpoint (Authorization Server)

Authorization ServerのToken Endpointに対する攻撃

access_tokenの盗聴

影響

影響は、コチラと同じ。

攻撃

盗聴

対策

  • SSL/TLSの利用
  • SSL/TLSの利用できない場合。
    • access_tokenのscope制限
    • access_tokenの有効期間を短くする。

DBからaccess_tokenを盗難

影響

すべてのaccess_tokenが開示される。
1人のResource Ownerのaccess_token漏洩より影響が大きい)

攻撃

  • データベースへのアクセス権を取得
  • SQLインジェクション攻撃

対策

  • システムのセキュリティ対策を実施
  • 標準のSQLインジェクション対策を実施
  • access_tokenハッシュのみを格納
    JWTの場合、DBに保存しないので対策になる)

DBからclient_secretを盗難

影響

すべてのclient_id / client_secretが開示される。
1つのClientのclient_id / client_secret漏洩より影響が大きい)

攻撃

  • データベースへのアクセス権を取得
  • SQLインジェクション攻撃

対策

  • システムのセキュリティ対策を実施
  • 標準のSQLインジェクション対策を実施

client_secretのオンライン推測

影響

影響は、コチラと同じ。

攻撃

有効な client_id / client_secretのオンライン推測

対策

client_id, client_secretの盗聴

影響

影響は、コチラと同じ。

攻撃

盗聴

対策

  • SSL/TLSを利用する。
  • 平文認証を使用しない代替認証を使用する。

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


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