web-dev-qa-db-ja.com

状態パラメータ値をCookieに保存しても安全ですか？

https://tools.ietf.org/html/rfc6749#section-10.12 に従って：

クライアントは、リダイレクトURIにCSRF保護を実装する必要があります。これは通常、リダイレクトURIエンドポイントに送信されるすべての要求に、要求をユーザーエージェントの認証済み状態にバインドする値（たとえば、ユーザーエージェントの認証に使用されるセッションCookieのハッシュ）を含めることを要求することで実現されます。 クライアントは、承認リクエストを行うときに「state」リクエストパラメータを使用してこの値を承認サーバーに配信する必要があります。

エンドユーザーから認証が取得されると、認証サーバーは、「state」パラメーターに含まれる必要なバインディング値を使用して、エンドユーザーのユーザーエージェントをクライアントにリダイレクトします。 バインディング値を使用すると、クライアントは、バインディング値をユーザーエージェントの認証済み状態と照合することで、リクエストの有効性を検証できます。 CSRF保護に使用されるバインディング値は、（セクション10.10で説明されているように）推測不可能な値を含んでいる必要があり、ユーザーエージェントの認証された状態（たとえば、セッションCookie、HTML5ローカルストレージ）は、クライアントのみがアクセスできる場所に保持する必要がありますおよびユーザーエージェント（つまり、同一オリジンポリシーで保護されています）。

stateパラメータの値を格納するために、安全なHTTPOnlyのSameSite Cookie（たとえば、短いタイムアウト）を使用しても安全ですか？ Cookieの値をstateパラメータの値で検証しても、リクエストの有効性を確認できますか？

oauthoauth2
6
neverendingqs

セキュアなHTTPOnlyのSameSite Cookie（たとえば、タイムアウトが短い）を使用して状態パラメータの値を保存しても安全ですか？

makeできます。

サーバー側のソフトウェアを作成していると仮定します（CookieのHTTPOnlyオプションの設定について言及しているため、作成していると想定しています）。サーバーの状態パラメーターを暗号化し、暗号化された値をCookieに格納します。 （詳細：ランダムなivで安全な暗号化アルゴリズムを使用し、ecbモードは使用しないでください）。暗号化キーをサーバー上で安全に保つようにしてください。

なぜクッキーを暗号化するのですか？

次の2つの理由により、状態値（またはCookie全体）を暗号化する必要があります。

  1. 原則として、セキュリティ担当者はセキュリティ対策を重ねることを好みます。 1つが失敗しても、もう1つはあなたを守ります。 SSLでトラフィックを保護している場合でも、SSL暗号化が侵害される可能性があります。たとえば、私が作業している場所には、SSLでMITMを実行するコンテンツ検査ファイアウォールがあり、設計によって接続のセキュリティを破っています。 （これは全体として本当に悪い考えですが、私はこれはかなり一般的であると信じています-そしてそれはあなたがあなたのサーバーからあなたのクライアントへの接続を保護するSSLに頼ることができないことを意味します。

  2. クライアント（ユーザーエージェント）から状態値を保護するため。クライアントにマルウェアが存在する場合、状態の値をクライアントに公開する必要はありません。盗まれる可能性があります。状態値が暗号化されている場合、クライアントソフトウェアはその値にアクセスできません。

これは安全ですか？

これは、CookieにセッションIDを格納し、サーバーIDのデータベーステーブルへのインデックスとしてセッションIDを使用するのと同じくらい安全です。ブラウザも、ブラウザに座っている悪意のあるJavaScriptも、誰も不透明なもの以外は何も見えないからです。 、暗号化されたCookie内のランダムに見える文字列、およびそれらが何らかの方法でそれを混乱させた場合、元の状態値に復号化されないため、状態の検証が失敗します。ただし、MAC（メッセージ認証コード）を追加し、MACがチェックアウトしたときにCookieの暗号化された状態の値のみを変更して、Cookieの内容を干渉から保護することもできます。

ローカルのブラウザー内JavaScriptとサーバー側の処理

oauthリクエストを行うブラウザのJavaScriptを作成している場合は、特に注意する必要があります（ただし、JavaScriptブラウザのセキュリティは根本的に壊れています。JavaScriptブラウザアプリケーションがある場合はoauthリクエスト、本当に安全にすることはできないと思います-合理的に安全にすることはできますが、決定的な敵に対して防御することはできません。

状態パラメーターの検証は十分ですか？

リクエストの有効性を検証するには、cookieの値をstateパラメータの値で検証するだけで十分でしょうか？

状態の検証がoauth要求（応答？）を検証するのに十分であるかどうか）は、使用しているフローとプロトコルのステップによって異なります。

たとえば、jwt idトークンを取得している場合、ほとんどすべてのシナリオでmust idトークンを検証して、それが有効であり、自分に合っていることを確認します（自分で行うことも、それを検証エンドポイントに送信します。jwtIDトークンはデジタル署名されており、署名に問題がないこと、オーディエンスとクライアントIDが一致していること、トークンの有効期限が切れていないことなどを確認する必要があります。

同じことがアクセストークンにも当てはまります。たとえば、アクセストークンの対象者を確認しないと、悪いことが発生する可能性があります（たとえば、アクセストークンが別のクライアントを対象としている可能性があります...）

しないでくださいトークンを確認する必要があるいくつかのケースがあります。 open id connectを使用してIDプロバイダーからIDトークンを取得し、ブラウザー経由でリクエストをルーティングせず、サーバー側のリクエストを介してIDプロバイダーからIDトークンを取得する場合、私はできると思います検証せずにIDトークンを信頼します。ただし、私は常に自分自身の賢さを間違えないように、常に確認しています。;-)

1
Out of Band