ブラウザが同じオリジンポリシーをXMLHttpRequestに適用するのはなぜですか?開発者にとっては本当に不便ですが、実際にハッカーを阻止することにはほとんど効果がないようです。回避策がありますが、外部ソースからのjavascriptを含めることができます(JSONPの背後にある力)。
これは、大部分が相互に関連しているWebの古い「機能」のようです。
ブラウザが同じオリジンポリシーをXMLHttpRequestに適用するのはなぜですか?開発者にとっては本当に不便ですが、実際にハッカーを阻止することにはほとんど効果がないようです。回避策がありますが、外部ソースからのjavascriptを含めることができます(JSONPの背後にある力)。
これは、大部分が相互に関連しているWebの古い「機能」のようです。
XMLHttpRequestはユーザーの認証トークンを渡すためです。ユーザーが基本認証またはいくつかのCookieを使用してexample.comにログオンし、attacker.comにアクセスした場合、後者のサイトは、そのユーザーの完全な認証を使用してexample.comへのXMLHttpRequestを作成し、ユーザーが実行できる任意のプライベートページを読み取ることができます(その後攻撃者に転送して戻します)。
Webアプリケーションページにシークレットトークンを配置することは、単純なクロスサイトリクエストフォージェリ攻撃を阻止する方法であるため、attacker.comは、ユーザーがexample.comで行うことができるページ上のアクションを、ユーザーの同意や対話なしに実行できることを意味します。グローバルXMLHttpRequestは、グローバルなクロスサイトスクリプティングです。
(認証に合格しなかったバージョンのXMLHttpRequestがある場合でも、問題があります。たとえば、攻撃者がイントラネット上の他の非公開マシンにリクエストを送信し、それらからダウンロードできるファイルを読み取る可能性があります。<script>
タグはすでにこの種の脆弱性の限定された形式に苦しんでいますが、XMLHttpRequestの完全に読み取り可能な応答は、JavaScriptとして解析できるいくつかの残念なことに作成されたファイルではなく、すべての種類のファイルをリークします。)