CORSにすべてのドメインを追加するセキュリティの影響

Question

CORSにすべてのドメインを追加するのではなく、一連のドメインのみを追加する必要があります。 しかし、一連のドメインを追加するのは簡単ではありません。例えば。 APIを公開したい場合は、そのAPIを呼び出すすべてのドメインに対して、そのドメインを許可されたドメインのリストに追加する必要があります。

私は、セキュリティの影響とより少ない作業の間に意識的なトレードオフの意思決定をしたいと考えています。

私が見る唯一のセキュリティ問題は、DoS attacksとCSRFです。 CSRF攻撃は、IMG要素とFORM要素で既に達成することができます。 CORSに関連するDoS攻撃は、参照元ヘッダーでの要求をブロックすることで克服できます。

セキュリティの影響はありますか？

===編集===

• 私が「CORSのアクセスを」ドメインの特定のリストを追加する方法を知っているAccess-Control-Allow-Credentialsヘッダーが
• に設定されていないことが想定され、したがって、私はすべてのドメイン「CORSアクセス」を追加することによるセキュリティの関与にのみ興味があります

Answer 1

csauveのものを除いて、私の元の質問に答えるものはありません。

私の質問に答えるには、 Access-Control-Allow-Credentialsが設定されていない限り、セキュリティ上の問題はありません。

Answer 2

ベストプラクティスは、ドメイン応答ヘッダーを生成します。このドメインが要求の送信を許可されているかどうかに応じて、応答ヘッダー（これだけ）をAccess-Control-Allow-Originレスポンスヘッダーに追加します。

Afaikでは、このヘッダーに複数のドメインを追加することはできません。だから、どちらか*または1つの特定のドメインだと私はいつも*

Answer 3

を追加したくないあなたは次のように、1以上のものを送ることができます。

Access-Control-Allow-Origin: http://my.domain.com https://my.domain.com http://my.otherdomain.com 

が、私はそれに対して助言します。代わりに、許可されたドメインのホワイトリストを保管してください。

allowed = [ "X", "Y", "A.Z" ]; 

をあなたはXからの要求を取得する場合、あなたはで応答：あなたがで応答A.Zからの要求を取得する場合

Access-Control-Allow-Origin: X 

：

Access-Control-Allow-Origin: A.Z 

あなたが取得する場合としましょう許可されていないドメインからの要求、エラーまたはCORSポリシーなしの応答。

すべてのXHRリクエストはOriginヘッダーを送信しますので、それを使用してください。また、次のGET/POST/HEADリクエストではなく、OPTIONSリクエストに対してCORSポリシーヘッダーを送信するだけで済みます。

---

私が見る主な問題は、すべてのドメインを公開していることです。おそらく、あなたはhttps://admin.mydomain.comのような安全な管理ドメインを持っているかもしれません。あるいは、まだ起動準備が整っていない製品ウェブサイトがあるかもしれません。あなたは、手元にあるリクエストに絶対に必要ではないものを含めることは望ましくありません。

*は、非常に怠惰です。

---

Answer 4

CORSはリクエストを行うだけでなく、コンテンツを取り戻すことについてです。 imgタグまたはscriptタグを使用してリソースを取得すると、誰かのブラウザを騙してCSRFスタイル要求を行うことができます。これは正常であり、通常のCSRFトークンで保護することができます。

CORSをすべてのドメインで有効にすると、攻撃側のサイトでjavascriptをリクエストしてコンテンツを取得し、プライバシーを侵害することができます。

例：

すべてのドメインでCORSを有効にするとします。今私はyourimaginarybank.com/balanceへのリクエストを行うウェブサイトを作成します

私のjavascriptはあなたの銀行のウェブサイトのそのページのHTMLにあったものを取得できないため、IMGリクエストは何もしません。 CORSをオンにしたところで、私のサイトのjavascriptは実際に残高があるHTMLページを取得し、それを私のサーバーに保存します。これまでのようにGETリクエストを行うだけでなく、内部に何があるかを見ることができます。これは大きなセキュリティ上の問題です。

ヘッダーに大きなリストを追加することなく問題を解決するにはどうすればよいですか？各CORS要求は、Originヘッダで行われます。おそらく最良の解決策は、原点のヘッダーを読み取ってからデータベースを照会して、フリッツが答えてホワイトリストに登録されているかどうかを確認することです。

Answer 5

クロスサイトリクエスト偽装攻撃は、Access-Control-Allow-Originが主張している主な懸念事項です。

ライアンはコンテンツ検索に関しては間違いありません。しかし、要求の主題については、ここでもっと言いたいことがあります。多くのWebサイトでは、RESTfulなWebサービスが提供されており、バックエンドで大幅な変更が行われる可能性のある幅広い機能が公開されています。非常に多くの場合、これらのRESTfulサービスは、XHR（AJAXなど）のリクエスト（おそらくフロントエンドとして「Single Page Application」）を使用して呼び出されることを想定しています。ユーザーが悪意のある第三者サイトにアクセスしたときにこれらのサービスへのアクセスを許可するアクティブセッションがある場合、そのサイトはユーザーまたはサイトを侵害する可能性のある値を渡して、その場でRESTエンドポイントを呼び出そうとする可能性があります。 RESTサービスがどのように定義されているかによって、これを防ぐさまざまな方法があります。

単一ページアプリケーションのREST Webサービスの特定のケースでは、バックエンドRESTエンドポイントへのすべての要求がXHRで行われ、XHR以外の要求は拒否されることを指示できます。カスタムリクエストヘッダ（jQueryのX-Requested-Withのようなもの）が存在するかどうかをチェックすることで、これを指示できます。これらのヘッダーは、XHRタイプの要求でのみ設定できます。フォームや埋め込みリソースからの単純なGET/POSTリクエストはできません。最後に、XHRリクエストを指示する理由は、元の質問に戻ってきます.XHRリクエストはCORSルールの対象です。

Access-Control-Allow-Origin：*を許可した場合、任意のサイトがユーザーのためにRESTエンドポイントにAJAXリクエストを行うことができます。 RESTエンドポイントに機密データが含まれていたり、データの永続性が確保されている場合、これは容認できないセキュリティ上の脆弱性です。その代わりに、私が記述したようなXHRのみの要求を実施し、その要求を許可する起点のホワイトリストを定義します。

RESTエンドポイントで機密情報が公開されていない場合や、ユーザーが永続的なデータ変更を行えない場合は、Access-Control-Allow-Origin：*が適切である可能性があります決定。たとえば、Googleマップはパブリックマップデータに読み取り専用のビューを提供します。これらのサービスを呼び出すサードパーティのサイトを制限する理由はありません。

Answer 6

古い質問ですが、ここでは多くの悪い回答がありますので、私は私のものを追加しなければなりません。

Access-Control-Allow-Credentialsを設定しておらず、クッキーレス認証を行っている場合（発信者がベアラ認証ヘッダーを提供している場合）、発信元をホワイトリストに登録する必要はありません。原点をAccess-Control-Allow-Originに戻してください。

適切に構造化されたREST APIは、任意の起点から安全に呼び出すことができます。