MS_OAuthThreatModelImplicitFlow - NetDevInfraWGinOSSConsortium/NetDevInfraWiki GitHub Wiki

OAuth 2.0 Threat Model (Implicit Flow)

概要

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

補足（Implicit Flow は廃止された）: 本ページが列挙している脅威は、
最終的に Implicit Flow そのものの廃止という結論に至った。
OAuth 2.0 Security Best Current Practice と
OAuth 2.1 では、
パブリック クライアントも含めて
Authorization Code ＋ PKCE を使うことになっている。
本ページは「なぜ廃止に至ったか」の記録として読むとよい。

access_token漏洩

access_token は、

  • Fragment identifier で Client に直接返される。
  • これにより、HTTP referer（サーバ側）を介しての漏洩はしない。

共通項

共通的な影響

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

移行メモ（空の見出し）: 元ページの「access_token 漏洩」節には
「攻撃」「対策」という見出しだけの項目が並んでいたが、
実際の攻撃と対策は以降の各節に個別に書かれているため、
見出しのみの 2 項目は落として「共通項」だけを残した。

単純な攻撃

Endpointからのaccess_token漏洩

Endpoint漏洩の影響

共通的な影響

Endpoint漏洩の攻撃

盗聴

Endpoint漏洩の対策

SSL/TLS の利用

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

ブラウザ履歴漏洩の影響

共通的な影響

ブラウザ履歴漏洩の攻撃

ブラウザ履歴の参照

ブラウザ履歴漏洩の対策

  • キャッシュを無効化する。

  • access_token

    • 短い有効期限
    • scope を小さくする

補足（Fragment だから安全、ではない）: 冒頭にあるとおり
Fragment（# 以降）はサーバに送られないため HTTP referer では漏れないが、
ブラウザの履歴・アドレス バー・拡張機能からは見える。
「サーバ側に漏れない」ことと「クライアント側で守られている」ことは別、
というのが Implicit Flow の弱さの核心である。

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

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

OAuth 2.0 Threat Model (Authorization code Flow)と同じ。

スクリプトの実装を置換する

スクリプト置換の影響

共通的な影響

スクリプト置換の攻撃

  • DNS または ARP スプーフィング
  • 攻撃者のスクリプトをダウンロードする。
  • access_token の盗難・漏洩

スクリプト置換の対策

  • スクリプトを取得する CDN などのサーバを認証する。
  • スクリプトの改ざんの確認処理を実装する。
  • 1 回限りの使用ごとの秘密値の導入などは、
    攻撃者のスクリプトの有効性を低下させる。

補足（現在の手段）: 「スクリプトの改ざんの確認処理」は、現在は
**SRI（Subresource Integrity）**として
<script integrity="sha384-..."> で宣言的に書ける。
併せて Content-Security-Policy で
読み込み元を制限するのが定石である。

access_tokenの置換・注入

CSRFによる攻撃者のaccess_token注入

Authorization code（OAuth 2.0 Threat Model (Authorization code Flow)）と同じ。

access_token置換によるOAuthログイン

Authorization code（OAuth 2.0 Threat Model (Authorization code Flow)）と同じ。

補足（置換攻撃が成立する理由）: access_token には
「どのクライアント向けに発行されたか」が書かれていない（Bearer Token）。
このため、攻撃者が自分のサイトで集めたトークンを別のサイトに持ち込んでも、
受け取った側はそれを見抜けない。
OpenID Connect の ID トークンが
aud（宛先）と nonce を含む署名付きトークンとして
別立てで発行されるのは、この穴を塞ぐためである
（「OAuth 2.0 セキュリティ関連トピック」も参照）。

参考

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

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

⚠️ **GitHub.com Fallback** ⚠️