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

目次

概要

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

Authorization code

主に、code漏洩にフォーカスした内容。

Implicit

access_tokenは、

  • Fragment identifierでClientに直接返される。
  • HTTP refererを介して漏洩しない。

共通項

共通的な影響

access_tokenの漏洩により、
Resource Ownerの、そのscopeのリソースにアクセス可能になる。

攻撃区分での分類

Endpointからのaccess_token漏洩

影響

共通的な影響

攻撃

盗聴

対策

SSL/TLSの利用

ブラウザ履歴からのaccess_token漏洩

影響

共通的な影響

攻撃

ブラウザ履歴の参照

対策

  • キャッシュを無効化する。
  • code
    • 短い有効期限
    • 1回限りの使用制限

悪意のある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 を認証に使うと、
車が通れる程どてかいセキュリティ・ホールが開く。」らしい。

攻撃

この、セキュリティ・ホールとは、

ザックリ言って、

  • 攻撃者の構築したClient(A)は、Access Tokenを収集する。
  • 攻撃者は、 Access Token置き換え攻撃により、Client(B)経由でリソース・アクセスできる。

と言うモノらしい。

対策

access_tokenのJWT化などによって、Resource Server側でもClient検証を行う。


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


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