フロントエンドに必要なHTTPスキルの同源戦略の詳細

同源ポリシーはwebアプリケーションのセキュリティモデルにおいて重要な概念である.このポリシーの下で、webブラウザは最初のページのスクリプトが2番目のページのデータにアクセスすることを許可しますが、2つのページに同じソースがある場合だけです.ソースはURI,ホスト名,ポート番号を組み合わせたものである.このポリシーは、あるページ上の悪意のあるスクリプトが、ページのDOMオブジェクトを介して別のページ上の機密情報にアクセスする権限を得ることを阻止することができる.
このメカニズムは、クッキーメンテナンスライセンスユーザsessionに一般的に依存する現代のブラウザにとって特別な意味を持つ.クライアントは、データ機密または整合性の喪失を防ぐために、異なるサイトが提供するコンテンツ間で厳格な制限を維持する必要があります.
歴史
同源ポリシーの概念は1995年のネットビューブラウザに遡る.同源ポリシーは重要なセキュリティ基盤として、すべての現代ブラウザが同源ポリシーをある程度実現しています.同源ポリシーは明確な仕様ではありませんが、Microsoft Silverlight、Adobe Flash、Adobe AcrobatなどのWebテクノロジーやXMLfttpRequestなどのメカニズムの拡張のために、ほぼ互換性のあるセキュリティ境界を定義することがよくあります.
ソース決定ルール
RFC 6454にはURIソースを定義するアルゴリズム定義がある.絶対的なURIsの場合、ソースは{プロトコル、ホスト、ポート}で定義されます.これらの値が完全に同じである場合にのみ、2つのリソースが同源であると考えられます.
例として、下記の表は、URL "http://www.example.com/dir/page.html"との比較を示している.
比較URL
結果
結果http://www.example.com/dir/page2.html
どうげん
同じプロトコル、ホスト、ポートhttp://www.example.com/dir2/other.html
どうげん
同じプロトコル、ホスト、ポートhttp://username:[email protected]/dir2/other.html
どうげん
同じプロトコル、ホスト、ポートhttp://www.example.com:81/dir/other.html
異なったソース
同じプロトコル、ホスト、ポートが異なるhttps://www.example.com/dir/other.html
異なったソース
プロトコルが異なるhttp://en.example.com/dir/other.html
異なったソース
異なるホストhttp://example.com/dir/other.html
異なったソース
異なるホスト(正確な一致が必要)http://v2.www.example.com/dir/other.html
異なったソース
異なるホスト(正確な一致が必要)http://www.example.com:80/dir/other.html
状況を見る
ポートが明確で、ブラウザに依存して実現
他のブラウザとは異なり、IEはソースを計算する際にポートを含まない.
安全を考える
このような制限の主な原因は、同源ポリシーがない場合、セキュリティリスクを引き起こすことです.ユーザーが銀行のウェブサイトにアクセスし、ログインしていないと仮定します.そして彼はまた任意の他のウェブサイトに行って、ちょうどこのウェブサイトに悪意のあるjsコードがあって、バックグラウンドで銀行のウェブサイトの情報を要求しました.ユーザーは現在も銀行サイトのログイン状態であるため、悪意のあるコードは銀行サイトで任意のことをすることができます.たとえば、最近の取引記録を取得したり、新しい取引を作成したりします.ブラウザは、銀行サイトドメイン上で銀行サイトを受信するsession cookiesを送信することができるからです.悪意のあるサイトにアクセスしたユーザーは、アクセスしたサイトに銀行サイトのクッキーにアクセスする権限がないことを望んでいます.もちろんそうです.jsは銀行サイトのsession cookieを直接取得することはできませんが、銀行サイトに銀行サイトのsession cookie付きのリクエストを受信することができます.本質的には通常のユーザーが銀行サイトにアクセスするようにします.送信された新しい取引については、銀行サイトのCSRF(駅をまたいで偽造を要求する)保護も無力であり、スクリプトは正常なユーザーのような行為を簡単に実現することができるからだ.セッションが必要な場合やログインが必要な場合は、すべてのサイトがこの問題に直面します.上記の例の銀行サイトが公開データだけを提供している場合、任意のものをトリガーすることはできません.これは危険ではありません.これらは同源戦略で保護されています.もちろん、2つのサイトが同じ組織であるか、互いに信頼している場合は、このような危険はありません.
同源ポリシーの回避
場合によっては、同源ポリシーが厳しすぎて、複数のサブドメインを持つ大規模なWebサイトに問題が発生します.次は、この問題を解決するためのテクノロジーです.
document.domainプロパティ
2つのwindowまたはframesに含まれるスクリプトがdomainを同じ値に設定できる場合、同じソースポリシーを回避することができ、各window間で相互にコミュニケーションすることができます.たとえば、orders.example.comの下のページのスクリプトとcatalog.example.comの下のページのスクリプトは、document.domainのプロパティをexample.comに設定することができ、2つのサイトの下のドキュメントが同じソースの下にあるように見え、各ドキュメントに別のドキュメントのプロパティを読み込むことができます.この方法は、ポート番号が内部に保存されているため、nullに保存される可能性があります.すなわち、example.comのポート番号80は、document.domainのプロパティを更新するとnullになる可能性があります.nullのポートは80と見なされない可能性があります.これは主にブラウザに依存して実現されます.
ドメイン間リソース共有
この方式は、新しいOrigin要求ヘッダと、新しいAccess-Control-Allow-Origin応答ヘッダとを使用してHTTPを拡張する.サービス側設定Access-Control-Allow-Originヘッダは、どのサイトがファイルを要求できるかを識別するか、またはAccess-Control-Allow-Originヘッダが「*」に設定され、任意のサイトがファイルにアクセスできるようにします.ブラウザ、例えばFirefox 3.5、Safari 4、IE 10は、このヘッダを使用して、ドメイン間HTTP要求を許可する.
ドキュメント間通信
この方法では、スクリプトがドメインをまたいでいるかどうかにかかわらず、1つのページのスクリプトが別のページのスクリプトにテキスト情報を送信することができます.1つのwindowオブジェクト上でpostMessage()を呼び出すと、window上のonmessageイベントが非同期でトリガーされ、定義されたイベント処理方法がトリガーされます.1つのページのスクリプトは、別のページのメソッドや変数に直接アクセスできませんが、メッセージングテクノロジーを介して安全にコミュニケーションできます.
JSONP
JOSNPは、ページが別のドメインのJSONデータを受け取ることを許可し、ページにコールバックJSON応答付きのラベルを のドメインからロードできるようにする.
WebSocket
のブラウザでは、スクリプトを ポリシーに なくWebSocketアドレスに できます.しかしながら、WebSocket URIを する 、 にOriginヘッダを することで、スクリプト のソースを することができる.WebSocketサーバは、クロスステーションのセキュリティを するために、リクエストを するホワイトリストのソースリストに づいてヘッダデータを する があります.
ケースおよび
いくつかの では、ホスト またはポートを に していないプロトコル(file:,data:,など)、 チェック、および メカニズムがどのように するかについては、あまり されていません.これは、 のローカルに されたHTMLファイルがディスク の のファイルにアクセスできず、ネットワーク のサイトと できないなど、 に くのセキュリティ を き こしています.
さらに、のドメイン およびフォームPOST など、 は ポリシーによって されていなかった くの されたドメイン が されている.
に、DNS バインド、サービス・エンド・エージェントなど、いくつかのタイプの は、アドレスが ではないにもかかわらず、ヤクザ・ページがアドレスを してサイトと できるように、ホスト チェックを することができます.このような の は、 えば、ブラウザが の のサイトを じている 、 クッキーまたは の を に していない に られる.

が な に ポリシーを できるようにするために、fragment identifier、window.nameプロパティなどの なるドメインのドキュメント でデータを するために、いくつかの「hacks」メソッドを することができる.HTML 5 によれば、postMessageインタフェースはこのような を することができるが、 のブラウザでのみサポートされている.JSONPは、Ajaxのような でドメイン リソースにアクセスすることを するためにも できます.
フロントエンドの をしっかりと うには、HTTPに する を しなければならないので、 はフロントエンドに なHTTPスキルを して、フロントエンドに するHTTPの を して、 して、 を します.
PS: はウィキペディアから して、 の https://en.wikipedia.org/wiki/Same-origin_policy