「マイクロソフト系技術情報 Wiki」は、「Open棟梁Project」,「OSSコンソーシアム .NET開発基盤部会」によって運営されています。
目次 †
概要 †
OAuth 2.0 Threat Model and Security ConsiderationsのFlowに着目した脅威モデル。
主に、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の仕様について言及されていないので、
ここでは唯一、サインイン・プロセスの問題を扱う（ただし非対話）。
共通項 †
共通的な影響 †
- クライアントにユーザID/パスワードが渡る。
- トークン取り消しが機能しない。
- 認可プロセスを制御できない。
攻撃区分での分類 †
ユーザID/パスワードの盗難 †
影響 †
共通的な影響
攻撃 †
悪意のあるクライアントによるユーザID/パスワード盗難
対策 †
- 限定的に利用する。
- 基本認証から移行する過渡期
- UserAgent?がAuthorization Serverに接続できない場合
- ClientとAuthorization Serverが同じ組織に利用されているケース
- ユーザに異なるサービスに同じ
ユーザID/パスワードを使用しないように促す。
- refresh_tokenとユーザIDの紐付けと検証（？
ユーザID/パスワードの盗聴 †
影響 †
共通的な影響
攻撃 †
エンドポイントに対するユーザID/パスワード盗聴
対策 †
- SSL/TLSを利用する。
- 平文認証を使用しない代替認証を使用する。
Client側でのパスワードの露見アクシデント †
影響 †
共通的な影響
攻撃 †
クライアントが十分な保護を提供していない場合、偶発的に起きる。
対策 †
- 他のフローを使用する。
- ダイジェスト認証を使用
- ログのパスワードを難読化
意図しない不要に大きなscope †
影響 †
悪意のあるClientが、不要に大きなscopeを持ったトークンを取得できる。
攻撃 †
悪意のあるClientが、不要に大きなscopeを持ったトークンを要求する。
対策 †
- scope
- 当該（非対話的）フローでのscope制限
- クライアントの信頼性よって緩和
- 任意の通知手段によって認可をResource Ownerに通知する。
refresh_tokenによる長期的認可の維持 †
影響 †
攻撃 †
対策 †
- 当該フローでrefresh_token
- 発行しない。
- クライアントの信頼性よって緩和
- 任意の通知手段によってリフレッシュをResource Ownerに通知する。
ユーザID/パスワードのオンライン推測 †
影響 †
単一のユーザー名とパスワードの組み合わせの啓示
攻撃 †
有効なユーザー名とパスワードの組み合わせを推測
対策 †
- サインイン
- 安全なパスワードポリシー設定する。
- ロックアウト、タールピット（一時的ロック）を使用する。
- CAPTCHAを使用する。
- 他のフローを使用する。
- クライアント認証を併用する。
Client Credentials †
Resource Owner Password Credentialsで説明したものと同様だが、
ユーザID/パスワードは使用しないため、非対話的問題を突いた攻撃の考慮事項に限定される。
参考 †
ネットでピックアップされていたもの。
全グラント種別共通 †
影響 †
Clientを用いた攻撃が可能になる。
- Clientなりすまし（偽装）
- 悪意のあるClientの登録
攻撃 †
- Clientなりすまし（偽装）
- client_idを盗んで、特定のClientになり済ますことができる。
- これにより、攻撃用のClientを使用した攻撃が可能になる。
- 悪意のあるClientの登録
- する場合、悪意のあるClientが登録できる。
- Clientを利用してcodeやtokenを盗むことができる。
対策 †
- Clientなりすまし（偽装）
クライアント認証、redirect_uri 検証
- 悪意のあるClientの登録
クライアントの登録機能をサポートしない。
Authorization Code, Implicitグラント種別共通 †
Open Redirect
影響 †
攻撃者のClientのRedirectエンドポイントに誘導できる。
攻撃 †
redirect_uriパラメタを用いたOpen Redirectの脆弱性を攻撃
対策 †
Authorization Serverの甘めの redirect_uri 検証処理に起因するので、
Authorization Serverは、client_id + redirect_uri の事前登録必須 + 完全一致にする。
Authorization Codeグラント種別 †
codeの置換・注入（CSFR）
影響 †
- 置換
他人のaccess_tokenを取得できる可能性がある。
- 注入（CSFR）
自分のaccess_tokenで他のユーザが操作を行える。
攻撃 †
codeを収集し、置換・注入（CSFR）の攻撃を行う。
- 置換
- 自分のClientを使用して、他人のcodeを収集する。
- 他人のcodeを収集して、自分のフロー中に埋め込む（置換）。
- 注入（CSFR）
- 攻撃対象のClientを使用して、自分のcodeを収集する。
- 自分のcodeを収集して、他人のフロー中に埋め込む（注入（CSFR））。
対策 †
- 置換
クライアント認証、redirect_uri 検証に対策を施す。
- 注入（CSFR）
ClientにCSFR対策を施す。
認可エンドポイントへ遷移する際にstateパラメタを付与する。
そして、Redirectエンドポイントでstateパラメタをチェックする。
Implicitグラント種別 †
Tokenの置き換え（不正利用）
影響 †
「OAuth 2.0 の implicit grant flow を認証に使うと、
車が通れる程どてかいセキュリティ・ホールが開く。」らしい。
攻撃 †
この、セキュリティ・ホールとは、
ザックリ言って、
と言うモノらしい。
対策 †
access_tokenのJWT化などによって、Resource Server側でもClient検証を行う。
Tags: :IT国際標準, :認証基盤, :クレームベース認証, :OAuth
![[PukiWiki]](image/pukiwiki.png "[PukiWiki]")
