web-dev-qa-db-ja.com

同一生成元ポリシーとCORS-ポイントは何ですか？

同一生成元ポリシーとそれを「回避」するさまざまな方法を理解するのに問題があります。

セキュリティ対策として同一生成元ポリシーが存在することは明らかであるため、サーバー/ドメインからの1つのスクリプトは、別のサーバー/ドメインからのデータにアクセスできません。

このルールを破ることができると便利な場合があることも明らかです。たとえば、マッシュアップアプリケーションは、必要な結果を構築するために、さまざまなサーバーからの情報にアクセスします。そして、これを行う方法の1つはCORSです。

1）私が間違っていなければ、CORSはターゲットサーバーがブラウザに「データを取得しても大丈夫です/応答にいくつかのヘッダーを追加して、自分自身からのコード "。ただし、これが正しければ、悪意のあるサーバーがこのヘッダーを追加するだけで、ブラウザーがそのサーバーからの潜在的に有害なデータまたはコードの取得を許可することを意味します。

2）反対側にはJSONPがあり、CORSを有効にせずにサーバーから任意のコードまたはデータを取得できるため、SOPの主な目的を回避できます。繰り返しになりますが、JSONPを管理できる悪意のあるサーバーは、ブラウザーにSOPが組み込まれていても、データまたはコードを挿入できます。

私の質問は次のとおりです。

2番目の議論は正しいですか？ブラウザがコンテンツを受け入れる必要があるかどうかはサーバーの決定ですか？ 2番目の議論は正しいですか？繰り返しになりますが、データを受け入れるかどうかはブラウザの決定ではありませんか？

JSONPはSOPを役に立たないものにしませんか？

私を啓発してくれてありがとう！

corssame-origin-policy
33
Roberto

ここで注意すべき重要なことは、ユーザーがサイトにサインインしている場合 http://example.com/ およびリクエスト http://example.com/delete?id = 1 ユーザーによる投稿を削除すると、次のコードでユーザーの投稿が削除されます。

<script src="http://example.com/delete?id=1" />

これは、CSRF/XSRF攻撃（クロスサイトリクエストフォージェリ）と呼ばれます。これが、ほとんどのサーバー側Webアプリケーションがトランザクションチケットを要求する理由です。 http://example.com/delete?id=1 の代わりに http：// example。 com/delete？id = 1＆txid = SomethingTheUserCannotGuess

これで、次の攻撃は機能しなくなります。

<script src="http://example.com/delete?id=1" />

... txidパラメータが含まれていないため。それでは、XmlHttpRequestを使用してサイトにアクセスできるとどうなるかを考えてみましょう。ユーザーのブラウザで実行されているスクリプトは、ユーザーのバックリトリーブの背後で取得および解析する可能性があります http://example.com/pageThatContainsDeleteLink 、txidを抽出してから、リクエストします http://example.com/ delete？id = 1＆txid = SomethingTheUserCannotGuess

ここで、XmlHttpRequestが異なるオリジンを持つサイトにアクセスできない場合、txidを取得しようとする唯一の方法は、次のようなことを試みることです。

<script src="http://example.com/pageThatContainsDeleteLink" />

...しかし、結果はJavaScriptコードではなく、HTMLページであるため、役に立ちません。したがって、他のサイトから<script>：sを含めることはできても、XmlHttpRequestを介して他のサイトにアクセスできないのには理由があります。

あなたはこれを読むことに興味があるかもしれません： http://haacked.com/archive/2008/11/20/anatomy-of-a-subtle-json-vulnerability.aspx/

この攻撃は当時Gmailに対して機能し、別のサイトで実行されているJavaScriptコードからユーザーのメールを取得することを可能にしました。これはすべて、WWWのセキュリティモデルが非常に微妙で、よく考えられていないことを示しています。うまく設計されているのではなく、進化してきました。

あなたの質問に関して：あなたはサーバー http://example.com/ が悪意のあるものだと思っているようです。そうではありません。私の答えの表記を使用すると、 http://example.com/ は攻撃のターゲットであるサーバーであり、 http://attacker.com/ は攻撃者のサイト。 http://example.com/ がJSONPまたはCORSを使用してリクエストを送信する可能性を開く場合、先ほど説明したCSRF/XSRF攻撃に対して脆弱になる可能性があることは事実です。しかし、それは他のサイトが攻撃に対して脆弱になるという意味ではありません。同様に、 http://attacker.com/ がJSONPまたはCORSを使用してリクエストを送信する可能性を開く場合、攻撃者のサイトはCSRF/XSRF攻撃に対して脆弱になります。したがって、誤った情報を与えられたサーバー管理者は、自分のサイトに穴を開ける可能性がありますが、他のサイトのセキュリティには影響しません。

17
juhist