(57)【要約】【課題】ウェブアプリケーション上の脆弱性などを良好に防止する。【解決手段】処理部は、複数の処理データから選択された所定の処理データに基づいて情報処理を行う。制御部は、処理部の動作を制御する。この場合、制御部は、所定の処理データに関連付けされたセキュリティ制約に基づいて、制御を行う。例えば、処理部はウェブブラウザであり、処理データは、ドキュメントオブジェクトモデルを構成するオブジェクトである。例えば、セキュリティ制約は、オブジェクトに属性として与えられるか、セキュリティオブジェクトにより定義されるか、あるいはＨＴＴＰヘッダにより定義される、などである。【選択図】図３
2013125497.tif 000002
【特許請求の範囲】
【請求項１】
複数の処理データから選択された所定の処理データに基づいて情報処理を行う処理部と、
上記所定の処理データに関連付けされたセキュリティ制約に基づいて上記処理部の動作を制御する制御部とを備える
情報処理装置。
【請求項２】
上記処理部は、ウェブブラウザであり、
上記処理データは、ドキュメントオブジェクトモデルを構成するオブジェクトである
請求項１に記載の情報処理装置。
【請求項３】
上記セキュリティ制約は、上記オブジェクト内へのスクリプトの挿入権限である
請求項２に記載の情報処理装置。
【請求項４】
上記セキュリティ制約は、上記オブジェクト内のスクリプトの実行可能権限である
請求項２に記載の情報処理装置。
【請求項５】
上記セキュリティ制約は、リクエストに関する制限である
請求項２に記載の情報処理装置。
【請求項６】
上記セキュリティ制約は、スクリプトのアクセス可能なオブジェクトまたはアクス不可能なオブジェクトの指定である
請求項２に記載の情報処理装置。
【請求項７】
上記セキュリティ制約は、アプリケーション・プログラミング・インタフェースへのアクセス権限である
請求項２に記載の情報処理装置。
【請求項８】
上記セキュリティ制約は、異なる生成元からのオブジェクトの参照あるいは変更のリクエストのポリシー変更である
請求項２に記載の情報処理装置。
【請求項９】
上記セキュリティ制約は、子オブジェクトも含めたヒープ使用量の上限である
請求項２に記載の情報処理装置。
【請求項１０】
上記セキュリティ制約は、子オブジェクトも含めたオブジェクト数の上限である
請求項２に記載の情報処理装置。
【請求項１１】
上記セキュリティ制約は、上記オブジェクトに設定できる文字列長の上限である
請求項２に記載の情報処理装置。
【請求項１２】
上記セキュリティ制約は、上記オブジェクトに属性として与えられる
請求項２に記載の情報処理装置。
【請求項１３】
上記セキュリティ制約は、クラスで指定される
請求項１２に記載の情報処理装置。
【請求項１４】
上記セキュリティ制約は、セキュリティオブジェクトにより定義される
請求項２に記載の情報処理装置。
【請求項１５】
上記セキュリティ制約の指定のないオブジェクトのセキュリティ制約として、親からのセキュリティ制約を引き継ぐ
請求項２に記載の情報処理装置。
【請求項１６】
所定のオブジェクト内のスクリプトが他のオブジェクト内のスクリプトを呼び出して実行する場合、該所定のオブジェクトのセキュリティ制約を引き継ぐ
請求項２に記載の情報処理装置。
【請求項１７】
ＨＴＴＰヘッダにより上記セキュリティ制約を指定する
請求項２に記載の情報処理装置。
【請求項１８】
上記セキュリティ制約は、所定の条件に応じて動的に変化する
請求項２に記載の情報処理装置。
【請求項１９】
複数の処理データから選択された所定の処理データに基づいて情報処理を行う処理ステップと、
上記所定の処理データに関連付けされたセキュリティ制約に基づいて上記処理ステップ得の動作を制御する制御ステップとを備える
情報処理方法。
【請求項２０】
コンピュータを、
複数の処理データから選択された所定の処理データに基づいて情報処理を行う処理手段と、
上記所定の処理データに関連付けされたセキュリティ制約に基づいて上記処理手段の動作を制御する制御手段と
して機能させるプログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本技術は、情報処理装置、情報処理方法およびプログラムに関し、特に、ウェブアプリケーション上の脆弱性などを防ぐようにした情報処理装置、情報処理方法およびプログラムに関する。
【背景技術】
【０００２】
近年、ネットワークを介してホームページの閲覧やメールの送受信を行うウェブ（Ｗｅｂ）システムが広く利用されている（例えば、特許文献１参照）。ウェブアプリケーションは、スクリプトコードを利用したリッチクライアント技術などの技術進歩と、クライアント装置にウェブブラウザがインストールされていれば簡単に実行できる簡便さから、ビジネス用途を含め、さまざまな分野で利用されている。ウェブアプリケーションは、クライアント装置とサーバ装置がネットワークで接続された、クライアント・サーバ型のウェブシステム上で動作する。
【０００３】
ウェブアプリケーションでは、ウェブアプリケーションあるいはサーバ上のプログラムのエスケープ忘れ等のバグが存在した場合、（１）悪意のある任意のスクリプトがウェブブラウザ上で動く、（２）悪意のあるリクエストをサーバに送る、などのような脆弱性につながる。これは、ウェブアプリケーションの僅かなバグによって、ユーザは,アカウントの乗っ取り、個人情報の漏洩等の被害を受けることを意味する。
【０００４】
現状では、上述の脆弱性による被害を防ぐために、ウェブブラウザ上で動くウェブアプリケーションおよびサーバ上のプログラムを検証し、バグを取り除くことで対処している。例えば、（１）エスケープ漏れがないかの確認、（２）必ずサーバとの通信にはワンタイムトークンを使っているかの確認等である。あるいは、クライアント側やサーバ側で攻撃や情報漏洩の可能性のあるリクエストかをチェックする仕組みが考えられる。
【先行技術文献】
【特許文献】
【０００５】
【特許文献１】特開２０１０−１２８８７７号公報
【発明の概要】
【発明が解決しようとする課題】
【０００６】
しかし、プログラムをどれだけ検証しても、現実にはバグが発見され脆弱性が露呈することが後を絶たない。また、ウェブアプリケーションは年々規模を拡大し複雑化していることから、バグの発見はより困難になると予想される。そのことを踏まえると、ウェブアプリケーションにはバグが必ずある前提で、ウェブブラウザがそのバグから利用者を守る必要がある。しかし、従来の技術ではそれに該当するものはなかった。
【０００７】
本技術の目的は、ウェブアプリケーション上の脆弱性などを良好に防止可能とすることにある。
【課題を解決するための手段】
【０００８】
本技術の概念は、
複数の処理データから選択された所定の処理データに基づいて情報処理を行う処理部と、
上記所定の処理データに関連付けされたセキュリティ制約に基づいて上記処理部の動作を制御する制御部とを備える
情報処理装置にある。
【０００９】
処理部により、複数の処理データから選択された所定の処理データに基づいて情報処理が行われる。制御部により、処理部の動作が制御される。この場合、所定の処理データに関連付けされたセキュリティ制約に基づいて、制御が行われる。ここで、例えば、処理部はウェブブラウザであり、処理データは、ドキュメントオブジェクトモデルを構成するオブジェクトであってもよい。本技術においては、ウェブアプリケーション上の脆弱性などを良好に防止できる。
【００１０】
例えば、セキュリティ制約は、オブジェクト内へのスクリプトの挿入権限であってもよい。また、例えば、セキュリティ制約は、オブジェクト内のスクリプトの実行可能権限であってもよい。また、例えば、セキュリティ制約は、リクエストに関する制限であってもよい。また、例えば、セキュリティ制約は、スクリプトのアクセス可能なオブジェクトまたはアクス不可能なオブジェクトの指定であってもよい。
【００１１】
また、例えば、セキュリティ制約は、アプリケーション・プログラミング・インタフェースへのアクセス権限であってもよい。また、例えば、セキュリティ制約は、異なる生成元からのオブジェクトの参照あるいは変更のリクエストのポリシー変更であってもよい。また、例えば、セキュリティ制約は、子オブジェクトも含めたヒープ使用量の上限であってもよい。また、例えば、セキュリティ制約は、子オブジェクトも含めたオブジェクト数の上限であってもよい。また、例えば、セキュリティ制約は、オブジェクトに設定できる文字列長の上限であってもよい。
【００１２】
例えば、セキュリティ制約は、オブジェクトに属性として与えられてもよい。その場合、セキュリティ制約は、クラスで指定されてもよい。また、例えば、セキュリティ制約は、セキュリティオブジェクトにより定義されてもよい。また、例えば、セキュリティ制約の指定のないオブジェクトのセキュリティ制約として、親からのセキュリティ制約を引き継ぐようにされてもよい。
【００１３】
また、例えば、所定のオブジェクト内のスクリプトが他のオブジェクト内のスクリプトを呼び出して実行する場合、この所定のオブジェクトのセキュリティ制約を引き継ぐようにされてもよい。また、例えば、ＨＴＴＰヘッダによりセキュリティ制約を指定するようにされてもよい。また、例えば、セキュリティ制約は、所定の条件に応じて動的に変化するようにされてもよい。
【発明の効果】
【００１４】
本技術によれば、ウェブアプリケーション上の脆弱性などを良好に防止できる。
【図面の簡単な説明】
【００１５】
【図１】実施の形態としてのウェブシステムの構成例を示すブロック図である。
【図２】ウェブブラウザの構成例を示すブロック図である。
【図３】スクリプトエンジンの処理の流れの一例を概略的に示すフローチャートである。
【図４】ＤＯＭのオブジェクトに与えられるセキュリティ制約がオブジェクト内へのスクリプトの挿入権限である場合について説明するための図である。
【図５】ＤＯＭのオブジェクトに与えられるセキュリティ制約がオブジェクト内のスクリプトの実行可能権限である場合について説明するための図である。
【図６】ＤＯＭのオブジェクトに与えられるセキュリティ制約がオブジェクト内のスクリプトの実行可能権限である場合（スクリプトを介して“div要素”が操作される場合）について説明するための図である。
【図７】ＤＯＭのオブジェクトに与えられるセキュリティ制約がリクエストに関する制限である場合について説明するための図である。
【図８】ＤＯＭのオブジェクトに与えられるセキュリティ制約がスクリプトのアクセス可能なオブジェクトまたはアクス不可能なオブジェクトの指定である場合について説明するための図である。
【図９】セキュリティ制約を、各オブジェクトに属性として与える場合におけるセキュリティ制約の書き方例（例１）を示す図である。
【図１０】セキュリティ制約を、各オブジェクトに属性として与える場合におけるセキュリティ制約の書き方例（例２）を示す図である。
【図１１】セキュリティ制約をクラス指定で間接的に指定する場合、ＤＯＭにセキュリティクラスを定義するオブジェクトが設けられることを説明するための図である。
【図１２】セキュリティ制約を、ＨＴＴＰヘッダで指定する場合におけるセキュリティ制約の書き方例（例３）を示す図である。
【図１３】スクリプトエンジンの処理の流れの一例（セキュリティ制約の動的変化）を概略的に示すフローチャートである。
【発明を実施するための形態】
【００１６】
以下、発明を実施するための形態（以下、「実施の形態」とする）について説明する。なお、説明を以下の順序で行う。
１．実施の形態
２．変形例
【００１７】
＜１．実施の形態＞
［ウェブシステム］
図１は、実施の形態としてのウェブシステム１００の構成例を示している。このウェブシステム１００は、ウェブブラウザを含むクライアント装置１１０と、サーバ装置１２０ａ，１２０Ｂとが、ネットワーク１３０を介して接続されて構成されている。クラインアント装置１１０とサーバ装置１２０Ａ，１２０Ｂとは互いに通信を行う。
【００１８】
このウェブシステム１００は、一般的なネットワークレベルでは既存のシステムと異なる点はない。ウェブブラウザは、サーバ装置１２０Ａからページを読込み、表示する。その際に、他のサーバ装置１２０Ｂからリソースを取得することも含む。また、ウェブブラウザは、表示した後もスクリプトによって継続してサーバ装置１２０Ａ，１２０Ｂとのアクセスが発生するシステムも含む。
【００１９】
図２は、ウェブブラウザの構成例を示している。ウェブブラウザは、画面やスクリプト等のオブジェクトから構成されるドキュメントオブジェクトモデル（ＤＯＭ：Document Object Model）と、スクリプトエンジンからなる。ウェブブラウザは、ページや画像をロードする。また、ウェブブラウザは、スクリプトから呼ばれるアプリケーション・プログラミング・インタフェース（ＡＰＩ：Application Programming Interface）により、サーバ装置へリクエストを出し、サーバ装置からレスポンスを受け取る。
【００２０】
この実施の形態では、ＤＯＭの各オブジェクトにセキュリティ制約が与えられる。そして、スクリプトエンジンがスクリプトを実行する際に、その制約を満たしているかが検証され、満たしていない場合に、特殊な動作に移行するようにされる。
【００２１】
図３のフローチャートは、スクリプトエンジンの処理の流れの一例を概略的に示している。スクリプトエンジンは、ステップＳＴ１において、処理を開始する。そして、スクリプトエンジンは、ステップＳＴ２において、スクリプトの実行が指示されたか否かを判断する。スクリプトの実行が指示されたとき、スクリプトエンジンは、ステップＳＴ３において、セキュリティ制約を満たしているか否かを判断する。
【００２２】
セキュリティ制約を満たしているとき、スクリプトエンジンは、ステップＳＴ４において、スクリプトを実行する。スクリプトエンジンは、このステップＳＴ４の処理の後、ステップＳＴ５において、処理を終了する。一方、ステップＳＴ３でセキュリティ制約を満たしていないとき、スクリプトエンジンは、ステップＳＴ６において、スクリプトを実行する代わりに、特殊な動作、例えば、エラー箇所やその原因を示すエラーダイアログを出す等する。スクリプトエンジンは、このステップＳＴ６の処理の後、ステップＳＴ５におおいて、処理を終了する。
【００２３】
次に、セキュリティ制約、セキュリティ制約の指定方法、ウェブブラウザの動作などを具体的に説明していく。
【００２４】
［セキュリティ制約］
ＤＯＭのオブジェクトに与えられるセキュリティ制約として、例えば、以下が挙げられる。
【００２５】
（１）オブジェクト内へのスクリプトの挿入権限
ＤＯＭのオブジェクトに与えられるセキュリティ制約を、オブジェクト内へのスクリプトの挿入権限とすることができる。この場合、例えば、攻撃スクリプトを含んだ投稿などのオブジェクトへの挿入を防止できる。
【００２６】
図４は、ＤＯＭのオブジェクトに与えられるセキュリティ制約がオブジェクト内へのスクリプトの挿入権限である場合について示している。最初に、セキュリティ制約が与えられていない場合の動作例を説明する。（１）アタッカ（attacker）は、サーバに、攻撃スクリプトを含んだ投稿を送る。（２）クライアント（client）は、サーバ（server）から、この攻撃スクリプトを含んだ投稿を受信する。（３）クライアントでは、この攻撃スクリプトを含んだ投稿がＤＯＭ上に配置される。（４）そして、この攻撃スクリプトが実行される。
【００２７】
ＤＯＭのオブジェクトに、セキュリティ制約として、オブジェクト内へのスクリプトの挿入権限が与えられる場合には、挿入される“div要素”にスクリプトの挿入権限が無ければ、上述の（３）の段階で攻撃スクリプトの挿入を防止でき、攻撃スクリプトの実行を阻止できる。
【００２８】
（２）オブジェクト内のスクリプトの実行可能権限
ＤＯＭのオブジェクトに与えられるセキュリティ制約を、オブジェクト内のスクリプトの実行可能権限とすることができる。この場合、例えば、攻撃スクリプトの実行を阻止できる。
【００２９】
図５は、ＤＯＭのオブジェクトに与えられるセキュリティ制約がオブジェクト内のスクリプトの実行可能権限である場合について示している。最初に、セキュリティ制約が与えられていない場合の動作例を説明する。（１）アタッカ（attacker）は、サーバに、攻撃スクリプトを含んだ投稿を送る。（２）クライアント（client）は、サーバ（server）から、この攻撃スクリプトを含んだ投稿を受信し、表示する。（３）攻撃スクリプトが、実行される。
【００３０】
ＤＯＭのオブジェクトに、セキュリティ制約として、オブジェクト内のスクリプトの実行可能権限が与えられる場合には、挿入される“div要素”にスクリプトの実行可能権限が無ければ、上述の（３）の段階における攻撃スクリプトの実行を阻止できる。
【００３１】
図６も、ＤＯＭのオブジェクトに与えられるセキュリティ制約がオブジェクト内のスクリプトの実行可能権限である場合について示している。この場合は、スクリプトを介して“div要素”が操作される場合を示している。最初に、セキュリティ制約が与えられていない場合の動作例を説明する。（１）アタッカ（attacker）は、サーバに、攻撃スクリプトを含んだ投稿を送る。（２）クライアント（client）は、サーバ（server）から、この攻撃スクリプトを含んだ投稿を受信する。（３）クライアントにおいて、攻撃スクリプトを含んだ投稿がＤＯＭ上に配置される。（４）そして、攻撃スクリプトが、実行される。
【００３２】
ＤＯＭのオブジェクトに、セキュリティ制約として、オブジェクト内のスクリプトの実行可能権限が与えられる場合には、挿入される“div要素”にスクリプトの実行可能権限が無ければ、上述の（４）の段階における攻撃スクリプトの実行を阻止できる。
【００３３】
（３）リクエスト制限
ＤＯＭのオブジェクトに与えられるセキュリティ制約を、リクエストに関する制限（クッキー（cookie）等の情報の送出許可）とすることができる。この場合、例えば、攻撃リンクからサーバへのクッキー（cookie）付きのリクエストの送信を防止できる。
【００３４】
図７は、ＤＯＭのオブジェクトに与えられるセキュリティ制約がリクエストに関する制限である場合について示している。ここでは、認証が必要なメール（Mail）やソーシャル・ネットワーキング・サービス（ＳＮＳ：Social NetworkService）を想定している。
【００３５】
最初に、セキュリティ制約が与えられていない場合の動作例を説明する。（１）アタッカ（attacker）は、サーバに、攻撃リンクを含んだ投稿を送る。（２）クライアント（client）は、サーバ（server）から、この攻撃リンクを含んだ投稿を受信し、攻撃リンクも表示する。（３）クライアントにおいて、攻撃リンクをユーザが踏むと、（４）クライアントからサーバにリクエストが飛ぶ。このとき、クライアントはサーバにクッキー（cookie）も送る。そのため、クライアントのユーザの権限でサーバの状態を変更できる（投稿や削除、設定変更が可能）。
【００３６】
ＤＯＭのオブジェクトに、セキュリティ制約として、リクエストに関する制限が与えられる場合には、投稿が表示される“div要素”にクッキー（cookie）を送る権限が無ければ、攻撃リンクを何の効力も持たないものとできる。
【００３７】
（４）スクリプトのアクセス可能／不可能オブジェクトの指定
ＤＯＭのオブジェクトに与えられるセキュリティ制約を、スクリプトのアクセス可能なオブジェクトまたはアクス不可能なオブジェクトの指定とすることができる。この場合、例えば、攻撃スクリプトがクッキー（cookie）を取得することを阻止でき、また、例えば、攻撃スクリプトが取得した情報をＡＰＩで攻撃者のサーバに送信することを阻止できる。
【００３８】
図８は、ＤＯＭのオブジェクトに与えられるセキュリティ制約がスクリプトのアクセス可能なオブジェクトまたはアクス不可能なオブジェクトの指定である場合について示している。最初に、セキュリティ制約が与えられていない場合の動作例を説明する。
【００３９】
（１）クライアント（client）は、サーバ（server）から、コンテンツを読み込む。（２）外部サーバ（hacked server）がハック（hack）され、攻撃スクリプトを含んだライブラリに差し替えられ、それがクライアントに読み込まれる。（３）クライアントにおいて、攻撃スクリプトが実行され、攻撃スクリプトはセッション情報や個人情報を取得する。（４）そして、攻撃スクリプトは、取得した情報を攻撃者のサーバ（attacker sever）に送る。
【００４０】
ＤＯＭのオブジェクトに、セキュリティ制約として、スクリプトのアクセス可能なオブジェクトまたはアクス不可能なオブジェクトの指定が与えられる場合には、クッキー（cookie）等へのアクセス権限が制限されていれば、攻撃スクリプトによる、クッキー（cookie）等の取得を阻止できる。また、この場合には、使用可能なＡＰＩが制限されていれば、攻撃スクリプトが、攻撃者のサーバへ取得した情報を送信すること阻止できる。
【００４１】
（５）その他のセキュリティ制約
ＤＯＭのオブジェクトに与えられるセキュリティ制約を、ＡＰＩへのアクセス権限とすることができる。ただし、ＡＰＩもオブジェクトとして定義される場合は、上述の「（４）スクリプトのアクセス可能／不可能オブジェクトの指定」の項目と等価となる。
【００４２】
また、ＤＯＭのオブジェクトに与えられるセキュリティ制約を、ＳＯＰ（SameOrigin Policy）やＣＯＲＳ（Cross-Origin Resource Sharing)）等のリクエストのポリシーの変更とすることができる。ここで、ＳＯＰとは、異なる生成元からのオブジェクトの参照や変更を禁止する仕組みであり、ＣＯＲＳとは、異なる生成元からオブジェクトの参照や変更を可能にする仕組みである。
【００４３】
また、ＤＯＭのオブジェクトに与えられるセキュリティ制約を、子オブジェクトも含めたヒープ使用量の上限とすることができる。また、ＤＯＭのオブジェクトに与えられるセキュリティ制約を、子オブジェクトも含めたオブジェクト数の上限とすることができる。さらに、ＤＯＭのオブジェクトに与えられるセキュリティ制約を、オブジェクトの各アトリビュート等に設定できる文字列長の上限とすることができる。
【００４４】
また、ＸＨＲ（XML Http Request）以外にも、“img”や“iframe”等による外部へのリクエスト先のドメインやポートで制約することもできる。
【００４５】
［セキュリティ制約の指定方法］
次に、セキュリティ制約の指定方法（書き方）について説明する。
【００４６】
（１）各オブジェクトに属性として与える
セキュリティ制約を、各オブジェクトに属性として与えることができる。図９は、その場合における、セキュリティ制約の書き方例（例１）を示している。図１０も、その場合におけるセキュリティ制約の書き方例（例２）を示している。図９の例の場合には、要素にセキュリティ制約を直接指定するが、図１０の例の場合には、要素にセキュリティクラスを指定し、セキュリティ制約を間接的に指定する。図１０の例の場合、図１１に示すように、ＤＯＭ上にセキュリティクラスを定義するオブジェクトが設けられることになる。
【００４７】
（２）セキュリティオブジェクトによる定義
各オブジェクトのセキュリティ制約を、セキュリティオブジェクトにより定義することができる。この場合、ＨＴＭＬの中にセキュリティ制約を列挙したオブジェクトが定義され、オブジェクト生成時にどのようなセキュリティ制約を与えるかが決定される。
【００４８】
（３）ＨＴＴＰヘッダによる指定
各オブジェクトのセキュリティ制約を、ＨＴＴＰヘッダで指定することができる。この場合、セキュリティオブジェクトの定義を書くことができる。あるいは、ヘッダでのみスクリプトを実行可能といった簡易的な指定を行うことができる。図１２は、その場合におけるセキュリティ制約の書き方例（例３）を示している。この場合、ヘッダ（head）タグのみでのスクリプト（script）の実行を許可する。１行で指定するため、複雑な指定はできない。フォーム（Form）の中でのスクリプト（script）の実行禁止など、攻撃の対象となる場所をピンポイントに潰す指定が主になる。
【００４９】
（４）親からのセキュリティ制約の引き継ぎ
セキュリティ制約の指定のないオブジェクトのセキュリティ制約を、親のセキュリティ制約を引き継ぐようにすることもできる。このように親からのセキュリティ制約の指定を引き継ぐことで、効率的なセキュリティ制約の指定が可能となる。例えば、親オブジェクトのセキュリティがＡクラスに指定され、第１の子オブジェクトのセキュリティが指定されておらず、第２の子オブジェクトのセキュリティがＢクラスに指定されているとする。この場合、第１の子オブジェクトには、親オブジェクトのセキュリティであるＡクラスが引き継がれることとなる。
【００５０】
（５）呼び戻し元のセキュリティ制約の引き継ぎ
所定のオブジェクト内のスクリプトが他のオブジェクト内のスクリプトを呼び出して実行する場合、この所定のオブジェクトのセキュリティ制約を引き継ぐようにすることもできる。自分固有のセキュリティ制約を持たないオブジェクトへのアクセスのラッパーなどの機能を持つライブラリ等で用いることができる。
【００５１】
なお、上述したようにセキュリティ制約の定義をＨＴＭＬに書いてもよいが、外部ファイルによって定義することもできる。その場合、ＨＴＭＬには、外部ファイルを参照することが記載される。
【００５２】
［ウェブブラウザの動作］
（１）スクリプト実行時に、ＤＯＭ上のオブジェクトに対するアクセスが発生した場合には、以下の動作をする。すなわち、実行中のコンテキストのセキュリティ制約から、対象のオブジェクトへのアクセス権限があるかを確認する。そして、アクセス権限がある場合には実行を続けるが、無い場合には処理を中断して例外を発生させる。この場合、スクリプトエンジンは例外ハンドラを読み出し、また、エラー個所や原因を示すエラーダイアログを出して停止する。
【００５３】
（２）リンククリックやスクリプトなどによってネットワークに対するリクエストが発生した場合、以下の動作をする。すなわち、実行中のコンテキストのセキュリティ制約から、対象ドメインやポートへのアクセス権限があるかを確認する。そして、リンクをクリックした場合は、そのリンクが属するセキュリティ制約に従ってリクエスト権限があるかを確認する。そして、リクエスト権限がある場合には実行を続けるが、無い場合には処理を中断して例外を発生させる。
【００５４】
（３）異なったセキュリティ制約を持つ関数オブジェクトを呼び出す場合、現在のセキュリティ制約をスタックに積み、飛び先の関数オブジェクトのセキュリティ制約をコンテキストに設定する。そして、異なったセキュリティ制約を持つ関数オブジェクトから戻る場合、上述のスタックからセキュリティ制約をポップして、それをコンテキストに設定する。
【００５５】
（４）オブジェクトのプロパティを書き換える場合、現在のセキュリティ制約に従い、文字数などの制約を超えないことを確認する。
【００５６】
上述したように、図１に示すウェブシステム１００においては、ＤＯＭ上のオブジェクトに対して適切なセキュリティ制約が設定されることにより、バグが発見されても、ＸＳＳやＣＳＲＦ、あるいは未知の脆弱性を防ぐことができる。
【００５７】
また、図１に示すウェブシステム１００においては、ＤＯＭ上のオブジェクトに対して適切なセキュリティ制約が設定されることにより、外部サーバ上のスクリプトを安全に利用することができる。仮に、中に悪意のあるスクリプトが混ざっていても、このスクリプタは、重要な情報を取得できず、被害を最小限に留めることができる。
【００５８】
また、図１に示すウェブシステム１００においては、ＤＯＭ上のオブジェクトに対して適切なセキュリティ制約が設定されることにより、ウェブブラウザ自体のバグ等によるＵＸＳＳ(ユニバーサルクロススクリプティング)等の未知の脆弱性も防ぐことができる。
【００５９】
また、図１に示すウェブシステム１００においては、一部のスクリプトに対して制限をかけると同時に同一生成元ポリシーを変更することで、安全に同一生成元ポリシーを越えてウェブＡＰＩを利用することができる。
【００６０】
また、図１に示すウェブシステム１００においては、変更できるオブジェクトや使用できるオブジェクトの個数や属性の文字列長に適切な制限をかけることで、バッファ・オーバーフロー（buffer overflow）やヒープ・スプレイ（heap spray）攻撃など、ウェブブラウザ自体の脆弱性を狙った攻撃を防ぐことができる。
【００６１】
＜２．変形例＞
なお、上述実施の形態においては、各オブジェクトに対して設定されるセキュリティ制約が固定であるように説明した。しかし、このセキュリティ制約が、他の条件に応じて動的に変化する例も考えられる。
【００６２】
例えば、ＵＲＬ（Uniform Resource Locator）に従って外部のセキュリティ制約を与える例が考えられる。すなわち、（１）外部ベンダーが各メジャーサイトを安全に使うために、サイト毎にセキュリティ制約を配布することが考えられる。（２）そのサイトがセキュリティ制約を持っていない場合、ウェブブラウザがＵＲＬに紐付いた制約を適用することが考えられる。
【００６３】
図１３のフローチャートは、その場合におけるスクリプトエンジンの処理の流れの一例を概略的に示している。スクリプトエンジンは、ステップＳＴ１１において、処理を開始する。そして、スクリプトエンジンは、ステップＳＴ１２において、スクリプトの実行が指示されたか否かを判断する。スクリプトの実行が指示されたとき、スクリプトエンジンは、ステップＳＴ１３の処理に移る。
【００６４】
このステップＳＴ３において、スクリプトエンジンは、実行指示されたスクリプトの取得先のサイトがセキュリティ制約を持っているか否かを判断する。持っているとき、スクリプトエンジンは、ステップＳＴ１４において、取得先のサイトが持っているセキュリティ制約を使用することに決定し、その後に、ステップＳＴ１５の処理に移る。一方、スクリプトエンジンは、ステップＳＴ１３で取得先のサイトがセキュリティ制約を持っていないとき、ステップＳＴ１６において、取得先のサイトのＵＲＬに紐付いたセキュリティ制約を使用することに決定し、その後に、ステップＳＴ１５の処理に移る。
【００６５】
ステップＳＴ１５において、スクリプトエンジンは、セキュリティ制約を満たしているか否かを判断する。セキュリティ制約を満たしているとき、スクリプトエンジンは、ステップＳＴ１７において、スクリプトを実行する。スクリプトエンジンは、このステップＳＴ１７の処理の後、ステップＳＴ１８において、処理を終了する。一方、ステップＳＴ１５でセキュリティ制約を満たしていないとき、スクリプトエンジンは、ステップＳＴ１９において、スクリプトを実行する代わりに、特殊な動作、例えば、エラー箇所やその原因を示すエラーダイアログを出す等する。スクリプトエンジンは、このステップＳＴ１９の処理の後、ステップＳＴ１８におおいて、処理を終了する。
【００６６】
また、本技術は、以下のような構成を取ることもできる。
（１）複数の処理データから選択された所定の処理データに基づいて情報処理を行う処理部と、
上記所定の処理データに関連付けされたセキュリティ制約に基づいて上記処理部の動作を制御する制御部とを備える
情報処理装置。
（２）上記処理部は、ウェブブラウザであり、
上記処理データは、ドキュメントオブジェクトモデルを構成するオブジェクトである
前記（１）に記載の情報処理装置。
（３）上記セキュリティ制約は、上記オブジェクト内へのスクリプトの挿入権限である
前記（２）に記載の情報処理装置。
（４）上記セキュリティ制約は、上記オブジェクト内のスクリプトの実行可能権限である
前記（２）または（３）に記載の情報処理装置。
（５）上記セキュリティ制約は、リクエストに関する制限である
前記（２）から（４）のいずれかに記載の情報処理装置。
（６）上記セキュリティ制約は、スクリプトのアクセス可能なオブジェクトまたはアクス不可能なオブジェクトの指定である
前記（２）から（５）のいずれかに記載の情報処理装置。
（７）上記セキュリティ制約は、アプリケーション・プログラミング・インタフェースへのアクセス権限である
前記（２）から（６）のいずれかに記載の情報処理装置。
（８）上記セキュリティ制約は、異なる生成元からのオブジェクトの参照あるいは変更のリクエストのポリシー変更である
前記（２）から（７）のいずれかに記載の情報処理装置。
（９）上記セキュリティ制約は、子オブジェクトも含めたヒープ使用量の上限である
前記（２）から（８）のいずれかに記載の情報処理装置。
（１０）上記セキュリティ制約は、子オブジェクトも含めたオブジェクト数の上限である
前記（２）から（９）のいずれかに記載の情報処理装置。
（１１）上記セキュリティ制約は、上記オブジェクトに設定できる文字列長の上限である
前記（２）から（１０）のいずれかに記載の情報処理装置。
（１２）上記セキュリティ制約は、上記オブジェクトに属性として与えられる
前記（２）から（１１）のいずれかに記載の情報処理装置。
（１３）上記セキュリティ制約は、クラスで指定される
前記（１２）に記載の情報処理装置。
（１４）上記セキュリティ制約は、セキュリティオブジェクトにより定義される
前記（２）から（１３）のいずれかに記載の情報処理装置。
（１５）上記セキュリティ制約の指定のないオブジェクトのセキュリティ制約として、親からのセキュリティ制約を引き継ぐ
前記（２）から（１４）のいずれかに記載の情報処理装置。
（１６）所定のオブジェクト内のスクリプトが他のオブジェクト内のスクリプトを呼び出して実行する場合、該所定のオブジェクトのセキュリティ制約を引き継ぐ
前記（２）から（１５）のいずれかに記載の情報処理装置。
（１７）ＨＴＴＰヘッダにより上記セキュリティ制約を指定する
請求項２に記載の情報処理装置。
（１８）上記セキュリティ制約は、所定の条件に応じて動的に変化する
前記（２）から（１７）のいずれかに記載の情報処理装置。
（１９）複数の処理データから選択された所定の処理データに基づいて情報処理を行う処理ステップと、
上記所定の処理データに関連付けされたセキュリティ制約に基づいて上記処理ステップ得の動作を制御する制御ステップとを備える
情報処理方法。
（２０）コンピュータを、
複数の処理データから選択された所定の処理データに基づいて情報処理を行う処理手段と、
上記所定の処理データに関連付けされたセキュリティ制約に基づいて上記処理手段の動作を制御する制御手段と
して機能させるプログラム。
【符号の説明】
【００６７】
１００・・・ウェブシステム
１１０・・・クライアント装置
１２０Ａ，１２０Ｂ・・・サーバ装置
１３０・・・ネットワーク
【図１】
2013125497.tif 000003
【図２】
2013125497.tif 000004
【図３】
2013125497.tif 000005
【図４】
2013125497.tif 000006
【図５】
2013125497.tif 000007
【図６】
2013125497.tif 000008
【図７】
2013125497.tif 000009
【図８】
2013125497.tif 000010
【図９】
2013125497.tif 000011
【図１０】
2013125497.tif 000012
【図１１】
2013125497.tif 000013
【図１２】
2013125497.tif 000014
【図１３】
2013125497.tif 000015