OAuth 2.0 Threat Model (Role)

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

• 戻る

目次 †

概要 †

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

• Client
• Authorization Server
  • Authorization Endpoint
  • Token Endpoint

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を用いる。

• クライアント認証に対するリプレイ攻撃を行う
  （若しくは漏洩したclient_secretを使用する。）。

攻撃 †

• 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の入手と同じ攻撃。

対策 †

• Client側の要件
  • 一時メモリやプライベート・メモリに保持する。
  • その他、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が漏洩する。

• code : Authorization Codeグラント種別
  • codeからaccess_tokenに変換するには、client_secretも必要になる。
  • code漏洩の状態は、refresh_token漏洩の状態に近い。

• access_token : Implicitグラント種別
  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の有効期間を短くする。

client_secretのオンライン推測 †

影響 †

影響は、コチラと同じ。

攻撃 †

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

対策 †

• client_secretに高いエントロピーを使用
• 強力なクライアント認証
• （クライアント認証の）アカウント・ロック

client_id, client_secretの盗聴 †

影響 †

影響は、コチラと同じ。

攻撃 †

盗聴

対策 †

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

DBからaccess_tokenを盗難 †

影響 †

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

攻撃 †

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

対策 †

• システムのセキュリティ対策を実施

• 標準のSQLインジェクション対策を実施

• access_tokenハッシュのみを格納
  （JWTの場合、DBに保存しないので対策になる）

DBからclient_secretを盗難 †

影響 †

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

攻撃 †

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

対策 †

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

---

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