Tweet

アーキテクチャ・ジャーナル ブラウザでのクロス・ドメイン通信のセキュリティ保護 Danny Thorpe 2009/04/20

Page1 Page2 Page3

■概要

　買い物客は、事実上どの店に入っても、プラスチックのカードと写真付きの身分証明書以外の何も持たずに商品を購入できます。買い物客と店主の通貨、国籍、言語が異なっていてもかまいません。彼らが共有するのは、グローバル通信システムおよびグローバル金融ネットワークです。これにより、買い物客はどこに行っても自分の銀行サービスを利用できます。また、店主にはインフラストラクチャ上のサポートが提供されます。では、Web サーファーとサイト管理者が情報を共有するための、同様な保護とサービスをインターネットで提供できるとしたら、どうなるでしょうか。

■

　Web ブラウザ内に常駐するアプリケーションの開発は、大通りでのウィンドウ ショッピングとよく似ています。すなわち、数多くの店から選択でき、各店のウィンドウで素敵な商品を数多く見ることができますが、それらを手にとって見ることはできません。ウィンドウのガラスに近づくたびに意地悪な継母 Frau Browser が、あなたの鎖を引っ張ります。これはあなたのためだと彼女は言いますが、短い鎖はあなたの安全のためではなく、彼女の便宜のためではないかとあなたは思い始めます。

　Web ブラウザでは、エンド ユーザーに関する各ページの情報がのぞき見られないように、別々のドメインに属するページが切り離されます。初期のインターネットでは、ブラウザ クライアントの重要なアプリケーション ロジックを配置したサイトは少なく、そのようなサイトでも独自のサーバーからのみデータにアクセスしていたため、この分離モデルに問題はありませんでした。各 Web サーバーは、外部のコンテンツへの HTML リンクのみを格納する独自のサイロでした。

　しかし、現在のインターネットは異なります。インターネット体験は、複数のドメインからのデータの集約へと変貌しました。このデータの集約は、サイトのカスタム化のほか、多様なデータ ソースの組み合わせで付加価値を提供するサイトによって促進されています。このような世界では、Web ブラウザのドメイン分離モデルはクライアント側の Web アプリケーション開発を妨げる大きな障害となります。この障害を避けるために、Web アプリケーション設計者は、とにかく仕事を片付けるためにサーバーの拡張性を犠牲にして、より多くのアプリケーション ロジックを Web サーバーに移動する傾向にあります。一方、エンド ユーザーの 2GHz、2GB のターミナルはアイドル状態になっています。

　パーソナル コンピュータが Web ブラウザのように構築されていたとすると、データはディスクに保存できますが、自分のマシン上でも、他のユーザーのマシン上でも、その他のアプリケーションでそれらのファイルを使用することはできません。ブランドの異なるフォト エディタに切り替えた場合、古い写真は編集できなくなります。古いフォト エディタのメーカーに苦情を言っても、「別のフォト エディタが古いデータをどのように扱うかはわからない。そのフォト エディタについて知らないし、信頼もしていないので、あなたも信頼しない方がいい。" あなた" の写真に保存スペースを提供しているのは弊社なので、それらの写真は実際には弊社の写真の一部ということになる。それらの写真を別のフォト エディタで使用させるわけにはいかない」と鼻であしらわれるでしょう。

　ファイルの作成に使用したアプリケーションがわからなければ、それらを見つけることもできません。「Stevie の誕生日の写真に使ったフォト エディタはどれだったかしら。写真が見つからない。」ということになります。

　また、そのフォト エディタが壊れた場合はどうなるでしょうか。あなたの写真もすべて道連れにされます。

　聞き覚えがあるでしょう。インターネットの Web サイトや Web アプリケーションを使用する私たちはみな経験していることです。ドメインを分離すると、ミュージック リストを使用して、自分の音楽プレーヤーのメーカーとは無関係の独立したオンライン ストアや、小売店内のキオスクで同様な曲を探すことはできません。

　ドメインを分離することにより、企業ネットワーク内のさまざまなデータ サーバーからのデータを処理する軽量の低インフラストラクチャ Web アプリケーションの構築が非常に難しくなります。内部の bar.com 企業ネット上の foo.bar.com サブドメインは、xyz.com のような外部アドレスから分離されているのと同様に、bar.com や bee.bar.com からも分離されています。

　それでも、すべての壁を取り壊して、すべてのソースを歓迎するわけにはいきません。ブラウザの厳重なドメイン分離ポリシーによって保護されるデータおよび個人のセキュリティに対する脅威は現実的で重大なものです。注意深い配慮とインフラストラクチャにより、必要なセキュリティ慣行を維持する中で、ユーザーにとっての利点の拡大にもつながる妥協案も実現できます。特定の Web サイトで使用可能な自分の個人情報の内容や量、およびそれをいつ使用可能にするかの制御は、ユーザーが行う必要があります。ここでの目的は、情報がすべての方向に自由に流れることではなく、保存場所にかかわらず、自分の目的にかなう時と場所に応じて自由に自分のデータを使用することです。

　必要なのは、エンド ユーザーの安全やそのデータの制御を損なうことなく、正当なクロス ドメイン データ アクセスをブラウザでサポートする方法です。

　その方向での 1 つの重要なステップは、Ian Hickson によってまとめられた開発規格の提案です。この提案では、リクエスト対象のサーバーによるドメインベースのオプトイン/ オプトアウトを使用して、クロス ドメイン接続をサポートするように xmlHttpRequest を拡張します (「参考資料」を参照)。これがピア レビューを経て、主要なブラウザで実装された場合、不正な使用から保護する一方で、正当な使用におけるクロス ドメインの障害を軽減することができます。現実的には、主要なブラウザでこの提案が実装され、現場でユビキタスになるまでには、何年もかかるでしょう。

　では今何ができるのでしょうか。すべてのブラウザによってサポートされる動作パターンがあります。これにより 1 つのブラウザ ドメインコンテキストに存在する JavaScript コードは、同じブラウザ インスタンス内の別のドメイン コンテキストに存在する JavaScript によって加えられた変更を確認できます。たとえば、iframe の幅または高さのプロパティに加えた変更は、iframe 内でもその外でも確認できます。さらに別の例としては、iframe.src プロパティがあります。iframe の外部のコードでは、iframe の src URL プロパティを読み取ることはできませんが、iframe の src URL に書き込むことはできます。したがって、iframe の外部のコードは、iframe の URL を介して iframe にデータを送信できます。

　この URL 手法は、HTML への iframe の最初の導入時から Web デザイナによって使用されていますが、その用途は一般的にプリミティブで目的志向なものであり、素早く構築されています。さらに、iframe src URL を介してデータを渡すと、セキュリティ上の弱点のベクトルが生成され、悪意のあるコードが iframe にゴミを投げ入れることにより、Web アプリケーションの状態を損なう可能性があります。ブラウザのどのコンテキストのどのコードでも、iframe の .src プロパティに書き込むことができ、受け取り側の iframe では URL データからのソースを知ることはできません。ほとんどの場合、ソースが不明なデータは信頼するべきではありません。

　この記事では、Windows Live Developer Platform グループによって開発された、セキュリティ保護されたクライアント側クロス ドメイン データ チャネルの問題とソリューション手法について検討します。

INDEX
	［アーキテクチャ・ジャーナル］
	ブラウザでのクロス・ドメイン通信のセキュリティ保護
	1．複数のドメインへのデータ・アクセスするときの問題
	2．問題を回避するソリューション手法
	3．送受信の手法／アイディアの応用／ユーザーのエンパワーメント

「アーキテクチャ・ジャーナル」

＠ITメールマガジン　新着情報やスタッフのコラムがメールで届きます（無料）