• 戻る（OAuth 2.0 Threat Model (Flow)）
  • OAuth 2.0 Threat Model (Authorization code Flow)
  • OAuth 2.0 Threat Model (Implicit Flow)
  • OAuth 2.0 Threat Model (Resource Owner Password Credentials Flow)

OAuth 2.0 Threat Model and Security Considerationsの
Flow に着目した脅威モデルのうち、主に、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 漏洩」の脅威は大幅に軽減されている。

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}）を推奨している。

上記の「共通的な影響」

盗聴

• SSL/TLS の利用

• クライアント認証

• code

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

上記の「共通的な影響」

code のオンライン推測

• クライアント認証

• code

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

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

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

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

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

• OAuth 2.0 の脆弱性 (!?) "Covert Redirect" とは - OAuth.jp
  http://oauth.jp/blog/2014/05/07/covert-redirect/

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

上記の「共通的な影響」

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

redirect_uri のフルパス登録・検証

上記の「共通的な影響」

• 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 なので、クライアント認証は対策として無効。

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

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

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

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

攻撃者は、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）

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

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

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

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

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

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

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

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

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

• その他

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

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

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

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

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

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

※ 外部ログイン・シナリオでは、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 により、code プールなどのリソースを枯渇させる。

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

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

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

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

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

• RFC 6819 - OAuth 2.0 Threat Model and Security Considerations
  https://tools.ietf.org/html/rfc6819

• 本 Wiki 内

  • OAuth 2.0 Threat Model and Security Considerations
  • OAuth 2.0 Threat Model (Flow)
  • OAuth 2.0 Threat Model (Role)
  • OAuth PKCE
  • CSRF(XSRF)対策の実装方針

---

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