通信制御機能を有する通信装置、方法、プログラム
【課題】
Webアプリケーションの通信制限を掛ける方法として、アプリケーションごとに全ての通信し得る全ての通信先を事前に指定することは困難であった。
【解決手段】
本発明の通信装置は、リソースにアクセスする通信部と、
前記通信部が前記リソースにアクセスする時にアクセス先のサーバから前記リソースに関連付けられる通信制御ポリシを取得する通信制御ポリシ取得部と、
前記通信部がアクセスする前記リソースを前記通信制御ポリシに基づいて限定する通信制御部と、を有する。
Webアプリケーションの通信制限を掛ける方法として、アプリケーションごとに全ての通信し得る全ての通信先を事前に指定することは困難であった。
【解決手段】
本発明の通信装置は、リソースにアクセスする通信部と、
前記通信部が前記リソースにアクセスする時にアクセス先のサーバから前記リソースに関連付けられる通信制御ポリシを取得する通信制御ポリシ取得部と、
前記通信部がアクセスする前記リソースを前記通信制御ポリシに基づいて限定する通信制御部と、を有する。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明はWebアプリケーションの脆弱性が原因で利用者の情報が漏えいすることを防ぐ通信装置、方法、プログラムに関する。
【背景技術】
【０００２】
近年では、インターネット上の複数のサービスや、利用者の情報などをマッシュアップしたサービスが広く利用されている。マッシュアップとはWeb上に提供されている複数の異なる情報やサービス、コンテンツなどを組み合わせて、新しいサービス等を形作ることである。これらのサービスは、Webアプリケーションとして提供され、利用者はWebブラウザを使ってそれらのWebアプリケーションを利用する。ここで、Webアプリケーションは、Webサーバ上で動作するサーバサイドのプログラムと、利用者のブラウザ上で動作するクライアントサイドのプログラムとから構成される。
【０００３】
クライアントサイドのプログラムは主にHTML（Hypertext Markup Language）やJavaScriptで実装される。また、サーバサイドのプログラムはJava（登録商標）やPHP(Hypertext Preprocessor)などで実装される。
【０００４】
マッシュアップサービスの例として、利用者の周辺の地図上にレストランの情報をマッピングして、利用者に提示するアプリケーションがある。このアプリケーションは、レストランの情報を提供するサービスと、座標から地図情報を提供するサービスと、そして利用者の現在位置情報とをマッシュアップする。
【０００５】
このようなマッシュアップサービスは、クライアントサイドのプログラム(以降、クライアントサイドアプリと呼ぶ)とサーバサイドのプログラム(以降、サーバサイドアプリと呼ぶ)との間で様々な情報を送受信する。前述の例では、まず利用者のブラウザ上のクライアントサイトアプリがレストラン情報を提供するサーバサイドアプリからレストラン情報を取得する。同時に利用者の通信端末(ローカルサーバ)のサーバサイドアプリから利用者の現在位置情報を取得する。最後に、クライアントアプリは取得した上記２つの情報を地図情報を提供するサーバサイドアプリに送り、サーバサイドアプリから地図情報を取得する。
【０００６】
このとき、利用者の通信端末上で実行されるアプリケーションやインターネット上のサービス間で送受信される情報の中には、利用者にとって漏えいさせたくない重要な情報、特に個人情報が含まれることがある。前述の例では、利用者の通信端末が個人情報を持つ場合がある。また、インターネット上のサービスが個人情報を持つ場合も考えられる。
【０００７】
このような個人情報をマッシュアップサービスで利用する場合、その個人情報は信頼できるアプリケーションに対してのみ提供されなければならない。前述の例でいうと、通信端末のサーバサイドアプリは、クライアントサイドアプリから要求があると、そのクライアントサイドアプリが信頼できるアプリケーションである場合にのみ、個人情報を渡すようにしなければならない。
【０００８】
そのため、個人情報の要求を受け付けるサーバサイドアプリは、個人情報を要求するクライアントサイドアプリを認証することが一般的である。
【０００９】
サーバサイドアプリがクライアントサイドアプリを認証する方法の例として、サーバサイドアプリがクライアントサイドアプリから受け取る要求メッセージに含まれるRefererを確認する方法が考えられる。Refererとは、あるWebページのリンクをクリックして別のページに移動したときの、リンク元のページのことである。Refererには、クライアントサイドアプリのダウンロード元のサーバ識別子が記載されている。このサーバ識別子が信頼できるサーバを指す場合は、サーバサイドサプリはこのクライアントサイドアプリを信頼する。つまり、クライアントサイドアプリの配信元サーバが信頼できる場合、そのクライアントサイドアプリも信頼することになる。
【００１０】
このように、個人情報を管理するサーバサイドアプリは、クライアントサイドアプリを認証することで、自身が管理する個人情報が信頼できないアプリケーションに漏えいすることを防止している。
【００１１】
しかし、信頼できるクライアントサイドアプリに、攻撃者が意図した悪意のあるスクリプトが埋め込まれている場合は、攻撃者に個人情報を奪取される危険性がある。このような状況は、クロスサイトスクリプティング(XSS: Cross Site Scripting)攻撃に代表されるようなサーバサイドアプリを対象とした攻撃によって、起こり得る。XSS攻撃とは、攻撃者がサイト間を横断して悪意のあるスクリプトを混入させて、脆弱なアプリケーション上で不正なスクリプトを実行させることである。個人情報が攻撃者に奪取される具体的な例を、以下にて説明する。
【００１２】
あるサーバサイドアプリは、利用者の通信端末からの要求に応じて動的にクライアントサイドアプリを生成して、通信端末に返すという動作をするものとする。具体的には、サーバサイドアプリは、利用者の通信端末から何らかの文字列、例えばユーザ名などを受け取ると、ユーザ名をクライアントサイドアプリに含めて利用者の通信端末に返す。さらに、このサーバサイドアプリは、利用者の通信端末内にあるローカルサーバ上のサーバサイドアプリから信頼されていることとする。つまり、サーバサイドアプリが生成するクライアントサイドアプリも同様に信頼されることになる。
【００１３】
ここで、このサーバサイドアプリが利用者から受け取る文字列が不正な文字列でないことを確認しない場合、このサーバサイドアプリはXSS攻撃に脆弱となる。攻撃者はこのXSS攻撃に脆弱なサーバサイドアプリを悪用して、利用者の通信端末に悪意のあるスクリプトを含んだクライアントサイドアプリをロードさせるように仕向けることができるからである。攻撃は次のように行われる。攻撃者は自身が用意したサイト上に、リンクを用意する。
【００１４】
このリンクは、前述のXSS攻撃に脆弱なサーバサイドアプリのURL(Uniform Resource Locator)であり、さらにこのURLには、パラメータとして、悪意のあるスクリプトを含んでいる。利用者が前述のリンクをクリックすることで、サーバサイドアプリに悪意のあるスクリプトを送ることになる。その結果、サーバサイドアプリは、利用者から受け取った悪意のあるスクリプトを含むクライアントサイドアプリを生成し、利用者の通信端末に返すことになる。
【００１５】
このとき、通信端末が受け取るクライアントサイドアプリが含むスクリプトは２つの動作をする。１つは、通信端末のサーバサイドアプリから個人情報を取得するスクリプト(スクリプト１)と、その情報を攻撃者サイトに送信するスクリプト(スクリプト２)である。
【００１６】
上記スクリプトは、通信端末上のブラウザにロードされると同時に実行される。まず、スクリプト１により通信端末は、ローカルサーバ上のサーバサイドアプリに個人情報を要求する。クライアントサイドアプリはもともとこのサーバサイドアプリから信頼されるアプリであるため、ローカルサーバ上のサーバサイドアプリは通信端末に個人情報に返す。 次にスクリプト２により通信端末は、スクリプト１により取得した個人情報を攻撃者サイトに送信する。このようにして、攻撃者は利用者の個人情報を奪取することに成功する。
【００１７】
上記のような、サーバサイドアプリの脆弱性が原因となる個人情報の漏えいは何らかの方法で防ぐ必要がある。この問題に対応する為の関連技術として、通信端末がクライアントサイドアプリの通信制御を行うことが考えられる。例えば、通信端末がクライアントサイドアプリの正しい通信先のリストを把握しておき、このアプリがそのリスト以外と通信しようとすると、その通信を中止するという方法がある。その結果、信頼できるクライアントサイドアプリに悪意のあるスクリプトが含まれていて、このスクリプトによって通信端末が攻撃者サイトに個人情報を送信しようとしても、その通信を止めることができる。通信端末は、攻撃者サイトへの通信は通信先のリストに記載のないため、その通信が不正な通信であると判断できるからである。
【００１８】
上記の関連した技術が記載された文献として、非特許文献１がある。非特許文献１には、通信端末内のアプリケーションマネージャがJavaアプリケーションの属性ファイルを参照することで、アプリケーションに通信制限を掛けることができるとしている。具体的には、属性ファイルにはJavaアプリケーションの通信先のリストが記載されており、そのアプリケーションがそのリストに記載されない通信先と通信しようとすると、アプリケーションマネージャがその通信を中止できる技術が記載されている。
【００１９】
また、関連した技術として下記特許文献１には、次のような技術が記載されている。即ち、ローカルネットワークを介して他のネットワークに接続する携帯端末上で動作するアプリケーションが、ローカルネットワークから機密情報を流出させることを防ぐ技術である。この関連技術では通信端末が、アプリケーションが実行する通信を監視する通信監視手段とアプリケーションの通信において接続されたネットワークの履歴を示す通信履歴情報を記録する。同時に且つ該通信履歴情報に応じて前記アプリケーションによるネットワークへの接続の可否を判定する通信制御手段とを備えている。
【００２０】
また、関連した技術として下記特許文献２には、次の様な技術が記載されている。即ち、
各通信装置の要求に基づいた通信転送ポリシを通信制御装置に反映させることのできる通信装置を提供するものである。
【先行技術文献】
【非特許文献】
【００２１】
【非特許文献１】JSR 118 Expert Group, Java Community Process「Mobile Information Device Profile for Java. 2 Micro Edition」(P431〜P452)[online].(retrieved on 2010-03-16)Retrieved from the Internet: <URL:http://www.nada.kth.se/projects/proj03/minime/other/midp-2_0-fr-spec.pdf>.
【特許文献】
【００２２】
【特許文献１】特開２００８−１９１８６２号公報
【特許文献２】特開２００５―２１７８２８号公報
【発明の概要】
【発明が解決しようとする課題】
【００２３】
しかし、この非特許文献１の技術をクライアントサイドのWebアプリケーションの通信制御として適用することは困難である。なぜなら、クライアントサイドアプリでは不特定多数のサイトへのリンクを持つことが多いため、先行技術１のようにWebアプリケーションが通信し得る全ての通信先を事前に指定することは現実的でないためである。不特定多数のサイトへのリンクとして、関連サイトへのリンクや、広告によるリンクが挙げられる。これらのリンクの総数は多数であり、アプリケーションごとに全てのリンクを指定した属性ファイルを用意することはアプリケーション開発者に負担がかかる。
【００２４】
もともとクライアントサイドアプリに通信制限を掛ける理由は、利用者にとって漏えいさせたくない情報を守ることである。そのため、クライアントサイドアプリが上記の情報を取得する前であれば、そのアプリに通信制限を掛ける必要がない。つまり、漏えいさせたくない情報を持たないクライアントサイドアプリには通信制限を掛けず、上記の情報を取得したときに通信制限を掛けることが望ましいということになる。しかし、先行技術１ではそのような通信制御を実現できない。
【００２５】
また特許文献１では、通信制御をかけるためのポリシを通信履歴ＤＢに蓄積する必要があるので、通信装置の資源を圧迫するという不具合を生じる可能性がある。
【００２６】
また、特許文献２では、ある通信装置が起動したとき、あるいは通信装置が特定のサービスを起動した際に対応する通信装置にポリシが適用されるというものであり、アクセスするリソースの種別等に拘わらずポリシが適用されてしまうという無駄が生じる恐れがある。
【００２７】
本発明はクライアントサイドアプリの通信制御に利用でき、そのアプリが個人情報などの重要な情報を取得した場合に、上記のような不具合無く個人情報が漏えいすることを防止できる通信装置等を提供することを目的としている。
【課題を解決するための手段】
【００２８】
本発明の通信装置は、リソースにアクセスする通信部と、
前記通信部が前記リソースにアクセスする時にアクセス先のサーバから前記リソースに関連付けられる通信制御ポリシを取得する通信制御ポリシ取得部と、
前記通信部がアクセスする前記リソースを前記通信制御ポリシに基づいて限定する通信制御部と、を有する。
【００２９】
また、本発明の通信制御方法は、リソースにアクセスする通信工程と、
前記通信工程が前記リソースにアクセスする時にアクセス先のサーバから前記リソースに関連付けられる通信制御ポリシを取得する通信制御ポリシ取得工程と、
前記通信工程がアクセスする前記リソースを前記通信制御ポリシに基づいて限定する通信制御工程と、を有する。
【００３０】
また、本発明のプログラムは、リソースにアクセスする通信ステップと、
前記通信ステップが前記リソースにアクセスする時にアクセス先のサーバから前記リソースに関連付けられる通信制御ポリシを取得する通信制御ポリシ取得ステップと、
前記通信ステップがアクセスする前記リソースを前記通信制御ポリシに基づいて限定する通信制御ステップと、をコンピュータに実行させる。
【００３１】
また、本発明の通信システムはデータを送受信するサーバ及び通信装置からなる通信システムであって、
前記通信装置は、リソースにアクセスする通信部と、
前記通信部が前記リソースにアクセスする時にアクセス先のサーバから前記リソースに関連付けられる通信制御ポリシを取得する通信制御ポリシ取得部と、
前記通信部がアクセスする前記リソースを前記通信制御ポリシに基づいて限定する通信制御部と、を有し、
前記サーバは、通信装置のリクエストに応じて対応するリソース及びリソースに関連する通信制御ポリシを前記通信装置に返すレスポンス生成部と、
を有する。
【発明の効果】
【００３２】
本発明では、事前にアプリケーションごとに全てのリンクを指定した属性ファイルを用意することなく、個人情報などの重要な情報が漏えいすることを防止できる通信装置、方法、プログラムを提供することを提供することが出来る。
【図面の簡単な説明】
【００３３】
【図１】本発明の第１の実施形態における通信装置を示す構成図である。
【図２】本発明の第１の実施形態における通信制御部がリクエスト元のタブと関連付けて記憶しているポリシの例である。
【図３】本発明の第１の実施形態におけるポリシ保存部が保存するポリシの例である。
【図４】本発明の第１の実施形態における通信装置がクライアントサイドアプリをブラウザにロードする処理を示す動作シーケンスである。
【図５】本発明の第１の実施形態におけるクライアントサイドアプリがリソースにアクセスする処理を示す動作シーケンスである。
【図６】本発明の第１の実施形態におけるクライアントサイドアプリ内に埋め込まれた悪意のあるスクリプトが攻撃者サーバと通信する処理を示す動作シーケンスである。
【図７】本発明の第１の実施形態における状態遷移図である。
【図８】本発明の第２の実施形態におけるポリシ保存部が保存するポリシの例である。
【図９】本発明の第２の実施形態における通信制御部がリクエスト元のタブと関連付けて記憶しているポリシの例である。
【図１０】本発明の第２の実施形態における通信制御部がリクエスト元のタブと関連付けて記憶しているポリシの例である。
【図１１】本発明の第２の実施形態におけるクライアントサイドアプリがページ遷移する際にポリシを操作する処理を示す動作シーケンスである。
【図１２】本発明の第３の実施形態における通信システムの構成図である。
【図１３】本発明の第３の実施形態における通信制御部がリクエスト元のタブと関連付けて記憶しているポリシの例である。
【図１４】本発明の第３の実施形態におけるサーバが保存するポリシの例である。
【図１５】本発明の第３の実施形態における通信装置上のクライアントサイドアプリがリソースを取得する処理を示す動作シーケンスである。
【図１６】本発明の第３の実施形態におけるレスポンスヘッダの例である。
【図１７】本発明の第３の実施形態におけるレスポンスメッセージボディの例である。
【図１８】本発明の第５の実施形態における通信装置の構成図である。
【発明を実施するための形態】
【００３４】
（第１の実施形態）
次に、本発明の第１の実施形態について図面を参照して詳細に説明する。
図１は本発明の第１の実施形態における通信装置の構成図である。通信装置１は、ブラウザ１０１を持ち、ブラウザ１０１はクライアントサイドアプリ１０２、通信部１０３、通信制御部１０４、およびポリシ保存部１０５から構成される。
【００３５】
通信装置１は、例えば、ノートＰＣ、携帯電話、ＰＤＡなどのサーバとの通信手段を持つ通信端末がこれに該当する。ブラウザ１０１は、通信装置がサーバからダウンロードしたWebアプリケーションを実行し、ユーザインターフェイスを持つ。例として、Firefox（登録商標）、Internet Explorer（登録商標）、Safari（登録商標）などが挙げられる。クライアントサイドアプリ１０２は、HTMLやJavaScript（登録商標）などの言語で記述されるアプリケーションである。
【００３６】
通信部１０３は、リソースとの通信手段である。ここで、リソースとは、サーバ、サーバサイドアプリ、サーバが管理する情報などを示す。通信制御部１０４は、ブラウザが送信するリクエストをフックする。さらに、自身が記憶している通信制御ポリシを確認して、そのリクエストが許可されない通信である場合はその通信を中止する。
【００３７】
このポリシの例を図２を用いて説明する。図２を参照すると、ブラウザのタブＡに関連付けられて通信が許可されるリソースが通信制御部１０４に記憶されている。これは、タブＡからのリクエストにサーバ３、サーバ４への通信が許可されていることを示す。このタブとは、ブラウザ１０１の１つのウィンドウに複数のアプリケーションがロードされる場合に、各アプリケーションを区別するために用いられるものである。「サーバ３、サーバ４」はリソースの識別子であり、ホスト名やURLがこれに該当する。例えば、ホスト名として「server1、localhost・・・」が、 URLとして「http://server1.com、http://localhost.local、http://server1.com /server1.cgi、http://server1.com/server1.cgi?parama=123、http: //server1.com/*」などが挙げられる。
【００３８】
さらに、通信装置がリソースにアクセスする度に、そのリソースに関連するポリシを、ポリシ保存部１０５から取り出し、ブラウザのタブと紐づけし、関連付けて記憶する。このとき、過去に記憶しているポリシがある場合は、記憶しているポリシと最後にアクセスしたリソースに関連する通信制御ポリシとをマージしたポリシを最新のポリシとして記憶する。
【００３９】
マージする例としては、２つのポリシの共通部分を取る方法が考えられる。例えば、通信制御部１０４が既に記憶しているポリシにより通信を許可されるリソースがサーバ３、サーバ４、サーバ５であり、さらに、通信制御部１０４がポリシ保存部から取り出したポリシにより通信を許可されるリソースが、サーバ３、サーバ４である場合を考える。このとき、上記２つのポリシの共通部分により通信を許可されるリソースは、サーバ３、サーバ４になる。
【００４０】
なお、通信制御部１０４は、利用者が新規作成したタブに関連付けられて記憶しているポリシを持たない。そのため、利用者が新規作成したタブには通信制御は適用されないことになる。前述のリソースに関連付けられて記憶されているポリシは、ポリシ保存部１０５が保存している。
【００４１】
このポリシについて図３を用いて説明する。図３を参照すると、リソースに関連付けられて通信が許可されるリソースが保存されている。具体的には、リソース「サーバ４」に関連付けられて、通信が許可されるリソース「サーバ３、サーバ４」が保存されている。このポリシの意味するところは、サーバ４と通信した場合、それ以降はサーバ３もしくはサーバ４とのみ通信が可能になる、ということである。
【００４２】
次に、動作シーケンス図を参照して本実施の形態の全体の動作について詳細に説明する。
本実施の形態の全体の動作は、
１）通信装置がクライアントサイドアプリをブラウザにロードする処理
２）クライアントサイドアプリがリソースを取得する処理
３）クライアントサイドアプリ内に埋め込まれた悪意のあるスクリプトが攻撃者サーバと通信する処理
４）ブラウザ上のタブの状態遷移
の４つから構成される。
以下、それぞれの処理の詳細について説明する。
【００４３】
まず、「１）通信装置がクライアントサイドアプリをブラウザにロードする処理」について図４を用いて説明する。以下、図４の構成について、図１との差分のみ説明する。ネットワーク２は、通信装置１とサーバ３の間で送受信されるデータの伝送経路であり、無線LAN、基地局、ルータ、などネットワーク装置で構成される。サーバ３は、リクエストを受けた通信装置にクライアントサイドアプリ１０２を配信するサーバである。サーバサイドアプリ３０１は、サーバ３上に配置されるWebアプリケーションであり、利用者からリクエストを受けるとクライアントサイドアプリ１０２を生成するアプリケーションである。
【００４４】
利用者は、ブラウザ１０１を起動し(タブが新規に作成される)、サーバ３にクライアントサイドアプリ１０２を要求する(ステップS１０１)。通信部１０３は、クライアントサイドアプリ１０２を取得するためのリクエストを通信制御部１０４に送信する(ステップS１０２)。 通信制御部１０４は、リクエストを受け取るとリクエスト元のブラウザのタブを特定する。ここでは、リクエスト元のタブを「タブＡ」とする(ステップS１０３)。
【００４５】
さらに、通信制御部１０４は、そのタブＡに関連するポリシを自身が記憶しているか確認する(ステップS１０４)。このとき、ポリシを記憶していない場合は、リクエストをネットワーク２を介してサーバ３に送信する。ポリシを記憶している場合は、処理が分岐するが、説明は後述する。
【００４６】
本実施の形態では、利用者は新規にタブを作成しているため、ステップＳ１０４では、このタブＡに関連するポリシはない。そのため、リクエストをサーバ３に送信する(ステップS１０５)。サーバ３はリクエストを受け取るとサーバサイドアプリ３０１を用いて、クライアントサイドアプリ１０２を生成し、ネットワーク２を介して通信装置１に返す(ステップS１０６)。
【００４７】
通信制御部１０４は、サーバ３からのレスポンスを受け取ると、受け取ったクライアントアプリ１０２をブラウザにロードする。同時に、通信制御部１０４は、ポリシ保存部１０５にステップS１０５におけるリクエストの送信先(サーバ３もしくは、サーバ３のWebアプリ１０２)に関連するポリシを要求する(ステップS１０７)。
【００４８】
ポリシ保存部１０５は、サーバ３に関するポリシがある場合は、それを返す。 また、サーバ３に関するポリシがない場合は、関連するポリシがないことを通知する。本シーケンスでは、サーバ３に関連するポリシはないため、ポリシがないことを通知する(ステップS１０８)。
【００４９】
通信制御部１０４は、ポリシを受け取った場合は、ポリシに記載される通信を許可されるリソースをステップS１０３で特定したリクエスト元タブと関連付けて記憶する。このとき、既にリクエスト元のタブに関連付けるポリシがある場合は、そのポリシとステップS１０８で受け取ったポリシとの共通部分を新たなポリシとして、リクエスト元のタブに関連付けて記憶する。
【００５０】
例えば、既にリクエスト元のタブに関連付けられているポリシにより通信を許可されるリソースがサーバ３、サーバ４、サーバ５であり、さらに、ステップS１０８で受け取ったポリシにより通信を許可されるリソースが、サーバ３、サーバ４である場合を考える。このとき、リクエスト元のタブに関連付けて記憶されるリソースは、サーバ３、サーバ４になる。また、ステップS１０８でポリシのない通知を受けとる場合は、何もしない。本シーケンスでは、ポリシがない通知を受け取るため、ここでは何も処理しない(ステップS１０９)。
【００５１】
さらに、通信制御部１０４は、通信部１０３にクライアントサイドアプリ１０２を渡す(ステップS１１０)。
【００５２】
次に、「２）クライアントサイドアプリがリソースを取得する処理」について図５を用いて説明する。以下、図５の構成について、図４との差分のみ説明する。クライアントサイドアプリ１０２は、１）において、サーバ３からロードしたクライアントサイドのWebアプリケーションである。サーバ４は、リクエストを受けた通信装置に個人情報を配信するサーバである。サーバサイドアプリ４０１は、リクエストを受け取ると個人情報を生成するWebアプリケーションである。
【００５３】
利用者は、クライアントサイドアプリ１０２を利用してサーバ４に個人情報を要求する(ステップS２０１)。通信部１０３は受け取ったリクエストを通信制御部１０４に送信する(ステップS２０２)。
【００５４】
通信制御部１０４は、リクエストを受け取るとリクエスト元のブラウザのタブ「タブＡ」を特定する(ステップS２０３)。さらに、そのタブに関連するポリシを自身が記憶しているか確認する(ステップS２０４)。
【００５５】
本シーケンスでは、ステップS１０９でポリシを記憶していないため、タブAには、この時点では無制限で通信が許可されている。 そのため、通信制御部１０４はリクエストをサーバ４へ送信する(ステップS２０５)。
【００５６】
サーバ４はリクエストを受け取ると、サーバサイドアプリ４０１を利用して個人情報を生成し、通信装置１に返す(ステップS２０６)。通信制御部１０４は、個人情報を受け取ると、ステップS２０５における通信先のリソース(サーバ４もしくはサーバ４が提供する個人情報)に関連するポリシをポリシ保存部１０５に要求する(ステップS２０７)。
【００５７】
ポリシ保存部１０５は、要求されるポリシがある場合は、そのポリシを返す(ステップS２０８)。 本シーケンスでは図３に示す通り、ポリシ保存部１０５が、サーバ４に関連するポリシとしてサーバ３、サーバ４にアクセスが許可されるポリシを保持している。
【００５８】
通信制御部１０４は、ポリシを受け取ると、ステップS２０３で特定したリクエスト元のブラウザのタブ「タブＡ」と関連付けて記憶する(ステップS２０９)。このとき通信制御部１０４が、記憶するポリシは図２に示す通りである。図２を参照すると、タブＡに関連付けてリソース「サーバ３、サーバ４」が記憶されている。このポリシの意味するところは、この時点で、タブＡに通信制御が掛けられており、許可される通信先は、サーバ３、サーバ４に限定されるということである。
【００５９】
さらに通信制御部１０４は、個人情報を通信部１０３に渡す(ステップS２１０)。通信部１０３は、個人情報をクライアントサイドアプリ１０２に渡す(ステップS２１１)。
【００６０】
次に、「３）クライアントサイドアプリ内に埋め込まれた悪意のあるスクリプトが攻撃者サーバと通信する処理」について図６を用いて説明する。以下、図６の構成について、図４との差分のみ説明する。これは、クライアントサイドアプリ１０２を生成する図４におけるサーバサイドアプリ３０１がXSS攻撃に脆弱であることを想定しており、その結果、図６におけるクライアントサイドアプリ１０２には、悪意のあるスクリプトが埋め込まれている。
【００６１】
さらに、このスクリプトは、２）で取得した個人情報を攻撃者サーバ６に送るように動作する。また、攻撃者サーバ６は、クライアントサイドアプリ１０２から個人情報を受け取るために攻撃者が用意するサーバである。
【００６２】
クライアントサイドアプリ１０２は、悪意のあるスクリプトにより、攻撃者サーバ６にステップS２１１で取得した個人情報を送信することを要求する(ステップS３０１)。通信部１０３は受け取ったリクエストを通信制御部１０４に送信する(ステップS３０２)。
【００６３】
通信制御部１０４は、リクエストを受け取るとリクエスト元のブラウザのタブ「タブＡ」を特定する(ステップS３０３)。さらに、そのタブに関連するポリシを自身が記憶しているか確認する(ステップS３０４)。
【００６４】
本シーケンスでは、ステップS２０９でポリシを記憶している。さらに、ステップS３０２で受け取ったリクエストが、記憶しているポリシで許可される通信かどうかを確認する(ステップS３０５)。本シーケンスでは、図２に示す通り、タブＡにはサーバ３、サーバ４が記憶されている。そのため、攻撃者サーバ６への通信が許可されていないと判断し、リクエストを中止する(ステップS３０６)。
【００６５】
このように、クライアントサイドアプリ１０２に悪意のあるスクリプトが埋め込まれている場合でも、取得した個人情報を攻撃者サーバ送信すること中止するので個人情報が意図せずに漏えいすることを阻止できる。
【００６６】
次に、「４）ブラウザ上のタブの状態遷移」について図７を用いて説明する。この状態遷移図は、図３のポリシを元に作成したものである。
【００６７】
まず、利用者がブラウザ上で新規タブを作成した時点では、初期状態となる。初期状態では、ポリシがない。ここで、初期状態からサーバ３と通信(クライアントサイドアプリ１０２を取得)する。このとき、サーバ３に関連付けられるポリシがないため、初期状態を維持する。つまり、ブラウザがクライアントサイドアプリ１０２をロードした時点では、リクエスト元のタブに通信制御は適用されない。
【００６８】
次に、初期状態からサーバ４と通信(個人情報を取得)するときを考える。ここでは、サーバ４に関連するポリシがあるため、リクエスト元のタブに通信制御が適用されて状態１に遷移する。この状態１は、リクエスト元のタブが通信できるリソースが、サーバ３、サーバ４に限定される、という状態である。
【００６９】
また、初期状態からサーバ５に通信するときを考える。このとき、サーバ５に関連するポリシがあるため、リクエスト元のタブに通信制御が適用されて状態２に遷移する。この状態２は、リクエスト元のタブが通信できるリソースが、サーバ３、サーバ４、サーバ５に限定される、という状態である。さらに、状態２の状態からサーバ４にアクセスするときを考える。ここでは、サーバ４に関連するポリシがあるため、リクエスト元のタブに通信制御が適用される。このとき、状態２のポリシと、サーバ４に関連するポリシの共通部分が新たなポリシとなる。このとき、リクエスト元のタブが通信できるリソースは、サーバ３、サーバ４である。つまり、状態１に遷移することになる。
【００７０】
このように、リソースにアクセスして初めて、そのリソースに関する通信制御が適用されることになる。以降、異なるリソースにアクセスするたびに、そのリソースに関連したポリシが追加されるようになる。
【００７１】
このように、本実施形態では、事前にアプリケーションごとに全てのリンクが指定された属性ファイルを用意せずに、クライアントサイドアプリが利用者にとって漏えいさせたくない情報を取得した場合の情報漏えいを防止できる、という効果を有する。なぜなら、情報にアクセスした時点で、リクエスト元のタブにその情報に関連するポリシに応じた通信制御が適用されるためである。
【００７２】
なお、本実施の形態において、通信制御部１０４は、あるリクエスト元のタブ上のクライアントサイドアプリがページを遷移する場合、そのタブに関連付けて記憶しているポリシを削除してもよい。
【００７３】
さらに、本実施の形態において、通信制御部１０４は、通信したリソースに関連するポリシをリクエスト元のタブと関連付けて記憶したが、これをリクエスト元のウィンドウや、クライアントサイドアプリ１０２のURLに関連付けて記憶してもよい。
【００７４】
さらに、本実施の形態において、通信制御部１０４が通信先と自身が記憶するポリシを比較する際、それらが完全一致した場合にその通信先へのリクエストを許可することを想定しているが、部分一致した場合にその通信先リクエストを許可するようにしてもよい。
【００７５】
さらに、本実施の形態において、通信制御部１０４は、利用者が新規作成したタブに関連付けられて記憶するポリシとして、あらかじめ定められるポリシを記憶しても構わない。 このとき、上記のタブには、あらかじめ定められたポリシを元に、通信制御が適用されることになる。
【００７６】
さらに、本実施の形態において、ブラウザ１０１は、クライアントサイドアプリを実行する機能のみを持つとしても良い。
【００７７】
さらに、本実施の形態において、通信制御部１０４、ポリシ保存部１０５は、ブラウザ１０１に内蔵されているが、それらの構成は、ブラウザ１０１の外部にあっても良い。
（第２の実施形態）
次に、本発明の第２の実施形態について説明する。
ここでは、本発明の第１の実施形態で述べた構成及び動作との差分のみ説明する。
【００７８】
本発明を実施するための第２の実施の形態における通信装置の構成図は図１と同様である。ここで、通信制御部１０４は、さらにリソースに関連付けられるポリシに記載される、 ポリシを削除する条件に一致するリソースにアクセスした場合、記憶しているポリシを破棄する。さらに、ポリシ保存部１０５は、図８に示すようなポリシを持つ。図８を参照すると、通信したリソースに関連付けてポリシを削除する条件として通信先リソースが保存されている。
【００７９】
次に、本発明の第２の実施形態の動作を説明する。
本実施形態の全体の動作は
１）通信装置がクライアントサイドアプリをブラウザにロードする処理
２）クライアントサイドアプリがリソースを取得する処理
３）クライアントサイドアプリがページ遷移する際にポリシを操作する処理
から構成される。以下は、上記の処理の詳細について説明する。
【００８０】
１）通信装置がクライアントサイドアプリをブラウザにロードする処理について、図４を用いて説明する。第１の実施形態における図４の処理とは、ステップS１０８〜S１０９が異なる。
【００８１】
ポリシ保存部１０５は、ポリシを要求されると、サーバ３に関連するポリシを返す。 この時のポリシの例として図８を用いて説明する。図８を参照すると、サーバ３に関連付けられるポリシには、通信が許可されるリソースの記載がない。これは無制限で通信が許可されることを意味する。
【００８２】
さらに、ページ遷移時にポリシをKeepする条件として「サーバ７」が記載されている。一方、ページ遷移時にポリシを削除する条件として「*」が記載されている。
前者「サーバ７」の記載は、ページ遷移時、つまりクライアントサイドアプリ１０２が異なるクライアントサイドアプリに遷移する場合に、通信先のリソースがサーバ７である場合は、リクエスト元のタブに関連付けて記憶するポリシを保持することを意味する。
【００８３】
ページを遷移する例としては、クライアントサイドアプリ上のaタグで張られるリンクを利用者がクリックする場合が挙げられる。また、ポリシを削除しない状況として例えば、遷移前のクライアントサイドアプリから異なるクライアントサイドアプリにページする際に、遷移前のアプリが取得した利用者にとって漏えいしたくない情報を、遷移後のページに渡すときが考えられる。このとき、遷移後のアプリは利用者にとって漏えいしたくない情報を持つため、その情報漏えいを防止するために、遷移前のアプリの通信制御がそのまま適用されることが望ましい。
【００８４】
一方、後者「*」の記載は所謂ワイルドカード、即ち、任意の文字列にマッチする特殊文字を意味する。従って、この場合、通信先のリソースが「サーバ７」以外の全ての場合に、リクエスト元のタブに関連付けて記憶するポリシを削除することを意味する。これは以降サーバ７にアクセスすると通信制御部１０４はリクエスト元のタブに関連付けて記憶しているポリシを削除することを意味する(ステップS１０８)。
【００８５】
ポリシを削除しない状況としては、例えば、あるクライアントサイドアプリから異なるクライアントサイドアプリのページに移動（遷移）する場合がある。遷移前のクライアントサイドアプリが取得した情報を、遷移後のクライアントサイドアプリに渡さない場合は、遷移後のクライアントサイドアプリが利用者にとって漏えいさせたくない情報を持たない。このような場合、遷移前のクライアントサイドアプリに適用される通信制御は解除しても良い。
【００８６】
通信制御部１０４は、渡されたポリシをステップS１０３で特定したタブと関連付けて記憶する。このとき記憶するポリシは図９の通りである。図９を参照すると、タブＡに関連付けられて、通信が許可されるリソースは空白であるため無制限で通信を許可されている。さらに、ポリシを削除する条件としてサーバ７が記載されており、サーバ７と通信を行う時点で通信制御部１０４が記憶するポリシを削除している。
【００８７】
次に、２）クライアントサイドアプリがリソースを取得する処理について図５を用いて説明する。第１の実施形態における図５の処理とは、ステップS２０９が異なる。
【００８８】
通信制御部１０４は、ポリシを受け取ると、既に記憶しているポリシを受け取ったポリシの共通部分を新しいポリシとして記憶する。このとき記憶するポリシは図１０のようになる。ここでは、通信が許可されるリソースは、「サーバ３、サーバ４、サーバ７」であり、 ポリシを削除する条件となる通信先リソースは「サーバ７」となる。
【００８９】
次に、３）クライアントサイドアプリがページ遷移する際にポリシを操作する処理について図１１を用いて説明する。 図１１の構成について、図４との違いのみ説明する。サーバ７は、通信装置からのリクエストに対してクライアントサイドアプリを配信するサーバである。
【００９０】
サーバサイドアプリ７０１は、クライアントサイドアプリ１０２上でaタグなどによりリンクされているWebアプリケーションであり、クライアントサイドアプリ１０２とは異なるクライアントサイドアプリを生成する。
【００９１】
利用者は、クライアントサイドアプリ１０２のaタグをクリックし、ページを遷移するためのリクエストをサーバ７に送信する(ステップS４０１)。 図１１におけるステップS４０２〜S４０４は、図４のステップS１０２〜S１０４と同様の処置であるため説明を省略する。 通信制御部１０４は、記憶しているポリシでアクセスが許可されるリクエストかどうかを確認する(ステップS４０５)。このとき、記憶しているポリシは図１０に示す通りであり、サーバ７へのアクセスは許可されているため、ステップS４０６に進む。
【００９２】
さらに通信制御部１０４は、このリクエストがページ遷移時のリクエストである場合に、ポリシを操作する条件に一致するかどうかを確認する(ステップS４０６)。このとき、図１０のポリシを再度参照する。
【００９３】
このとき、「サーバ７との通信」は、記憶しているポリシを保持する条件「サーバ７：Keep」に合致するため、記憶しているポリシを保持(Keep)する(ステップS４０７)。図１１における以降のステップS４０８〜S４１３は、図４のステップS１０５〜S１１０と同様の処理であるため説明を省略する。
【００９４】
なお、本実施の形態において、ステップS４０１において、ページを遷移するためのリクエストをサーバ７とは異なるサーバに送信した場合は、記憶しているポリシを削除する。ステップS４０７において、記憶しているポリシを削除するための条件「*：Delete」と一致するためである。
【００９５】
このように、本発明の第２の実施形態では、あるクライアントサイドアプリが異なるクライアントサイドアプリに遷移する際に、リクエスト元のタブに適用される通信制御ポリシを継続して保持する否かを、遷移する際の通信先に応じて制御できるようになる。
（第３の実施形態）
次に、本発明を実施するための第３の実施形態について説明する。
ここでは、第１の実施形態で述べた構成及び動作との差分のみ説明する。
【００９６】
図１２は本発明の第３の実施形態における通信システムの構成図である。第３の実施の形態における通信システムは、通信装置８とサーバ９、ネットワーク２で構成される。通信装置８における８０１〜８０３の構成は、図１の１０１〜１０３の構成と同様であるため 説明を省略する。通信装置８は、通信制御部８０４を備える。
【００９７】
通信制御部８０４は、図１の通信制御部１０４に加えて、サーバ９から受け取ったHTTPレスポンスからポリシを取得し、そのポリシをタブに関連付けて記憶する。タブに関連付けて記憶されるポリシの例を図１３を用いて説明する。
【００９８】
図１３を参照すると、タブＡに関連付けて通信が許可されるリソースとしてサーバ９を記憶している。
【００９９】
サーバ９は、通信部９０１、レスポンス生成部９０２、個人情報保存部９０３、ポリシ保存部９０４を備える。通信部９０１は、通信装置８とのデータの送受信を行う通信手段である。
【０１００】
個人情報保存部９０３は、サーバ９が管理する利用者の情報（個人情報）である。ポリシ保存部９０４は、個人情報に関連付けて記録される通信制御ポリシである。このポリシについて図１４を用いて説明する。
【０１０１】
図１４では、個人情報保存部９０３に保存されている個人情報に関連付けて通信が許可されるリソースの一覧が記載されている。ここでは、サーバ９がアクセスが許可されるリソースとなる。
【０１０２】
次に、本発明の第３の実施形態の動作について、通信装置が個人情報を取得する処理の詳細について説明する。
【０１０３】
クライアントサイドアプリ８０２がサーバ９から個人情報を取得する処理について図１５を用いて説明する。
【０１０４】
図１５のステップS５０１〜S５０５は、図５のS２０１〜S２０５と同様の処理であるため説明を省略する。通信部９０１は、リクエストを受け取ると、リクエストをレスポンス生成部９０２に渡す(ステップS５０６)。レスポンス生成部９０２は、個人情報保存部９０３に保存すべき個人情報を取得し保存する(ステップS５０７)。
【０１０５】
さらにレスポンス生成部９０２は、個人情報保存部９０３に保存された個人情報に関連するポリシをポリシ保存部９０４に要求する(ステップS５０８)。ポリシ保存部９０４は、関連するポリシがある場合は、そのポリシを返す(ステップS５０９)。
図１４を参照すると、このときポリシ保存部９０４は、アクセスが許可されるリソースのリストとして、「サーバ９」を返す。レスポンス生成部９０２は、ステップS５０７で取得して個人情報保存部９０３に保存された個人情報とステップS５０９で取得したポリシを元に、レスポンスを生成する(ステップS５１０)。レスポンスメッセージにポリシを記載する方法としては、例えばHTTPレスポンスヘッダに記載する方法がある。
【０１０６】
具体的には、図１６を用いて説明する。図１６を参照すると、HTTPレスポンスヘッダに、アクセス許可リストを記載する拡張ヘッダとして「Access-Permit」が追加されている。さらに、この拡張ヘッダに記載される内容は、ステップS５０９で取得したポリシに記載されるアクセスが許可されるリソースのリストである「サーバ９」が記載される。
【０１０７】
この「サーバ９」はサーバ９のURLであり「http://server9.com」が記載されている。 また別の方法として、例えばHTTPレスポンスのボディ内に記載する方法もある。 具体的には、図１７を用いて説明する。図１７を参照すると、HTTPレスポンスのボディの、先頭にアクセス許可リストを記載している。また、そのときの記載の内容は、ステップS５０９で取得したポリシに記載されるアクセスが許可されるリソースのリストである 「サーバ９」が記載される。この「サーバ９」はサーバ９のURLであり「http://server9.com」が記載されている。
【０１０８】
さらに、レスポンス生成部９０２は、レスポンスメッセージを通信部３０１に渡す(ステップS５１１)。通信部９０１は、レスポンスメッセージを通信装置８に返す(ステップS５１２)。
【０１０９】
通信制御部８０４は、レスポンスメッセージにポリシが記載されている場合は、そのポリシをメッセージから抜き出し、そのポリシをリクエスト元のタブと関連付けて記憶する。 このとき、既に記憶しているポリシがある場合は、既に記憶しているポリシとメッセージから抜き出したポリシとの共通部分を新たなポリシとしてリクエスト元のタブ「タブＡ」に関連付けて記憶する。
【０１１０】
本動作シーケンスでは、通信制御部８０４はポリシを記憶していないため、取得したポリシを新たなポリシとして記憶する(ステップS５１３)。ここで、通信制御部８０４は、レスポンスメッセージからポリシを抜き出すために、サーバ９がレスポンスメッセージにポリシを記載する方法を知っているものとする。
【０１１１】
また、このとき通信制御部８０４が記憶したポリシについて、図１３を用いて説明する。図１３に記載される通り、通信制御部８０４は、タブＡに関連付けてアクセスが許可されるリソースのリストとして、「サーバ９」を記憶していることが分かる。さらに通信制御部８０４は、ポリシを抜き出した後のレスポンスメッセージを通信部８０３に渡す(ステップS５１４)。
【０１１２】
このように、本実施の形態では、通信装置は、通信するリソースごとにポリシを自身で保存することなく、アクセスするリソースに応じた通信制御が実現できる。
【０１１３】
本実施の形態において、ステップS５０７においてレスポンス生成部９０２がクライアントサイドアプリ(HTML)を取得する場合、そのHTML内、例えばヘッダ内に、もともと通信制御ポリシが記載されていてもよい。このとき、ポリシ保存部９０４はサーバ９の構成として不要であり、ステップS５０８およびステップS５０９も不要となる。
【０１１４】
また、本実施の形態において、ステップS５１０においてレスポンス生成部９０２がもともと定められた通信制御ポリシを、HTTPレスポンスヘッダに記述してもよい。
【０１１５】
このとき、ポリシ保存部９０４はサーバ９の構成として不要であり、ステップS５０８およびステップS５０９も不要となる。
【０１１６】
また本実施の形態では、サーバがリソースに紐づいたポリシを配布する方法について記載しているが、プロキシサーバがリソースに紐づいたポリシを通信装置に配布する方法でも良い。具体的には、サーバからのレスポンスをプロキシサーバが受け取ると、そのレスポンスに関連するポリシを含めて通信装置に返す、としても良い。
（第４の実施形態）
次に、本発明を実施するための第４の実施形態について説明する。
【０１１７】
ここでは、本発明の第１の実施形態の構成及び動作との差分のみ説明する。
【０１１８】
本実施の形態における通信装置の構成について、図１を用いて説明する。図１における通信制御部１０４は、本発明の第１の実施形態における機能に加えて、リソースへアクセスする際のリクエストがポリシに違反すると判断した場合に、ブラウザを介して利用者に警告メッセージを表示させる。あるいは、外部リソースに対して警告メッセージを送信する。ここで、外部リソースとして、この通信装置の管理会社などが該当するが、これに限定するものではない。
【０１１９】
動作シーケンスについて図６を用いて説明する。図６におけるステップS３０５において、 通信制御部１０４は、クライアントサイドアプリ１０２からのリクエストが、 ポリシに違反すると判断し、このリクエストを中止する。このとき、通信制御部１０４はさらに、ブラウザ１０１上に警告メッセージを表示する。あるいは、外部のリソースにポリシ違反があったことを意味するメッセージを送信する。このとき外部のリソースとして、クライアントサイドアプリ１０２の配信サーバであるサーバ３や、通信装置１の管理会社などが考えられる。
【０１２０】
このように、ポリシに違反する通信が起こった場合に、利用者やこの通信装置の管理会社に通知することができる。
（第５の実施形態）
次に、本発明を実施するための第５の実施形態について説明する。
【０１２１】
図１８は本発明の第５の実施形態の通信装置の構成図である。
【０１２２】
通信装置１８０１は、リソースにアクセスする通信手段１８０２と、アクセス先のサーバから通信制御ポリシを取得する通信制御ポリシ取得手段１８０３とを有する。更に、通信装置１８０１は、前記通信手段がアクセスするリソースを前記通信制御ポリシに基づいて制限する通信制御部１８０４と、を有する。通信手段１８０２がリソースにアクセスする時に該通信制御ポリシ取得手段１８０３が該リソースに関連付けられる通信制御ポリシを取得し、通信制御手段１８０４が通信手段のアクセスするリソースを該通信制御ポリシに基づいて制限する。
【０１２３】
これによって、クライアントサイドアプリが利用者にとって漏えいさせたくない情報を取得した時点で、そのアプリに通信制御を適用する。従って事前にアプリケーションごとに全てのリンクを指定した属性ファイルを用意することなく、個人情報などの重要な情報が漏えいすることを防止できる。
【０１２４】
なお、ここまで説明した各実施の形態では、通信装置やサーバは、専用の装置を想定したが、次のようなものでもよい。即ち例えば各種データ処理を行うパーソナルコンピュータ装置に、本例に相当する処理を行うボードやカードなどを装着し、各処理を、コンピュータ装置側で実行させる。このようにして、その処理を実行するソフトウェアをパーソナルコンピュータ装置に実装させて実行する構成としても良い。
【０１２５】
そのパーソナルコンピュータ装置などのデータ処理装置に実装されるプログラムについては、光ディスク，メモリカードなどの各種記録（記憶）媒体を介して配付しても良く、或いはインターネットなどの通信手段を介して配付しても良い。
【０１２６】
以上に述べた実施形態の一部又は全部は、以下の付記のようにも記載されうるが、以下には限られない。
（付記１）
リソースにアクセスする通信部と、
前記通信部が前記リソースにアクセスする時にアクセス先のサーバから前記リソースに関連付けられる通信制御ポリシを取得する通信制御ポリシ取得部と、
前記通信部がアクセスする前記リソースを前記通信制御ポリシに基づいて限定する通信制御部と、
を有することを特徴とする通信装置。
（付記２）
前記通信装置は更に、前記通信制御ポリシを保存するポリシ保存部を有し、前記通信制御部は前記通信制御ポリシを前記通信制御ポリシ保存部から取得する、
ことを特徴とする付記１の通信装置。
（付記３）
前記通信制御部は、過去に前記通信部が通信した際に取得した通信制御ポリシと、今回取得した通信制御ポリシとをマージし、マージした通信制御ポリシを利用して、通信部がアクセスするリソースを限定する
ことを特徴とする、付記２記載の通信装置。
（付記４）
前記マージは、過去に通信部が通信した際に取得した通信制御ポリシと、今回取得した通信制御ポリシとの共通部分である、
ことを特徴とする、付記３記載の通信装置。
（付記５）
取得した前記通信制御ポリシに応じて前記取得した通信制御ポリシを破棄または保持する、前記付記１乃至４のいずれかに記載された通信装置。
（付記６）
前記通信部の通信が通信制御ポリシ違反であると判断した場合に 利用者または外部サーバに対して警告メッセージを表示または送信することを特徴とする、付記１乃至５のいずれかに記載された通信装置。
（付記７）
リソースにアクセスする通信工程と、
前記通信工程が前記リソースにアクセスする時にアクセス先のサーバから前記リソースに関連付けられる通信制御ポリシを取得する通信制御ポリシ取得工程と、
前記通信工程がアクセスする前記リソースを前記通信制御ポリシに基づいて限定する通信制御工程と、
を有することを特徴とする通信制御方法。
（付記８）
前記通信制御方法は更に、前記通信制御ポリシを保存するポリシ保存工程を有し、前記通信制御ポリシを前記ポリシ保存工程から取得する、
ことを特徴とする付記７の通信制御方法。
（付記９）
前記通信制御工程は、過去に通信工程が通信した際に取得した通信制御ポリシと、今回取得した通信制御ポリシとをマージし、マージした通信制御ポリシを利用して、通信工程がアクセスするリソースを限定する
ことを特徴とする、付記８記載の通信制御方法。
（付記１０）
前記マージは、過去に通信工程が通信した際に取得した通信制御ポリシと、今回取得した通信制御ポリシとの共通部分である、
ことを特徴とする、付記９記載の通信制御方法。
（付記１１）
前記通信制御ポリシに応じて前記取得した通信制御ポリシを破棄または保持する、
ことを特徴とする前記付記７乃至１０のいずれかに記載された通信制御方法。
（付記１２）
前記通信工程の通信が通信制御ポリシ違反であると判断した場合に 利用者または外部サーバに対して警告メッセージを表示または送信する
ことを特徴とする、付記７乃至１１のいずれかに記載された通信制御方法。
（付記１３）
リソースにアクセスする通信ステップと、
前記通信ステップが前記リソースにアクセスする時にアクセス先のサーバから前記リソースに関連付けられる通信制御ポリシを取得する通信制御ポリシ取得ステップと、
前記通信ステップがアクセスする前記リソースを前記通信制御ポリシに基づいて限定する通信制御ステップと、
をコンピュータに実行させることを特徴とするプログラム。
（付記１４）
前記通信制御ステップは、過去に通信ステップが通信した際に取得した通信制御ポリシと、今回取得した通信制御ポリシとをマージし、マージした通信制御ポリシを利用して、通信ステップがアクセスするリソースを限定する
ことを特徴とする、付記１３記載のプログラム。
（付記１５）
前記マージは、過去に通信ステップが通信した際に取得した通信制御ポリシと、今回取得した通信制御ポリシとの共通部分である、
ことを特徴とする、付記１４記載のプログラム。
（付記１６）
データを送受信するサーバ及び通信装置からなる通信システムであって、
前記通信装置は、リソースにアクセスする通信部と、
前記通信部が前記リソースにアクセスする時にアクセス先のサーバから前記リソースに関連付けられる通信制御ポリシを取得する通信制御ポリシ取得部と、
前記通信部がアクセスする前記リソースを前記通信制御ポリシに基づいて限定する通信制御部と、を有し、
前記サーバは、通信装置のリクエストに応じて対応するリソース及びリソースに関連する通信制御ポリシを前記通信装置に返すレスポンス生成部と、
を有することを特徴する通信システム。
【符号の説明】
【０１２７】
１ 通信装置
１０１ ブラウザ
１０２ クライアントサイドアプリ
１０３ 通信部
１０４ 通信制御部
１０５ ポリシ保存部
２ ネットワーク
３ サーバ
３０１ サーバサイドアプリ
４ サーバ
４０１ サーバサイドアプリ
５ サーバ
６ 攻撃者サーバ
７ サーバ
７０１ サーバサイドアプリ
８ 通信装置
８０１ ブラウザ
８０２ Webアプリ
８０３ 通信部
８０４ 通信制御部
９ サーバ
９０１ 通信部
９０２ レスポンス生成部
９０３ 個人情報保存部
９０４ ポリシ保存部
【技術分野】
【０００１】
本発明はWebアプリケーションの脆弱性が原因で利用者の情報が漏えいすることを防ぐ通信装置、方法、プログラムに関する。
【背景技術】
【０００２】
近年では、インターネット上の複数のサービスや、利用者の情報などをマッシュアップしたサービスが広く利用されている。マッシュアップとはWeb上に提供されている複数の異なる情報やサービス、コンテンツなどを組み合わせて、新しいサービス等を形作ることである。これらのサービスは、Webアプリケーションとして提供され、利用者はWebブラウザを使ってそれらのWebアプリケーションを利用する。ここで、Webアプリケーションは、Webサーバ上で動作するサーバサイドのプログラムと、利用者のブラウザ上で動作するクライアントサイドのプログラムとから構成される。
【０００３】
クライアントサイドのプログラムは主にHTML（Hypertext Markup Language）やJavaScriptで実装される。また、サーバサイドのプログラムはJava（登録商標）やPHP(Hypertext Preprocessor)などで実装される。
【０００４】
マッシュアップサービスの例として、利用者の周辺の地図上にレストランの情報をマッピングして、利用者に提示するアプリケーションがある。このアプリケーションは、レストランの情報を提供するサービスと、座標から地図情報を提供するサービスと、そして利用者の現在位置情報とをマッシュアップする。
【０００５】
このようなマッシュアップサービスは、クライアントサイドのプログラム(以降、クライアントサイドアプリと呼ぶ)とサーバサイドのプログラム(以降、サーバサイドアプリと呼ぶ)との間で様々な情報を送受信する。前述の例では、まず利用者のブラウザ上のクライアントサイトアプリがレストラン情報を提供するサーバサイドアプリからレストラン情報を取得する。同時に利用者の通信端末(ローカルサーバ)のサーバサイドアプリから利用者の現在位置情報を取得する。最後に、クライアントアプリは取得した上記２つの情報を地図情報を提供するサーバサイドアプリに送り、サーバサイドアプリから地図情報を取得する。
【０００６】
このとき、利用者の通信端末上で実行されるアプリケーションやインターネット上のサービス間で送受信される情報の中には、利用者にとって漏えいさせたくない重要な情報、特に個人情報が含まれることがある。前述の例では、利用者の通信端末が個人情報を持つ場合がある。また、インターネット上のサービスが個人情報を持つ場合も考えられる。
【０００７】
このような個人情報をマッシュアップサービスで利用する場合、その個人情報は信頼できるアプリケーションに対してのみ提供されなければならない。前述の例でいうと、通信端末のサーバサイドアプリは、クライアントサイドアプリから要求があると、そのクライアントサイドアプリが信頼できるアプリケーションである場合にのみ、個人情報を渡すようにしなければならない。
【０００８】
そのため、個人情報の要求を受け付けるサーバサイドアプリは、個人情報を要求するクライアントサイドアプリを認証することが一般的である。
【０００９】
サーバサイドアプリがクライアントサイドアプリを認証する方法の例として、サーバサイドアプリがクライアントサイドアプリから受け取る要求メッセージに含まれるRefererを確認する方法が考えられる。Refererとは、あるWebページのリンクをクリックして別のページに移動したときの、リンク元のページのことである。Refererには、クライアントサイドアプリのダウンロード元のサーバ識別子が記載されている。このサーバ識別子が信頼できるサーバを指す場合は、サーバサイドサプリはこのクライアントサイドアプリを信頼する。つまり、クライアントサイドアプリの配信元サーバが信頼できる場合、そのクライアントサイドアプリも信頼することになる。
【００１０】
このように、個人情報を管理するサーバサイドアプリは、クライアントサイドアプリを認証することで、自身が管理する個人情報が信頼できないアプリケーションに漏えいすることを防止している。
【００１１】
しかし、信頼できるクライアントサイドアプリに、攻撃者が意図した悪意のあるスクリプトが埋め込まれている場合は、攻撃者に個人情報を奪取される危険性がある。このような状況は、クロスサイトスクリプティング(XSS: Cross Site Scripting)攻撃に代表されるようなサーバサイドアプリを対象とした攻撃によって、起こり得る。XSS攻撃とは、攻撃者がサイト間を横断して悪意のあるスクリプトを混入させて、脆弱なアプリケーション上で不正なスクリプトを実行させることである。個人情報が攻撃者に奪取される具体的な例を、以下にて説明する。
【００１２】
あるサーバサイドアプリは、利用者の通信端末からの要求に応じて動的にクライアントサイドアプリを生成して、通信端末に返すという動作をするものとする。具体的には、サーバサイドアプリは、利用者の通信端末から何らかの文字列、例えばユーザ名などを受け取ると、ユーザ名をクライアントサイドアプリに含めて利用者の通信端末に返す。さらに、このサーバサイドアプリは、利用者の通信端末内にあるローカルサーバ上のサーバサイドアプリから信頼されていることとする。つまり、サーバサイドアプリが生成するクライアントサイドアプリも同様に信頼されることになる。
【００１３】
ここで、このサーバサイドアプリが利用者から受け取る文字列が不正な文字列でないことを確認しない場合、このサーバサイドアプリはXSS攻撃に脆弱となる。攻撃者はこのXSS攻撃に脆弱なサーバサイドアプリを悪用して、利用者の通信端末に悪意のあるスクリプトを含んだクライアントサイドアプリをロードさせるように仕向けることができるからである。攻撃は次のように行われる。攻撃者は自身が用意したサイト上に、リンクを用意する。
【００１４】
このリンクは、前述のXSS攻撃に脆弱なサーバサイドアプリのURL(Uniform Resource Locator)であり、さらにこのURLには、パラメータとして、悪意のあるスクリプトを含んでいる。利用者が前述のリンクをクリックすることで、サーバサイドアプリに悪意のあるスクリプトを送ることになる。その結果、サーバサイドアプリは、利用者から受け取った悪意のあるスクリプトを含むクライアントサイドアプリを生成し、利用者の通信端末に返すことになる。
【００１５】
このとき、通信端末が受け取るクライアントサイドアプリが含むスクリプトは２つの動作をする。１つは、通信端末のサーバサイドアプリから個人情報を取得するスクリプト(スクリプト１)と、その情報を攻撃者サイトに送信するスクリプト(スクリプト２)である。
【００１６】
上記スクリプトは、通信端末上のブラウザにロードされると同時に実行される。まず、スクリプト１により通信端末は、ローカルサーバ上のサーバサイドアプリに個人情報を要求する。クライアントサイドアプリはもともとこのサーバサイドアプリから信頼されるアプリであるため、ローカルサーバ上のサーバサイドアプリは通信端末に個人情報に返す。 次にスクリプト２により通信端末は、スクリプト１により取得した個人情報を攻撃者サイトに送信する。このようにして、攻撃者は利用者の個人情報を奪取することに成功する。
【００１７】
上記のような、サーバサイドアプリの脆弱性が原因となる個人情報の漏えいは何らかの方法で防ぐ必要がある。この問題に対応する為の関連技術として、通信端末がクライアントサイドアプリの通信制御を行うことが考えられる。例えば、通信端末がクライアントサイドアプリの正しい通信先のリストを把握しておき、このアプリがそのリスト以外と通信しようとすると、その通信を中止するという方法がある。その結果、信頼できるクライアントサイドアプリに悪意のあるスクリプトが含まれていて、このスクリプトによって通信端末が攻撃者サイトに個人情報を送信しようとしても、その通信を止めることができる。通信端末は、攻撃者サイトへの通信は通信先のリストに記載のないため、その通信が不正な通信であると判断できるからである。
【００１８】
上記の関連した技術が記載された文献として、非特許文献１がある。非特許文献１には、通信端末内のアプリケーションマネージャがJavaアプリケーションの属性ファイルを参照することで、アプリケーションに通信制限を掛けることができるとしている。具体的には、属性ファイルにはJavaアプリケーションの通信先のリストが記載されており、そのアプリケーションがそのリストに記載されない通信先と通信しようとすると、アプリケーションマネージャがその通信を中止できる技術が記載されている。
【００１９】
また、関連した技術として下記特許文献１には、次のような技術が記載されている。即ち、ローカルネットワークを介して他のネットワークに接続する携帯端末上で動作するアプリケーションが、ローカルネットワークから機密情報を流出させることを防ぐ技術である。この関連技術では通信端末が、アプリケーションが実行する通信を監視する通信監視手段とアプリケーションの通信において接続されたネットワークの履歴を示す通信履歴情報を記録する。同時に且つ該通信履歴情報に応じて前記アプリケーションによるネットワークへの接続の可否を判定する通信制御手段とを備えている。
【００２０】
また、関連した技術として下記特許文献２には、次の様な技術が記載されている。即ち、
各通信装置の要求に基づいた通信転送ポリシを通信制御装置に反映させることのできる通信装置を提供するものである。
【先行技術文献】
【非特許文献】
【００２１】
【非特許文献１】JSR 118 Expert Group, Java Community Process「Mobile Information Device Profile for Java. 2 Micro Edition」(P431〜P452)[online].(retrieved on 2010-03-16)Retrieved from the Internet: <URL:http://www.nada.kth.se/projects/proj03/minime/other/midp-2_0-fr-spec.pdf>.
【特許文献】
【００２２】
【特許文献１】特開２００８−１９１８６２号公報
【特許文献２】特開２００５―２１７８２８号公報
【発明の概要】
【発明が解決しようとする課題】
【００２３】
しかし、この非特許文献１の技術をクライアントサイドのWebアプリケーションの通信制御として適用することは困難である。なぜなら、クライアントサイドアプリでは不特定多数のサイトへのリンクを持つことが多いため、先行技術１のようにWebアプリケーションが通信し得る全ての通信先を事前に指定することは現実的でないためである。不特定多数のサイトへのリンクとして、関連サイトへのリンクや、広告によるリンクが挙げられる。これらのリンクの総数は多数であり、アプリケーションごとに全てのリンクを指定した属性ファイルを用意することはアプリケーション開発者に負担がかかる。
【００２４】
もともとクライアントサイドアプリに通信制限を掛ける理由は、利用者にとって漏えいさせたくない情報を守ることである。そのため、クライアントサイドアプリが上記の情報を取得する前であれば、そのアプリに通信制限を掛ける必要がない。つまり、漏えいさせたくない情報を持たないクライアントサイドアプリには通信制限を掛けず、上記の情報を取得したときに通信制限を掛けることが望ましいということになる。しかし、先行技術１ではそのような通信制御を実現できない。
【００２５】
また特許文献１では、通信制御をかけるためのポリシを通信履歴ＤＢに蓄積する必要があるので、通信装置の資源を圧迫するという不具合を生じる可能性がある。
【００２６】
また、特許文献２では、ある通信装置が起動したとき、あるいは通信装置が特定のサービスを起動した際に対応する通信装置にポリシが適用されるというものであり、アクセスするリソースの種別等に拘わらずポリシが適用されてしまうという無駄が生じる恐れがある。
【００２７】
本発明はクライアントサイドアプリの通信制御に利用でき、そのアプリが個人情報などの重要な情報を取得した場合に、上記のような不具合無く個人情報が漏えいすることを防止できる通信装置等を提供することを目的としている。
【課題を解決するための手段】
【００２８】
本発明の通信装置は、リソースにアクセスする通信部と、
前記通信部が前記リソースにアクセスする時にアクセス先のサーバから前記リソースに関連付けられる通信制御ポリシを取得する通信制御ポリシ取得部と、
前記通信部がアクセスする前記リソースを前記通信制御ポリシに基づいて限定する通信制御部と、を有する。
【００２９】
また、本発明の通信制御方法は、リソースにアクセスする通信工程と、
前記通信工程が前記リソースにアクセスする時にアクセス先のサーバから前記リソースに関連付けられる通信制御ポリシを取得する通信制御ポリシ取得工程と、
前記通信工程がアクセスする前記リソースを前記通信制御ポリシに基づいて限定する通信制御工程と、を有する。
【００３０】
また、本発明のプログラムは、リソースにアクセスする通信ステップと、
前記通信ステップが前記リソースにアクセスする時にアクセス先のサーバから前記リソースに関連付けられる通信制御ポリシを取得する通信制御ポリシ取得ステップと、
前記通信ステップがアクセスする前記リソースを前記通信制御ポリシに基づいて限定する通信制御ステップと、をコンピュータに実行させる。
【００３１】
また、本発明の通信システムはデータを送受信するサーバ及び通信装置からなる通信システムであって、
前記通信装置は、リソースにアクセスする通信部と、
前記通信部が前記リソースにアクセスする時にアクセス先のサーバから前記リソースに関連付けられる通信制御ポリシを取得する通信制御ポリシ取得部と、
前記通信部がアクセスする前記リソースを前記通信制御ポリシに基づいて限定する通信制御部と、を有し、
前記サーバは、通信装置のリクエストに応じて対応するリソース及びリソースに関連する通信制御ポリシを前記通信装置に返すレスポンス生成部と、
を有する。
【発明の効果】
【００３２】
本発明では、事前にアプリケーションごとに全てのリンクを指定した属性ファイルを用意することなく、個人情報などの重要な情報が漏えいすることを防止できる通信装置、方法、プログラムを提供することを提供することが出来る。
【図面の簡単な説明】
【００３３】
【図１】本発明の第１の実施形態における通信装置を示す構成図である。
【図２】本発明の第１の実施形態における通信制御部がリクエスト元のタブと関連付けて記憶しているポリシの例である。
【図３】本発明の第１の実施形態におけるポリシ保存部が保存するポリシの例である。
【図４】本発明の第１の実施形態における通信装置がクライアントサイドアプリをブラウザにロードする処理を示す動作シーケンスである。
【図５】本発明の第１の実施形態におけるクライアントサイドアプリがリソースにアクセスする処理を示す動作シーケンスである。
【図６】本発明の第１の実施形態におけるクライアントサイドアプリ内に埋め込まれた悪意のあるスクリプトが攻撃者サーバと通信する処理を示す動作シーケンスである。
【図７】本発明の第１の実施形態における状態遷移図である。
【図８】本発明の第２の実施形態におけるポリシ保存部が保存するポリシの例である。
【図９】本発明の第２の実施形態における通信制御部がリクエスト元のタブと関連付けて記憶しているポリシの例である。
【図１０】本発明の第２の実施形態における通信制御部がリクエスト元のタブと関連付けて記憶しているポリシの例である。
【図１１】本発明の第２の実施形態におけるクライアントサイドアプリがページ遷移する際にポリシを操作する処理を示す動作シーケンスである。
【図１２】本発明の第３の実施形態における通信システムの構成図である。
【図１３】本発明の第３の実施形態における通信制御部がリクエスト元のタブと関連付けて記憶しているポリシの例である。
【図１４】本発明の第３の実施形態におけるサーバが保存するポリシの例である。
【図１５】本発明の第３の実施形態における通信装置上のクライアントサイドアプリがリソースを取得する処理を示す動作シーケンスである。
【図１６】本発明の第３の実施形態におけるレスポンスヘッダの例である。
【図１７】本発明の第３の実施形態におけるレスポンスメッセージボディの例である。
【図１８】本発明の第５の実施形態における通信装置の構成図である。
【発明を実施するための形態】
【００３４】
（第１の実施形態）
次に、本発明の第１の実施形態について図面を参照して詳細に説明する。
図１は本発明の第１の実施形態における通信装置の構成図である。通信装置１は、ブラウザ１０１を持ち、ブラウザ１０１はクライアントサイドアプリ１０２、通信部１０３、通信制御部１０４、およびポリシ保存部１０５から構成される。
【００３５】
通信装置１は、例えば、ノートＰＣ、携帯電話、ＰＤＡなどのサーバとの通信手段を持つ通信端末がこれに該当する。ブラウザ１０１は、通信装置がサーバからダウンロードしたWebアプリケーションを実行し、ユーザインターフェイスを持つ。例として、Firefox（登録商標）、Internet Explorer（登録商標）、Safari（登録商標）などが挙げられる。クライアントサイドアプリ１０２は、HTMLやJavaScript（登録商標）などの言語で記述されるアプリケーションである。
【００３６】
通信部１０３は、リソースとの通信手段である。ここで、リソースとは、サーバ、サーバサイドアプリ、サーバが管理する情報などを示す。通信制御部１０４は、ブラウザが送信するリクエストをフックする。さらに、自身が記憶している通信制御ポリシを確認して、そのリクエストが許可されない通信である場合はその通信を中止する。
【００３７】
このポリシの例を図２を用いて説明する。図２を参照すると、ブラウザのタブＡに関連付けられて通信が許可されるリソースが通信制御部１０４に記憶されている。これは、タブＡからのリクエストにサーバ３、サーバ４への通信が許可されていることを示す。このタブとは、ブラウザ１０１の１つのウィンドウに複数のアプリケーションがロードされる場合に、各アプリケーションを区別するために用いられるものである。「サーバ３、サーバ４」はリソースの識別子であり、ホスト名やURLがこれに該当する。例えば、ホスト名として「server1、localhost・・・」が、 URLとして「http://server1.com、http://localhost.local、http://server1.com /server1.cgi、http://server1.com/server1.cgi?parama=123、http: //server1.com/*」などが挙げられる。
【００３８】
さらに、通信装置がリソースにアクセスする度に、そのリソースに関連するポリシを、ポリシ保存部１０５から取り出し、ブラウザのタブと紐づけし、関連付けて記憶する。このとき、過去に記憶しているポリシがある場合は、記憶しているポリシと最後にアクセスしたリソースに関連する通信制御ポリシとをマージしたポリシを最新のポリシとして記憶する。
【００３９】
マージする例としては、２つのポリシの共通部分を取る方法が考えられる。例えば、通信制御部１０４が既に記憶しているポリシにより通信を許可されるリソースがサーバ３、サーバ４、サーバ５であり、さらに、通信制御部１０４がポリシ保存部から取り出したポリシにより通信を許可されるリソースが、サーバ３、サーバ４である場合を考える。このとき、上記２つのポリシの共通部分により通信を許可されるリソースは、サーバ３、サーバ４になる。
【００４０】
なお、通信制御部１０４は、利用者が新規作成したタブに関連付けられて記憶しているポリシを持たない。そのため、利用者が新規作成したタブには通信制御は適用されないことになる。前述のリソースに関連付けられて記憶されているポリシは、ポリシ保存部１０５が保存している。
【００４１】
このポリシについて図３を用いて説明する。図３を参照すると、リソースに関連付けられて通信が許可されるリソースが保存されている。具体的には、リソース「サーバ４」に関連付けられて、通信が許可されるリソース「サーバ３、サーバ４」が保存されている。このポリシの意味するところは、サーバ４と通信した場合、それ以降はサーバ３もしくはサーバ４とのみ通信が可能になる、ということである。
【００４２】
次に、動作シーケンス図を参照して本実施の形態の全体の動作について詳細に説明する。
本実施の形態の全体の動作は、
１）通信装置がクライアントサイドアプリをブラウザにロードする処理
２）クライアントサイドアプリがリソースを取得する処理
３）クライアントサイドアプリ内に埋め込まれた悪意のあるスクリプトが攻撃者サーバと通信する処理
４）ブラウザ上のタブの状態遷移
の４つから構成される。
以下、それぞれの処理の詳細について説明する。
【００４３】
まず、「１）通信装置がクライアントサイドアプリをブラウザにロードする処理」について図４を用いて説明する。以下、図４の構成について、図１との差分のみ説明する。ネットワーク２は、通信装置１とサーバ３の間で送受信されるデータの伝送経路であり、無線LAN、基地局、ルータ、などネットワーク装置で構成される。サーバ３は、リクエストを受けた通信装置にクライアントサイドアプリ１０２を配信するサーバである。サーバサイドアプリ３０１は、サーバ３上に配置されるWebアプリケーションであり、利用者からリクエストを受けるとクライアントサイドアプリ１０２を生成するアプリケーションである。
【００４４】
利用者は、ブラウザ１０１を起動し(タブが新規に作成される)、サーバ３にクライアントサイドアプリ１０２を要求する(ステップS１０１)。通信部１０３は、クライアントサイドアプリ１０２を取得するためのリクエストを通信制御部１０４に送信する(ステップS１０２)。 通信制御部１０４は、リクエストを受け取るとリクエスト元のブラウザのタブを特定する。ここでは、リクエスト元のタブを「タブＡ」とする(ステップS１０３)。
【００４５】
さらに、通信制御部１０４は、そのタブＡに関連するポリシを自身が記憶しているか確認する(ステップS１０４)。このとき、ポリシを記憶していない場合は、リクエストをネットワーク２を介してサーバ３に送信する。ポリシを記憶している場合は、処理が分岐するが、説明は後述する。
【００４６】
本実施の形態では、利用者は新規にタブを作成しているため、ステップＳ１０４では、このタブＡに関連するポリシはない。そのため、リクエストをサーバ３に送信する(ステップS１０５)。サーバ３はリクエストを受け取るとサーバサイドアプリ３０１を用いて、クライアントサイドアプリ１０２を生成し、ネットワーク２を介して通信装置１に返す(ステップS１０６)。
【００４７】
通信制御部１０４は、サーバ３からのレスポンスを受け取ると、受け取ったクライアントアプリ１０２をブラウザにロードする。同時に、通信制御部１０４は、ポリシ保存部１０５にステップS１０５におけるリクエストの送信先(サーバ３もしくは、サーバ３のWebアプリ１０２)に関連するポリシを要求する(ステップS１０７)。
【００４８】
ポリシ保存部１０５は、サーバ３に関するポリシがある場合は、それを返す。 また、サーバ３に関するポリシがない場合は、関連するポリシがないことを通知する。本シーケンスでは、サーバ３に関連するポリシはないため、ポリシがないことを通知する(ステップS１０８)。
【００４９】
通信制御部１０４は、ポリシを受け取った場合は、ポリシに記載される通信を許可されるリソースをステップS１０３で特定したリクエスト元タブと関連付けて記憶する。このとき、既にリクエスト元のタブに関連付けるポリシがある場合は、そのポリシとステップS１０８で受け取ったポリシとの共通部分を新たなポリシとして、リクエスト元のタブに関連付けて記憶する。
【００５０】
例えば、既にリクエスト元のタブに関連付けられているポリシにより通信を許可されるリソースがサーバ３、サーバ４、サーバ５であり、さらに、ステップS１０８で受け取ったポリシにより通信を許可されるリソースが、サーバ３、サーバ４である場合を考える。このとき、リクエスト元のタブに関連付けて記憶されるリソースは、サーバ３、サーバ４になる。また、ステップS１０８でポリシのない通知を受けとる場合は、何もしない。本シーケンスでは、ポリシがない通知を受け取るため、ここでは何も処理しない(ステップS１０９)。
【００５１】
さらに、通信制御部１０４は、通信部１０３にクライアントサイドアプリ１０２を渡す(ステップS１１０)。
【００５２】
次に、「２）クライアントサイドアプリがリソースを取得する処理」について図５を用いて説明する。以下、図５の構成について、図４との差分のみ説明する。クライアントサイドアプリ１０２は、１）において、サーバ３からロードしたクライアントサイドのWebアプリケーションである。サーバ４は、リクエストを受けた通信装置に個人情報を配信するサーバである。サーバサイドアプリ４０１は、リクエストを受け取ると個人情報を生成するWebアプリケーションである。
【００５３】
利用者は、クライアントサイドアプリ１０２を利用してサーバ４に個人情報を要求する(ステップS２０１)。通信部１０３は受け取ったリクエストを通信制御部１０４に送信する(ステップS２０２)。
【００５４】
通信制御部１０４は、リクエストを受け取るとリクエスト元のブラウザのタブ「タブＡ」を特定する(ステップS２０３)。さらに、そのタブに関連するポリシを自身が記憶しているか確認する(ステップS２０４)。
【００５５】
本シーケンスでは、ステップS１０９でポリシを記憶していないため、タブAには、この時点では無制限で通信が許可されている。 そのため、通信制御部１０４はリクエストをサーバ４へ送信する(ステップS２０５)。
【００５６】
サーバ４はリクエストを受け取ると、サーバサイドアプリ４０１を利用して個人情報を生成し、通信装置１に返す(ステップS２０６)。通信制御部１０４は、個人情報を受け取ると、ステップS２０５における通信先のリソース(サーバ４もしくはサーバ４が提供する個人情報)に関連するポリシをポリシ保存部１０５に要求する(ステップS２０７)。
【００５７】
ポリシ保存部１０５は、要求されるポリシがある場合は、そのポリシを返す(ステップS２０８)。 本シーケンスでは図３に示す通り、ポリシ保存部１０５が、サーバ４に関連するポリシとしてサーバ３、サーバ４にアクセスが許可されるポリシを保持している。
【００５８】
通信制御部１０４は、ポリシを受け取ると、ステップS２０３で特定したリクエスト元のブラウザのタブ「タブＡ」と関連付けて記憶する(ステップS２０９)。このとき通信制御部１０４が、記憶するポリシは図２に示す通りである。図２を参照すると、タブＡに関連付けてリソース「サーバ３、サーバ４」が記憶されている。このポリシの意味するところは、この時点で、タブＡに通信制御が掛けられており、許可される通信先は、サーバ３、サーバ４に限定されるということである。
【００５９】
さらに通信制御部１０４は、個人情報を通信部１０３に渡す(ステップS２１０)。通信部１０３は、個人情報をクライアントサイドアプリ１０２に渡す(ステップS２１１)。
【００６０】
次に、「３）クライアントサイドアプリ内に埋め込まれた悪意のあるスクリプトが攻撃者サーバと通信する処理」について図６を用いて説明する。以下、図６の構成について、図４との差分のみ説明する。これは、クライアントサイドアプリ１０２を生成する図４におけるサーバサイドアプリ３０１がXSS攻撃に脆弱であることを想定しており、その結果、図６におけるクライアントサイドアプリ１０２には、悪意のあるスクリプトが埋め込まれている。
【００６１】
さらに、このスクリプトは、２）で取得した個人情報を攻撃者サーバ６に送るように動作する。また、攻撃者サーバ６は、クライアントサイドアプリ１０２から個人情報を受け取るために攻撃者が用意するサーバである。
【００６２】
クライアントサイドアプリ１０２は、悪意のあるスクリプトにより、攻撃者サーバ６にステップS２１１で取得した個人情報を送信することを要求する(ステップS３０１)。通信部１０３は受け取ったリクエストを通信制御部１０４に送信する(ステップS３０２)。
【００６３】
通信制御部１０４は、リクエストを受け取るとリクエスト元のブラウザのタブ「タブＡ」を特定する(ステップS３０３)。さらに、そのタブに関連するポリシを自身が記憶しているか確認する(ステップS３０４)。
【００６４】
本シーケンスでは、ステップS２０９でポリシを記憶している。さらに、ステップS３０２で受け取ったリクエストが、記憶しているポリシで許可される通信かどうかを確認する(ステップS３０５)。本シーケンスでは、図２に示す通り、タブＡにはサーバ３、サーバ４が記憶されている。そのため、攻撃者サーバ６への通信が許可されていないと判断し、リクエストを中止する(ステップS３０６)。
【００６５】
このように、クライアントサイドアプリ１０２に悪意のあるスクリプトが埋め込まれている場合でも、取得した個人情報を攻撃者サーバ送信すること中止するので個人情報が意図せずに漏えいすることを阻止できる。
【００６６】
次に、「４）ブラウザ上のタブの状態遷移」について図７を用いて説明する。この状態遷移図は、図３のポリシを元に作成したものである。
【００６７】
まず、利用者がブラウザ上で新規タブを作成した時点では、初期状態となる。初期状態では、ポリシがない。ここで、初期状態からサーバ３と通信(クライアントサイドアプリ１０２を取得)する。このとき、サーバ３に関連付けられるポリシがないため、初期状態を維持する。つまり、ブラウザがクライアントサイドアプリ１０２をロードした時点では、リクエスト元のタブに通信制御は適用されない。
【００６８】
次に、初期状態からサーバ４と通信(個人情報を取得)するときを考える。ここでは、サーバ４に関連するポリシがあるため、リクエスト元のタブに通信制御が適用されて状態１に遷移する。この状態１は、リクエスト元のタブが通信できるリソースが、サーバ３、サーバ４に限定される、という状態である。
【００６９】
また、初期状態からサーバ５に通信するときを考える。このとき、サーバ５に関連するポリシがあるため、リクエスト元のタブに通信制御が適用されて状態２に遷移する。この状態２は、リクエスト元のタブが通信できるリソースが、サーバ３、サーバ４、サーバ５に限定される、という状態である。さらに、状態２の状態からサーバ４にアクセスするときを考える。ここでは、サーバ４に関連するポリシがあるため、リクエスト元のタブに通信制御が適用される。このとき、状態２のポリシと、サーバ４に関連するポリシの共通部分が新たなポリシとなる。このとき、リクエスト元のタブが通信できるリソースは、サーバ３、サーバ４である。つまり、状態１に遷移することになる。
【００７０】
このように、リソースにアクセスして初めて、そのリソースに関する通信制御が適用されることになる。以降、異なるリソースにアクセスするたびに、そのリソースに関連したポリシが追加されるようになる。
【００７１】
このように、本実施形態では、事前にアプリケーションごとに全てのリンクが指定された属性ファイルを用意せずに、クライアントサイドアプリが利用者にとって漏えいさせたくない情報を取得した場合の情報漏えいを防止できる、という効果を有する。なぜなら、情報にアクセスした時点で、リクエスト元のタブにその情報に関連するポリシに応じた通信制御が適用されるためである。
【００７２】
なお、本実施の形態において、通信制御部１０４は、あるリクエスト元のタブ上のクライアントサイドアプリがページを遷移する場合、そのタブに関連付けて記憶しているポリシを削除してもよい。
【００７３】
さらに、本実施の形態において、通信制御部１０４は、通信したリソースに関連するポリシをリクエスト元のタブと関連付けて記憶したが、これをリクエスト元のウィンドウや、クライアントサイドアプリ１０２のURLに関連付けて記憶してもよい。
【００７４】
さらに、本実施の形態において、通信制御部１０４が通信先と自身が記憶するポリシを比較する際、それらが完全一致した場合にその通信先へのリクエストを許可することを想定しているが、部分一致した場合にその通信先リクエストを許可するようにしてもよい。
【００７５】
さらに、本実施の形態において、通信制御部１０４は、利用者が新規作成したタブに関連付けられて記憶するポリシとして、あらかじめ定められるポリシを記憶しても構わない。 このとき、上記のタブには、あらかじめ定められたポリシを元に、通信制御が適用されることになる。
【００７６】
さらに、本実施の形態において、ブラウザ１０１は、クライアントサイドアプリを実行する機能のみを持つとしても良い。
【００７７】
さらに、本実施の形態において、通信制御部１０４、ポリシ保存部１０５は、ブラウザ１０１に内蔵されているが、それらの構成は、ブラウザ１０１の外部にあっても良い。
（第２の実施形態）
次に、本発明の第２の実施形態について説明する。
ここでは、本発明の第１の実施形態で述べた構成及び動作との差分のみ説明する。
【００７８】
本発明を実施するための第２の実施の形態における通信装置の構成図は図１と同様である。ここで、通信制御部１０４は、さらにリソースに関連付けられるポリシに記載される、 ポリシを削除する条件に一致するリソースにアクセスした場合、記憶しているポリシを破棄する。さらに、ポリシ保存部１０５は、図８に示すようなポリシを持つ。図８を参照すると、通信したリソースに関連付けてポリシを削除する条件として通信先リソースが保存されている。
【００７９】
次に、本発明の第２の実施形態の動作を説明する。
本実施形態の全体の動作は
１）通信装置がクライアントサイドアプリをブラウザにロードする処理
２）クライアントサイドアプリがリソースを取得する処理
３）クライアントサイドアプリがページ遷移する際にポリシを操作する処理
から構成される。以下は、上記の処理の詳細について説明する。
【００８０】
１）通信装置がクライアントサイドアプリをブラウザにロードする処理について、図４を用いて説明する。第１の実施形態における図４の処理とは、ステップS１０８〜S１０９が異なる。
【００８１】
ポリシ保存部１０５は、ポリシを要求されると、サーバ３に関連するポリシを返す。 この時のポリシの例として図８を用いて説明する。図８を参照すると、サーバ３に関連付けられるポリシには、通信が許可されるリソースの記載がない。これは無制限で通信が許可されることを意味する。
【００８２】
さらに、ページ遷移時にポリシをKeepする条件として「サーバ７」が記載されている。一方、ページ遷移時にポリシを削除する条件として「*」が記載されている。
前者「サーバ７」の記載は、ページ遷移時、つまりクライアントサイドアプリ１０２が異なるクライアントサイドアプリに遷移する場合に、通信先のリソースがサーバ７である場合は、リクエスト元のタブに関連付けて記憶するポリシを保持することを意味する。
【００８３】
ページを遷移する例としては、クライアントサイドアプリ上のaタグで張られるリンクを利用者がクリックする場合が挙げられる。また、ポリシを削除しない状況として例えば、遷移前のクライアントサイドアプリから異なるクライアントサイドアプリにページする際に、遷移前のアプリが取得した利用者にとって漏えいしたくない情報を、遷移後のページに渡すときが考えられる。このとき、遷移後のアプリは利用者にとって漏えいしたくない情報を持つため、その情報漏えいを防止するために、遷移前のアプリの通信制御がそのまま適用されることが望ましい。
【００８４】
一方、後者「*」の記載は所謂ワイルドカード、即ち、任意の文字列にマッチする特殊文字を意味する。従って、この場合、通信先のリソースが「サーバ７」以外の全ての場合に、リクエスト元のタブに関連付けて記憶するポリシを削除することを意味する。これは以降サーバ７にアクセスすると通信制御部１０４はリクエスト元のタブに関連付けて記憶しているポリシを削除することを意味する(ステップS１０８)。
【００８５】
ポリシを削除しない状況としては、例えば、あるクライアントサイドアプリから異なるクライアントサイドアプリのページに移動（遷移）する場合がある。遷移前のクライアントサイドアプリが取得した情報を、遷移後のクライアントサイドアプリに渡さない場合は、遷移後のクライアントサイドアプリが利用者にとって漏えいさせたくない情報を持たない。このような場合、遷移前のクライアントサイドアプリに適用される通信制御は解除しても良い。
【００８６】
通信制御部１０４は、渡されたポリシをステップS１０３で特定したタブと関連付けて記憶する。このとき記憶するポリシは図９の通りである。図９を参照すると、タブＡに関連付けられて、通信が許可されるリソースは空白であるため無制限で通信を許可されている。さらに、ポリシを削除する条件としてサーバ７が記載されており、サーバ７と通信を行う時点で通信制御部１０４が記憶するポリシを削除している。
【００８７】
次に、２）クライアントサイドアプリがリソースを取得する処理について図５を用いて説明する。第１の実施形態における図５の処理とは、ステップS２０９が異なる。
【００８８】
通信制御部１０４は、ポリシを受け取ると、既に記憶しているポリシを受け取ったポリシの共通部分を新しいポリシとして記憶する。このとき記憶するポリシは図１０のようになる。ここでは、通信が許可されるリソースは、「サーバ３、サーバ４、サーバ７」であり、 ポリシを削除する条件となる通信先リソースは「サーバ７」となる。
【００８９】
次に、３）クライアントサイドアプリがページ遷移する際にポリシを操作する処理について図１１を用いて説明する。 図１１の構成について、図４との違いのみ説明する。サーバ７は、通信装置からのリクエストに対してクライアントサイドアプリを配信するサーバである。
【００９０】
サーバサイドアプリ７０１は、クライアントサイドアプリ１０２上でaタグなどによりリンクされているWebアプリケーションであり、クライアントサイドアプリ１０２とは異なるクライアントサイドアプリを生成する。
【００９１】
利用者は、クライアントサイドアプリ１０２のaタグをクリックし、ページを遷移するためのリクエストをサーバ７に送信する(ステップS４０１)。 図１１におけるステップS４０２〜S４０４は、図４のステップS１０２〜S１０４と同様の処置であるため説明を省略する。 通信制御部１０４は、記憶しているポリシでアクセスが許可されるリクエストかどうかを確認する(ステップS４０５)。このとき、記憶しているポリシは図１０に示す通りであり、サーバ７へのアクセスは許可されているため、ステップS４０６に進む。
【００９２】
さらに通信制御部１０４は、このリクエストがページ遷移時のリクエストである場合に、ポリシを操作する条件に一致するかどうかを確認する(ステップS４０６)。このとき、図１０のポリシを再度参照する。
【００９３】
このとき、「サーバ７との通信」は、記憶しているポリシを保持する条件「サーバ７：Keep」に合致するため、記憶しているポリシを保持(Keep)する(ステップS４０７)。図１１における以降のステップS４０８〜S４１３は、図４のステップS１０５〜S１１０と同様の処理であるため説明を省略する。
【００９４】
なお、本実施の形態において、ステップS４０１において、ページを遷移するためのリクエストをサーバ７とは異なるサーバに送信した場合は、記憶しているポリシを削除する。ステップS４０７において、記憶しているポリシを削除するための条件「*：Delete」と一致するためである。
【００９５】
このように、本発明の第２の実施形態では、あるクライアントサイドアプリが異なるクライアントサイドアプリに遷移する際に、リクエスト元のタブに適用される通信制御ポリシを継続して保持する否かを、遷移する際の通信先に応じて制御できるようになる。
（第３の実施形態）
次に、本発明を実施するための第３の実施形態について説明する。
ここでは、第１の実施形態で述べた構成及び動作との差分のみ説明する。
【００９６】
図１２は本発明の第３の実施形態における通信システムの構成図である。第３の実施の形態における通信システムは、通信装置８とサーバ９、ネットワーク２で構成される。通信装置８における８０１〜８０３の構成は、図１の１０１〜１０３の構成と同様であるため 説明を省略する。通信装置８は、通信制御部８０４を備える。
【００９７】
通信制御部８０４は、図１の通信制御部１０４に加えて、サーバ９から受け取ったHTTPレスポンスからポリシを取得し、そのポリシをタブに関連付けて記憶する。タブに関連付けて記憶されるポリシの例を図１３を用いて説明する。
【００９８】
図１３を参照すると、タブＡに関連付けて通信が許可されるリソースとしてサーバ９を記憶している。
【００９９】
サーバ９は、通信部９０１、レスポンス生成部９０２、個人情報保存部９０３、ポリシ保存部９０４を備える。通信部９０１は、通信装置８とのデータの送受信を行う通信手段である。
【０１００】
個人情報保存部９０３は、サーバ９が管理する利用者の情報（個人情報）である。ポリシ保存部９０４は、個人情報に関連付けて記録される通信制御ポリシである。このポリシについて図１４を用いて説明する。
【０１０１】
図１４では、個人情報保存部９０３に保存されている個人情報に関連付けて通信が許可されるリソースの一覧が記載されている。ここでは、サーバ９がアクセスが許可されるリソースとなる。
【０１０２】
次に、本発明の第３の実施形態の動作について、通信装置が個人情報を取得する処理の詳細について説明する。
【０１０３】
クライアントサイドアプリ８０２がサーバ９から個人情報を取得する処理について図１５を用いて説明する。
【０１０４】
図１５のステップS５０１〜S５０５は、図５のS２０１〜S２０５と同様の処理であるため説明を省略する。通信部９０１は、リクエストを受け取ると、リクエストをレスポンス生成部９０２に渡す(ステップS５０６)。レスポンス生成部９０２は、個人情報保存部９０３に保存すべき個人情報を取得し保存する(ステップS５０７)。
【０１０５】
さらにレスポンス生成部９０２は、個人情報保存部９０３に保存された個人情報に関連するポリシをポリシ保存部９０４に要求する(ステップS５０８)。ポリシ保存部９０４は、関連するポリシがある場合は、そのポリシを返す(ステップS５０９)。
図１４を参照すると、このときポリシ保存部９０４は、アクセスが許可されるリソースのリストとして、「サーバ９」を返す。レスポンス生成部９０２は、ステップS５０７で取得して個人情報保存部９０３に保存された個人情報とステップS５０９で取得したポリシを元に、レスポンスを生成する(ステップS５１０)。レスポンスメッセージにポリシを記載する方法としては、例えばHTTPレスポンスヘッダに記載する方法がある。
【０１０６】
具体的には、図１６を用いて説明する。図１６を参照すると、HTTPレスポンスヘッダに、アクセス許可リストを記載する拡張ヘッダとして「Access-Permit」が追加されている。さらに、この拡張ヘッダに記載される内容は、ステップS５０９で取得したポリシに記載されるアクセスが許可されるリソースのリストである「サーバ９」が記載される。
【０１０７】
この「サーバ９」はサーバ９のURLであり「http://server9.com」が記載されている。 また別の方法として、例えばHTTPレスポンスのボディ内に記載する方法もある。 具体的には、図１７を用いて説明する。図１７を参照すると、HTTPレスポンスのボディの、先頭にアクセス許可リストを記載している。また、そのときの記載の内容は、ステップS５０９で取得したポリシに記載されるアクセスが許可されるリソースのリストである 「サーバ９」が記載される。この「サーバ９」はサーバ９のURLであり「http://server9.com」が記載されている。
【０１０８】
さらに、レスポンス生成部９０２は、レスポンスメッセージを通信部３０１に渡す(ステップS５１１)。通信部９０１は、レスポンスメッセージを通信装置８に返す(ステップS５１２)。
【０１０９】
通信制御部８０４は、レスポンスメッセージにポリシが記載されている場合は、そのポリシをメッセージから抜き出し、そのポリシをリクエスト元のタブと関連付けて記憶する。 このとき、既に記憶しているポリシがある場合は、既に記憶しているポリシとメッセージから抜き出したポリシとの共通部分を新たなポリシとしてリクエスト元のタブ「タブＡ」に関連付けて記憶する。
【０１１０】
本動作シーケンスでは、通信制御部８０４はポリシを記憶していないため、取得したポリシを新たなポリシとして記憶する(ステップS５１３)。ここで、通信制御部８０４は、レスポンスメッセージからポリシを抜き出すために、サーバ９がレスポンスメッセージにポリシを記載する方法を知っているものとする。
【０１１１】
また、このとき通信制御部８０４が記憶したポリシについて、図１３を用いて説明する。図１３に記載される通り、通信制御部８０４は、タブＡに関連付けてアクセスが許可されるリソースのリストとして、「サーバ９」を記憶していることが分かる。さらに通信制御部８０４は、ポリシを抜き出した後のレスポンスメッセージを通信部８０３に渡す(ステップS５１４)。
【０１１２】
このように、本実施の形態では、通信装置は、通信するリソースごとにポリシを自身で保存することなく、アクセスするリソースに応じた通信制御が実現できる。
【０１１３】
本実施の形態において、ステップS５０７においてレスポンス生成部９０２がクライアントサイドアプリ(HTML)を取得する場合、そのHTML内、例えばヘッダ内に、もともと通信制御ポリシが記載されていてもよい。このとき、ポリシ保存部９０４はサーバ９の構成として不要であり、ステップS５０８およびステップS５０９も不要となる。
【０１１４】
また、本実施の形態において、ステップS５１０においてレスポンス生成部９０２がもともと定められた通信制御ポリシを、HTTPレスポンスヘッダに記述してもよい。
【０１１５】
このとき、ポリシ保存部９０４はサーバ９の構成として不要であり、ステップS５０８およびステップS５０９も不要となる。
【０１１６】
また本実施の形態では、サーバがリソースに紐づいたポリシを配布する方法について記載しているが、プロキシサーバがリソースに紐づいたポリシを通信装置に配布する方法でも良い。具体的には、サーバからのレスポンスをプロキシサーバが受け取ると、そのレスポンスに関連するポリシを含めて通信装置に返す、としても良い。
（第４の実施形態）
次に、本発明を実施するための第４の実施形態について説明する。
【０１１７】
ここでは、本発明の第１の実施形態の構成及び動作との差分のみ説明する。
【０１１８】
本実施の形態における通信装置の構成について、図１を用いて説明する。図１における通信制御部１０４は、本発明の第１の実施形態における機能に加えて、リソースへアクセスする際のリクエストがポリシに違反すると判断した場合に、ブラウザを介して利用者に警告メッセージを表示させる。あるいは、外部リソースに対して警告メッセージを送信する。ここで、外部リソースとして、この通信装置の管理会社などが該当するが、これに限定するものではない。
【０１１９】
動作シーケンスについて図６を用いて説明する。図６におけるステップS３０５において、 通信制御部１０４は、クライアントサイドアプリ１０２からのリクエストが、 ポリシに違反すると判断し、このリクエストを中止する。このとき、通信制御部１０４はさらに、ブラウザ１０１上に警告メッセージを表示する。あるいは、外部のリソースにポリシ違反があったことを意味するメッセージを送信する。このとき外部のリソースとして、クライアントサイドアプリ１０２の配信サーバであるサーバ３や、通信装置１の管理会社などが考えられる。
【０１２０】
このように、ポリシに違反する通信が起こった場合に、利用者やこの通信装置の管理会社に通知することができる。
（第５の実施形態）
次に、本発明を実施するための第５の実施形態について説明する。
【０１２１】
図１８は本発明の第５の実施形態の通信装置の構成図である。
【０１２２】
通信装置１８０１は、リソースにアクセスする通信手段１８０２と、アクセス先のサーバから通信制御ポリシを取得する通信制御ポリシ取得手段１８０３とを有する。更に、通信装置１８０１は、前記通信手段がアクセスするリソースを前記通信制御ポリシに基づいて制限する通信制御部１８０４と、を有する。通信手段１８０２がリソースにアクセスする時に該通信制御ポリシ取得手段１８０３が該リソースに関連付けられる通信制御ポリシを取得し、通信制御手段１８０４が通信手段のアクセスするリソースを該通信制御ポリシに基づいて制限する。
【０１２３】
これによって、クライアントサイドアプリが利用者にとって漏えいさせたくない情報を取得した時点で、そのアプリに通信制御を適用する。従って事前にアプリケーションごとに全てのリンクを指定した属性ファイルを用意することなく、個人情報などの重要な情報が漏えいすることを防止できる。
【０１２４】
なお、ここまで説明した各実施の形態では、通信装置やサーバは、専用の装置を想定したが、次のようなものでもよい。即ち例えば各種データ処理を行うパーソナルコンピュータ装置に、本例に相当する処理を行うボードやカードなどを装着し、各処理を、コンピュータ装置側で実行させる。このようにして、その処理を実行するソフトウェアをパーソナルコンピュータ装置に実装させて実行する構成としても良い。
【０１２５】
そのパーソナルコンピュータ装置などのデータ処理装置に実装されるプログラムについては、光ディスク，メモリカードなどの各種記録（記憶）媒体を介して配付しても良く、或いはインターネットなどの通信手段を介して配付しても良い。
【０１２６】
以上に述べた実施形態の一部又は全部は、以下の付記のようにも記載されうるが、以下には限られない。
（付記１）
リソースにアクセスする通信部と、
前記通信部が前記リソースにアクセスする時にアクセス先のサーバから前記リソースに関連付けられる通信制御ポリシを取得する通信制御ポリシ取得部と、
前記通信部がアクセスする前記リソースを前記通信制御ポリシに基づいて限定する通信制御部と、
を有することを特徴とする通信装置。
（付記２）
前記通信装置は更に、前記通信制御ポリシを保存するポリシ保存部を有し、前記通信制御部は前記通信制御ポリシを前記通信制御ポリシ保存部から取得する、
ことを特徴とする付記１の通信装置。
（付記３）
前記通信制御部は、過去に前記通信部が通信した際に取得した通信制御ポリシと、今回取得した通信制御ポリシとをマージし、マージした通信制御ポリシを利用して、通信部がアクセスするリソースを限定する
ことを特徴とする、付記２記載の通信装置。
（付記４）
前記マージは、過去に通信部が通信した際に取得した通信制御ポリシと、今回取得した通信制御ポリシとの共通部分である、
ことを特徴とする、付記３記載の通信装置。
（付記５）
取得した前記通信制御ポリシに応じて前記取得した通信制御ポリシを破棄または保持する、前記付記１乃至４のいずれかに記載された通信装置。
（付記６）
前記通信部の通信が通信制御ポリシ違反であると判断した場合に 利用者または外部サーバに対して警告メッセージを表示または送信することを特徴とする、付記１乃至５のいずれかに記載された通信装置。
（付記７）
リソースにアクセスする通信工程と、
前記通信工程が前記リソースにアクセスする時にアクセス先のサーバから前記リソースに関連付けられる通信制御ポリシを取得する通信制御ポリシ取得工程と、
前記通信工程がアクセスする前記リソースを前記通信制御ポリシに基づいて限定する通信制御工程と、
を有することを特徴とする通信制御方法。
（付記８）
前記通信制御方法は更に、前記通信制御ポリシを保存するポリシ保存工程を有し、前記通信制御ポリシを前記ポリシ保存工程から取得する、
ことを特徴とする付記７の通信制御方法。
（付記９）
前記通信制御工程は、過去に通信工程が通信した際に取得した通信制御ポリシと、今回取得した通信制御ポリシとをマージし、マージした通信制御ポリシを利用して、通信工程がアクセスするリソースを限定する
ことを特徴とする、付記８記載の通信制御方法。
（付記１０）
前記マージは、過去に通信工程が通信した際に取得した通信制御ポリシと、今回取得した通信制御ポリシとの共通部分である、
ことを特徴とする、付記９記載の通信制御方法。
（付記１１）
前記通信制御ポリシに応じて前記取得した通信制御ポリシを破棄または保持する、
ことを特徴とする前記付記７乃至１０のいずれかに記載された通信制御方法。
（付記１２）
前記通信工程の通信が通信制御ポリシ違反であると判断した場合に 利用者または外部サーバに対して警告メッセージを表示または送信する
ことを特徴とする、付記７乃至１１のいずれかに記載された通信制御方法。
（付記１３）
リソースにアクセスする通信ステップと、
前記通信ステップが前記リソースにアクセスする時にアクセス先のサーバから前記リソースに関連付けられる通信制御ポリシを取得する通信制御ポリシ取得ステップと、
前記通信ステップがアクセスする前記リソースを前記通信制御ポリシに基づいて限定する通信制御ステップと、
をコンピュータに実行させることを特徴とするプログラム。
（付記１４）
前記通信制御ステップは、過去に通信ステップが通信した際に取得した通信制御ポリシと、今回取得した通信制御ポリシとをマージし、マージした通信制御ポリシを利用して、通信ステップがアクセスするリソースを限定する
ことを特徴とする、付記１３記載のプログラム。
（付記１５）
前記マージは、過去に通信ステップが通信した際に取得した通信制御ポリシと、今回取得した通信制御ポリシとの共通部分である、
ことを特徴とする、付記１４記載のプログラム。
（付記１６）
データを送受信するサーバ及び通信装置からなる通信システムであって、
前記通信装置は、リソースにアクセスする通信部と、
前記通信部が前記リソースにアクセスする時にアクセス先のサーバから前記リソースに関連付けられる通信制御ポリシを取得する通信制御ポリシ取得部と、
前記通信部がアクセスする前記リソースを前記通信制御ポリシに基づいて限定する通信制御部と、を有し、
前記サーバは、通信装置のリクエストに応じて対応するリソース及びリソースに関連する通信制御ポリシを前記通信装置に返すレスポンス生成部と、
を有することを特徴する通信システム。
【符号の説明】
【０１２７】
１ 通信装置
１０１ ブラウザ
１０２ クライアントサイドアプリ
１０３ 通信部
１０４ 通信制御部
１０５ ポリシ保存部
２ ネットワーク
３ サーバ
３０１ サーバサイドアプリ
４ サーバ
４０１ サーバサイドアプリ
５ サーバ
６ 攻撃者サーバ
７ サーバ
７０１ サーバサイドアプリ
８ 通信装置
８０１ ブラウザ
８０２ Webアプリ
８０３ 通信部
８０４ 通信制御部
９ サーバ
９０１ 通信部
９０２ レスポンス生成部
９０３ 個人情報保存部
９０４ ポリシ保存部
【特許請求の範囲】
【請求項１】
リソースにアクセスする通信部と、
前記通信部が前記リソースにアクセスする時にアクセス先のサーバから前記リソースに関連付けられる通信制御ポリシを取得する通信制御ポリシ取得部と、
前記通信部がアクセスする前記リソースを前記通信制御ポリシに基づいて限定する通信制御部と、
を有することを特徴とする通信装置。
【請求項２】
前記通信装置は更に、前記通信制御ポリシを保存するポリシ保存部を有し、前記通信制御部は前記通信制御ポリシを前記通信制御ポリシ保存部から取得する、
ことを特徴とする請求項１の通信装置。
【請求項３】
前記通信制御部は、過去に前記通信部が通信した際に取得した通信制御ポリシと、今回取得した通信制御ポリシとをマージし、マージした通信制御ポリシを利用して、通信部がアクセスするリソースを限定する
ことを特徴とする、請求項２記載の通信装置。
【請求項４】
前記マージは、過去に通信部が通信した際に取得した通信制御ポリシと、今回取得した通信制御ポリシとの共通部分である、
ことを特徴とする、請求項３記載の通信装置。
【請求項５】
取得した前記通信制御ポリシに応じて前記取得した通信制御ポリシを破棄または保持する、前記請求項１乃至４のいずれかに記載された通信装置。
【請求項６】
前記通信部の通信が通信制御ポリシ違反であると判断した場合に 利用者または外部サーバに対して警告メッセージを表示または送信することを特徴とする、請求項１乃至５のいずれかに記載された通信装置。
【請求項７】
リソースにアクセスする通信工程と、
前記通信工程が前記リソースにアクセスする時にアクセス先のサーバから前記リソースに関連付けられる通信制御ポリシを取得する通信制御ポリシ取得工程と、
前記通信工程がアクセスする前記リソースを前記通信制御ポリシに基づいて限定する通信制御工程と、
を有することを特徴とする通信制御方法。
【請求項８】
前記通信制御方法は更に、前記通信制御ポリシを保存するポリシ保存工程を有し、前記通信制御ポリシを前記ポリシ保存工程から取得する、
ことを特徴とする請求項７の通信制御方法。
【請求項９】
前記通信制御工程は、過去に通信工程が通信した際に取得した通信制御ポリシと、今回取得した通信制御ポリシとをマージし、マージした通信制御ポリシを利用して、通信工程がアクセスするリソースを限定する
ことを特徴とする、請求項８記載の通信制御方法。
【請求項１０】
データを送受信するサーバ及び通信装置からなる通信システムであって、
前記通信装置は、リソースにアクセスする通信部と、
前記通信部が前記リソースにアクセスする時にアクセス先のサーバから前記リソースに関連付けられる通信制御ポリシを取得する通信制御ポリシ取得部と、
前記通信部がアクセスする前記リソースを前記通信制御ポリシに基づいて限定する通信制御部と、を有し、
前記サーバは、通信装置のリクエストに応じて対応するリソース及びリソースに関連する通信制御ポリシを前記通信装置に返すレスポンス生成部と、
を有することを特徴する通信システム。
【請求項１】
リソースにアクセスする通信部と、
前記通信部が前記リソースにアクセスする時にアクセス先のサーバから前記リソースに関連付けられる通信制御ポリシを取得する通信制御ポリシ取得部と、
前記通信部がアクセスする前記リソースを前記通信制御ポリシに基づいて限定する通信制御部と、
を有することを特徴とする通信装置。
【請求項２】
前記通信装置は更に、前記通信制御ポリシを保存するポリシ保存部を有し、前記通信制御部は前記通信制御ポリシを前記通信制御ポリシ保存部から取得する、
ことを特徴とする請求項１の通信装置。
【請求項３】
前記通信制御部は、過去に前記通信部が通信した際に取得した通信制御ポリシと、今回取得した通信制御ポリシとをマージし、マージした通信制御ポリシを利用して、通信部がアクセスするリソースを限定する
ことを特徴とする、請求項２記載の通信装置。
【請求項４】
前記マージは、過去に通信部が通信した際に取得した通信制御ポリシと、今回取得した通信制御ポリシとの共通部分である、
ことを特徴とする、請求項３記載の通信装置。
【請求項５】
取得した前記通信制御ポリシに応じて前記取得した通信制御ポリシを破棄または保持する、前記請求項１乃至４のいずれかに記載された通信装置。
【請求項６】
前記通信部の通信が通信制御ポリシ違反であると判断した場合に 利用者または外部サーバに対して警告メッセージを表示または送信することを特徴とする、請求項１乃至５のいずれかに記載された通信装置。
【請求項７】
リソースにアクセスする通信工程と、
前記通信工程が前記リソースにアクセスする時にアクセス先のサーバから前記リソースに関連付けられる通信制御ポリシを取得する通信制御ポリシ取得工程と、
前記通信工程がアクセスする前記リソースを前記通信制御ポリシに基づいて限定する通信制御工程と、
を有することを特徴とする通信制御方法。
【請求項８】
前記通信制御方法は更に、前記通信制御ポリシを保存するポリシ保存工程を有し、前記通信制御ポリシを前記ポリシ保存工程から取得する、
ことを特徴とする請求項７の通信制御方法。
【請求項９】
前記通信制御工程は、過去に通信工程が通信した際に取得した通信制御ポリシと、今回取得した通信制御ポリシとをマージし、マージした通信制御ポリシを利用して、通信工程がアクセスするリソースを限定する
ことを特徴とする、請求項８記載の通信制御方法。
【請求項１０】
データを送受信するサーバ及び通信装置からなる通信システムであって、
前記通信装置は、リソースにアクセスする通信部と、
前記通信部が前記リソースにアクセスする時にアクセス先のサーバから前記リソースに関連付けられる通信制御ポリシを取得する通信制御ポリシ取得部と、
前記通信部がアクセスする前記リソースを前記通信制御ポリシに基づいて限定する通信制御部と、を有し、
前記サーバは、通信装置のリクエストに応じて対応するリソース及びリソースに関連する通信制御ポリシを前記通信装置に返すレスポンス生成部と、
を有することを特徴する通信システム。
【図１】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図１２】
【図１３】
【図１４】
【図１５】
【図１６】
【図１７】
【図１８】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図１２】
【図１３】
【図１４】
【図１５】
【図１６】
【図１７】
【図１８】
【公開番号】特開２０１２−４８３５７（Ｐ２０１２−４８３５７Ａ）
【公開日】平成２４年３月８日（２０１２．３．８）
【国際特許分類】
【出願番号】特願２０１０−１８８０７５（Ｐ２０１０−１８８０７５）
【出願日】平成２２年８月２５日（２０１０．８．２５）
【出願人】（０００００４２３７）日本電気株式会社 (19,353)
【Ｆターム（参考）】
【公開日】平成２４年３月８日（２０１２．３．８）
【国際特許分類】
【出願日】平成２２年８月２５日（２０１０．８．２５）
【出願人】（０００００４２３７）日本電気株式会社 (19,353)
【Ｆターム（参考）】
[ Back to top ]