「マイクロソフト系技術情報 Wiki」は、「Open棟梁Project」,「OSSコンソーシアム .NET開発基盤部会」によって運営されています。
目次  †
概要  †
OAuth 2.0 Threat Model and Security ConsiderationsのFlowに着目した脅威モデル。
Authorization code  †
共通項  †
共通的な影響  †
- codeを用いたアクセストークン・リクエストが可能になる。
(access_token, refresh_tokenの開示) 
- ただし、アクセストークン・リクエストには、client_secretも必要。
 
クライアントの信頼性  †
Authorization codeでは、クライアントにcodeが渡る。
このクライアントの信頼性は、クライアントのタイプによって異なる。
- Webアプリケーション
グローバルに一意なネットワークエンドポイント 
- ネイティブクライアント
デバイスローカルリソース(カスタムスキーム) 
攻撃区分での分類  †
影響  †
攻撃  †
対策  †
codeの盗聴  †
影響  †
共通的な影響
攻撃  †
盗聴
対策  †
- SSL/TLSの利用
 
- クライアント認証
 
- 短い有効期限
 
- 1回限りの使用制限
 
codeの漏洩  †
影響  †
共通的な影響
攻撃  †
(記録から)漏洩
- HTTP referer
Redirectエンドポイントからのリダイレクト。 
対策  †
- SSL/TLSの利用
 
- クライアント認証
 
- 短い有効期限
 
- 1回限りの使用制限
 
- ブラウザキャッシュを自動的にクリーンアップするために、
redirect_uriのターゲットページをリロードする。 
DBからcodeを盗難  †
影響  †
- 共通的な影響
 
- すべてのcodeの開示
 
- 合わせて、client_idやredirect_uriの漏洩
 
攻撃  †
- データベースへのアクセス権を取得
 
- SQLインジェクション攻撃
 
対策  †
- システムのセキュリティ対策を実施
 
- 標準のSQLインジェクション対策を実施
 
- codeハッシュのみを格納
 
codeのオンライン推測  †
影響  †
共通的な影響
攻撃  †
codeのオンライン推測
対策  †
- codeに高いエントロピーを使用
 
- 強力なクライアント認証
 
- 有効期間を短くする。
 
- トークンに署名する。
 
- codeをredirect_uriに紐付け検証する。
- redirect_uriは、スターターとアクセストークン・リクエストで必要とする。
 
- codeのオンライン推測に加え(client_id、client_secret、)redirect_uriが必要。
 
 
悪意のあるClientを認可してしまう  †
影響  †
悪意のあるClientが、アクセストークンを取得できる。
※ 共通的な影響には合致しない(アクセストークンの取得が可能)。
攻撃  †
- パブリック・クライアントが登録される。
 
- フロー中のユーザ同意のシミュレートする(など)。
 
対策  †
- 認可画面の表示
- 目的(scope)の提示
 
- client_idに対応する名称
 
- access_tokenの期間
 
 
- 自動再認証の抑止
 
- スクリーン・スクレイピングの防止(CAPTCHAs)
 
codeフィッシング  †
影響  †
共通的な影響
攻撃  †
- クライアントに対するDNSまたはARPスプーフィングが行われる。
 
- 悪意のあるClientに誘導してcodeを入手する。
 
対策  †
- クライアント認証
 
- redirect_uriをSSL/TLS(サーバ証明)で保護
 
セッション・ハイジャック  †
前述の、パブリック・クライアント版。
影響  †
共通的な影響
攻撃  †
- パブリック・クライアントが登録される。
 
- 悪意のあるClientに対するDNSまたはARPスプーフィングが行われる。
 
- 悪意のあるClientに誘導してcodeを入手する。
 
対策  †
redirect_uriをSSL/TLS(サーバ証明)で保護
※ パブリック・クライアントなのでクライアント認証は無効
漏洩した利用者のcode置換  †
影響  †
攻撃者は、被害者のアカウントで正規のClientのリソースにアクセス可能。
※ 共通的な影響には合致しない(アクセストークンの取得が可能)。
攻撃  †
- 染着なAuthorization Serverの既存のパブリック・クライアントのredirect_uriを編集・追加する。
 
- 悪意のあるClientに誘導してcode(state)を取得する。
 
- codeを他の正規のクライアントに向けてcode(state)を置換する。
 
対策  †
CSRFによる攻撃者のcode注入  †
影響  †
脆弱なClientによって被害者は攻撃者のアカウントでリソースにアクセス可能。
※ 共通的な影響には合致しない(アクセストークンの取得が可能)。
攻撃  †
- 攻撃者は、脆弱なClientをターゲットとしたcodeを収集し、
 
- CSRFのリンクを踏ませるなどのCSRF攻撃を行う。
 
対策  †
- "state"パラメタを使用し、CSRFを防止する。
 
- ユーザの教育(偽造サイトのCSRFのリンクの識別)
 
認証に対するクリックジャッキング  †
影響  †
攻撃者は、ユーザーの認証資格情報を盗み、リソースにアクセス
※ 共通的な影響には合致しない(アクセストークンの取得が可能)。
攻撃  †
- ユーザを偽造サイトに誘導する。
 
- ダミーボタンのセットの上に、透明なiFrameでターゲットサイトを読み込む。
 
- ボタンをクリックすると、実際には隠しページのAuthorizeボタンなどをクリック。
 
対策  †
- ユーザの教育(偽造サイトのクリックジャッキングの識別)
 
- 新しいブラウザ
X-FRAME-OPTIONSヘッダーを使用し、サーバ側で許可中のiFramesの回避 
- 古いブラウザ
JavaScriptのフレームバスト処理技術を使用(すべてのブラウザで効果的でない) 
Resource Owner偽装  †
影響  †
攻撃者は、ユーザーの認証資格情報を盗み、リソースにアクセス
※ 共通的な影響には合致しない(アクセストークンの取得が可能)。
攻撃  †
- パブリック・クライアントが登録される。
 
- 既存ログイン・セッションを持っている。
 
- リソース所有者の同意なしに認可要求をプログラムで送信
- HTML User Agentを組み込み、
 
- Authorization Serverによって送信されたHTML Formを解釈し、
 
- HTML Formに対応するHTTP POST要求を自動的に送信する。
 
 
- 外部ブラウザで既存のセッションを乱用
 
- 特定のデバイスでブラウザ間のクッキーを乱用
 
- 別のスコープを静かに要求する。
 
対策  †
- これは、CSRF対策を使用して防止することはできない。
 
- 自動再認証、認可画面非表示を使用しない(行わない)。
 
- パスワード認証とユーザー同意を1つのフォームにまとめ、
- CAPTCHAを使用するか、
 
- ワンタイム秘密をリソース所有者に使用する。
 
 
- 任意の通知手段によって認可をResource Ownerに通知する。
 
DOSによるリソース枯渇  †
影響  †
リソース枯渇によるサーバ機能のダウン
攻撃  †
DOSにより、codeプールなどのリソースを枯渇させる。
対策  †
- ユーザ毎に付与されるアクセストークンの数を制限
 
- codeに重要な量のエントロピーを含める(ストアを使用しないということ?)
 
生成codeによるDoS  †
影響  †
リソース枯渇によるサーバ機能のダウン
攻撃  †
生成codeを使用して、redirect_uriにボットネットで攻撃する。
対策  †
- "state"パラメタを使用し負荷軽減を行う。
 
- 無効なcode要求の数がしきい値を超える
- クライアントからの接続を制限/禁止する。
 
- ユーザ・アカウントからの接続を制限/禁止する(Client側で認証が必要)。
 
 
code置換によるOAuthログイン  †
影響  †
外部ログイン・シナリオで、被害者の身元を使用してログインしてしまう。
※ 外部ログイン・シナリオでは、userinfoエンドポイントに対するリクエストによってログインが完了する。
攻撃  †
- 犠牲者の有効なcode(state)を収集する
 
- 正規のClientのログイン・プロセスを開始させ、てcode(state)置換を行う。
 
※ 漏洩した利用者のcode置換を外部ログイン・シナリオで利用する。
対策  †
Implicit  †
access_tokenは、
- Fragment identifierでClientに直接返される。
 
- HTTP refererを介して漏洩しない。
 
共通項  †
共通的な影響  †
access_tokenの漏洩により、
Resource Ownerの、そのscopeのリソースにアクセス可能になる。
攻撃区分での分類  †
Endpointからのaccess_token漏洩  †
影響  †
共通的な影響
攻撃  †
盗聴
対策  †
SSL/TLSの利用
ブラウザ履歴からのaccess_token漏洩  †
影響  †
共通的な影響
攻撃  †
ブラウザ履歴の参照
対策  †
- 有効期間を短くする。
 
- スコープを制限する。
 
- キャッシュを無効化する。
 
悪意のあるClientを認可してしまう  †
Implicitではクライアント認証が不可な点を除き、Authorization codeと同じ。
影響  †
-
攻撃  †
-
対策  †
- redirect_uri検証
 
- scope
- 認可画面の表示(通常の仕様では認可画面非表示)
 
- 若しくは、当該フロー(認可画面非表示)でのscope制限
 
 
スクリプトの実装を置換する  †
影響  †
共通的な影響
攻撃  †
- DNSまたはARPスプーフィング
 
- 攻撃者のスクリプトをダウンロードする。
 
- access_tokenの盗難・漏洩
 
対策  †
- スクリプトを取得するSDNを認証する。
 
- スクリプトの改竄の確認処理を実装する。
 
- Introduce one-time, per-use secrets (e.g., "client_secret") values that can only be used by scripts in a small time window once loaded from a server.
The intention would be to reduce the effectiveness of copying client-side scripts for re-use in an attacker's modified code. 
CSRFによる攻撃者のaccess_token注入  †
攻撃方法・対策は、Authorization codeと同じ。
影響  †
攻撃  †
対策  †
access_token置換によるOAuthログイン  †
攻撃方法・対策は、Authorization codeと同じ。
影響  †
攻撃  †
対策  †
Resource Owner Password Credentials  †
OAuth 2.0ではIdPの仕様について言及されていないので、
ここでは唯一、サインイン・プロセスの問題を扱う(ただし非対話)。
共通項  †
共通的な影響  †
- クライアントにユーザ/パスワードが渡る。
 
- トークン取り消しが機能しない。
 
- 認可プロセスを制御できない。
 
攻撃区分での分類  †
ユーザ/パスワードの盗難  †
影響  †
共通的な影響
攻撃  †
悪意のあるクライアントによるユーザ/パスワード盗難
対策  †
- 限定的に利用する。
- 基本認証から移行する過渡期
 
- UserAgent?がAuthorization Serverに接続できない場合
 
- ClientとAuthorization Serverが同じ組織に利用されているケース
 
 
- ユーザに異なるサービスに同じ
ユーザ/パスワードを使用しないように促す。 
- refresh_tokenとユーザIDの紐付けと検証(?
 
ユーザ/パスワードの盗聴  †
影響  †
共通的な影響
攻撃  †
エンドポイントに対するユーザ/パスワード盗聴
対策  †
- SSL/TLSを利用する。
 
- 平文認証を使用しない代替認証を使用する。
 
Client側でのパスワードの露見アクシデント  †
影響  †
共通的な影響
攻撃  †
クライアントが十分な保護を提供していない場合、偶発的に起きる。
対策  †
- 他のフローを使用する。
 
- ダイジェスト認証を使用
 
- ログのパスワードを難読化
 
意図しない不要に大きなscope  †
影響  †
悪意のあるClientが、不要に大きなscopeを持ったトークンを取得できる。
攻撃  †
悪意のあるClientが、不要に大きなscopeを持ったトークンを要求する。
対策  †
- scope
- 当該(非対話的)フローでのscope制限
 
- クライアントの信頼性よって緩和
 
- 任意の通知手段によって認可をResource Ownerに通知する。
 
 
refresh_tokenによる長期的認可の維持  †
影響  †
攻撃  †
対策  †
- 当該フローでrefresh_token
- 発行しない。
 
- クライアントの信頼性よって緩和
 
- 任意の通知手段によってリフレッシュをResource Ownerに通知する。
 
 
ユーザ/パスワードのオンライン推測  †
影響  †
単一のユーザー名とパスワードの組み合わせの啓示
攻撃  †
有効なユーザー名とパスワードの組み合わせを推測
対策  †
- サインイン
- 安全なパスワードポリシー設定する。
 
- ロックアウト、タールピット(一時的ロック)を使用する。
 
- CAPTCHAを使用する。
 
 
- 他のフローを使用する。
 
- クライアント認証を併用する。
 
Client Credentials  †
Resource Owner Password Credentialsで説明したものと同様だが、
ユーザ/パスワードは使用しないため、非対話的問題を突いた攻撃の考慮事項に限定される。
Tags: :認証基盤, :クレームベース認証, :OAuth