Skip to content

MS_OAuthThreatModelAuthCodeFlow

Jump to bottom
nishi_74322014 edited this page Sep 1, 2026 · 1 revision

OAuth 2.0 Threat Model (Authorization code Flow)

概要

OAuth 2.0 Threat Model and Security Considerationsの
Flow に着目した脅威モデルのうち、主に、code 漏洩にフォーカスした内容。

code 漏洩

攻撃

（記録から）漏洩

  • HTTP referer
    Redirect エンドポイントからのリダイレクト。

  • WWW サーバの要求ログ

  • WWW ブラウザの履歴情報

  • 下記「オープン・リダイレクタ」

対策

  • SSL/TLS の利用

  • クライアント認証

  • ブラウザ・キャッシュを自動的にクリーンアップするために、
    redirect_uri のターゲット・ページをリロードする。

  • code

    • 短い有効期限
    • 1 回限りの使用制限

共通項

共通的な影響

code 漏洩により、

  • code を用いたアクセストークン・リクエストが可能になる。
    （access_token, refresh_token の開示）

  • ただし、アクセストークン・リクエストには、client_secret も必要。

補足（今は code_verifier が必要）: 「client_secret も必要」という
前提は Confidential Client にしか成り立たず、ネイティブ アプリや
SPA では成立しない
（秘密を隠せないため）。
ここを埋めたのが PKCE（RFC 7636）で、
code を開始したクライアントだけが知る code_verifier を
トークン要求時に要求する。
Security BCP（RFC 9700）/ OAuth 2.1
では すべてのクライアントで PKCE 必須となっており、
本節の「code 漏洩」の脅威は大幅に軽減されている。

Client の信頼性

Authorization Code では、Client に code が渡る。
この Client の信頼性は、Client のタイプによって異なる。

  • Web アプリケーション
    グローバルに一意なネットワークエンドポイント
  • ネイティブクライアント
    デバイスローカルリソース（カスタムスキーム）

補足（カスタム スキームの奪い合い）: 「デバイスローカルリソース
（カスタムスキーム）」が一意でないのが、ネイティブ アプリ特有の弱点である。
同じカスタム スキーム（myapp://）を後から入れた別アプリが
横取りできてしまう（OS が保証しない）。
このため OAuth 2.0 for Native Apps（RFC 8252）は、
Claimed HTTPS スキーム（iOS の Universal Links /
Android の App Links）か、ループバック アドレス
（http://127.0.0.1:{port}）を推奨している。

単純な攻撃

code の盗聴

影響

上記の「共通的な影響」

攻撃

盗聴

対策

  • SSL/TLS の利用

  • クライアント認証

  • code

    • 短い有効期限
    • 1 回限りの使用制限

code のオンライン推測

影響

上記の「共通的な影響」

攻撃

code のオンライン推測

対策

  • クライアント認証

  • code

    • 短い有効期限
    • 1 回限りの使用制限
    • 高いエントロピーを使用
    • code を redirect_uri に紐付け検証する。
      • redirect_uri は、スターターとアクセストークン・リクエストで必要とする。
      • code のオンライン推測に加え（client_id、client_secret、）
        redirect_uri が必要。

DB から code を盗難

影響

  • すべての code の開示（上記の「共通的な影響」）
  • 合わせて、client_id や redirect_uri の漏洩

攻撃

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

対策

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

Client への誘導による盗難

オープン・リダイレクタや、DNS または ARP スプーフィングが用いられる。

オープン・リダイレクタ

OAuth 2.0 Threat Model (Role)の
「オープン・リダイレクタ」も参照。

影響

上記の「共通的な影響」

攻撃

redirect_uri を使用して任意の URL に誘導

対策

redirect_uri のフルパス登録・検証

code フィッシング

影響

上記の「共通的な影響」

攻撃

  • Client（と言うより、ココでは任意の redirect_uri）
    に対する DNS または ARP スプーフィングが行われる。
  • 悪意のある Client に誘導して code を入手する。

対策

  • クライアント認証
  • redirect_uri を SSL/TLS
    （サーバ証明）で保護

セッション・ハイジャック

上記「code フィッシング」の考慮事項に、
「Client 登録機能で登録された悪意のある Client」を追加した版。

影響

上記の「共通的な影響」

攻撃

  • 悪意のある Client が登録される。
  • 悪意のある Client に対する DNS または ARP スプーフィングが行われる。
  • 悪意のある Client に誘導して code を入手する。

対策

redirect_uri を SSL/TLS
（サーバ証明）で保護

悪意のある Client の登録・誘導による盗難

  • 登録機能で登録された Client なので、クライアント認証は対策として無効。

  • 従って、アクセストークン・リクエストをパスされる可能性が高まる。

  • ただし、code と client（例えば、redirect_uri など）を、
    紐付ける仕組みを導入すれば、対策は可能と思われる。

補足（この「紐付ける仕組み」が PKCE）: 元ページが
「対策は可能と思われる」と推測している仕組みは、
code を「それを開始したクライアント自身」に縛るというもので、
まさに PKCE が実現したことである
（redirect_uri ではなく、クライアントが毎回生成する
code_verifier のハッシュで縛る点が、より強い）。
本ページの原文が 2013 年、PKCE の RFC 7636 が 2015 年なので、
著者の見立ては後の標準化を先取りしていたことになる。

セッション・ハイジャック

上記「セッション・ハイジャック」を参照。

WebView などの組込ブラウザ（Resource Owner 偽装）

影響

攻撃者は、Resource Owner の認証資格情報を盗み、リソースにアクセス

攻撃

  • 悪意のある Client が登録される。

  • 既存ログイン・セッションを持っている。

    • 外部ブラウザで既存のセッションを乱用
    • 特定のデバイスでブラウザ間のクッキーを乱用

  • 悪意のある Client は、

    • 以下の方法で認可画面の POST バックをプログラムで送信

      • WebView などの組込ブラウザを組み込み、
      • Authorization Server によって送信された HTML Form を解釈し、
      • HTML Form に対応する POST バックを自動的に送信。

    • これにより、別の scope のアクセストークンを同意なしで取得可能。

対策

  • これは、CSRF 対策を使用して防止することはできない。

  • 自動再認証、認可画面非表示を使用しない（行わない）。

  • パスワード認証とユーザ同意を 1 つのフォームにまとめ、

    • CAPTCHA を使用するか、
    • ワンタイム秘密を Resource Owner に使用する。

  • 任意の通知手段によって認可を Resource Owner に通知する。

スクリーン・スクレイピング

影響

悪意のある Client が、アクセストークンを取得できる。

攻撃

  • 悪意のある Client が登録される。
  • 悪意のある Client は、フロー中のユーザ同意を、
    スクリーン・スクレイピング技術を利用してシミュレートする（など）。

対策

  • redirect_uri 検証

  • 画面の表示

    • 自動再認証の抑止
    • 認可画面の表示
      • 目的（scope）の提示
      • client_id に対応する名称
      • access_token の期間
      • スクリーン・スクレイピングの防止（CAPTCHA）

code の置換・注入

  • 既存 Client を利用した攻撃なので、Client 登録機能が無くても攻撃可能。

  • code の置換・注入があり、其々以下のような特徴がある。

    • code の置換：「被害者のアカウント」でリソースにアクセス
    • code の注入：「攻撃者のアカウント」でリソースにアクセス

※ 上記の「共通的な影響」には合致しない（アクセストークンの取得が可能）。

漏洩した利用者の code 置換

影響

攻撃者は、「被害者のアカウント」でリソースにアクセス可能。
（被害者のアカウントに紐付いたリソースの CRUD が可能）

攻撃

  • 被害者の code（state）を入手する。

    • 上記「単純な攻撃」では、state を入手できない。
    • 脆弱な Authorization Server の既存のクライアントの redirect_uri を
      編集・追加する。
      （ココでは、redirect_uri パラメタではなく、
      登録されているデータそのものの編集・追加を言っている模様）

  • code（state）を他の正規のクライアントに向けて置換する。

対策

  • redirect_uri の改ざんなどがされないようにする。

  • その他

    • クライアント認証
    • 他のフローを使用する。

CSRF による攻撃者の code 注入

影響

脆弱な Client によって被害者は「攻撃者のアカウント」でリソースにアクセス可能。
（攻撃者のアカウントに紐付いたリソースのストアに
被害者のデータを登録させることが出来る）

攻撃

攻撃者は、脆弱な Client をターゲットとして、

  • Client を対象とした code を収集する。
  • その code を含む Client への CSRF リンクを踏ませる。

対策

  • state パラメタを使用し、CSRFを防止する。
  • ユーザの教育（偽造サイトの CSRF のリンクの識別）

code 置換による OAuth ログイン

影響

外部ログイン・シナリオで、攻撃者は、「被害者のアカウント」でログイン可能
（場合によっては、悪意のあるアプリケーションにログインさせることが出来る）

※ 外部ログイン・シナリオでは、userinfo エンドポイントに対する
リクエストによってログインが完了する。

攻撃

上記「漏洩した利用者の code 置換」を外部ログイン・シナリオで利用する。

対策

code を access_token に交換する際、

  • 事前のユーザ認証
  • ユーザ ID と code の対応付け
    OpenID / OpenID Connectや
    SAMLを利用
    （aud による Client 制限を行うことが出来る）

補足（state だけでは足りない、が結論）: 本節に並ぶ 3 つの攻撃
（置換・注入・OAuth ログイン）は、いずれも
state パラメタだけでは防げないという点で共通している
（state は「自分が始めたフローか」しか確かめられない）。
現在の標準的な対策は次の 2 つである。

  • PKCE（RFC 7636）
    code を開始したクライアント自身に縛る。code 注入への直接の答え。
  • iss パラメタ（RFC 9207）
    認可レスポンスに発行者を明示し、複数 IdP 構成での取り違えを防ぐ。

外部ログイン（OAuth ログイン）については、
OpenID Connect の ID トークンを使い、
aud / nonce / iss を検証するのが正解である
（OAuth による外部ログイン（認証）の研究を参照）。

アクセストークンまで取得が可能な攻撃

※ 上記の「共通的な影響」には合致しない（アクセストークンの取得が可能）。

  • 上記「WebView などの組込ブラウザ（Resource Owner 偽装）」
  • 上記「スクリーン・スクレイピング」
  • 上記「漏洩した利用者の code 置換」
  • 上記「CSRF による攻撃者の code 注入」
  • 上記「code 置換による OAuth ログイン」

クリック・ジャッキング

影響

攻撃者は、Resource Owner の認証資格情報を盗み、リソースにアクセス

攻撃

  • 上記「スクリーン・スクレイピング」に近いが、

    • 「悪意のある Client」の
      • 「POST バックを自動的」や、
      • 「スクリーン・スクレイピング技術」ではなく
    • 「偽造サイト」の「クリック・ジャッキング」とする。

  • 以下で認証済みアクセスする。

    • Resource Owner を偽造サイトに誘導する。
    • ダミーボタンのセットの上に、透明な iFrame でターゲットサイトを読み込む。
    • ボタンをクリックすると、実際には隠しページの Authorize ボタンなどをクリック。

対策

  • ユーザの教育（偽造サイトのクリック・ジャッキングの識別）

  • IFrame の回避

    • 新しいブラウザ
      X-FRAME-OPTIONS ヘッダ
    • 古いブラウザ
      アンチフレーム、フレームバストの JavaScript
      （すべてのブラウザで効果的でない）

補足（現在は frame-ancestors）: X-Frame-Options は今も
互換のために送られるが、標準としては
Content-Security-Policy の
frame-ancestors 'none' が後継である。
認可エンドポイントは iframe 埋め込みを一切許さないのが原則で、
「フレームバストの JavaScript」は現在では不要
（かつ、sandbox 属性付き iframe では無力）。

DoS によるサーバ機能のダウン

DoS によるリソース枯渇

影響

リソース枯渇によるサーバ機能のダウン

攻撃

DoS により、code プールなどのリソースを枯渇させる。

対策

  • Resource Owner 毎に付与されるアクセストークンの数を制限
  • code に十分な量のエントロピーを含める。

移行メモ（意味の取れない箇所）: 元ページの
「code に些細ではない量のエントロピーを含める（？）」は、
RFC 6819 の "non-trivial amount of entropy" の直訳と思われる。
趣旨は「推測されない程度に十分なエントロピーを持たせる」なので
その旨に書き改めた。
なお、この項ではcode を保存せずステートレスに検証する
（署名付き code にする）ことが、プール枯渇に対する
より直接的な回避策になる。

生成 code による DoS

影響

リソース枯渇によるサーバ機能のダウン

攻撃

生成 code を使用して、redirect_uri にボットネットで攻撃する。

対策

  • state パラメタを使用し負荷軽減を行う。
  • 無効な code 要求の数がしきい値を超える
    • クライアントからの接続を制限 / 禁止する。
    • ユーザ・アカウントからの接続を制限 / 禁止する（Client 側で認証が必要）。

参考

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

このWikiは「Open棟梁Project」,「OSSコンソーシアム 開発基盤部会」によって運営されています。

NetDevInfraWiki

マイクロソフト系技術情報 Wiki
Open 棟梁 Wiki

（未着手）

開発基盤部会 Wiki

移行管理: DONE ／ TODO

Clone this wiki locally