js同一オリジンポリシー_javascriptスキルの詳細説明

この記事では、JS の同一オリジン戦略をより詳細に分析します。皆さんの参考に共有してください。詳細は以下の通りです。

コンセプト: 同一生成元ポリシーは、クライアント側スクリプト (特に Javascript) にとって重要なセキュリティ メトリックです。これは Netscape Navigator2.0 から初めて登場し、その目的はドキュメントまたはスクリプトが複数の異なるソースからロードされるのを防ぐことです。

ここでの同じオリジンとは、同じプロトコル、同じドメイン名、同じポートを指します。

エッセンス:

その本質は単純です。サイトから読み込まれた信頼できるコンテンツは安全でないとみなします。ブラウザーによって信頼されていないスクリプトがサンドボックスで実行される場合、悪意のある可能性のある他のサイトからのリソースではなく、同じサイトからのリソースへのアクセスのみを許可する必要があります。

同一生成元制限があるのはなぜですか?

例を挙げてみましょう。たとえば、ハッカー プログラムは IFrame を使用して、実際のユーザー名とパスワードを使用してログインすると、そのページのコンテンツを読み取ることができます。ユーザー名とパスワードを簡単に取得できるように、フォームに入力します。

Ajax アプリケーション:

このセキュリティ制限は、Ajax アプリケーションでは破られます。

通常の Javascript アプリケーションでは、Frame の href または IFrame の src を変更して、GET モードでのクロスドメイン送信を実現できますが、クロスドメイン Frame/IFrame のコンテンツにアクセスすることはできません。

Ajax は非同期対話に XMLHTTP を使用します。このオブジェクトはリモート サーバーと対話することもできます。さらに危険なのは、この対話プロセスがユーザーによって認識されることです。したがって、XMLHTTP は、JavaScript の本来のセキュリティ制限を実際に突破しました。

XMLHTTP のリフレッシュ不要の非同期対話機能を利用したいが、JavaScript のセキュリティ ポリシーをあからさまに破りたくない場合は、別の方法として、厳格な同一オリジン制限を XMLHTTP に追加します。このようなセキュリティ ポリシーは、アプレットのセキュリティ ポリシーと非常によく似ています。 IFrame の制限は、クロスドメイン HTMLDOM 内のデータにアクセスできないことですが、XMLHTTP は基本的にクロスドメイン リクエストの送信を制限します 。

ブラウザのサポート: IE は、このセキュリティ ポリシーに対して実際に 2 つのバックドアを開きます。1 つは、ローカル ファイルがアクセスされるコンテンツを自然に認識していることを前提としているため、ローカル ファイルは外部データにアクセスしません。警告。もう 1 つは、アクセスした Web サイトのスクリプトがクロスドメイン情報にアクセスしようとしている場合、実際にはダイアログ ボックスをポップアップ表示して注意を促すことです。詐欺的な Web サイトがこの方法を使用して偽のページを提供し、XMLHTTP を介して実際の銀行サーバーにリモートでログインできるようにする場合。 10 人のユーザーのうち 1 人だけが混乱して [OK] をクリックしました。彼らのアカウント盗難は成功しました！ 考えてみてください、これはどれほど危険なことでしょう。

FireFox はこれを行いません。デフォルトでは、FireFox はクロスドメイン XMLHTTP リクエストをまったくサポートしておらず、ハッカーにそのような機会を与えません。

同一生成元戦略を避ける:

JSON および動的スクリプトタグ

src="http://yoursiteweb.com/findItinerary?username=sachiko&
予約番号=1234&output=json&callback=showItinerary" />

JavaScript コードが <script> タグを動的に挿入すると、ブラウザは src 属性の URL にアクセスします。これにより、クエリ文字列内の情報がサーバーに送信されます。リスト 1 では、ユーザー名と予約が名前と値のペアとして渡されます。さらに、クエリ文字列には、サーバーから要求された出力形式とコールバック関数の名前 (つまり、showItinerary) が含まれます。 <script> タグがロードされた後、コールバック関数が実行され、サービスから返された情報がパラメータを通じてコールバック関数に渡されます。 </script>

Ajax プロキシ

Ajax プロキシは、Web ブラウザとサーバー間の HTTP リクエストと応答を仲介するアプリケーション レベルのプロキシ サーバーです。 Ajax プロキシを使用すると、Web ブラウザが同一生成元ポリシーをバイパスできるようになり、XMLHttpRequest を使用してサードパーティのサーバーにアクセスできるようになります。このバイパスを実現するには、次の 2 つの方法から選択できます。
クライアント Web アプリケーションはサードパーティの URL を認識し、その URL を HTTP リクエストのリクエスト パラメーターとして Ajax プロキシに渡します。その後、プロキシはリクエストを [url]www.jb51.net[/url] に転送します。 Web アプリケーション開発者が使用する Ajax ライブラリの実装では、プロキシ サーバーの使用を隠すことができることに注意してください。 Web アプリケーション開発者にとっては、同一生成元ポリシーがまったく存在しないように見えるかもしれません。
クライアント Web アプリケーションはサードパーティの URL を認識せず、HTTP 経由で Ajax プロキシ サーバー上のリソースにアクセスしようとします。 Ajax プロキシは、事前定義されたエンコード ルールを使用して、要求された URL をサードパーティ サーバーの URL に変換し、クライアントに代わってコンテンツを取得します。これにより、Web アプリケーション開発者はプロキシ サーバーと直接通信しているように見えます。

グリースモンキー

Greasemonkey は、ユーザーが Web ページのスタイルとコンテンツを動的に変更できるようにする Firefox 拡張機能です。 Greasemonkey ユーザーは、ユーザー スクリプト ファイルを URL のコレクションに関連付けることができます。これらのスクリプトは、ブラウザがこの URL セットからページを読み込むときに実行されます。 Greasemonkey は、ユーザー スクリプトの API に追加の権限を提供します (ブラウザ サンドボックスで実行されるスクリプトの権限と比較して)。

GM_XMLHttpRequest はこれらの API の 1 つであり、本質的には同一生成元ポリシーのない XMLHttpRequest です。ユーザー スクリプトはブラウザの組み込み XMLHttpRequest を GM_XMLHttpRequest でオーバーライドし、XMLHttpRequest がクロスドメイン アクセスを実行できるようにします。

GM_XMLHttpRequest の使用は、ユーザーの同意によってのみ保護できます。つまり、Greasemonkey は、新しいユーザー スクリプトと特定の URL コレクションとの間の関連付けを確立するときにのみユーザー構成を必要とします。ただし、一部のユーザーが結果を十分に理解せずにだまされてインストールを受け入れる可能性があることは想像に難くありません。

この記事が皆様の JavaScript プログラミング設計に役立つことを願っています。