(57)【要約】【課題】クロスオリジンアクセス時における信頼性を向上させる情報処理装置を提供する。【解決手段】ＣＯＲＳモード判定部１３は、ＨＴＴＰリクエストのアクセス元オリジン及びアクセス先オリジンの情報を基に、アクセス元オリジンとは異なるオリジンをアクセス先オリジンとする異接続リクエストか否かを判定する。リクエスト送信部１４は、異接続リクエストの場合、異なるオリジン間のアクセスの形式に変更して他オリジン向けリクエストを生成し、アクセス先オリジンへ送信する。オリジン比較部１８は、他オリジン向けリクエストに対する応答を受信し、異接続リクエストの場合、応答から取得したアクセス先のオリジンへのアクセスが許可された許可オリジンの情報を基に、アクセス元オリジンが許可オリジンか否かを判定する。レスポンス送信部１９は、アクセス元オリジンが許可オリジンの場合、応答をＨＴＴＰリクエストに対する応答の形式に変更し送信する。【選択図】図２
2016066110.tif 000002
【特許請求の範囲】
【請求項１】
ＨＴＴＰリクエストに含まれるアクセス元オリジン及びアクセス先オリジンの情報を基に、前記ＨＴＴＰリクエストが前記アクセス元オリジンとは異なるオリジンを前記アクセス先オリジンとする異接続リクエストか否かを判定する判定部と、
前記ＨＴＴＰリクエストが前記異接続リクエストの場合、前記ＨＴＴＰリクエストを異なるオリジン間のアクセスの形式に変更して他オリジン向けリクエストを生成し、前記アクセス先オリジンへ送信するリクエスト送信部と、
前記他オリジン向けリクエストに対する応答を前記アクセス先オリジンから受信し、前記ＨＴＴＰリクエストが前記異接続リクエストの場合、前記応答から取得した前記アクセス先のオリジンへのアクセスが許可された許可オリジンの情報を基に、前記アクセス元オリジンが前記許可オリジンか否かを判定する許可判定部と、
前記アクセス元オリジンが前記許可オリジンの場合、受信した前記応答を前記ＨＴＴＰリクエストに対する応答の形式に変更し送信する応答送信部と
を備えたことを特徴とする情報処理装置。
【請求項２】
前記判定部による判定結果を記憶する記憶部をさらに備え、
前記許可判定部は、前記記憶部に記憶されている前記判定結果を基に、前記ＨＴＴＰリクエストが前記異接続リクエストか否かを判定することを特徴とする請求項１に記載の情報処理装置。
【請求項３】
前記判定部は、前記ＨＴＴＰリクエストに前記アクセス制御情報が付加されているか否かを判定し、
前記許可判定部は、前記応答に前記アクセス制御情報の使用を許可する情報が付加されているか否かを判定し、
前記応答送信部は、前記ＨＴＴＰリクエストにアクセス制御情報が付加されていた場合、前記アクセス元オリジンがデータの使用が許可された許可オリジンであることに加えて、前記応答に前記アクセス制御情報の使用を許可する情報が付加されている場合に、受信した前記応答を前記ＨＴＴＰリクエストに対する応答の形式に変更し送信する
ことを特徴とする請求項１又は２に記載の情報処理装置。
【請求項４】
前記リクエスト送信部は、前記アクセス元オリジンを示す情報を前記ＨＴＴＰリクエストに追加することで、他オリジン向けリクエストを生成することを特徴とする請求項１〜３のいずれか一つに記載の情報処理装置。
【請求項５】
前記ＨＴＴＰリクエストが前記異接続リクエストでない場合、
前記リクエスト送信部は、前記ＨＴＴＰリクエストを前記アクセス先オリジンへ送信し、
前記応答送信部は、前記応答を前記アクセス元オリジンへ送信する
ことを特徴とする請求項１〜４のいずれか一つに記載の情報処理装置。
【請求項６】
ＨＴＴＰリクエストに含まれるアクセス元オリジン及びアクセス先オリジンの情報を基に、前記ＨＴＴＰリクエストが前記アクセス元オリジンとは異なるオリジンを前記アクセス先オリジンとする異接続リクエストか否かを判定し、
前記ＨＴＴＰリクエストが前記異接続リクエストの場合、前記ＨＴＴＰリクエストを異なるオリジン間のアクセスの形式に変更して他オリジン向けリクエストを生成し、前記アクセス先オリジンへ送信し、
前記他オリジン向けリクエストに対する応答を前記アクセス先オリジンから受信し、
前記ＨＴＴＰリクエストが前記異接続リクエストの場合、前記応答から取得した前記アクセス先のオリジンへのアクセスが許可された許可オリジンの情報を基に、前記アクセス元オリジンが前記許可オリジンか否かを判定し、
前記アクセス元オリジンが前記許可オリジンの場合、受信した前記応答を前記ＨＴＴＰリクエストに対する応答の形式に変更し送信する
ことを特徴とする情報処理装置制御方法。
【請求項７】
ＨＴＴＰリクエストに含まれるアクセス元オリジン及びアクセス先オリジンの情報を基に、前記ＨＴＴＰリクエストが前記アクセス元オリジンとは異なるオリジンを前記アクセス先オリジンとする異接続リクエストか否かを判定し、
前記ＨＴＴＰリクエストが前記異接続リクエストの場合、前記ＨＴＴＰリクエストを異なるオリジン間のアクセスの形式に変更して他オリジン向けリクエストを生成し、前記アクセス先オリジンへ送信し、
前記他オリジン向けリクエストに対する応答を前記アクセス先オリジンから受信し、
前記ＨＴＴＰリクエストが前記異接続リクエストの場合、前記応答から取得した前記アクセス先のオリジンへのアクセスが許可された許可オリジンの情報を基に、前記アクセス元オリジンが前記許可オリジンか否かを判定し、
前記アクセス元オリジンが前記許可オリジンの場合、受信した前記応答を前記ＨＴＴＰリクエストに対する応答の形式に変更し送信する
処理をコンピュータに実行させることを特徴とする情報処理装置制御プログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、情報処理装置、情報処理装置制御方法及び情報処理装置制御プログラムに関する。
【背景技術】
【０００２】
近年、ウェブサイトのセキュリティ上の単位としてオリジンという単位が用いられることがある。オリジンは、ＵＲＬ（Uniform  Resource  Locator）におけるスキーム、ホスト及びポートの組み合わせによって決定される。例えば、http://www.expample.com:8080/というＵＲＬであれば、スキームは「ｈｔｔｐ」であり、ホストは「ｗｗｗ．ｅｘａｍｐｌｅ．ｃｏｍ」であり、ポートは「８０８０」である。
【０００３】
このようなオリジンにおいて、オリジン間で安全にデータをやり取りするための規格として、ＣＯＲＳ（Cross-Origin  Resource  Sharing）が提案されている。クロスオリジンとは、ウェブブラウザ上において、異なるオリジンからダウンロードしたコンテンツ間でデータを利用し合う技術である。クロスオリジンは、複数のウェブサイトが提供するサービスを組み合わせて新しいサービスを作り出すマッシュアップを行う際に用いられる。例えば、異なるオリジンの地図サイトと店舗検索サイトを組み合わせて、近距離店舗表示サイトを作成する場合などである。
【０００４】
このような状況下において、ＣＯＲＳに未対応のブラウザが依然として多く利用されている。その理由としては、ＣＯＲＳ対応のブラウザが動作しないＯＳ（Operating  System）などがコンピュータ上で動作する場合などが考えられる。
【０００５】
例えば、ウェブ文書規格ＨＴＭＬ（Hyper  Text  Markup  Language）として、モバイル端末を中心に近年利用されることが増えてきたＨＴＭＬ５がある。ＨＴＭＬ５では、別プラグインを使用せずに様々なインターネットアプリケーションに対応するため、従来のＨＴＭＬ４に不足していた機能が追加された。
【０００６】
そして、ＨＴＭＬ５は、ＣＯＲＳに対応しており、クロスオリジンアクセスにおけるサーバ側でのアクセス制御が可能とされた。具体的には、アクセス元のオリジンがクロスオリジンアクセスのリクエストをアクセス先のオリジンに送信する際に、ブラウザがオリジンヘッダを付与し、アクセス元のオリジンをアクセス先のオリジンに通知する。これにより、アクセス先のオリジンにおいて、アクセス元のオリジンに基づくアクセス制御が可能となる。ブラウザは、アクセス先のオリジンからの応答に付与されたＡｃｃｅｓｓ−Ｃｏｎｔｒｏｌ−Ａｌｌｏｗ−Ｏｒｉｇｉｎヘッダによりアクセス先のオリジンのデータにアクセス可能なオリジンの通知を受ける。アクセス可能なオリジンにアクセス元のオリジンが存在していれば、ブラウザは、アクセス先のオリジンからのデータをリクエスト送信元のデータに組み合わせて表示する。これに対して、アクセス可能なオリジンにアクセス元のオリジンが存在していない場合、ブラウザは、エラーを表示する。
【０００７】
これに対して、ＨＴＭＬ５以前のウェブ文書規格ＨＴＭＬであるＨＴＭＬ４では、クロスオリジンは原則禁止されている。すなわち、ＨＴＭＬ４では、あるオリジンのページから別のオリジンへのデータのリクエストは原則禁止されている。この規則は、ＳＯＰ（Same  Origin  Policy）の制限と呼ばれる。
【０００８】
ただし、ＨＴＭＬ４を利用する場合であっても、クロスオリジンアクセスを行いたいとの要望は多い。そこで、ＨＴＭＬ４を利用しつつクロスオリジンアクセスを実行する方法が提案されてきた。例えば、＜ｓｃｒｉｐｔ＞のｓｃｒ属性は、ＳＯＰの対象外であるため、別オリジンのデータをスクリプトとして読み込むことでクロスオリジンを可能にする方法がある。
【０００９】
また、ＨＴＭＬ５準拠でないブラウザクライアントに対してゲートウェイサービスを用いて分散ウェブアプリケーションを提供する従来技術が有る。また、ウェブブラウザ内で実行されるソフトウェア間の通信を中継サーバを介して行い、異なるオリジン間のデータを組み合わせる従来技術が有る。
【先行技術文献】
【特許文献】
【００１０】
【特許文献１】特表２０１２−５２５６５９号公報
【特許文献２】特開２０１０−２６２４５３号公報
【発明の概要】
【発明が解決しようとする課題】
【００１１】
しかしながら、スクリプトを用いてクロスオリジンアクセスを実現する場合、アクセス先のオリジン、すなわち他のオリジンからリクエストを受ける側のオリジンにおいて、アクセス制御を行うことが難しい。この方法では、例えば、アクセス先のオリジンンは、アクセス元のオリジンを把握することが困難であり、また、応答にアクセス可能なオリジンを指定することが困難である。そのため、クロスオリジンアクセス時における情報処理システムの信頼性を確保することが困難となってしまう。
【００１２】
また、ゲートウェイサービスを用いる従来技術や中継サーバを用いる従来技術であっても、リクエスト送信元のオリジンはアクセス制御を行うことは困難であり、クロスオリジンアクセス時における情報処理システムの信頼性を確保することが困難である。
【００１３】
１つの側面では、本発明は、クロスオリジンアクセス時におけるシステムの信頼性を向上させる情報処理装置、情報処理装置制御方法及び情報処理装置制御プログラムを提供することを目的とする。
【課題を解決するための手段】
【００１４】
本願の開示する情報処理装置、情報処理装置制御方法及び情報処理装置制御プログラムは、一つの態様において、判定部は、ＨＴＴＰリクエストに含まれるアクセス元オリジン及びアクセス先オリジンの情報を基に、前記ＨＴＴＰリクエストが前記アクセス元オリジンとは異なるオリジンを前記アクセス先オリジンとする異接続リクエストか否かを判定する。リクエスト送信部は、前記ＨＴＴＰリクエストが前記異接続リクエストの場合、前記ＨＴＴＰリクエストを異なるオリジン間のアクセスの形式に変更して他オリジン向けリクエストを生成し、前記アクセス先オリジンへ送信する。許可判定部は、前記他オリジン向けリクエストに対する応答を前記アクセス先オリジンから受信し、前記ＨＴＴＰリクエストが前記異接続リクエストの場合、前記応答から取得した前記アクセス先のオリジンへのアクセスが許可された許可オリジンの情報を基に、前記アクセス元オリジンが前記許可オリジンか否かを判定する。応答送信部は、前記アクセス元オリジンが前記許可オリジンの場合、受信した前記応答を前記ＨＴＴＰリクエストに対する応答の形式に変更し送信する。
【発明の効果】
【００１５】
一つの態様によれば、クロスオリジンアクセス時におけるシステムの信頼性を向上させることができるという効果を奏する。
【図面の簡単な説明】
【００１６】
【図１】図１は、ＣＯＲＳを実行する情報処理システムの全体構成図である。
【図２】図２は、実施例１に係るプロキシ装置のブロック図である。
【図３】図３は、リクエストの識別子を説明するための図である。
【図４】図４は、ＨＴＴＰリクエストヘッダの一例の図である。
【図５】図５は、ＣＯＲＳ対応リクエストのリクエストヘッダの一例の図である。
【図６】図６は、実施例１に係るオリジン判定情報の一例の図である。
【図７】図７は、ＣＯＲＳ対応リクエストに対するレスポンスの一例の図である。
【図８】図８は、ＣＯＲＳ非対応ブラウザに送信するレスポンスの一例の図である。
【図９】図９は、エラーレスポンスの一例の図である。
【図１０】図１０は、実施例１に係る情報処理システムにおけるクロスオリジンアクセス処理のフローチャートである。
【図１１】図１１は、実施例１に係るプロキシ装置によるＣＯＲＳ対応処理のフローチャートである。
【図１２】図１２は、実施例２に係るオリジン判定情報の一例の図である。
【図１３】図１３は、実施例２におけるＣＯＲＳ対応リクエストに対するレスポンスの一例の図である。
【図１４】図１４は、プロキシ装置のハードウェア構成図である。
【発明を実施するための形態】
【００１７】
以下に、本願の情報処理装置、情報処理装置制御方法及び情報処理装置制御プログラムの実施例を図面に基づいて詳細に説明する。なお、以下の実施例により本願の開示する情報処理装置、情報処理装置制御方法及び情報処理装置制御プログラムが限定されるものではない。特に以下では、情報処理装置としてプロキシ装置を例に説明するが、以下に説明する機能を備える情報処理装置であればこれに限らない。
【実施例１】
【００１８】
図１は、ＣＯＲＳを実行する情報処理システムの全体構成図である。本実施例に係る情報処理システムには、図１に示すように、オリジン３０１及びオリジン３０２という２つのオリジンが存在する。
【００１９】
そして、本実施例に係る情報処理システムは、プロキシ装置１、端末装置２、並びに、サーバ３１及び３２を有する。サーバ３１は、オリジン３０１のデータを提供するサーバである。また、サーバ３２は、オリジン３０２のデータを提供するサーバである。
【００２０】
以下では、端末装置２に読み込まれたオリジン３０２のコンテンツが、オリジン３０１のコンテンツを利用するＣＯＲＳを実行する場合を例に、各装置について説明する。また、以下では、ＨＴＴＰリクエストを単に「リクエスト」と呼ぶ。
【００２１】
端末装置２は、ＣＯＲＳ非対応ブラウザ２１を有する。ＣＯＲＳ非対応ブラウザ２１は、操作者からの指示を受けて、オリジン３０２のコンテンツを要求するリクエストをサーバ３２に対して送信する。その後、端末装置２は、サーバ３２からレスポンスを受けて、オリジン３０２のコンテンツを取得し、ＣＯＲＳ非対応ブラウザ２１にオリジン３０２のコンテンツを読み込ませる。
【００２２】
次に、ＣＯＲＳ非対応ブラウザ２１は、オリジン３０２のコンテンツからオリジン３０１のコンテンツを取得する命令である＜ｓｃｒｉｐｔ  ｓｃｒ＝“オリジン３０１”＞を読み込む。そして、ＣＯＲＳ非対応ブラウザ２１は、オリジン３０１のコンテンツを要求するサーバ３１に対するリクエストを、プロキシ装置１へ送信する。ここで、オリジン３０１とオリジン３０２とは、異なるオリジンであり、オリジン３０２のコンテンツによるオリジン３０１のコンテンツの要求は、クロスオリジンアクセスとなる。
【００２３】
その後、オリジン３０１がオリジン３０２に対してクロスオリジンアクセスを許可した場合、ＣＯＲＳ非対応ブラウザ２１は、プロキシ装置１からオリジン３０１のコンテンツを取得し、オリジン３０１及び３０２のコンテンツを組み合わせて操作者に提供する。
【００２４】
プロキシ装置１は、オリジン３０１のコンテンツを要求するサーバ３１宛てのリクエストを端末装置２から受信する。そして、プロキシ装置１は、リクエストがクロスオリジンアクセスを行うリクエストか否かを判定する。
【００２５】
この場合、リクエストがクロスオリジンアクセスであるので、プロキシ装置１は、ＣＯＲＳに対応した形式にリクエストを変換しＣＯＲＳ対応リクエストを生成する。そして、プロキシ装置１は、ＣＯＲＳ対応リクエストをサーバ３１へ送信する。
【００２６】
その後、プロキシ装置１は、送信したＣＯＲＳ対応リクエストに対する応答をサーバ３１から受信する。そして、プロキシ装置１は、オリジン３０１とのクロスオリジンアクセスに対する許可オリジンの情報を、サーバ３１から受信した応答から取得する。次に、プロキシ装置１は、オリジン３０２が許可オリジンに含まれるか否かを判定する。オリジン３０２が許可オリジンに含まれる場合、プロキシ装置１は、ＣＯＲＳ非対応ブラウザ２１が解釈できる形式にサーバ３１から受信した応答を変更しリクエストに対するレスポンスを生成する。そして、プロキシ装置１は、生成したレスポンスを端末装置２へ送信する。
【００２７】
サーバ３２は、オリジン３０１のコンテンツを要求するＣＯＲＳ対応リクエストをプロキシ装置１から受信する。そして、サーバ３２は、要求されたコンテンツとともに、オリジン３０１に対する許可オリジンの情報を含む応答を生成する。そして、サーバ３２は、生成した応答をプロキシ装置１へ送信する。
【００２８】
次に、図２を参照してプロキシ装置１の詳細について説明する。図２は、実施例１に係るプロキシ装置のブロック図である。以下では、リクエストを発行したオリジンを「アクセス元オリジン」といい、リクエストの宛先となるオリジンを「アクセス先オリジン」という。
【００２９】
プロキシ装置１は、リクエスト受信部１１、リクエストヘッダ解析部１２、ＣＯＲＳモード判定部１３、リクエスト送信部１４、ＣＯＲＳモード保存部１５を有する。さらに、プロキシ装置１は、レスポンス受信部１６、レスポンスヘッダ解析部１７、オリジン比較部１８及びレスポンス送信部１９を有する。
【００３０】
リクエスト受信部１１は、ＣＯＲＳ非対応ブラウザ２１からオリジン３０１のコンテンツを要求するリクエストを受信する。リクエスト受信部１１は、一般的なプロキシと同様の手順でリクエストの受信を行う。次に、リクエスト受信部１１は、ＴＣＰ（Transmission  Control  Protocol）コネクション毎に、受信した順にＨＴＴＰリクエストに対して連番で番号を割り当てる。そして、リクエスト受信部１１は、受信したリクエストをリクエストヘッダ解析部１２へ出力する。
【００３１】
ここで、図３を参照して、リクエストの識別子について説明する。図３は、リクエストの識別子を説明するための図である。リクエストは、ＴＣＰコネクションによりリクエスト受信部１１へ送信される。そして、ＨＴＴＰリクエストは、１つのＴＣＰコネクションに複数存在する。
【００３２】
ここで、ＴＣＰコネクションは、接続元と接続先のＩＰアドレスとポート番号との組で識別することができる。ここでは、ＣＯＲＳ非対応ブラウザ２１からプロキシ装置１へ送られたリクエストであるので、接続元は端末装置２のＩＰアドレス及びポートであり、接続先はプロキシ装置１のＩＰアドレス及びポートとなる。そして、１つのＴＣＰコネクションに存在するＨＴＴＰリクエストは、同一のコネクション内で届いたリクエストの順番で一意に識別することができる。このことから、ＨＴＴＰリクエストは、接続先と接続先のＩＰアドレスとポート番号との組と、リクエスト受信部１１により割り当てられた通し番号の組み合わせで一意に識別することができる。すなわち、図３における各行がリクエストの識別子を表す。以下では、この組み合わせを、「リクエストの識別子」として説明する。
【００３３】
例えば、図３における上から２つのリクエストは、同じＴＣＰコネクションを用いた送られたリクエストを表す。そして、それらのリクエストは、リクエスト通し番号によって区別される。また、上２つのリクエストと、上から３つ目のリクエストは、ＴＣＰコネクションを表す接続元と接続先のＩＰアドレスとポート番号との組によって識別される。
【００３４】
リクエストヘッダ解析部１２は、ＣＯＲＳ非対応ブラウザ２１から送信されたオリジン３０１のコンテンツを要求するリクエストの入力をリクエスト受信部１１から受ける。次に、リクエストヘッダ解析部１２は、受信したリクエストからリクエストヘッダを取得する。
【００３５】
次に、リクエストヘッダ解析部１２は、取得したリクエストヘッダの解析を行う。ここでは、リクエストヘッダ解析部１２が図４に示すリクエストヘッダ２０１を取得した場合で説明する。図４は、ＨＴＴＰリクエストヘッダの一例の図である。
【００３６】
ここでのリクエストは、プロキシ装置１へのリクエストであるため、リクエストヘッダ２０１の冒頭のリクエストライン２１１にホスト名まで含めたＵＲＬが記載される。ここでは、オリジン３０２である「http://www.example.com」のページ「/crossTest.html」から、オリジン３０１である「http://www.example.org」のページ「test/html」にクロスオリジンアクセスのリクエストが発行された場合で説明する。このリクエストは、ＪＳＯＮＰ（JavaScript（登録商標）  Object  Notation  with  padding）形式であるものとする。
【００３７】
リクエストヘッダ解析部１２は、取得したリクエストヘッダ２０１からＲｆｅｒｅｒヘッダ２１２及びＨＯＳＴヘッダ２１３を抽出する。
【００３８】
Ｒｅｆｅｒｅｒヘッダ２１２には、リクエストを発生させた元のページのＵＲＬが記載される。すなわち、Ｒｅｆｅｒｅｒヘッダ２１２の場合、リクエストを発生された元のページのＵＲＬは、「http://www.example.com」である。
【００３９】
また、Ｈｏｓｔヘッダ２１３には、リクエストがアクセスを依頼したアクセス先オリジンであるオリジン３０１に配置されたサーバ３１のホスト名が記載される。ここで、サーバ３１のホスト名は、ＵＲＬのホスト名とポート番号で表される。Ｈｏｓｔヘッダ２１３は、同じＩＰアドレスでバーチャルホストなどを利用して仮想的に複数のサーバを運用する場合、どのサーバ向けのリクエストかをサーバ３１側で判定するために用意される。Ｈｏｓｔヘッダ２１３にポート番号が記載されていない場合は、ポート番号は８０である。すなわち、Ｈｏｓｔヘッダ２１３の場合、サーバ３１のホスト名は「www.example.org」であり、ポート番号は「８０」である。ただし、Ｈｏｓｔヘッダ２１３は、ｈｔｔｐやｈｔｔｐｓなどのスキーム名は記載されていない。
【００４０】
さらに、リクエストヘッダ解析部１２は、ＴＣＰパケットのヘッダからブラウザＴＣＰ接続番号及びブラウザＰＣＴ接続先番号を取得する。
【００４１】
そして、リクエストヘッダ解析部１２は、リクエストに含まれる全データ、リクエストの識別子、リクエストライン２１１の値、並びに、抽出したＲｅｆｅｒｅｒヘッダ２１２の値及びＨｏｓｔヘッダ２１３の値をＣＯＲＳモード判定部１３へ出力する。
【００４２】
ＣＯＲＳモード判定部１３は、リクエストに含まれる全データ、リクエストの識別子、リクエストライン２１１の値、並びに、抽出したＲｅｆｅｒｅｒヘッダ２１２の値及びＨｏｓｔヘッダ２１３の値の入力を、リクエストヘッダ解析部１２から受ける。
【００４３】
ＣＯＲＳモード判定部１３は、Ｒｅｆｅｒｅｒヘッダ２１２の値が存在しない場合、ＣＯＲＳ非対応ブラウザ２１からのリクエストを基にクロスオリジンアクセスを行うモードであるＣＯＲＳモードに移行しない。そして、ＣＯＲＳモード判定部１３は、リクエストに含まれる全データ及びリクエストの識別子をリクエスト送信部１４へ出力する。ここで、ＣＯＲＳモード判定部１３は、Ｒｅｆｅｒｅｒヘッダ２１２が存在しない場合、クロスオリジンアクセスに対するサーバ３１のセキュリティの確保が困難になるため、ＣＯＲＳモードを選択しない。以下では、ＣＯＲＳ非対応ブラウザ２１からのリクエストを基にクロスアクセスを行う処理を「ＣＯＲＳ対応処理」という。
【００４４】
一方、ＣＯＲＳモード判定部１３は、プロキシ装置１へのブラウザの接続方法を表すリクエストライン２１１の値から、スキームの情報を取得する。例えば、スキームがｈｔｔｐの場合、リクエストライン２１１は、「GET  http://www.example.com/test/.html  HTTP/1.1」と記載される。また、ｈｔｔｐｓの場合、リクエストライン２１１は、「CONNECT  www.example.com:443  HTTP/1.1」と記載される。すなわち、リクエストライン２１１のＵＲＬでｈｔｔｐが指定されていれば、ＣＯＲＳモード判定部１３は、スキームをｈｔｔｐと判定する。また、リクエストライン２１１でスキームの記載が無ければ、ＣＯＲＳモード判定部１３は、スキームをｈｔｔｐｓと判定する。
【００４５】
さらに、ＣＯＲＳモード判定部１３は、Ｈｏｓｔヘッダ２１３の値からホスト及びポートの情報を取得する。そして、ＣＯＲＳモード判定部１３は、取得したスキーム、ホスト及びポートの情報を組み合わせて、アクセス先オリジンであるオリジン３０１のオリジン値を取得する。ここで、オリジン値は、スキーム、ホスト及びポートの情報を組み合わせで表される。
【００４６】
ただし、ｈｔｔｐｓの場合、通常はＣＯＲＳ非対応ブラウザ２１とサーバ３１との間の通信は暗号化されたおり、プロキシ装置１は参照できない。そこで、ｈｔｔｐｓの場合、ＣＯＲＳモード判定部１３は、ＳＳＬ（Secure  Sockets  Layer）Ｉｎｓｐｅｃｔｉｏｎなどの復号化技術を用いて解析を行う。
【００４７】
例えば、図４のリクエスト２０１の場合、ＣＯＲＳモード判定部１３は、アクセス先オリジンであるオリジン３０１のオリジン値として、http://www.example.org:80を取得する。
【００４８】
次に、ＣＯＲＳモード判定部１３は、Ｒｅｆｅｒｅｒヘッダ２１２の値からアクセス元オリジンであるオリジン３０２のオリジン値を取得する。具体的に、ＣＯＲＳモード判定部１３は、Ｒｅｆｅｒｅｒヘッダ２１２の値からスキーム、ホスト及びポートを抽出することで、オリジン３０２のオリジン値を取得する。
【００４９】
例えば、図４のリクエスト２０１の場合、ＣＯＲＳモード判定部１３は、アクセス元オリジンであるオリジン３０２のオリジン値として、http://www.example.com:80を取得する。
【００５０】
次に、ＣＯＲＳモード判定部１３は、アクセス元オリジンであるオリジン３０２のオリジン値とアクセス先オリジンであるオリジン３０１のオリジン値とを比較する。オリジン３０２のオリジン値とオリジン３０１のオリジン値とが一致する場合、クロスオリジンアクセスではないため、ＣＯＲＳモード判定部１３は、ＣＯＲＳモードに移行しない。そして、ＣＯＲＳモード判定部１３は、リクエストに含まれる全データ及びリクエストの識別子をリクエスト送信部１４へ出力する。
【００５１】
これに対して、オリジン３０２のオリジン値とオリジン３０１のオリジン値とが異なる場合、クロスオリジンアクセスであるので、ＣＯＲＳモード判定部１３は、ＣＯＲＳモードに移行し、ＣＯＲＳ対応処理を実行する。このオリジン３０２のオリジン値とオリジン３０１のオリジン値とが異なるリクエストが「異接続リクエスト」の一例にあたる。次に、ＣＯＲＳ対応処理の詳細について説明する。
【００５２】
ＣＯＲＳモード判定部１３は、リクエストの識別子とともにアクセス元オリジンであるオリジン３０２のオリジン値をＣＯＲＳモード保存部１５に保存する。例えば、図４に示すリクエスト２０１の場合、ＣＯＲＳモード判定部１３は、オリジン値として「http://www.example.com:80」をＣＯＲＳモード保存部１５に保存する。
【００５３】
次に、ＣＯＲＳモード判定部１３は、アクセス先のオリジンであるオリジン３０１の値を有するオリジンヘッダを、リクエストに追加し、ＣＯＲＳ対応リクエストを生成する。図５は、ＣＯＲＳ対応リクエストのリクエストヘッダの一例の図である。例えば、ＣＯＲＳモード判定部１３は、図５に示すように「Origin:  http://www.example.com」のようなオリジンヘッダ２２２をリクエストに追加する。そして、ＣＯＲＳモード判定部１３は、オリジンヘッダ２２２を追加したリクエスト及びリクエストの識別子を、ＣＯＲＳモードの通知とともにリクエスト送信部１４へ出力する。このＣＯＲＳモード判定部１３が、「判定部」の一例にあたる。
【００５４】
リクエスト送信部１４は、ＣＯＲＳモードの場合、オリジンヘッダ２２２が追加されたリクエスト及びリクエストの識別子の入力を、ＣＯＲＳモードの通知とともにＣＯＲＳモード判定部１３から受ける。また、非ＣＯＲＳモードの場合、リクエスト送信部１４は、ＣＯＲＳ非対応ブラウザ２１から送られた修正が加えられてない状態のリクエスト及びリクエストの識別子の入力をＣＯＲＳモード判定部１３から受ける。
【００５５】
リクエスト送信部１４は、受信したリクエストのリクエストラインのＵＲＬからスキーム、ホスト及びポートを取り除き、図５に示すリクエストライン２２１に変換する。
【００５６】
これにより、ＣＯＲＳモードであれば、リクエスト送信部１４は、ＣＯＲＳ対応リクエスト２０２を生成する。ＣＯＲＳ対応リクエスト２０２は、スキーム、ホスト及びポートが取り除かれたリクエストライン２２１及びオリジン３０１の値を有するオリジンヘッダ２２２を有する。このＣＯＲＳ対応リクエストが、「他オリジン向けリクエスト」の一例にあたる。そして、リクエスト送信部１４は、ＣＯＲＳモードであれば、生成したＣＯＲＳ対応リクエスト２０２をサーバ３１へ送信する。
【００５７】
また、非ＣＯＲＳモードの場合、リクエスト送信部１４は、ＣＯＲＳ非対応ブラウザ２１から送られた修正が加えられてない状態のリクエストのリクエストラインのＵＲＬからスキーム、ホスト及びポートを取り除いたリクエストをサーバ３１へ送信する。
【００５８】
ここで、プロキシ装置１からサーバ３１へのリクエストの送信には、ＣＯＲＳ非対応ブラウザ２１とプロキシ装置１とを接続するＴＣＰコネクションとは別のＴＣＰコネクションが使用される。そこで、ＣＯＲＳモードの場合、リクエスト送信部１４は、プロキシＴＣＰ接続元のＩＰアドレス及びポート番号とプロキシＴＣＰ接続先のＩＰアドレス及びポート番号とを組み合わせてレスポンス識別子を生成する。そして、リクエスト送信部１４は、ＣＯＲＳモード保存部１５に格納されたリクエスト識別子に対応させてレスポンス識別子を保存する。ここで、サーバ３１からのレスポンスは、リクエストと同じ順番で返信される。そこで、サーバ３１からのレスポンスは、レスポンス識別子にリクエストとの同じ通し番号を用いることで、一意に識別される。
【００５９】
ＣＯＲＳモード保存部１５は、メモリなどの記憶媒体を有する。ＣＯＲＳモード保存部１５は、リクエスト識別子、レスポンス識別子及びオリジン値を対応させて記憶する。図６は、実施例１に係るオリジン判定情報の一例の図である。ＣＯＲＳモード判定部１３は、例えば、ブラウザＴＣＰ接続元情報１５１、ブラウザＴＣＰ接続先情報１５２、プロキシＴＣＰ接続元情報１５３、プロキシＴＣＰ接続先情報１５４、リクエスト通し番号１５５及びオリジン値１５６を対応させて記憶する。このＣＯＲＳモード保存部１５が、「記憶部」の一例にあたる。
【００６０】
レスポンス受信部１６は、リクエスト送信部１４が送信したＣＯＲＳ対応リクエスト２０２に対するＨＴＴＰレスポンスをサーバ３１から受信する。以下では、ＨＴＴＰレスポンスを単に「レスポンス」という。例えば、レスポンス受信部１６は、図７に示すようなレスポンス２０３をサーバ３１から受信する。図７は、ＣＯＲＳ対応リクエストに対するレスポンスの一例の図である。
【００６１】
次に、レスポンス受信部１６は、ＴＣＰパケットのヘッダからレスポンス２０３の送信元のＩＰアドレス及びポート番号、並びに、送信先のＩＰアドレス及びポート番号を取得しレスポンス識別子を生成する。そして、レスポンス受信部１６は、受信したレスポンス２０３の全てのデータ及びレスポンス識別子をレスポンスヘッダ解析部１７へ出力する。
【００６２】
レスポンスヘッダ解析部１７は、レスポンス２０３の全てのデータ及びレスポンス識別子の入力をレスポンス受信部１６から受ける。
【００６３】
レスポンスヘッダ解析部１７は、レスポンス２０３からＡｃｃｅｓｓ−Ｃｏｎｔｒｏｌ−Ａｌｌｏｗ−Ｏｒｉｇｉｎヘッダ２３１の値を抽出する。ここで、Ａｃｃｅｓｓ−Ｃｏｎｔｒｏｌ−Ａｌｌｏｗ−Ｏｒｉｇｉｎヘッダ２３１の値は、アクセス先のオリジンであるオリジン３０１がクロスオリジンアクセスを許可するオリジンである許可オリジンを示す。ここでは、レスポンスヘッダ解析部１７は、Ａｃｃｅｓｓ−Ｃｏｎｔｒｏｌ−Ａｌｌｏｗ−Ｏｒｉｇｉｎヘッダ２３１の値として「http://www.example.com」を取得する。
【００６４】
ここで、本実施例では、サーバ３１は、例えばＨＴＭＬ５に対応するなどＣＯＲＳに対応していれば、Ａｃｃｅｓｓ−Ｃｏｎｔｒｏｌ−Ａｌｌｏｗ−Ｏｒｉｇｉｎヘッダ２３１が付加したレスポンスを返す。また、例えＣＯＲＳに対応していない場合でも、サーバ３１は、Ａｃｃｅｓｓ−Ｃｏｎｔｒｏｌ−Ａｌｌｏｗ−Ｏｒｉｇｉｎヘッダ２３１が付加するように設定されていればよい。
【００６５】
そして、レスポンスヘッダ解析部１７は、レスポンス２０３の全データ、レスポンス識別子及びＡｃｃｅｓｓ−Ｃｏｎｔｒｏｌ−Ａｌｌｏｗ−Ｏｒｉｇｉｎヘッダ２３１の値をオリジン比較部１８へ出力する。
【００６６】
オリジン比較部１８は、レスポンス２０３の全データ、レスポンス識別子及びＡｃｃｅｓｓ−Ｃｏｎｔｒｏｌ−Ａｌｌｏｗ−Ｏｒｉｇｉｎヘッダ２３１の値の入力をレスポンスヘッダ解析部１７から受ける。
【００６７】
そして、オリジン比較部１８は、受信したレスポンス識別子に対応するエントリがＣＯＲＳモード保存部１５に保存されているか否かを判定する。保存されていない場合、オリジン比較部１８は、レスポンス２０３が非ＣＯＲＳモードで処理されていると判定する。そして、オリジン比較部１８は、サーバ３１から送信された修正が加えられてない状態のレスポンス２０３の全データ及びレスポンス識別子をレスポンス送信部１９へ出力する。
【００６８】
これに対して、受信したレスポンス識別子に対応するエントリがＣＯＲＳモード保存部１５に保存されている場合、オリジン比較部１８は、レスポンス２０３がＣＯＲＳモードで処理されていると判定する。次に、オリジン比較部１８は、レスポンス２０３のアクセス元オリジンであるオリジン３０２のオリジン値をＣＯＲＳモード保存部１５から取得する。そして、オリジン比較部１８は、Ａｃｃｅｓｓ−Ｃｏｎｔｒｏｌ−Ａｌｌｏｗ−Ｏｒｉｇｉｎヘッダ２３１の値にオリジン３０２のオリジン値が含まれているか否か、すなわちオリジン３０２が許可オリジンであるか否かを判定する。
【００６９】
ここで、オリジン比較部１８は、Ａｃｃｅｓｓ−Ｃｏｎｔｒｏｌ−Ａｌｌｏｗ−Ｏｒｉｇｉｎヘッダ２３１の値として「＊：ワイルドカード」が設定されている場合もオリジン３０２が許可オリジンであると判定する。また、レスポンス２０３にＡｃｃｅｓｓ−Ｃｏｎｔｒｏｌ−Ａｌｌｏｗ−Ｏｒｉｇｉｎヘッダ２３１が存在しない場合、オリジン比較部１８は、オリジン３０２は許可オリジンでないと判定する。
【００７０】
オリジン３０２が許可オリジンの場合、オリジン比較部１８は、レスポンス２０３の全データ及びレスポンス識別子を、ＣＯＲＳモードの通知とともにレスポンス送信部１９へ出力する。
【００７１】
オリジン３０２が許可オリジンでない場合、オリジン比較部１８は、エラーの通知をレスポンス送信部１９へ出力する。このオリジン比較部１８が、「許可判定部」の一例にあたる。
【００７２】
レスポンス送信部１９は、ＣＯＲＳモードであってオリジン３０２が許可オリジンの場合、レスポンス２０３の全データ及びレスポンス識別子の入力を、ＣＯＲＳモードの通知とともにオリジン比較部１８から受ける。次に、レスポンス送信部１９は、レスポンス２０３からＡｃｃｅｓｓ−Ｃｏｎｔｒｏｌ−Ａｌｌｏｗ−Ｏｒｉｇｉｎヘッダ２３１を削除し、図８に示すレスポンス２０４を生成する。図８は、ＣＯＲＳ非対応ブラウザに送信するレスポンスの一例の図である。ＣＯＲＳ非対応ブラウザ２１はＡｃｃｅｓｓ−Ｃｏｎｔｒｏｌ−Ａｌｌｏｗ−Ｏｒｉｇｉｎヘッダ２３１を理解できないので、図８に示すように、レスポンス２０４は、Ａｃｃｅｓｓ−Ｃｏｎｔｒｏｌ−Ａｌｌｏｗ−Ｏｒｉｇｉｎヘッダ２３１を有さない。このレスポンス２０３からＡｃｃｅｓｓ−Ｃｏｎｔｒｏｌ−Ａｌｌｏｗ−Ｏｒｉｇｉｎヘッダ２３１を削除しレスポンス２０４を生成する処理が、「ＨＴＴＰリクエストに対する応答の形式に変更する」処理の一例にあたる。
【００７３】
そして、レスポンス送信部１９は、ＣＯＲＳモード保存部１５に保存されているオリジン判定情報から、レスポンス２０３のレスポンス識別子に対応するリクエスト識別子のブラウザＴＣＰ接続元１５１（図６参照）の情報を取得する。そして、レスポンス送信部１９は、取得したブラウザＴＣＰ接続元１５１の情報を宛先としてレスポンス２０３をＣＯＲＳ非対応ブラウザ２１へ送信する。
【００７４】
これに対して、ＣＯＲＳモードであってオリジン３０２が許可オリジンでない場合、レスポンス送信部１９は、エラーの通知をオリジン比較部１８から受ける。この場合、レスポンス送信部１９は、レスポンス２０３のステータスラインを「403  Forbidden」に書き換え、Ｃｏｎｔｅｎｔ−Ｌｅｎｇｔｈヘッダ、Ｃｏｎｔｅｎｔ−Ｔｙｐｅヘッダ、及びレスポンスヘッダに続く実際のコンテンツを削除して、図９に示すエラーレスポンス２０５を生成する。図９は、エラーレスポンスの一例の図である。ただし、これは一例であり、レスポンス送信部１９は、エラーを通知するレスポンスであれば他の形式のエラーレスポンスを用いてもよい。そして、レスポンス送信部１９は、エラーレスポンス２０５をＣＯＲＳ非対応ブラウザ２１へ送信する。
【００７５】
また、非ＣＯＲＳモードの場合、レスポンス送信部１９は、サーバ３１が送信した修正が加えられてない状態のレスポンスの全データ及びレスポンス識別子をオリジン比較部１８から受信する。そして、レスポンス送信部１９は、サーバ３１が送信した修正が加えられてない状態のレスポンスをＣＯＲＳ非対応ブラウザ２１へ送信する。このレスポンス送信部１９が、「応答送信部」の一例にあたる。
【００７６】
次に、図１０を参照して、本実施例に係る情報処理システムにおけるクロスオリジンアクセス処理の流れについて説明する。図１０は、実施例１に係る情報処理システムにおけるクロスオリジンアクセス処理のフローチャートである。ここでは、オリジン３０２のコンテンツがオリジン３０１のコンテンツを要求する場合で説明する。
【００７７】
操作者は、端末装置２のＣＯＲＳ非対応ブラウザ２１のアドレスバーにオリジン３０２のＵＲＬを入力する（ステップＳ１）。
【００７８】
端末装置２は、オリジン３０２宛てにリクエストをＣＯＲＳ非対応ブラウザ２１から送信する（ステップＳ２）。
【００７９】
オリジン３０２に配置されたサーバ３２は、ＣＯＲＳ非対応ブラウザ２１から送信されたリクエストを受信する（ステップＳ３）。
【００８０】
サーバ３２は、ＣＯＲＳ非対応ブラウザ２１にレスポンスを送信する（ステップＳ４）。
【００８１】
端末装置２は、オリジン３０２のコンテンツをＣＯＲＳ非対応ブラウザ２１に読み込む（ステップＳ５）。
【００８２】
ＣＯＲＳ非対応ブラウザ２１は、＜ｓｃｒｉｐｔ  ｓｃｒ＝”オリジン３０１”＞を読み込み、オリジン３０１にリクエストを送信する（ステップＳ６）。
【００８３】
プロキシ装置１は、オリジン３０２をアクセス元オリジンとしオリジン３０１をアクセス先オリジンとするリクエストをＣＯＲＳ非対応ブラウザ２１から受ける（ステップＳ７）。
【００８４】
プロキシ装置１は、ＣＯＲＳ対応処理を実行する（ステップＳ８）。このＣＯＲＳ対応処理の流れの詳細については後で説明する。
【００８５】
ＣＯＲＳ非対応ブラウザ２１は、オリジン３０１へ送信したリクエストに対するレスポンスをプロキシ装置１から受信する。そして、ＣＯＲＳ非対応ブラウザ２１は、応答がエラー通知か否かを判定する（ステップＳ９）。
【００８６】
応答がエラー通知でない場合（ステップＳ９：否定）、ＣＯＲＳ非対応ブラウザ２１は、応答のデータを読み込み、オリジン３０１のコンテンツとオリジン３０２のコンテンツとを組み合わせて操作者に提供する（ステップＳ１０）。
【００８７】
これに対して、応答がエラー通知の場合（ステップＳ９：肯定）、ＣＯＲＳ非対応ブラウザ２１は、＜ｓｃｒｉｐｔ＞を無視して、オリジン３０２のコンテンツを表示する（ステップＳ１１）。
【００８８】
次に、図１１を参照して、ＣＯＲＳ対応処理の流れについて説明する。図１１は、実施例１に係るプロキシ装置によるＣＯＲＳ対応処理のフローチャートである。このフローは、図１０のステップＳ８にあたる。
【００８９】
リクエスト受信部１１は、オリジン３０２をアクセス元オリジンとするオリジン３０１に対するリクエストをＣＯＲＳ非対応ブラウザ２１から受信する（ステップＳ１０１）。リクエスト受信部１１は、受信したリクエスト及びリクエスト識別子をリクエストヘッダ解析部１２へ出力する。
【００９０】
リクエストヘッダ解析部１２は、リクエストをリクエスト受信部１１から受信する。そして、リクエストヘッダ解析部１２は、リクエストヘッダの解析を行う（ステップＳ１０２）。具体的には、リクエストヘッダ解析部１２は、Ｒｅｆｅｒｅｒヘッダの値とＨｏｓｔヘッダの値を抽出し、アクセス元オリジン及びアクセス先オリジンの情報を取得する。その後、リクエストヘッダ解析部１２は、リクエスト、リクエスト識別子、アクセス元オリジン及びアクセス先オリジンをＣＯＲＳモード判定部１３へ出力する。
【００９１】
ＣＯＲＳモード判定部１３は、リクエスト、リクエスト識別子、アクセス元オリジン及びアクセス先オリジンの入力をリクエストヘッダ解析部１２から受ける。そして、ＣＯＲＳモード判定部１３は、アクセス元オリジンとアクセス先オリジンとを比較し、ＣＯＲＳモードへ移行するか否かを判定する（ステップＳ１０３）。ＣＯＲＳモードへ移行しない場合（ステップＳ１０３：否定）、すなわち非ＣＯＲＳモードで動作する場合、ＣＯＲＳモード判定部１３は、リクエスト及びリクエストの識別子をリクエスト送信部１４へ送信し、ステップＳ１０６へ進む。
【００９２】
これに対して、ＣＯＲＳモードへ移行する場合（ステップＳ１０３：肯定）、ＣＯＲＳモード判定部１３は、アクセス元オリジンの情報を、リクエスト識別子に対応させてＣＯＲＳモード保存部１５にオリジン判定情報として保存する（ステップＳ１０４）。
【００９３】
次に、ＣＯＲＳモード判定部１３は、オリジンヘッダをリクエストに追加する（ステップＳ１０５）。そして、ＣＯＲＳモード判定部１３は、オリジンヘッダを追加したリクエスト及びリクエストの識別子を、ＣＯＲＳモードの通知とともにリクエスト送信部１４へ送信する。
【００９４】
リクエスト送信部１４は、リクエスト及びリクエストの識別子をＣＯＲＳモード判定部１３から受信する。リクエスト送信部１４は、リクエストラインのＵＲＬからスキーム、ホスト及びポートを取り除いたリクエストをサーバ３２へ送信する（ステップＳ１０６）。このとき、ＣＯＲＳモードであれば、リクエスト送信部１４は、レスポンス識別子をＣＯＲＳモード保存部１５に保存されたオリジン判定情報に追加する。
【００９５】
その後、レスポンス受信部１６は、リクエスト送信部１４が送信したリクエストに対するレスポンスをサーバ３２から受信する（ステップＳ１０７）。そして、レスポンス受信部１６は、受信したレスポンス及びレスポンスの識別子をレスポンスヘッダ解析部１７へ出力する。
【００９６】
レスポンスヘッダ解析部１７は、サーバ３２からのレスポンスの入力をレスポンス受信部１６から受ける。そして、レスポンスヘッダ解析部１７は、レスポンスヘッダの解析を行う（ステップＳ１０８）。具体的には、レスポンスヘッダ解析部１７は、Ａｃｃｅｓｓ−Ｃｏｎｔｒｏｌ−Ａｌｌｏｗ−Ｏｒｉｇｉｎヘッダの値を取得する。そして、レスポンスヘッダ解析部１７は、レスポンスの全データ、レスポンスの識別子及びＡｃｃｅｓｓ−Ｃｏｎｔｒｏｌ−Ａｌｌｏｗ−Ｏｒｉｇｉｎヘッダの値をオリジン比較部１８へ出力する。
【００９７】
オリジン比較部１８は、レスポンスの全データ、レスポンスの識別子及びＡｃｃｅｓｓ−Ｃｏｎｔｒｏｌ−Ａｌｌｏｗ−Ｏｒｉｇｉｎヘッダの値の入力をレスポンスヘッダ解析部１７から受ける。そして、オリジン比較部１８は、ＣＯＲＳモード保存部１５に保存されたオリジン判定情報にレスポンスの識別子に対応するエントリが存在するかにより、レスポンスに対してプロキシ装置１がＣＯＲＳモードでの動作か否かを判定する（ステップＳ１０９）。
【００９８】
プロキシ装置１がＣＯＲＳモードで動作していない場合（ステップＳ１０９：否定）、オリジン比較部１８は、レスポンスの全データ及びレスポンスの識別子をレスポンス送信部１９へ出力し、ステップＳ１１２へ進む。
【００９９】
これに対して、プロキシ装置１がＣＯＲＳモードでの動作の場合（ステップＳ１０９：肯定）、オリジン比較部１８は、オリジン判定情報からアクセス元オリジンであるオリジン３０２の情報を取得する。そして、オリジン比較部１８は、Ａｃｃｅｓｓ−Ｃｏｎｔｒｏｌ−Ａｌｌｏｗ−Ｏｒｉｇｉｎヘッダの値を用いて、アクセス元オリジンが許可オリジンか否か、すなわち、オリジン３０２が許可オリジンか否かを判定する（ステップＳ１１０）。
【０１００】
アクセス元オリジンが許可オリジンの場合（ステップＳ１１０：肯定）、オリジン比較部１８は、レスポンスからオリジンヘッダを削除する（ステップＳ１１１）。そして、オリジン比較部１８は、オリジンヘッダを削除したレスポンスをレスポンス送信部１９へ出力する。
【０１０１】
レスポンス送信部１９は、オリジンヘッダを削除したレスポンスの入力をオリジン比較部１８から受ける。そして、レスポンス送信部１９は、レスポンスをＣＯＲＳ非対応ブラウザ２１へ送信する（ステップＳ１１２）。
【０１０２】
これに対して、アクセス元オリジンが許可オリジンでない場合（ステップＳ１１０：否定）、オリジン比較部１８は、エラーの通知をレスポンス送信部１９へ出力する。レスポンス送信部１９は、エラーの通知をオリジン比較部１８から受けると、レスポンスの内容をエラー通知に変更する。そして、レスポンス送信部１９は、内容を変更したレスポンスを用いてエラー通知をＣＯＲＳ非対応ブラウザ２１へ送信する（ステップＳ１１３）。
【０１０３】
以上に説明したように、本実施例に係るプロキシ装置は、ＣＯＲＳ非対応のブラウザから送られてきたクロスオリジンアクセスのリクエストをＣＯＲＳ対応のリクエストに変更してアクセス先のオリジンに送る。その後、プロキシ装置は、アクセス先のオリジンから受信したレスポンスを用いてアクセス元オリジンに対してクロスオリジンアクセスが許可されているか否かを判定する。そして、プロキシ装置は、アクセス元オリジンに対してクロスオリジンアクセスが許可されている場合にアクセス元オリジンのコンテンツをＣＯＲＳ非対応ブラウザに送信する。これにより、ＣＯＲＳ非対応のブラウザであっても、クロスオリジンアクセスを行うことができるとともに、アクセス先のオリジンによるアクセス制御を実現でき、アクセス先のオリジンのセキュリティを向上させることができる。
【０１０４】
また、既存の情報処理システムにプロキシ装置を導入するだけで本実施例に情報処理システムを構築でき、既存のブラウザやサーバを改変せずに上記効果を得ることができるので、本実施例に係る構成を容易に実現することができる。
【実施例２】
【０１０５】
次に、実施例２について説明する。本実施例に係るプロキシ装置は、クレデンシャル情報を含むリクエストに対応したことが実施例１と異なる。クレデンシャル情報とは、操作者の認証に用いられる情報である。クレデンシャル情報の種類には、例えば、ＣｏｏｋｉｅやＢａｓｉｃ認証がある。本実施例に係るプロキシ装置のブロック図も図２で表される。以下では、各部における実施例１と同じ機能については説明を省略する。以下では、クレデンシャル情報として、Ｃｏｏｋｉｅ又はＢａｓｉｃ認証を用いる場合で説明する。
【０１０６】
リクエストヘッダ解析部１２は、Ｒｅｆｅｒｅｒヘッダ及びＨｏｓｔヘッダに加えて、Ｃｏｏｋｉｅヘッダ及びＡｕｔｈｏｒｉｚａｔｉｏｎヘッダを抽出する。そして、リクエストヘッダ解析部１２は、Ｃｏｏｋｉｅヘッダ及びＡｕｔｈｏｒｉｚａｔｉｏｎヘッダをＣＯＲＳモード判定部１３へ出力する。
【０１０７】
ＣＯＲＳモード判定部１３は、Ｃｏｏｋｉｅヘッダ及びＡｕｔｈｏｒｉｚａｔｉｏｎヘッダの入力をリクエストヘッダ解析部１２から受ける。そして、ＣＯＲＳモード判定部１３は、リクエストの識別子に対応させて、アクセス元オリジンの情報とともにクレデンシャル情報の有無もオリジン判定情報としてＣＯＲＳモード保存部１５に保存する。
【０１０８】
本実施例では、ＣＯＲＳモード保存部１５は、例えば、図１２に示すオリジン判定情報を保存する。図１２は、実施例２に係るオリジン判定情報の一例の図である。図１２に示すように、本実施例に係るオリジン判定情報には、クレデンシャルの欄１５７にクレデンシャル情報の有無が登録される。
【０１０９】
レスポンス受信部１６は、例えば、図１３に示すＡｃｃｅｓｓ−Ｃｏｎｔｒｏｌ−Ａｌｌｏｗ−Ｃｒｅｄｅｎｔｉａｌｓヘッダ２６１を付加させたレスポンス２０６をサーバ３１から受信する。図１３は、実施例２におけるＣＯＲＳ対応リクエストに対するレスポンスの一例の図である。Ａｃｃｅｓｓ−Ｃｏｎｔｒｏｌ−Ａｌｌｏｗ−Ｃｒｅｄｅｎｔｉａｌｓヘッダ２６１が「ｔｒｕｅ」であれば、サーバ３１は、クレデンシャル情報の利用が許可する。
【０１１０】
レスポンスヘッダ解析部１７は、レスポンスからＡｃｃｅｓｓ−Ｃｏｎｔｒｏｌ−Ａｌｌｏｗ−Ｃｒｅｄｅｎｔｉａｌｓヘッダ２６１の値を抽出する。レスポンスヘッダ解析部１７は、抽出したＡｃｃｅｓｓ−Ｃｏｎｔｒｏｌ−Ａｌｌｏｗ−Ｃｒｅｄｅｎｔｉａｌｓヘッダ２６１の値をオリジン比較部１８へ出力する。
【０１１１】
オリジン比較部１８は、Ａｃｃｅｓｓ−Ｃｏｎｔｒｏｌ−Ａｌｌｏｗ−Ｃｒｅｄｅｎｔｉａｌｓヘッダ２６１の値の入力をレスポンスヘッダ解析部１７から受ける。
【０１１２】
オリジン比較部１８は、オリジン３０２が許可オリジンであるとの判定後、ＣＯＲＳモード保存部１５に格納されたオリジン判定情報から、レスポンスに対応するリクエストがクレデンシャル情報を利用するリクエストか否か判定する。そして、オリジン比較部１８は、クレデンシャル情報を利用するリクエストの場合、Ａｃｃｅｓｓ−Ｃｏｎｔｒｏｌ−Ａｌｌｏｗ−Ｃｒｅｄｅｎｔｉａｌｓヘッダ２６１の値が「ｔｒｕｅ」か否かを判定する。
【０１１３】
Ａｃｃｅｓｓ−Ｃｏｎｔｒｏｌ−Ａｌｌｏｗ−Ｃｒｅｄｅｎｔｉａｌｓヘッダ２６１の値が「ｔｕｒｅ」の場合、オリジン比較部１８は、レスポンスをレスポンス送信部１９に送信する。
【０１１４】
これに対して、Ａｃｃｅｓｓ−Ｃｏｎｔｒｏｌ−Ａｌｌｏｗ−Ｃｒｅｄｅｎｔｉａｌｓヘッダ２６１の値が「ｔｕｒｅ」でない場合、オリジン比較部１８は、エラーの通知をレスポンス送信部１９に送信する。
【０１１５】
レスポンス送信部１９は、Ａｃｃｅｓｓ−Ｃｏｎｔｒｏｌ−Ａｌｌｏｗ−Ｃｒｅｄｅｎｔｉａｌｓヘッダ２６１の値が「ｔｕｒｅ」でない場合、オリジン比較部１８からエラーの通知を受信する。そして、レスポンス送信部１９は、レスポンスをエラー通知の内容に変更し、ＣＯＲＳ非対応ブラウザ２１へ送信する。
【０１１６】
以上に説明したように、本実施例に係るプロキシ装置は、クレデンシャル情報を用いるリクエストの場合、クレデンシャル情報を考慮してアクセス制御を行う。これにより、クロスオリジンアクセスにおける情報システムの信頼性をより向上させることができる。
【０１１７】
（ハードウェア構成）
図１４は、プロキシ装置のハードウェア構成図である。プロキシ装置１は、ＣＰＵ（Central  Processing  Unit）９１、メモリ９２、入力装置９３、出力装置９４、ハードディスク９５、可搬記憶媒体駆動装置９６及びネットワークインタフェース９７を有する。
【０１１８】
メモリ９２、入力装置９３、出力装置９４、ハードディスク９５、可搬記憶媒体駆動装置９６及びネットワークインタフェース９７は、バスを介してＣＰＵ９１と接続する。
【０１１９】
入力装置９３は、例えばキーボードやマウスなどである。また、出力装置９４は、モニタなどである。
【０１２０】
可搬記憶媒体駆動装置９６には、例えばＣＤ（Compact  Disk）やＤＶＤ（Digital  Versatile  Disc）などの可搬記憶媒体９８が挿入される。
【０１２１】
ハードディスク９５は、各種プログラムを記憶する。各種プログラムには、例えば、図２に例示したリクエスト受信部１１、リクエストヘッダ解析部１２、ＣＯＲＳモード判定部１３及びリクエスト送信部１４の各機能を実現するためのプログラムが含まれる。また、各種プログラムには、図２に例示したレスポンス受信部１６、レスポンスヘッダ解析部１７、オリジン比較部１８及びレスポンス送信部１９の各機能を実現するためのプログラムが含まれる。
【０１２２】
ＣＰＵ９１は、ハードディスク９５から各種プログラムを読み出しメモリ９２にプロセスとして展開し実行する。これにより、ＣＰＵ９１及びメモリ９２は、図２に例示したリクエスト受信部１１、リクエストヘッダ解析部１２、ＣＯＲＳモード判定部１３及びリクエスト送信部１４の各機能を実現する。また、ＣＰＵ９１及びメモリ９２は、図２に例示したレスポンス受信部１６、レスポンスヘッダ解析部１７、オリジン比較部１８及びレスポンス送信部１９の各機能を実現する。また、メモリ９２は、ＣＯＲＳモード保存部１５として動作する。
【０１２３】
ここで、以上に説明した各実施例では、特定の端末装置に対するプロキシ専用のプロキシ装置上でＣＯＲＳ対応処理を行う各機能を実現する場合で説明したが、各機能の配置方法はこれに限らない。例えば、個別の端末装置に対するＣＯＲＳ対応処理の方法としては、ブラウザと同じ端末装置上でローカルプロキシとして動作させてもよい。また、ブラウザのプラグインとして動作させてもよい。その場合、ＳＳＬ接続のＣＯＲＳ化が容易になる。
【０１２４】
さらに、複数の端末装置に対するＣＯＲＳ対応処理の方法としては、組織外へのアクセス用プロキシとして各機能を動作させ、組織内のＣＯＲＳ非対応ブラウザを一括して管理してもよい。この場合、既に導入されたプロキシの拡張機能とすれば導入が容易になる。
【符号の説明】
【０１２５】
１  プロキシ装置
２  端末装置
１１  リクエスト受信部
１２  リクエストヘッダ解析部
１３  ＣＯＲＳモード判定部
１４  リクエスト送信部
１５  ＣＯＲＳモード保存部
１６  レスポンス受信部
１７  レスポンスヘッダ解析部
１８  オリジン比較部
１９  レスポンス送信部
２１  ＣＯＲＳ非対応ブラウザ
３１，３２  サーバ
３０１，３０２  オリジン
【図１】
2016066110.tif 000003
【図２】
2016066110.tif 000004
【図３】
2016066110.tif 000005
【図４】
2016066110.tif 000006
【図５】
2016066110.tif 000007
【図６】
2016066110.tif 000008
【図７】
2016066110.tif 000009
【図８】
2016066110.tif 000010
【図９】
2016066110.tif 000011
【図１０】
2016066110.tif 000012
【図１１】
2016066110.tif 000013
【図１２】
2016066110.tif 000014
【図１３】
2016066110.tif 000015
【図１４】
2016066110.tif 000016