2013-10-30 10 views
7

私はここ3日間、XMLHttpRequestを使ってクロスドメインリクエストを作成する方法を研究しました。私がすでに使っているJSONPを使用するのが最良の選択肢です。クロスドメインAJAXリクエストはブロックされていません:これはセキュリティ上の脆弱性ですか?

しかし、まだ答えが見つからないという質問が残っています。私は何百もの投稿(SOを含む)を読んでおり、誰も良い責任を負う回答はありません。誰かが助けてくれることを願っています

セキュリティの理由から、私はドメインexample.comからyyy.comにAjaxリクエストを行い、私が望むデータを得ることができないという多くのウェブサイトを読んでいます。それは非常に明確で、私はそれについて疑問を持っていません。しかし、私のlocalhostで以下のコードを実行すると問題が発生します(私のドメインは "localhost"なので、別のドメインのデータを要求することはできません)。

xhReq = new XMLHttpRequest(); 
xhReq.open("GET","http://domain.com.br?parameter",true); 
xhReq.send(null); 

Firebug Netタブを調べると、リクエストがブロックされていないことがわかりました。それは明らかに要求された。私は信じられませんでした。だから私はdomain.com.br/log.phpに私のドメインにヒットしたリクエストを記録できるファイルを作成しました。驚いたことに、私がローカルホストを撃っているすべての要求が私のdomain.com.brに当たっていました。応答を取得しようとしたとき、ChromeとFIrebugブラウザの元のポリシーが同じであるため、実際にはそれを取得できませんでした。しかし、私は本当にレスポンスを操作することができないにもかかわらず、リクエストが実際にウェブサーバーに当たったことに驚いていました。

もっと驚くべきことに、domain.com.br/log.phpが1MBのような巨大なレスポンスを生成した場合、私のファイヤーバグは、ブラウザがWebサーバーから1MBをすべてダウンロードしたことを示し、アクセスが拒否されました "。だから、なぜ同じ発信元ポリシーがそのデータの読み込みを禁止していれば、すべてのファイルをダウンロードするのですか?

最後に、私が驚いたのは、私が読んだすべてのウェブサイトと仕様では、ターゲットドメインがソースドメインと一致しない場合にリクエストがAjaxを使用してブロックされているということです。しかし、明らかに、私の実験では、応答データにアクセスすることはできませんが、要求は完了しています。

毎日何千ものビューを持つウェブサイトがこの3行のコードを実行し、不快なウェブサイトで巨大なDdos攻撃を引き起こすような大きなセキュリティホールが開かれる可能性があるということです。ブラウザはリクエストをブロックしないため、短い間隔で別のWebサイトの

私はこのスクリプトをIE 7,8,9とChrome最新版とFirefox最新版でテストしました。動作は同じです。要求は完了し、ブラウザはSOPを実行できない状態ですべての応答をダウンロードします。

スペックが間違っているのか、私が間違って理解しているのか、誰かが私に説明できることを願っています!

+2

[同じ発信元ポリシー](http://www.w3.org/Security/wiki/Same_Origin_Policy):同じ発信元ポリシーの下では、情報のクロスサイト送信も危険です。これは、サイトリクエストフォージェリー(CSRF)とクリックジャッキー。同じ発信元ポリシーは、情報のクロスサイト送信を禁止するとサイト間のハイパーリンクが禁止されるため、これらのセキュリティ脆弱性は情報の受信と同じ方法で対処できません。 **「送信を許可」しないと、各起源が自分自身にしかリンクできないので、「ウェブ」は全くありません。** – Andreas

+1

@アンドレアスは助けてくれてありがとうございますが、私ははっきりしないかもしれないと思います。私は、ブラウザが画像、スクリプト、CSSシートを埋め込むような外部ドメインへのリクエストを許可するべきだと考えています...しかし、Ajaxで許可することは、Dos攻撃がどのWebサーバーに対しても実行できるため、大きな脅威です。仕様は、常に、ajaxを使用して外部ドメインに対して行われた要求は常にブロックされるべきだと言います。私が証明したように間違っている原因は、リクエストがブロックされておらず、レスポンスだけです。 – Samul

+0

非表示のiframeと動作を比較します。コンテンツが別のドメインのコンテンツであれば、JavaScriptではクロスドメインにアクセスできませんが、iframeのコンテンツは「完全にダウンロード」されます。私はXHRの詳細についてはわかりませんが、制限されたデータの転送を開始する既存の方法よりも、このdownload-then-block *はもはや問題ではないようです。 – user2864740

答えて

5

要求とすることができ、サーバーはCORSに関係なく応答を生成することがあります。ただし、応答が表示されないことがあります。最近balpha wrote about this in his blog

注同一生成元ポリシーは、必ずしもそれ自体の要求を防止していないこと - それだけでアクセス可能であることから応答を防ぐことができます。悪意あるサイトは、例えば、ブラウザをリダイレクトするか、フォームを送信するか、画像またはiframeを含めるだけです。これらのすべての場合、サイトにリクエストが送信されます。邪悪なサイトはただの応答を見ません。ある程度まで

、ブラウザは、サーバーの「アクセス制御 - 許可 - 起源」ヘッダかどうかを確認するためにサーバに要求をするためにを持っています。 CORSはブラウザによって完全に実装されています。誰かがあなたのサーバーに要求を出すためにコンソールアプリケーションを書くことができるだけなので、CORSに依頼して自分のサイトからのリクエストだけを確実に行うべきではありません。

+0

助けてくれてありがとう。あなたが提供したリンクは助けましたが、それほど多くはありません。問題は、ブラウザの表示がAjaxを使用してリクエストを許可していないと言っていることをどこからでも読んでいるということです。私は外部のsrcとを置くと、外部のリソースにヒットするだけでなく、それをダウンロードしてイメージのような応答を表示することを知っています。しかし、要求が完了すべきではないという仕様は本当に明らかです。これはセキュリティ上の脅威です.Dos攻撃と同様に、この3行のコードを使用してウェブサイトを傷つける可能性があります。 – Samul

+0

@Samulしかし、あなたはCORSの概念を全く持たないプレーンなCコンソール(3行以上ではあるが)で3行のコードを実装することができる。 CORSが要求をブロックしても、追加のセキュリティは得られません。 – vcsjones

+0

私はあなたに同意します。 CORSはDos攻撃の原因を防ぐことはできません.GETパラメータをURLに追加することはできますが、いつも違うように見えます。CORSによれば、ブラウザはそのWebサイトを再度要求してはいけないと言います。 URLを変更すると(ランダムなパラメータを追加しても)、Webサーバーから送信されたANYヘッダーにもかかわらず、ブラウザは常に外部リソースを要求します。 – Samul

0

シンプルなイメージファイルで同じ効果(DOS攻撃のような)を実現できますが、必ずしもXHRである必要はありません。別のウェブサイトの画像ファイルをリンクし、数百万個の画像をページに入れ、それをユーザーに表示してブームを起こします。

+0

あなたは非常に正しいです!しかし、外部画像、スクリプト、CSSシートをページに埋め込むことは可能であることは非常によく知られています...しかし、Ajaxリクエストは外部リソースをリクエストするときに常にブロックされるべきであることも非常に明白です。私が証明したように、応答だけがブロックされています。そして、そこに潜在的な脅威があります:Ajaxの使用私はPOSTをシミュレートすることができます。私は画像ではできないWebサーバーのログインとデータベースの過負荷を行います。 – Samul

+0

ポリシーで要求を拒否する必要があるかアクセスする必要があるかはわかりません。彼らは違う。しかし、あなたはまだXHRなしで任意のウェブサイトへの投稿をシミュレートすることができます。フォームを作成し、ターゲットWebサイトのログインページにアクションを設定します。ページの読み込み時に送信してください!ここにXHRの投稿要求はありません。 – regulus

関連する問題