OAuth +混乱した代理+アクセストークンの検証+状態パラメータ

Question

Googleの「OAuth 2.0 for Client-side Application）」の記事 https://developers.google.com/accounts/docs/OAuth2UserAgent には、クライアントが検証する必要があると記載されていますすべてのアクセストークン。アクセストークンの意図された受信者であることを確認し、混乱した代理の問題に対する脆弱性を回避します。

OAuth "state"パラメータを適切に使用することで、この脆弱性を防ぐこともできます。 "proper use"は、stateパラメータ値を現在のブラウザセッションに暗号化して安全にバインドします。これは、セッションIDとナンスの組み合わせのハッシュ（ナンスを含める必要があるかどうかはわかりません）。

2つの質問があります。

私の主な質問は次のとおりです。OAuth "state"パラメータを適切に使用し、サーバー証明書の検証でTLSを使用することで、アクセストークンの対象ユーザーを検証せずに、混乱した代理の問題を緩和できます。クロスサイトリクエストフォージェリを軽減する「適切な使用」の定義

私の2番目の質問は次のとおりです。クロスサイトリクエストフォージェリは、混乱した代理問題の一種ですか？そして、「はい」の場合、私の主な質問への回答も「はい」である必要はありませんか？

SilverlightFox · Accepted Answer

これは、トークンを検証することで防止しようとしている問題です：

単純化した例として、2つのアプリがあるとします。（1）正規のファイルストレージアプリであるFileStoreと、（2）EvilAppです。どちらのアプリも、クライアント側アプリに対してGoogleの認証プロセスを使用します。 Aliceは無実のエンドユーザーであり、GoogleユーザーIDはXYZです。

アリスはGoogleを使用してFileStoreにサインインします。

認証プロセスの後、FileStoreはAliceのアカウントを作成し、それをGoogleユーザーID XYZに関連付けます。

アリスはいくつかのファイルを自分のFileStoreアカウントにアップロードします。これまでのところ、すべてが順調です。

その後、アリスはEvilAppにサインインします。EvilAppは、一種の楽しいゲームを提供します。

その結果、EvilAppはGoogleユーザーID XYZに関連付けられたアクセストークンを取得します。

EvilAppの所有者は、FileStoreのリダイレクトURIを作成して、AliceのGoogleアカウントに対して発行されたアクセストークンを挿入できます。

攻撃者はFileStoreに接続します。FileStoreはアクセストークンを取得し、それが何のユーザーかをGoogleに確認します。 GoogleはそれがユーザーXYZであると言うでしょう。

攻撃者はGoogleユーザーXYZのアクセストークンを持っているため、FileStoreは攻撃者にアリスのファイルへのアクセス権を与えます。

FileStoreの間違いは、与えられたアクセストークンが本当にFileStoreに発行されたことをGoogleで確認することではありませんでした。トークンは実際にはEvilAppに発行されました。

OAuth "state"パラメータを適切に使用することで、この脆弱性を防ぐこともできます。 "proper use"は、stateパラメータ値を現在のブラウザセッションに暗号化して安全にバインドします。これは、セッションIDとナンスの組み合わせのハッシュ（ナンスを含める必要があるかどうかはわかりません）。

2つの質問があります。

私の主な質問は次のとおりです。OAuth "state"パラメータを適切に使用し、サーバー証明書の検証でTLSを使用することで、アクセストークンの対象ユーザーを検証せずに、混乱した代理の問題を緩和できます。クロスサイトリクエストフォージェリを軽減する「適切な使用」の定義

いいえ、状態ではなくaudienceを検証する必要がありますこの記事のとおり：

OAuthでstateパラメータを使用すると、トークンの置換を防ぐことができます。ブラウザのCookieを状態にバインドすることで保護できるのは、クロスサイトスクリプティングだけだと考える人もいます[=平均CSRF]攻撃では、クライアントを正当な要求を生成して不正なユーザーエージェントにキャプチャし、それをキャプチャして、要求から変更されていない状態を含む応答を提供します。それらは、 OAuthブラウザを介してリクエストを送信した発行者が、それを受信し、応答している発行者であることを証明するクライアント側のフロー。access_tokenパラメータのみが認証サーバーによって生成され、他のすべてのパラメータクライアントは、access_tokenを発行しているのが誰であると認証サーバーが判断したかを知る方法がありません。

攻撃者がアプリのボタンをクリックして、身元を確認するためにGoogleアカウントへのアクセスを許可するとします（認証など）。ただし、リダイレクトに従うのではなく、代わりに状態値を取得してどこかに保存します。次に、悪意のあるアプリからトークンを取得し、それをredirect_uri、彼女が自分を捕らえたstateに置き換えます。

その後、アプリはユーザーを悪意のあるアプリへのアクセスを許可したユーザーとして認証します。代わりにオーディエンスの検証は安全なアプローチです。これは、トークンをサーバー側で検証するときにGoogleによってチェックされるためです。

私の2番目の質問は次のとおりです。クロスサイトリクエストフォージェリは、混乱した代理問題の一種ですか？そして、「はい」の場合、私の主な質問への回答も「はい」である必要はありませんか？

はい、CSRFは別のタイプの混乱した代理問題です。

stateを使用すると、悪意のあるユーザーがユーザーをサイトに誘導せず、エンドポイントにリダイレクトしてアプリに対する攻撃者のアカウントを承認していないことが検証されます。たとえば、アプリがコンテンツをコピーしてGoogleアカウントと同期する場合、攻撃者はユーザーをエンドポイントにリダイレクトし、サーバー側でトークンが一致することを確認してから、コンテンツをGoogleアカウントに同期します-これは攻撃者のアカウントであるため、ユーザーのファイルにアクセスできるようになりました。したがって、stateを確認することがこれに対する良い緩和策である理由は何ですか。