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