web-dev-qa-db-ja.com

応答ヘッダーで「Access-Control-Allow-Credentials」を「true」に設定する必要があるのはいつですか。

[〜＃〜] mdn [〜＃〜] は、Cookie、認証ヘッダー、TLSクライアント証明書などの資格情報をサイト間で交換する必要がある場合、Access-Control-Allow-Crendentialsをtrueに設定する必要があることを示しています。

2つのサイトA --- https://example1.xyz.com ともう1つのサイトB- https://example2.xyz.com を考えてみましょう。ここで、AからBにhttpGetリクエストを送信する必要があります。AからBをリクエストすると、次のようになります。

「要求されたリソースに「Access-Control-Allow-Origin」ヘッダーがありません。したがって、「Origin」 http://example1.xyz.com 'はアクセスを許可されていません。」

そこで、Bに次の応答ヘッダーを追加します

response.setHeader("Access-Control-Allow-Origin", request.getHeader("Origin"));

これにより、同一生成元エラーが解決され、Bにリクエストできます。いつ、なぜ設定する必要がありますか

response.setHeader("Access-Control-Allow-Credentials", "true");

このsame-Originエラーを解決するためにグーグルで検索したとき、それらのほとんどは両方のヘッダーを使用することを推奨しました。 2番目のAccess-Control-Allow-Credentialsの使用についてはよくわかりません。

  1. いつ両方を使用する必要がありますか？
  2. ワイルドカードAccess-Control-Allow-Originではなく、リクエストヘッダーから取得したOriginに*を設定する必要があるのはなぜですか？

それをよりよく理解するために例を引用してください。

httpcorshttpresponsesame-origin-policyfetch-api
7
user7946343

Allow-リクエストでCookieも送信できるようにする場合は、認証情報が必要になります。着信要求を承認する必要がある場合は、セッションIDCookieに基づいて行うのが一般的な理由です。

ワイルドカードを設定すると、どのサイトでもエンドポイントにリクエストを送信できます。リクエストが定義したホワイトリストと一致する場合、Originにallowを設定するのが一般的です。一部のブラウザは許可応答をキャッシュします。別のドメインからも同じコンテンツをリクエストした場合、リクエストが拒否される可能性があります。

4
clint

ワイルドカードAccess-Control-Allow-Originではなくリクエストヘッダーから取得した*をOriginに設定する必要があるのはなぜですか？

自分が何をしているのか非常に確信が持てない限り、そうすべきではありません。

次の場合は実際に安全です。

  1. このように応答ヘッダーを設定するリソースは、誰もがアクセスできるようにすることを目的とした公開サイトまたはAPIエンドポイントです。
  2. 攻撃者が機密情報や機密データにアクセスできるようにするCookieを設定しているだけではありません。

たとえば、サーバーコードが、ユーザーの便宜のためにアプリケーションの状態またはセッションの状態を保存する目的でCookieを設定しているだけの場合、Originリクエストヘッダーの値を取得して反映するリスクはありません。 Access-Control-Allow-Origin応答ヘッダーも送信しながら、それをAccess-Control-Allow-Credentials: true値にエコーバックします。

一方、設定しているCookieが機密情報や機密データを公開している場合は、他の方法でロックされていることが本当に確実でない限り（どういうわけか…）、Originを反映しないようにします。 Access-Control-Allow-Originを送信しながら、（サーバー側でチェックせずに）Access-Control-Allow-Credentials: true値に入力します。

これを行うと、悪意のある攻撃者がアクセスできるような方法で機密情報や機密データが公開される可能性があります。リスクの説明については、以下をお読みください。

また、CORSヘッダーを送信するリソースがnotである場合、誰もがアクセスできるように意図されたパブリックサイトまたはAPIエンドポイントではなく、イントラネット内にあります。または、IPアドレスが制限されたファイアウォールの背後にある場合は、Access-Control-Allow-Origin-reflects -OriginとAccess-Control-Allow-Credentials: trueの組み合わせを絶対に避けたいと思うでしょう。 （イントラネットの場合、ほとんどの場合、特定のハードコードされた/ホワイトリストに登録されたオリジンのみを許可する必要があります。）

3
sideshowbarker

Access-Control-Allow-Credentials: trueを設定すると、実際には2つの効果があります。

これらの効果は、設定 XMLHttpRequest.withCredentials または credentials: 'include' （Fetch API）が 資格情報（HTTP Cookie、TLS）を引き起こす効果と組み合わされますクライアント証明書、および認証エントリ） 実際にリクエストの一部として含まれます。

https://fetch.spec.whatwg.org/#example-cors-with-credentials Fetch仕様には良い例があります

2
sideshowbarker