CORSは、クロスドメインAJAXリクエストを行うための安全な方法ですか？

StackOverflow https://stackoverflow.com/questions/4850702

質問

CORS（クロスオリジンリソース共有）について読んだ後、セキュリティがどのように改善されるか理解できません。正しいオリジンヘッダーが送信されると、クロスドメインAJAX通信が許可されます。例として、私が送る場合

元： http://example.com

サーバーは、このドメインが白いリストにあるかどうかを確認します。

Access-Control-Allow-Origin：[ここでURLを受信

回答とともに送り返されます（これは単純なケースであり、事前に描かれたリクエストもありますが、質問は同じです）。

これは本当に安全ですか？誰かが情報を受け取りたい場合、オリジンのヘッダーを偽造することは本当に些細な仕事のように思えます。また、標準では、ポリシーがブラウザで実施されていると述べており、アクセスコントロールオリジンが正しくない場合は応答をブロックします。明らかに、誰かがその情報を取得しようとしている場合、彼はそれをブロックするために標準のブラウザを使用しません。

役に立ちましたか？

解決

WebブラウザーでJavaScriptを使用してOrigin Headerを偽造することはできません。 CORSはそれを防ぐように設計されています。

Webブラウザ以外では、それは問題ではありません。一般に利用可能なデータを取得するのを妨げるようには設計されていません。一般の人々がそれを手に入れなければ、それを一般に公開することはできません。

与えられたように設計されています：

  • アリス、Ajaxを介してアクセスするように設計されたAPIを提供する人
  • Webブラウザを持っている人、ボブ
  • チャーリー、独自のウェブサイトを運営しているサードパーティ

ボブがチャーリーのウェブサイトにアクセスした場合、チャーリーはJSをボブのブラウザに送信することができないため、アリスのウェブサイトからデータを取得してチャーリーに送信します。

ボブがアリスのウェブサイトにユーザーアカウントを持っている場合、上記の状況がより重要になります。 いいえ 一般の人々は利用できます - 保護なしでは、チャーリーのJSはボブのブラウザにボブの背中の後ろにそれを行うように伝えることができました（そして、結果をチャーリーに送信します）。

不正な人々がデータを見るのを止めたい場合は、パスワード、SSLクライアント証明書、またはIDベースの認証/認証の他の手段でそれを保護する必要があります。

他のヒント

目的はこれを防ぐことです -

  • あなたはウェブサイトxに行きます
  • ウェブサイトXの著者は、ブラウザに送信される邪悪なスクリプトを書きました
  • ブラウザで実行されているそのスクリプトは、銀行のウェブサイトにログインし、邪悪なものを実行しています。 あなたのように ブラウザでは、そうする許可があります。

アイデアは、銀行のウェブサイトが、ウェブサイトXのスクリプトが銀行のページにアクセスすることを信頼する必要がある場合にブラウザを伝えるための何らかの方法が必要だということです。

@JCoderの答えに追加するために、 Origin ヘッダーは、サーバーで要求されたリソースを保護するためではありません。そのタスクは、攻撃者が実際に適切なツールを使用してこのヘッダーを押し付けることができるため、他の手段を介してサーバー自体に至ります。

のポイント Origin ヘッダーはユーザーを保護することです。シナリオは次のとおりです。

  • 攻撃者は悪意のあるウェブサイトmを作成します

  • ユーザーアリスはMに接続するようにだまされています。これには、実際にCORをサポートするサーバーB上のCORSを介していくつかのアクションを実行しようとするスクリプトが含まれています。

  • bはおそらくmがありません Access-Control-Allow-Origin ヘッダー、なぜそれがそうなるのですか？

  • 重要なポイントは、Mにはスプーフィングまたは上書きする手段がないということです Origin リクエストはアリスのブラウザによって開始されるため、ヘッダー。したがって、彼女のブラウザは（正しい）を設定します Origin Mに、それはありません Access-Control-Allow-Origin したがって、Bの場合、リクエストは失敗します。

アリスはそれを変えることができます Origin ヘッダー自身ですが、なぜ彼女は自分を傷つけていることを意味するのでしょうか？

tl; dr：the Origin ヘッダーは無実のユーザーを保護します。サーバー上のリソースを保護しません。それは彼自身のマシンで攻撃者によってスプーフィング可能ですが、それは彼の制御下にないマシンでスプーフィングすることはできません。

サーバーは、マッチングとしてリソースを保護する必要があります Origin ヘッダーは、許可されたアクセスを意味するものではありません。しかし、a Origin 一致しないヘッダーは、不正アクセスを意味します。

同じ起源のポリシーの目的は、一般的に人々がウェブサイトのコンテンツにアクセスするのを止めることではありません。誰かがそれをしたい場合、ブラウザさえ必要ありません。ポイントは停止することです クライアントスクリプト 必要なアクセス権なしに別のドメインでコンテンツにアクセスします。ウィキペディアのエントリを参照してください 同じ起源のポリシー.

Corsについて読んだ後、私はそれがどのようにセキュリティを改善するか理解していません。

CORSはセキュリティを改善しません。 CORSは、サーバーが外部ドメインによってどのようにアクセスするかをブラウザに伝えるメカニズムを提供し、CORSの前に存在していたブラウザーセキュリティモデルと一致する方法でそうしようとします（つまり、 同じ起源のポリシー).

しかし、同じ起源のポリシーとCORの範囲は限られています。具体的には、 CORS仕様 それ自体には、リクエストを拒否するメカニズムがありません。ヘッダーを使用して、外部ドメインのページが応答を読み取らないようにブラウザに指示できます。また、プレイライトリクエストの場合、外国ドメインから特定のリクエストを送信しないようブラウザに依頼できます。ただし、CORSは、サーバーが実際の要求を拒否する（つまり、実行されない）手段を指定していません。

例を見てみましょう。ユーザーがサイトにログインします A クッキーを介して。ユーザーは悪意のあるサイトをロードします M, 、それを行うフォームを送信しようとします POST に A. 。何が起こるか？まあ、corsの有無にかかわらず、そして M 許可されているドメインであるため、ブラウザはリクエストをに送信します A ユーザーの承認Cookieを使用すると、サーバーは悪意のあるものを実行します POST ユーザーがそれを開始したかのように。

この攻撃は呼ばれます クロスサイトリクエスト偽造, 、そしてCors自体はそれを軽減するために何もしません。そのため、ユーザーに代わってデータを変更するリクエストを許可する場合、CSRF保護が非常に重要です。

今、の使用 Origin ヘッダーは、CSRF保護の重要な部分になります。確かに、それをチェックすることです 多面的なCSRF防御に関する現在の推奨. 。しかし、その使用 Origin ヘッダーはCORS仕様の外側にあります。

要するに、CORSは、既存の同じ起源ポリシーセキュリティモデルを他の受け入れられたドメインに拡張するための便利な仕様です。セキュリティは追加されず、サイトはCORSの前に行ったのと同じ種類の防御メカニズムを必要とします。

私は答えるのに遅れていますが、ここの投稿は本当に求められている答えを提供しているとは思いません。最大のポイントは、ブラウザが書いているエージェントであることです origin ヘッダー値。邪悪なスクリプトは書くことができません origin ヘッダー値。サーバーがaで応答するとき Access-Control-Allow-Origin ヘッダー、ブラウザは、このヘッダーに origin 以前に送信された値。そうでない場合は、エラーをトリガーし、値を要求スクリプトに戻しません。この質問に対する他の答えは、邪悪なスクリプトへの答えを否定したいときの良いシナリオを示しています。

@DanielFも質問に対する良い答えを提供します

ライセンス： CC-BY-SA と 帰属
所属していません StackOverflow
scroll top