24

CORSについて読んでいましたが、実装はシンプルで効果的だと思います。

しかし、私が何かを見逃していない限り、仕様には大きな部分が欠けていると思います. 私が理解しているように、そのリソースへのアクセスを許可するかどうかを、リクエストの発信元 (およびオプションで資格情報を含む) に基づいて決定するのは外部サイトです。これで問題ありません。

しかし、ページ上の悪意のあるコードが、ユーザーの機密情報を外国のサイトに POST しようとしている場合はどうなるでしょうか? 外部サイトは明らかにリクエストを認証しようとしています。したがって、何かを見逃していなければ、実際には CORS を使用すると機密情報を簡単に盗むことができます。

元のサイトが、そのページがアクセスを許可されているサーバーの不変リストも提供できれば、はるかに理にかなっていると思います。

したがって、展開されたシーケンスは次のようになります。

  1. 受け入れ可能な CORS サーバー (abc.com、xyz.com など) のリストを含むページを提供します。
  2. ページが abc.com に XHR リクエストを送信しようとしています - 許可リストにあり、認証が通常どおり行われるため、ブラウザーはこれを許可します
  3. Page は Malicious.com に XHR リクエストを送信しようとしています - サーバーがリストにないため、リクエストはローカルで (つまり、ブラウザーによって) 拒否されました。

悪意のあるコードが依然として JSONP を使用して不正な作業を行う可能性があることはわかっていますが、CORS の完全な実装は、スクリプト タグのマルチサイトの抜け穴を塞ぐことを暗示していると考えていたでしょう。

公式の CORS 仕様 ( http://www.w3.org/TR/cors ) も調べましたが、この問題についての言及は見つかりませんでした。

4

6 に答える 6

15

しかし、ページ上の悪意のあるコードが、ユーザーの機密情報を外国のサイトに POST しようとしている場合はどうなるでしょうか?

それはどうですか？CORSなしですでにそれを行うことができます。form.submit()Netscape 2 までさかのぼっても、new Imageや設定などの単純なインターフェースによって引き起こされる単純な GET および POST 要求を介して、いつでもサードパーティのサイトに情報を転送することができましたwindow.location。

悪意のあるコードが機密情報にアクセスした場合、あなたはすでに完全に負けています。

3) ページが Malicious.com に XHR リクエストを送信しようとしている - リクエストがローカルで拒否された

ページがまだホワイトリストに登録されていないサイトに XHR リクエストを送信しようとするのはなぜですか?

XSS の脆弱性が原因で挿入された悪意のあるスクリプトのアクションから保護しようとしている場合は、原因ではなく、症状を修正しようとしています。

于 2010-03-28T14:41:00.413 に答える
3

あなたの心配は完全に有効です。

しかし、さらに気になるのは、悪意のあるコードが存在しなくても、これを悪用できるという事実です。DOM ベースのクロスサイト スクリプティングの脆弱性が多数存在し、攻撃者はあなたが説明した問題を利用して、脆弱な Web ページに悪意のある JavaScript を挿入することができます。問題は、データを送信できる場所だけではなく、どこからデータを受信できるかです。

これについては、ここで詳しく説明します。

于 2012-04-15T20:43:55.127 に答える
2

CORS は可能なことを純粋に拡張し、安全に実行しようとしているように思えます。これは明らかに保守的な動きだと思います。安全性を高めながら他のタグ (スクリプト/イメージ) に対してより厳密なクロス ドメイン ポリシーを作成すると、多くの既存のコードが壊れ、新しいテクノロジの採用がはるかに難しくなります。うまくいけば、そのセキュリティホールを閉じるために何かが行われるでしょうが、最初に簡単に移行できることを確認する必要があると思います.

于 2010-03-28T13:45:21.437 に答える
1

問題は、サイトが既にアクセスしていた別のサイト リソースにアクセスできることではありません。問題はドメインの 1 つです。会社でブラウザを使用していて、ajax スクリプトが悪意を持って 10.0.0.1 (おそらく私のゲートウェイ) を試すことにした場合、リクエストが私のサーバーから来ているという理由だけでアクセスできる可能性があります。コンピューター (おそらく 10.0.0.2)。

だから解決策 - CORS。私はそれが最高だと言っているわけではありませんが、この問題を解決します。

1) ゲートウェイが「bobthehacker.com」の承認済みオリジン ヘッダーを返すことができない場合、リクエストはブラウザによって拒否されます。これは、古いサーバーまたは準備ができていないサーバーを処理します。

2) ゲートウェイが myinternaldomain.com ドメインからのアイテムのみを許可する場合、「bobthehacker.com」の ORIGIN は拒否されます。SIMPLE CORS の場合でも、実際には結果が返されます。デフォルトでは; そうしないようにサーバーを構成することもできます。その後、結果はブラウザによってロードされずに破棄されます。

3) 最後に、特定のドメインを受け入れる場合でも、それらのサイトからの要求を特定の形状に適合させるために、受け入れられるヘッダーと拒否されるヘッダーをある程度制御できます。

注 - ORIGIN および OPTIONS ヘッダーはリクエスタによって制御されます。明らかに、独自の HTTP リクエストを作成する人は、そこに必要なものを何でも入れることができます。ただし、最新の CORS 準拠のブラウザーはそれを行いません。インタラクションを制御するのはブラウザです。ブラウザが bobthehacker.com によるゲートウェイへのアクセスを妨げています。それはあなたが欠けている部分です。

于 2017-02-02T17:23:55.470 に答える
0

I share David's concerns. Security must be built layer by layer and a white list served by the origin server seems to be a good approach.

Plus, this white list can be used to close existing loopholes (forms, script tag, etc...), it's safe to assume that a server serving the white list is designed to avoid back compatibility issues.

于 2010-05-06T11:13:19.033 に答える