160

最近、クロスサブドメインの AJAX 呼び出しを行うことができるように設定Access-Control-Allow-Originする必要がありました。*これはセキュリティ上の問題かもしれないと感じています。設定を維持すると、どのようなリスクにさらされますか?

4

6 に答える 6

88

で応答することによりAccess-Control-Allow-Origin: *、要求されたリソースをすべてのオリジンと共有できます。これは基本的に、すべてのサイトが XHR リクエストをサイトに送信し、サーバーのレスポンスにアクセスできることを意味します。これは、この CORS レスポンスを実装していない場合には当てはまりません。

したがって、どのサイトでも、訪問者に代わってサイトにリクエストを送信し、そのレスポンスを処理できます。ブラウザーによって自動的に提供されるもの (Cookie、Cookie ベースのセッションなど) に基づく認証または承認スキームのようなものを実装している場合、サード パーティのサイトによってトリガーされる要求もそれらを使用します。

特に、選択したリソースだけでなくすべてのリソースに対してリソース共有を許可する場合、これは確かにセキュリティ上のリスクをもたらします。このコンテキストでは、いつ CORS を有効にしても安全ですか? を確認する必要があります。.

更新 (2020-10-07)

資格情報モードが に設定されている場合、現在のFetch Standardは資格情報を省略します。includeAccess-Control-Allow-Origin*

したがって、Cookie ベースの認証を使用している場合、資格情報は要求で送信されません。

于 2012-08-17T23:54:12.533 に答える
13

私の知る限り、 Access-Control-Allow-Origin は、サーバーからブラウザーに送信される単なる http ヘッダーです。特定のアドレスに制限しても (または無効にしても)、ロボットなどに対してサイトが安全になるわけではありません。ロボットが望む場合は、ヘッダーを無視できます。通常のブラウザー (Explorer、Chrome など) は、デフォルトでヘッダーを尊重します。しかし、Postmanのようなアプリケーションは単純にそれを無視します。

サーバー側は、応答を返すときに、要求の「発信元」が何であるかを実際には確認しません。httpヘッダーを追加するだけです。アクセス制御ヘッダーを読み取ってそれに基づいて処理することを決定するのは、要求を送信したブラウザー (クライアント エンド) です。XHR の場合、特別な「OPTIONS」リクエストを使用して、最初にヘッダーを要求する場合があることに注意してください。

そのため、創造的なスクリプト作成能力を持つ人なら誰でも、ヘッダーに設定されている内容が何であれ、ヘッダー全体を簡単に無視できます。

Access-Control-Allow-Origin の設定で考えられるセキュリティの問題も参照してください。

実際に質問に答える

自分の環境をセキュリティ リスクにさらしていると感じずにはいられません。

誰かがあなたを攻撃したい場合、Access-Control-Allow-Origin を簡単に回避できます。しかし、'*' を有効にすると、攻撃者は、その HTTP ヘッダーを尊重する通常の Web ブラウザーを使用するなど、いくつかの「攻撃ベクトル」を利用できるようになります。

于 2013-10-16T23:13:29.047 に答える