2016-04-18 5 views
2

私は今これでいくつかの仕事をしています。私は言いたいことがあります。私にとっては意味がありません!基本的には、サイトにイメージを提供するCSSを提供するCDNサーバーがあります。何らかの理由で、私のブラウザがCORSエラーでこれらのリソースをブロックするのを止めるために、そのサーバ(CDN)にAccess-Control-Allow-Originヘッダを追加させる必要がありました。しかし、限り、私はそれが絶対にセキュリティを高めるために何も言うことができます。これらのクロスドメインリソースがブラウザーにどの参照を参照しているかを要求するページでは、他のドメインから取得するのは安全ですか?悪意のあるドメインの場合は、アクセス制御許可原点が*に設定されているため、サイトが悪意のある応答を読み込むことはできません(明らかにそう答える必要はありません)。CORS(Access-Control-Allow-Originヘッダー)はどのようにセキュリティを強化しますか?

誰かがこのメカニズム/機能がセキュリティをどのように提供しているか説明できますか?限り、私は実装者に犯されたと言うことができ、実際には何もしません。ヘッダーは、要求されているドメインからではなく、クロスドメインリソースを参照/要求するページから要求されます。

明確になります。ドメインAのページをリクエストすると、レスポンスがドメインB(Access Control-Allow-Origin:.B.com)のAccess-Control-Allow-Originヘッダーホワイトリストリソースを含めることは意味がありますが、ドメインBがヘッダーを提供することによって効果的にホワイトリスト自体を意味をなさない。アクセス制御許可元:これはこれが現在実装されている方法です。誰でもこの機能の利点を明確にすることはできますか?

+0

[CORSプリフライトリクエストのセキュリティ上の利点は何ですか?](http://stackoverflow.com/questions/35424709/what-are-the-security-benefits-of-cors-preflight-requests) – dippas

答えて

4

サイトAでホストされている保護されたリソースだけでなく、サイトB、C、Dを管理している場合は、自分のすべてのサイトでそのリソースを使用したいと思うかもしれません。だから、私は自分のサイトAにすべての回答と一緒にAccess-Control-Allow-Origin: B, C, Dを送るよう指示します。これを尊重し、潜在的なJavascriptへの応答や、許可された起源から来なかった場合には要求を開始したものは、Webブラウザ自体に任されています。代わりにエラーハンドラが呼び出されます。したがって、サーバーのためのアクセス制御方法(すべての主要なブラウザーがこれを行う)である限り、あなたのセキュリティのためではありません。

+0

ああ、アイデアはあなたのリソースの使用を制限することです?これらのリソースを要求するものを保護しないでください。 – evanmcdonnal

+0

はい、あなたが言ったことを正確に行うクロスソースリソース共有(CORS)の一部です。あなたのリソースの使用を制限/管理します。 CORSは、CORSに準拠していない状況での潜在的な悪意のあるドメイン間の要求を防止することによって、エンドユーザーを保護する特定の状況で、同一起点ポリシーを緩和するための標準化された方法です。 –

+0

いったん私はそれを "Bドメインで自分のリソースを無作為に使うことを望まない"という観点から見ると、まだ役に立たないとは思うが、それは意味をなさない。それは実際にインターネットの仕組みと一貫していません。ドメインBでリソースを盗みたいのであれば、ブラウザにURLを入力してコピー/貼り付け/保存して自分のサーバーに置くだけです。システムは本質的にあなたが行うことができます! – evanmcdonnal

1

Access-Control-Allow-Originは、疑うことを知らないユーザーのWebブラウザを経由して(evil.comそれを呼び出すことができます)別のサーバーに(privateHomeServer.comそれを呼び出すことができます)から漏れるからデータを保護するためのものです。あなたが誤ってevil.com上につまずいたときにウェブを閲覧するホームネットワーク上にある

は、このシナリオを考えてみましょう。このWebページには、あなたのローカルホームネットワーク上のWebサーバを探して悪意のあるjavascriptが含まれていて、それらのコンテンツをevil.comに送り返します。これは、すべてのローカルIPアドレス(例えば、192.168.1.1、192.168.1.2、.. 192.168.1.255)上でXMLHttpRequestsを開き、Webサーバーを見つけるまで試みます。

あなたは気づいていないAccess-Control-Allow-Originある古いWebブラウザを使用しているか、あなたのprivateHomeServerにAccess-Control-Allow-Origin *を設定した後、お使いのブラウザは喜んであなたのprivateHomeServerからデータを取得したい場合(それが安全にあったように、おそらくあなたはpasswording気にしませんでしたあなたの家のファイアウォールの背後にある)、そのデータを悪質なjavascriptに渡します。悪質なjavascriptはevil.comサーバに情報を送信します。 privateHomeServerから取得した任意のデータを見てから、悪意のあるJavaScriptをブロックするWebブラウザ(Access-Control-Allow-Origin *を送信すなわち。ない)privateHomeServer上Access-Control-Allow-Origin意識ブラウザとデフォルトのWeb設定を使用して一方

。このようにして、サーバーのデフォルト構成を変更することができない限り、このような攻撃から保護されます。

それらのクロスドメイン のリソースを参照して、私が要求するページには、それが他の ドメインからのものを入手しても安全ですブラウザを語っすべきではありません:?質問について

特定のサーバーからリソースを取得しようとしているコードがページに含まれているということは、リソースがフェッチするのが安全だとWebブラウザに暗黙的に伝えています。もう一度これを繰り返す必要はありません。

0

CORSはマッシュアップコンテンツプロバイダにのみ意味があります。

例:登録が必要な埋め込みマップマッシュアップサービスのプロバイダです。これで、ajaxマッシュアップ・マップが登録されたユーザーのドメインでのみ機能することを確認します。他のドメインは除外する必要があります。この理由からのみ、CORSは理にかなっています。

別の例:誰かがCORSをREST-Serviceに悪用します。巧妙な開発者は、そのサービス上のすべてのドメインからアクセスできるajaxプロキシを設定しました。

このようなajaxプロキシはマッシュアップには意味がありません。逆に単純なhttp-clientで制限を回避できるため、CORSはREST-Servicesには意味がありません。

関連する問題