[論文レビュー] Mitigating CSRF attacks on OAuth 2.0 and OpenID Connect

Wanpeng Li, Chris J. Mitchell+1 more|arXiv (Cornell University)|Jan 24, 2018

Web Application Security Vulnerabilities参考文献 6被引用数 5

ひとこと要約

この論文は、OAuth 2.0 および OpenID Connect における CSRF 攻撃に対する実用的でクライアント側の防御を提案している。Referer ヘッダを活用して、認可応答の送信元を検証することで、IdP のインfra構成を変更せずに、RPs が偽装されたリクエストを検出・ブロックできる。これにより、SSO 実装のセキュリティが著しく向上する。

ABSTRACT

Many millions of users routinely use their Google, Facebook and Microsoft accounts to log in to websites supporting OAuth 2.0 and/or OpenID Connect-based single sign on. The security of OAuth 2.0 and OpenID Connect is therefore of critical importance, and it has been widely examined both in theory and in practice. Unfortunately, as these studies have shown, real-world implementations of both schemes are often vulnerable to attack, and in particular to cross-site request forgery (CSRF) attacks. In this paper we propose a new technique which can be used to mitigate CSRF attacks against both OAuth 2.0 and OpenID Connect.

研究の動機と目的

• 実世界の展開において広く見られる OAuth 2.0 および OpenID Connect 実装における CSRF 攻撃の脆弱性に対処すること。
• IdP やプロトコル標準の変更を要しない、軽量で展開可能な緩和手法を提供すること。
• RPs が Referer ヘッダを用いて送信元を検証することで、偽装された認可応答を検出・ブロックできること。
• 特に複数の IdP 環境を想定した OAuth 2.0 および OpenID Connect SSO フローのセキュリティを向上させること。
• IdPs が追加保護を実装していない場合でも、RPs が独立して採用可能な実用的解決策を提供すること。

提案手法

• この手法は、OAuth 2.0 のリダイレクト フロー中に到着する認可応答の送信元を検証するために、HTTP Referer ヘッダを使用する。
• redirect_uri の追跡において、RP は Referer ヘッダのドメインが登録済みの IdP または自らのドメインと一致するかを確認する。
• 明示的なユーザー意図の追跡において、RP は意図した IdP をセッションに保存し、Referer ヘッダをこの保存値と照合する。
• このアプローチは、認可コードおよびインクリメンタル グラント フローの両方に対応し、標準的な HTTP ヘッダを用いて検証を行う。
• XMLHttpRequest を使用する IdP 専用のクライアント ライブラリ（例：Google、Facebook）に対しても適応可能であり、コールバックが RP ドメインを指す Referer ヘッダを保持する。
• IdP 側では状態なしで動作し、RP 側での検証ロジックのみがサーバーサイドで必要となる。

実験結果

リサーチクエスチョン

• RQ1 RPs は、実際の OAuth 2.0 および OpenID Connect リダイレクト フローにおいて、どのように CSRF 攻撃を検出・防止できるか？
• RQ2 IdP の動作を変更せずに、認可応答の送信元を検証するクライアント側メカニズムとして、何が利用可能か？
• RQ3 実世界の OAuth 2.0 展開において、Referer ヘッダを用いて正当な認可応答と偽装された応答を信頼性高く区別できるか？
• RQ4 postMessage および XMLHttpRequest を使用する IdP クライアント ライブラリと組み合わせた場合、Referer ヘッダベースの防御はどの程度有効か？
• RQ5 Referer ヘッダを用いた CSRF 減軽化における実用的限界は何か？また、それらはどのように解決できるか？

主な発見

• Referer ヘッダベースの検証手法は、認可応答の送信元を検証することで、OAuth 2.0 および OpenID Connect における CSRF 攻撃を効果的に緩和する。
• RP が redirect_uri 追跡を使用している場合、およびセッションに保存された IdP としての明示的ユーザー意図を追跡している場合の両方で、この手法は有効である。
• Google や Facebook などの IdP クライアント ライブラリを使用する RP は、Referer ヘッダが常に RP ドメインを指すため、信頼性の高い検証が可能になる。
• このアプローチは実用的であり、IdP サービスやプロトコル標準の変更を要せず、RP が独立して展開可能である。
• HTTP が redirect_uri 登録に使用されている場合、ブラウザの圧縮処理によって Referer ヘッダが削除されるという主な制限が生じるが、登録に HTTPS を必須とすることでこれを緩和できる。
• Amazon や Microsoft のような IdP は HTTPS 登録を要件としているため、この防御は実世界の展開の大部分において有効に機能する。