OAuth2 Authorization Code Grantワークフローで「状態」として使用するもの

Question

Webアプリでcsrf保護を使用しています。

次に、window.open(myOAuth2StartEndpoint?oauthstuff&state=mystate)を使用して新しいブラウザーウィンドウで静的テンプレートを開いて、OAuth2承認コード付与ワークフローをトリガーすることを計画しています。

ただし、この場合、ワークフローの開始時にmystate変数が静的hrefタグ内で公開されているため、デフォルトのcsrfトークンをmystateとして公開するだけでは危険かどうか疑問に思っています。 _myOAuth2StartEndpoint_内でcsrfチェックを行うことができるので、トークンは無料で公開されませんが、これで十分ですか？

そうでない場合、このケースを処理する方法についての推奨事項はありますか？

Gudradain · Answer

免責事項：件名に関する参照が見つからなかったので、「ロジック」と呼ばれる疑わしいツールを使用します。誰かが良い参照を見つけたら、追加してください。

CSRFは危険です

間違いなくOAuth2も例外ではありません。実際、OAuth2の使用中にCSRF攻撃を悪用できる方法はいくつかあります。その理由は、CSRF攻撃をトリガーするために使用される可能性のある複数のメッセージが送信されるためです。セクション OAuth2仕様セクション10.12 は、CSRFで実行できることの概要を示しています

しかし、ユーザーがOAuth2を使用してログインしたいときに、詳細がどうなるかを見てみましょう。この例では、次のアクターがあります。

ユーザー（あなたとあなたのブラウザ）
攻撃者（通常は悪意のあるWebサイト）
クライアント（使用しているWebアプリケーション）
プロバイダー（ユーザーを認証するoauth2サーバー）

次に、プロバイダーの認証を試みたときにユーザーの観点から何が起こるかを見てみましょう。

ユーザーがクライアントWebサイトのリンクをクリックすると、プロバイダー認証フォームにリダイレクトされます
ユーザーはプロバイダーで認証され、クライアントのWebサイトにリダイレクトされ、そこで認証も自動的に行われます。

どこで攻撃できますか？

ユーザーの観点からは、2つの簡単な手順ですが、攻撃できる場所が複数あります。ここでの根本的な問題の1つは、すでにログインしている場合、OAuth2プロバイダーが自動的にリダイレクトすることがよくあることです。良い例は、stackoverflowです。詳細については、この回答を参照してください：

OAuth2クロスサイトリクエストフォージェリ、および状態パラメーター

したがって、異なる攻撃は次のとおりです。

攻撃者は認証コードを自分のものに置き換えて、あなたのアカウントではなく自分のアカウントにログインさせることができます。おかしなアイデアのように見えるかもしれませんが、彼のアカウントに機密情報を入力することにした場合、彼はその情報にアクセスできます。例：銀行情報
攻撃者は自分のマシンで有効なプロバイダーリンクを生成し、それを提供します。プロバイダーが自動的にリダイレクトしている場合、攻撃者が攻撃したいサービスにログインします。
攻撃者は、クライアントのWebサイトから有効なプロバイダーリンクを生成させ（リンクが静的URLへの投稿/取得によって生成された場合にのみ機能します）、プロバイダーが自動的にリダイレクトする場合は、攻撃者のサービスにログインします。攻撃したい。

それらからどのように保護するのですか？

簡単です。＃1と＃2から保護するには、OAuth2の状態パラメーターでCSRF偽造防止トークンを渡すだけです。次に、＃3から保護するには、ユーザーの操作なしではリンクを生成できないことを確認する必要があります。つまり、そのリンクをCSRF保護で保護します。しかし、＃1と＃2に戻って...

状態としてCSRFトークンを含めることで、攻撃者が自分で生成していないリンクを提供することが不可能になるため、これらの攻撃を無効にします。 CSRFトークンの単純な実装は、セッションに格納され、ユーザーが送信するすべてのフォームに含まれる乱数です。フォームにトークンが含まれている場合、クライアントはそれを有効と見なします。含まれていない場合、クライアントは要求が無効であると見なします。

通常、そのCSRFトークンにはユーザー/ブラウザーとクライアントのみがアクセスできますが、OAuth2の場合は、より多くの関係者がアクセスできます。何をすべきかを理解するには、これらの追加の当事者がどれであるかを知る必要があります。

答え：トークンを送信するだけです

したがって、その場合、トークンは

クライアント（作成者）
ユーザー
プロバイダー

これはHTTPSを介した単純な往復です。攻撃者がその会話に自分を挿入することはできないため、そのことを心配する必要はありません。

プロバイダーからトークンを保護する必要がありますか？

いいえ。OAuth2プロバイダーが悪意のあるものであれば、すでに失っています。彼が望めば、彼はあなたのすべてのアカウントを引き継ぐためにあなたのCSRFトークンを必要としません。 OAuth2を使用することを選択した場合、基本的に彼にすべてのユーザーアカウントの神を任せました。

結論

CSRFトークンの送信方法をあまり気にしないでください。必ず送信してください。また、それがurlパラメータとして送信されるという事実は、永続的なパスワードを心配するもう1つのポイントですが、これらのトークンは一時的なものであるため、それほど問題にはなりません。

Archimedes Trajano · Answer

stateは、RP（リソースプロバイダー）からIP（アイデンティティプロバイダー）に渡される情報であり、IPが同じ情報を返すことが期待されています。

私の場合、私は JavaEE OpenID Connect実装のstateを、OPログイン画面が表示される前にRPで最初に要求されたURLに相対的なアプリケーションへのURLとして使用しました。

対称暗号を使用して保護し、base64urlで暗号化しました。それが有効なURLであり、アプリケーションのルートに対して解決されたときにアプリケーションのルートに関連していることの検証に加えて。対称鍵はランダム化され、RPの外部に渡されません。

より安全な実装が必要な場合（ただし、ナンスをサポートするIPに限定されます）、ソースURLとnonceの両方を一緒にエンコードし、デコードされたナンス値が確実に抽出されるようにします。 nonceはソルトとして機能できます。

追記

他のIPは、異なるstate値をRPに返す場合があります。ただし、これは通常、RPからIPに渡される非標準データがあり、それらが互いに理解し合うことを意味します。たとえば、セカンダリstateを渡すことができ、IP処理に応じて、必要に応じて他の状態を送信できます。