SOP（Same Origin Policy）の本当の意味とは？
これは、あるオリジンの Javascript コードが別のオリジンのリソースにアクセスできないことを意味します。しかし、「リソース」という言葉は正確には何を意味するのでしょうか? 例えば：
ただし、JSON パディングを使用すると、パディングされたスクリプト タグの読み込みが完了した後、サード パーティのスクリプトが指定されたコールバックを呼び出します。あるサイトの Javascript コードが、別のサイトの Javascript コードのメソッドを呼び出しています。これは SOP に違反しますか?
いくつかのタイプがありますが、指定しない場合:
SOP は、JavaScript やその他のスクリプト言語がドメイン全体で DOM のプロパティやメソッドにアクセスする機能を管理するメカニズムを指します。
ここには、さまざまなタイプの SOP の優れた説明があります。
Same Origin Policy は主に、ロードされたドメインのコンテキストで他のドメインのスクリプトが AJAX (XMLHTTP) 要求を実行するのを防ぎ、他のドメインのサイトが Cookie やローカル ストレージなどのサイト リソースにアクセスすることを制限することを目的としています。セキュリティ対策のために策定された仕様であり、ブラウザごとに仕様に準拠した独自の実装方法があります。
「他のドメインのスクリプトが AJAX (XMLHTTP) リクエストを実行するのを防ぐ」とは、同じドメインに属さないクロスオリジン リクエストを意味します。
たとえば、domain.com と test.domain.com は同じドメインに属し、test はサブドメインですが、test.domain2.com はまったく異なるドメインに属します。
それでは、そのセキュリティへの影響を考えてみましょう:-
1. Web サイト site1.com に、パスワードを更新するための API 呼び出しがあるとします。ユーザーが必要なデータを入力すると、バックエンドに対して HTTP 呼び出しが行われ、Cookie に含まれるセッション データを使用してユーザーの認証が検証されます。
2) 攻撃者が site2 という名前のサイトを作成し、site1 のパスワード変更エンドポイントへの HTTP 呼び出しを行うための JavaScript コードを持っているとします。ブラウザのデフォルトの動作では、site1 用に持っているすべての Cookie データをリクエストに添付します。これにより、HTTP 呼び出しが成功し、攻撃者が成功する可能性があります。
3) このブラウザ実装の SOP を緩和できるようにするため、許可するように指示されない限り、たとえば、site2 から site1 へのクロスドメインへのリクエストをブロックするようにブラウザの JavaScript エンジンに指示します。
4) 現在、マイクロサービス アーキテクチャと複数のサブドメインを備えたこの成長している現代の世界では、これは非常に問題になります。このブラウザは、Access-Control-Allow-Origin、Access-Control-Allow-Methods、Access-Control-Allow-Credentials などのヘッダーを使用して API 応答でクロスオリジン要求がサポートされている場合、この問題を回避できます。
5) サイト 2 からサイト 1 への ajax 要求が行われたときにそれを進めるために、ブラウザーは API 応答ヘッダーをチェックし、応答にこれらの値のいずれかが存在する場合に要求を許可します:- Access-Control-Allow-Origin:* または Access -Control-Allow-Origin:site2.com または Access-Control-Allow-Origin:*.site2.com (ワイルドカード エントリ)
6) とはいえ、ここには大きな抜け穴があります。たとえ sop ポリシーがリクエストをブロックしたとしても、実際にはブラウザがサイト 2 アクセスをブロックして応答データを読み取ることを意味し、リクエストがサーバーに対して既に行われたことを意味します。このシナリオは、プリフライト オプションの呼び出しをトリガーしない特定の条件でのいくつかの要求にのみ適用されます。オプション コールが行われると、ブラウザは、オプション コールのヘッダー応答に基づいて、リクエストの通過を許可しません。
7) 次に、2 番目の部分である Access-Control-Allow-Credentials に進みます。オプション呼び出しに対するサーバー応答で、サーバーが Authorization ヘッダーなどのすべての機密セッション データのヘッダーを true に設定すると、サイト 2 からサイト 1 へのクロスオリジン リクエストにセキュア Cookie が追加されます。
注:- このヘッダーは、Access-Control-Allow-Origin がドメインに非常に固有である場合にのみ追加されます。つまり、ヘッダーの * 値では機能しません。Access-Control-Allow-Origin ヘッダーが * の場合、ブラウザーの SOP ポリシーが開始され、Access-Control-Allow-Credentials が true に設定されている場合、安全なデータの許可がブロックされます。
SOP オリジン ポリシーは、イメージ ソースと外部スクリプト インクルードを扱いません。それらを制御できるようにするには、コンテンツ セキュリティ ポリシー (CSP) を使用します。それを使用すると、画像、スクリプト、フォント、スタイルなどの外部サイトへのアクセスを制御できます。また、警告ボックスのようなサイト内の安全でないインライン eval をブロックして、一部の XSS 攻撃を防ぐこともできます。これは新しい事実上の標準であり、多くの Web サイトが実装を開始しています。
このような攻撃 (CSRF 攻撃) を防ぐために、Web サイトは、状態が変化するたびに変化するフォームと共に csrf-token も実装しています。攻撃者が何らかの方法でサイト 2 からサイト 1 にリクエストを行ったとしても、サイト 1 のサーバーがリクエストと共に csrf トークンを検証するため、リクエストは通過しません。攻撃者はこれを介してアクセスできません。オリジンヘッダーが存在する場合、他の手段はオリジンベースの検証を追加します。
JSONP は、コールバックを通じてこのようなメカニズムを可能にするように設計されています。
非常に長い回答で申し訳ありません。トピックはこれよりもはるかに大きくなります。これは私自身の理解であり、どこかで間違っている場合はお知らせください。
JSONP は、動的にスクリプト タグを DOM に追加し、リモート Web サービスの JSON データをパラメーターとして使用して事前定義された関数を呼び出すことにより、Same Origin ポリシーを回避します。タグは同一オリジン ポリシーの対象ではないため、クロスドメインのコンテンツをリクエストできます。
Google のバージョンのjQueryをサイトで SOP に違反せずに使用する方法と同じように、Web サービスから返されるデータで事前定義された関数を呼び出すスクリプト タグを「含める」ことができます。