(57)【要約】【課題】脆弱性問題に対応しても複数の画像処理装置を簡単に管理することを可能にすることを目的とする。【解決手段】ＨＴＴＰサーバを有する画像処理装置であって、ＨＴＴＰサーバは、Ｗｅｂブラウザに送信するＨＴＴＰレスポンスにＷｅｂブラウザに対してＨＴＴＰレスポンスで送信されるＨＴＭＬデータをフレーム内に表示できるかを指定するオプションを付加するか否かの設定に基づきＨＴＴＰレスポンスにオプションを付加するか否かを制御し、ＨＴＴＰレスポンスをＷｅｂブラウザに送信する。【選択図】図７
2019045889.tif 000002
【特許請求の範囲】
【請求項１】
ＨＴＴＰサーバを有する画像処理装置であって、
前記ＨＴＴＰサーバは、Ｗｅｂブラウザに送信するＨＴＴＰレスポンスに前記Ｗｅｂブラウザに対してＨＴＴＰレスポンスで送信されるＨＴＭＬデータをフレーム内に表示できるかを指定するオプションを付加するか否かの設定に基づき前記ＨＴＴＰレスポンスに前記オプションを付加するか否かを制御し、前記ＨＴＴＰレスポンスを前記Ｗｅｂブラウザに送信する画像処理装置。
【請求項２】
前記ＨＴＴＰサーバは、前記ＷｅｂブラウザよりＨＴＴＰリクエストを受信し、前記ＨＴＴＰリクエストに基づき呼び出すＨＴＴＰサーバを拡張するソフトウェアを決定し、決定した前記ソフトウェアを呼び出し、前記ソフトウェアから受け取ったレスポンスヘッダに前記オプションがない場合、前記設定に基づき前記ＨＴＴＰレスポンスに前記オプションを付加するか否かを制御し、前記ソフトウェアから受け取ったレスポンスヘッダに前記オプションがある場合、前記オプションを付加するか否かを制御せず、ＨＴＴＰレスポンスを前記Ｗｅｂブラウザに送信する請求項１記載の画像処理装置。
【請求項３】
前記ＨＴＴＰサーバは、前記設定が前記オプションを付加することを示している場合、前記ＨＴＴＰレスポンスに同じＨＴＴＰサーバで生成されたフレームでの表示を許可する値を設定した前記オプションを追加し、前記設定が前記オプションを付加することを示していない場合、前記ＨＴＴＰレスポンスに前記オプションを付加せず、前記ＨＴＴＰレスポンスを前記Ｗｅｂブラウザに送信する請求項１又は２記載の画像処理装置。
【請求項４】
ＨＴＴＰサーバを有する画像処理装置であって、
前記ＨＴＴＰサーバは、許可サーバが設定されている場合、Ｗｅｂブラウザに送信するＨＴＴＰレスポンスに前記許可サーバの生成したフレームでのみ表示することを許可する値を設定した、前記Ｗｅｂブラウザに対してＨＴＴＰレスポンスで送信されるＨＴＭＬデータをフレーム内に表示できるかを指定するオプションを追加し、許可サーバが設定されていない場合、前記Ｗｅｂブラウザに送信するＨＴＴＰレスポンスに同じＨＴＴＰサーバで生成されたフレームでの表示を許可する値を設定した前記オプションを追加し、前記ＨＴＴＰレスポンスを前記Ｗｅｂブラウザに送信する画像処理装置。
【請求項５】
前記ＨＴＴＰサーバは、前記許可サーバが設定されていない場合、前記Ｗｅｂブラウザより受信したＨＴＴＰリクエストから設定されたヘッダを取得し、前記設定されたヘッダに記載のサーバと前記ＨＴＴＰリクエストの送信元のホストとが同一のドメインである場合、前記Ｗｅｂブラウザに送信するＨＴＴＰレスポンスに前記オプションを付加せず、前記設定されたヘッダに記載のサーバと前記ＨＴＴＰリクエストの送信元のホストとが同一のドメインである場合、前記Ｗｅｂブラウザに送信するＨＴＴＰレスポンスに同じＨＴＴＰサーバで生成されたフレームでの表示を許可する値を設定した前記オプションを追加し、前記ＨＴＴＰレスポンスを前記Ｗｅｂブラウザに送信する請求項４記載の画像処理装置。
【請求項６】
前記設定されたヘッダは、Ｒｅｆｅｒｒｅｒヘッダである請求項５記載の画像処理装置。
【請求項７】
ＨＴＴＰサーバを有する画像処理装置であって、
前記ＨＴＴＰサーバは、Ｗｅｂブラウザより受信したＨＴＴＰリクエストから前記ＨＴＴＰサーバを拡張するソフトウェアを指定するパスを取得し、前記パスに対応する許可サーバが設定されている場合、前記Ｗｅｂブラウザに送信するＨＴＴＰレスポンスに前記許可サーバの生成したフレームでのみ表示することを許可する値を設定した、前記Ｗｅｂブラウザに対してＨＴＴＰレスポンスで送信されるＨＴＭＬデータをフレーム内に表示できるかを指定するオプションを追加し、前記パスに対応する許可サーバが設定されていない場合、前記Ｗｅｂブラウザに送信するＨＴＴＰレスポンスに同じＨＴＴＰサーバで生成されたフレームでの表示を許可する値を設定した前記オプションを追加し、前記ＨＴＴＰレスポンスを前記Ｗｅｂブラウザに送信する画像処理装置。
【請求項８】
前記オプションは、Ｘ−ＦＲＡＭＥ−ＯＰＴＩＯＮＳである請求項１乃至７何れか１項記載の画像処理装置。
【請求項９】
ＨＴＴＰサーバを有する画像処理装置が実行する情報処理方法であって、
前記ＨＴＴＰサーバが、Ｗｅｂブラウザに送信するＨＴＴＰレスポンスに前記Ｗｅｂブラウザに対してＨＴＴＰレスポンスで送信されるＨＴＭＬデータをフレーム内に表示できるかを指定するオプションを付加するか否かの設定に基づき前記ＨＴＴＰレスポンスに前記オプションを付加するか否かを制御する工程と、
前記ＨＴＴＰサーバが、前記ＨＴＴＰレスポンスを前記Ｗｅｂブラウザに送信する工程と、
を含む情報処理方法。
【請求項１０】
ＨＴＴＰサーバを有する画像処理装置が実行する情報処理方法であって、
前記ＨＴＴＰサーバが、許可サーバが設定されている場合、Ｗｅｂブラウザに送信するＨＴＴＰレスポンスに前記許可サーバの生成したフレームでのみ表示することを許可する値を設定した、前記Ｗｅｂブラウザに対してＨＴＴＰレスポンスで送信されるＨＴＭＬデータをフレーム内に表示できるかを指定するオプションを追加する工程と、
前記ＨＴＴＰサーバが、許可サーバが設定されていない場合、前記Ｗｅｂブラウザに送信するＨＴＴＰレスポンスに同じＨＴＴＰサーバで生成されたフレームでの表示を許可する値を設定した前記オプションを追加する工程と、
前記ＨＴＴＰサーバが、前記ＨＴＴＰレスポンスを前記Ｗｅｂブラウザに送信する工程と、
を含む情報処理方法。
【請求項１１】
ＨＴＴＰサーバを有する画像処理装置が実行する情報処理方法であって、
前記ＨＴＴＰサーバが、Ｗｅｂブラウザより受信したＨＴＴＰリクエストから前記ＨＴＴＰサーバを拡張するソフトウェアを指定するパスを取得する工程と、
前記ＨＴＴＰサーバが、前記パスに対応する許可サーバが設定されている場合、前記Ｗｅｂブラウザに送信するＨＴＴＰレスポンスに前記許可サーバの生成したフレームでのみ表示することを許可する値を設定した、前記Ｗｅｂブラウザに対してＨＴＴＰレスポンスで送信されるＨＴＭＬデータをフレーム内に表示できるかを指定するオプションを追加する工程と、
前記ＨＴＴＰサーバが、前記パスに対応する許可サーバが設定されていない場合、前記Ｗｅｂブラウザに送信するＨＴＴＰレスポンスに同じＨＴＴＰサーバで生成されたフレームでの表示を許可する値を設定した前記オプションを追加する工程と、
前記ＨＴＴＰサーバが、前記ＨＴＴＰレスポンスを前記Ｗｅｂブラウザに送信する工程と、
を含む情報処理方法。
【請求項１２】
前記オプションは、Ｘ−ＦＲＡＭＥ−ＯＰＴＩＯＮＳである請求項９乃至１１何れか１項記載の情報処理方法。
【請求項１３】
コンピュータを、請求項１乃至８何れか１項記載の画像処理装置のＨＴＴＰサーバとして機能させるためのプログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、画像処理装置、情報処理方法及びプログラムに関する。
【背景技術】
【０００２】
特許文献１で示されるような複数のＨＴＴＰサーバの生成したデータを統合してブラウザ上に表示する技術がある。
画像処理装置の管理においても管理を簡単にするため、ＨＴＭＬのフレーム機能を利用して複数の画像処理装置の管理用Ｗｅｂページを一つのブラウザウインドウに表示させることが行われている。
一方、Ｗｅｂの脆弱性の一つにクリックジャッキングがある。
攻撃者はＨＴＭＬのフレーム機能を悪用し、一見、無害な攻撃者のサイト上に透明化した標的サイトを張り付けたＷｅｂページを用意する。そしてユーザを攻撃サイトに誘導する。
攻撃者のサイトに誘導されたユーザは攻撃者のサイト上で操作をしているつもりが、実際には透明化された標的サイトを操作させられてしまい、攻撃が成立する。
更に、ユーザが標的サイトにログイン済みの状態で攻撃サイトにアクセスすると、透明化された標的サイトはログイン状態で操作できてしまう。
現在、画像処理装置の機能が高くなり、画像処理装置の外部記憶装置に保持されているユーザの機密データをねらう攻撃者が存在する。
そのため、画像処理装置のＨＴＴＰサーバにおいてもクリックジャッキング対策が必須となっている。
【先行技術文献】
【特許文献】
【０００３】
【特許文献１】特開２０１６−６６１１０号公報
【発明の概要】
【発明が解決しようとする課題】
【０００４】
画像処理装置のＨＴＴＰサーバでクリックジャッキング対策を行うことにより、複数の画像処理装置の管理用Ｗｅｂページをまとめたシステムが利用できなくなる課題がある。
【課題を解決するための手段】
【０００５】
本発明は、ＨＴＴＰサーバを有する画像処理装置であって、ＨＴＴＰサーバは、Ｗｅｂブラウザに送信するＨＴＴＰレスポンスにＷｅｂブラウザに対してＨＴＴＰレスポンスで送信されるＨＴＭＬデータをフレーム内に表示できるかを指定するオプションを付加するか否かの設定に基づきＨＴＴＰレスポンスにオプションを付加するか否かを制御し、ＨＴＴＰレスポンスをＷｅｂブラウザに送信する。
【発明の効果】
【０００６】
本発明によれば、脆弱性問題に対応しても複数の画像処理装置を簡単に管理することを可能にすることができる。
【図面の簡単な説明】
【０００７】
【図１】画像処理装置のハードウェア構成の一例を示す図である。
【図２】画像処理装置のソフトウェア構成の一例を示す図である。
【図３】情報処理システムのシステム構成の一例を示す図である。
【図４】ＨＴＴＰページの一例を示す図である。
【図５】ＨＴＴＰリクエスト、ＨＴＴＰレスポンスの一例を示す図である。
【図６】ＨＴＴＰサーバのソフトウェア構成の一例を示す図である。
【図７】リクエスト受信・レスポンス送信処理の一例を示すフローチャートである。
【図８】Ｘ−ＦＲＡＭＥ−ＯＰＴＩＯＮＳ設定記憶部の一例を示す図である。
【図９】リクエスト受信・レスポンス送信処理の一例を示すフローチャートである。
【図１０】Ｘ−ＦＲＡＭＥ−ＯＰＴＩＯＮＳ設定記憶部の一例を示す図である。
【図１１】リクエスト受信・レスポンス送信処理の一例を示すフローチャートである。
【図１２】ＨＴＴＰリクエスト、ＨＴＴＰレスポンスの一例を示す図である。
【図１３】リクエスト受信・レスポンス送信処理の一例を示すフローチャートである。
【図１４】Ｓ１１０５の具体的な処理の一例を示すフローチャートである。
【図１５】Ｓ１１０５の具体的な処理の一例を示すフローチャートである。
【発明を実施するための形態】
【０００８】
以下、本発明の実施形態について図面に基づいて説明する。
【０００９】
＜実施形態１＞
本実施形態では、管理者が複数の画像処理装置を管理する場合に行われる、一つのＷｅｂブラウザのウインドウで複数の画像処理装置の管理を可能とする画像処理装置１００のＨＴＴＰサーバ２０３の処理について説明する。
図１は、画像処理装置１００のハードウェア構成の一例を示す図である。
画像処理装置１００は、ハードウェア構成として、ＣＰＵ１０１、ＲＯＭ１０２、ＲＡＭ１０３、外部記憶装置１０４、ＵＩ１０５、ネットワークＩ／Ｆ制御部１０７、印刷エンジン１０８を含む。ＣＰＵ１０１は、画像処理装置１００の全体の処理を制御する。ＲＯＭ１０２は、プログラムや設定値等を記憶する。ＲＡＭ１０３は、ＣＰＵ１０１がプログラムに基づき処理を実行する際に利用するデータ等を一時的に記憶する。外部記憶装置１０４は、プログラムやＣＰＵ１０１がプログラムに基づき処理を実行する際に利用するデータ等を記憶する。ＵＩ１０５は、液晶タッチパネルや液晶パネルとハードキーとを組み合わせたものとして実現されており、ユーザの操作をＣＰＵ１０１に入力する。ネットワークＩ／Ｆ制御部１０７は、画像処理装置１００（又はＣＰＵ１０１）をネットワーク１０９に接続する。印刷エンジン１０８は、ＣＰＵ１０１の制御に基づき印刷を実行する。各ハードウェア構成はバス１０６によって相互に接続されておりデータのやり取りを行う。
ＣＰＵ１０１がＲＯＭ１０２又は外部記憶装置１０４に記憶されたプログラムに基づき処理を実行することによって、後述する図２のソフトウェア構成及び後述する図５、１２のシーケンス図におけるＨＴＴＰサーバ２０３の処理が実現される。また、ＣＰＵ１０１がＲＯＭ１０２又は外部記憶装置１０４に記憶されたプログラムに基づき処理を実行することによって、後述する図６、８、１０の画像処理装置１００のソフトウェア構成が実現される。また、ＣＰＵ１０１がＲＯＭ１０２又は外部記憶装置１０４に記憶されたプログラムに基づき処理を実行することによって、後述する図７、９、１１、１３、１４、１５のフローチャートの処理が実現される。
【００１０】
図２は、画像処理装置１００のソフトウェア構成の一例を示す図である。
ハードウェア２０１は、例えば、ＣＰＵ１０１、ＲＯＭ１０２、ＲＡＭ１０３、外部記憶装置１０４等であり、ＯＳ２０２はハードウェア２０１上で動作する。
また、ＯＳ２０２上でＨＴＴＰサーバ２０３が動作する。
ＨＴＴＰサーバ２０３は、ＯＳ２０２の提供するネットワークＡＰＩを使用し画像処理装置１００のネットワークＩ／Ｆ制御部１０７を通じて外部と通信を行う。
Ｓｅｒｖｌｅｔ２０４は、ＨＴＴＰサーバ２０３を拡張するソフトウェアである。Ｓｅｒｖｌｅｔ２０４は、ＨＴＴＰサーバ２０３から呼び出され、ＨＴＴＰリクエストのデータを受け取り、ＨＴＴＰレスポンスデータを生成しＨＴＴＰサーバ２０３に返す。ＨＴＴＰサーバ２０３上で０個以上のＳｅｒｖｌｅｔ２０４が動作している。
Ｓｅｒｖｌｅｔ２０４は、画像処理装置１００の設定をリモートから変更する機能を実現するため等に使用されている。
ＨＴＴＰサーバ２０３は、外部からリクエストを受信すると、リクエストの内容を解析して適切なＳｅｒｖｌｅｔ２０４を選択し、Ｓｅｒｖｌｅｔ２０４を呼び出す。
Ｓｅｒｖｌｅｔ２０４が処理結果をＨＴＴＰサーバ２０３に返すと、ＨＴＴＰサーバ２０３は、Ｓｅｒｖｌｅｔ２０４の処理結果をリクエスト元に返送する。
【００１１】
図３は、情報処理システムのシステム構成の一例を示す図である。
画像処理装置１００上でＨＴＴＰサーバ２０３が動作している。
ＰＣ３０１上ではＷｅｂブラウザ３０２が動作している。
管理サーバ３０３上では管理用ＨＴＴＰサーバ３０４が動作している。
画像処理装置１００、ＰＣ３０１、管理サーバ３０３はネットワーク１０９によって接続されており、相互に通信を行うことができる。
【００１２】
図４は、ＨＴＴＰページの一例を示す図である。
画像処理装置１００がローカルＵＩをもっていなかったり、多数の画像処理装置が分散して設置されているため管理者が各画像処理装置の場所に行くことが困難であったりする。
そのため画像処理装置１００は、管理者がリモートから管理を行うためのＷｅｂのインターフェースを提供するＨＴＴＰサーバ２０３を持つことが多い。
そして、管理者はＷｅｂブラウザを使ってＬＡＮを経由し画像処理装置１００に接続し、管理を行う。
一方、管理者が多数の画像処理装置を管理する場合、それぞれの画像処理装置毎にＷｅｂブラウザのウインドウを開く必要がある。その場合、操作が煩雑になり、設定を変更する画像処理装置を間違える可能性がある。
そのため、図４のように管理用ＨＴＴＰサーバ３０４の生成するフレームセット４０１に、画像処理装置１００のＨＴＴＰサーバ２０３が生成したフレーム４０３のＨＴＭＬデータ４０５を挿入し、Ｗｅｂブラウザ３０２に表示するようにする。
この場合、管理者の開くＷｅｂブラウザ３０２のウインドウは一つであり、画像処理装置１００へのリンクをクリックするだけで管理を行う画像処理装置１００を簡単に切り替えることができる。
【００１３】
図５は、実施形態１のＨＴＴＰリクエスト、ＨＴＴＰレスポンスの一例を示す図である。
ユーザがＷｅｂブラウザ３０２を介して管理用ＨＴＴＰサーバ３０４に対して管理用ページを取得するためのＨＴＴＰリクエスト５０１を送信する。
すると管理用ＨＴＴＰサーバ３０４から管理用ページを返すＨＴＴＰレスポンス５０２が返される。
Ｗｅｂブラウザ３０２は、ＨＴＴＰレスポンス５０２に含まれるＨＴＴＰページを表示する。
フレーム４０２内に表示されるＨＴＭＬデータ４０４には画像処理装置１００のＨＴＴＰサーバ２０３へのリンク情報が記載されている。
ＨＴＴＰページに含まれるフレームセット４０１、フレーム４０２、フレーム４０３、フレーム４０２内に表示されるＨＴＭＬデータ４０４は管理用ＨＴＴＰサーバ３０４が生成し、Ｗｅｂブラウザ３０２に送信している。
ユーザがフレーム４０２内に表示されるＨＴＭＬデータ４０４に含まれる一つ以上のＨＴＴＰサーバ２０３へのリンクを選択することにより、Ｗｅｂブラウザ３０２は、ＨＴＴＰサーバ２０３にＨＴＴＰリクエスト５０３を送信する。
ＨＴＴＰサーバ２０３は、Ｗｅｂブラウザ３０２にＨＴＴＰレスポンス５０４を返信する。Ｗｅｂブラウザ３０２はＨＴＴＰレスポンス５０４から取得したＨＴＭＬデータをフレーム４０３内に表示されるＨＴＭＬデータ４０５として表示する。
【００１４】
図６は、ＨＴＴＰサーバ２０３のソフトウェア構成の一例を示す図である。
ＨＴＴＰサーバ２０３は、ソフトウェア構成として、リクエスト受信部６０１、Ｓｅｒｖｌｅｔ呼出部６０２、レスポンス送信部６０３、Ｘ−ＦＲＡＭＥ−ＯＰＴＩＯＮＳ設定記憶部６０４を含む。各部の処理の詳細は、図７を用いて説明する。
図７は、実施形態１のＨＴＴＰサーバ２０３のリクエスト受信・レスポンス送信処理の一例を示すフローチャートである。
ユーザがＨＴＭＬデータ４０４に含まれるＨＴＴＰサーバ２０３へのリンクの選択操作を行う。操作が行われるとＷｅｂブラウザ３０２は、フレーム４０３内に表示するＨＴＴＰデータを取得するためＨＴＴＰサーバ２０３にＨＴＴＰリクエスト６０５を送信する。
ＨＴＴＰサーバ２０３のリクエスト受信部６０１がＨＴＴＰリクエスト６０５を受信すると、Ｓ７０１において、リクエスト受信／レスポンス送信処理が開始される。
【００１５】
Ｓ７０２において、リクエスト受信部６０１は、ＨＴＴＰリクエスト６０５からリクエストパスを取得し、Ｓｅｒｖｌｅｔ呼出部６０２に渡す。リクエストパスは、ＨＴＴＰサーバ２０３内のＳｅｒｖｌｅｔ２０４を指定するための識別子である。例えば、ＨＴＴＰリクエスト５０３の「／管理ページ」がリクエストパスである。ＨＴＴＰサーバ２０３は、一般的にリクエストパスとＳｅｒｖｌｅｔ２０４との対応表を持っている。
Ｓ７０３において、Ｓｅｒｖｌｅｔ呼出部６０２は、Ｓ７０２で取得したリクエストパスから呼び出すＳｅｒｖｌｅｔ２０４を決定する。
Ｓ７０４において、Ｓｅｒｖｌｅｔ呼出部６０２は、Ｓｅｒｖｌｅｔ２０４のリクエスト処理関数を呼び出す。Ｓｅｒｖｌｅｔ２０４の処理が完了し、リクエスト処理関数が返ってくると、Ｓｅｒｖｌｅｔ呼出部６０２は、レスポンス送信部６０３に処理を移す。Ｓｅｒｖｌｅｔ２０４のリクエスト処理関数の返値はレスポンスヘッダとＨＴＴＰのボディデータとから構成される。
Ｓ７０５において、レスポンス送信部６０３は、Ｓｅｒｖｌｅｔ２０４のリクエスト処理関数の返値からレスポンスヘッダを取得する。
【００１６】
Ｓ７０６において、レスポンス送信部６０３は、Ｓ７０５で取得した一つ以上のレスポンスヘッダのなかにヘッダ名が「Ｘ−ＦＲＡＭＥ−ＯＰＴＩＯＮＳ」であるヘッダがあるかを判定する。「Ｘ−ＦＲＡＭＥ−ＯＰＴＩＯＮＳ」ヘッダは、ブラウザに対してレスポンスで送信されるＨＴＭＬデータがフレーム内に表示できるかを指定するヘッダである。「Ｘ−ＦＲＡＭＥ−ＯＰＴＩＯＮＳ」は、Ｗｅｂブラウザに対してＨＴＴＰレスポンスで送信されるＨＴＭＬデータをフレーム内に表示できるかを指定するオプションの一例である。
ヘッダの値としては以下の３種類がある。
・フレーム内での表示を許さない「ＤＥＮＹ」
・同じＨＴＴＰサーバで生成されたフレームでの表示を許可する「ＳＡＭＥＯＲＩＧＩＮ」
・ｕｒｉで指定されたサーバの生成したフレームでのみ表示を許可する「ＡＬＬＯＷ−ＦＲＯＭ  ｕｒｉ」
Ｗｅｂブラウザ３０２は「Ｘ−ＦＲＡＭＥ−ＯＰＴＩＯＮＳ」ヘッダの値に従い、フレーム内にＨＴＬＭを表示するか、エラーとするかを決定する。
レスポンス送信部６０３は、「Ｘ−ＦＲＡＭＥ−ＯＰＴＩＯＮＳ」ヘッダがあればＳ７０７に遷移し、なければＳ７０９に遷移する。
Ｓ７０７において、レスポンス送信部６０３は、Ｓｅｒｖｌｅｔ２０４のリクエスト処理関数の返値に含まれるレスポンスヘッダとＨＴＴＰのボディデータとをＨＴＴＰレスポンス６０６として返送する。
そしてＳ７０８において、レスポンス送信部６０３は、リクエスト受信／レスポンス送信処理を終了する。
【００１７】
一方、Ｓ７０９において、レスポンス送信部６０３は、Ｘ−ＦＲＡＭＥ−ＯＰＴＩＯＮＳ設定記憶部６０４からＸ−ＦＲＡＭＥ−ＯＰＴＩＯＮＳ設定を取得する。Ｘ−ＦＲＡＭＥ−ＯＰＴＩＯＮＳ設定記憶部６０４には予めユーザの設定によりＯＮ又はＯＦＦの設定が保存されている。
Ｓ７１０において、レスポンス送信部６０３は、Ｓ７０９で取得したＸ−ＦＲＡＭＥ−ＯＰＴＩＯＮＳ設定が「ＯＮ」であるかを判定する。レスポンス送信部６０３は、設定がＯＮであればＳ７１１に遷移し、ＯＦＦであればＳ７０７に遷移する。
Ｓ７１１において、レスポンス送信部６０３は、リクエスト処理関数の返値に含まれるレスポンスヘッダにレスポンスヘッダ「Ｘ−ＦＲＡＭＥ−ＯＰＴＩＯＮＳ：ＳＡＭＥＯＲＩＧＩＮ」を追加して、Ｓ７０７に遷移する。
【００１８】
画像処理装置１００が閉じたＬＡＮの中にあり、外部の攻撃者に画像処理装置１００のＩＰアドレスが知られることのない環境において、管理者はＸ−ＦＲＡＭＥ−ＯＰＴＩＯＮＳ設定をＯＦＦに設定できる。
Ｘ−ＦＲＡＭＥ−ＯＰＴＩＯＮＳ設定がＯＦＦであれば、Ｗｅｂブラウザ３０２は、管理用ＨＴＴＰサーバ３０４の生成するフレームにＨＴＴＰサーバ２０３の生成するＨＴＴＰのコンテンツデータを挿入して表示できる。
よって、管理者は一つのＷｅｂブラウザのウインドウで、複数の画像処理装置を管理することができる。
【００１９】
＜実施形態２＞
実施形態１ではＨＴＴＰサーバ２０３がＸ−ＦＲＡＭＥ−ＯＰＴＩＯＮＳヘッダを付加する・しないの設定しかできない。そのため、ユーザのネットワーク環境によってはセキュリティと利便性とのどちらかを選ばないといけないという課題がある。
図８は、実施形態２のＸ−ＦＲＡＭＥ−ＯＰＴＩＯＮＳ設定記憶部６０４の一例を示す図である。
Ｘ−ＦＲＡＭＥ−ＯＰＴＩＯＮＳ設定記憶部６０４は許可サーバ８０１のｕｒｉを保持している。
【００２０】
図９は、実施形態２のＨＴＴＰサーバ２０３のリクエスト受信・レスポンス送信処理の一例を示すフローチャートである。Ｓ７０１〜７０８は実施形態１と同じである。
Ｓ７０６において、レスポンス送信部６０３は、Ｓ７０５で取得した一つ以上のレスポンスヘッダのなかにヘッダ名が「Ｘ−ＦＲＡＭＥ−ＯＰＴＩＯＮＳ」であるヘッダがあるかを判定する。
レスポンス送信部６０３は、「Ｘ−ＦＲＡＭＥ−ＯＰＴＩＯＮＳ」ヘッダがあればＳ７０９に遷移し、なければＳ９０１に遷移する。
Ｓ９０１において、レスポンス送信部６０３は、Ｘ−ＦＲＡＭＥ−ＯＰＴＩＯＮＳ設定記憶部６０４に記憶されている許可サーバ８０１を取得する。
Ｓ９０２において、レスポンス送信部６０３は、Ｓ９０１で許可サーバを取得できたかを判定する。レスポンス送信部６０３は、取得できていればＳ９０３に遷移し、取得できていない場合はＳ９０４に遷移する。
Ｓ９０３において、レスポンス送信部６０３は、リクエスト処理関数の返値に含まれるレスポンスヘッダにＳ１５０１で取得した許可サーバ８０１を値とする「Ｘ−ＦＲＡＭＥ−ＯＰＴＩＯＮＳ」ヘッダを追加して、Ｓ７０７に遷移する。
一方、Ｓ９０４において、レスポンス送信部６０３は、リクエスト処理関数の返値に含まれるレスポンスヘッダにレスポンスヘッダ「Ｘ−ＦＲＡＭＥ−ＯＰＴＩＯＮＳ：ＳＡＭＥＯＲＩＧＩＮ」を追加して、Ｓ７０７に遷移する。
【００２１】
ＨＴＴＰサーバ２０３は、管理用ＨＴＴＰサーバ３０４の生成するフレームにＨＴＴＰサーバ２０３の生成するＨＴＴＰのコンテンツデータを挿入してＷｅｂブラウザ３０２で表示できるかを制御できる。
よって、管理者は一つのＷｅｂブラウザのウインドウで、複数の画像処理装置を管理することができる。
【００２２】
＜実施形態３＞
画像処理装置１００ではユーザ毎に機能をカスタマイズするため、アプリケーションをインストール、実行することができる。
アプリケーションは様々な種類があり、アプリ毎に異なる部門の管理者が管理を行う場合がある。
一方、実施形態２ではＨＴＴＰサーバ２０３で動作するＳｅｒｖｌｅｔ２０４に対して付加するＸ−ＦＲＡＭＥ−ＯＰＴＩＯＮＳヘッダの許可サーバの設定は一律に決められてしまう。
そのため、複数の管理者がそれぞれの管理用ＨＴＴＰサーバ３０４を利用して管理することができないという課題がある。
図１０は、実施形態３のＸ−ＦＲＡＭＥ−ＯＰＴＩＯＮＳ設定記憶部６０４の一例を示す図である。
Ｘ−ＦＲＡＭＥ−ＯＰＴＩＯＮＳ設定記憶部６０４はパス１４０２、許可サーバ１４０３を含む許可サーバリスト１４０１を保持している。
パス１４０２にはＨＴＴＰサーバ２０３に登録されているＳｅｒｖｌｅｔ２０４を示すリクエストパスが記憶されている。許可サーバ１４０３にはＨＴＴＰのコンテンツデータの挿入を許可する管理用ＨＴＴＰサーバ３０４のＵＲＬ又は、ＳＡＭＥＯＲＩＧＩＮ、ＤＥＮＹが記憶されている。
【００２３】
図１１は、実施形態３のＨＴＴＰサーバ２０３のリクエスト受信・レスポンス送信処理の一例を示すフローチャートである。Ｓ７０１〜７０８は実施形態１と同じである。Ｓ９０２〜９０５は実施形態２と同じである。
Ｓ７０６において、レスポンス送信部６０３は、Ｓ７０５で取得した一つ以上のレスポンスヘッダのなかにヘッダ名が「Ｘ−ＦＲＡＭＥ−ＯＰＴＩＯＮＳ」であるヘッダがあるかを判定する。レスポンス送信部６０３は、「Ｘ−ＦＲＡＭＥ−ＯＰＴＩＯＮＳ」ヘッダがあればＳ７０９に遷移し、なければＳ１５０１に遷移する。
Ｓ１５０１において、レスポンス送信部６０３は、Ｓ７０２で取得したリクエストパスをキーにＸ−ＦＲＡＭＥ−ＯＰＴＩＯＮＳ設定記憶部６０４に記憶されている許可サーバリスト１４０１を検索し、許可サーバを取得する。
次にＳ９０２において、レスポンス送信部６０３は、Ｓ１５０１で許可サーバを取得できたか否かを判定する。レスポンス送信部６０３は取得できていればＳ９０３に遷移し、取得できていない場合はＳ９０４に遷移する。
【００２４】
ＨＴＴＰサーバ２０３はＳｅｒｖｌｅｔ２０４毎に、異なる管理用ＨＴＴＰサーバ３０４の生成するフレームにＨＴＴＰサーバ２０３の生成するＨＴＴＰのコンテンツデータを挿入してＷｅｂブラウザ３０２で表示できるかを制御できる。
よって、画像処理装置１００にインストールされているアプリ毎に管理用ＨＴＴＰサーバ３０４が異なっていても、管理者は一つのＷｅｂブラウザのウインドウで、複数の画像処理装置を管理することができる。
【００２５】
＜実施形態４＞
実施形態２、３では予め、ユーザが管理用ＨＴＴＰサーバ３０４を許可サーバとしてＸ−ＦＲＡＭＥ−ＯＰＴＩＯＮＳ設定記憶部６０４に登録しておかなくてはならないという課題がある。
図１２は、実施形態４のＨＴＴＰリクエスト、ＨＴＴＰレスポンスの一例を示す図である。
ＨＴＴＰリクエスト５０３にはｒｅｆｅｒｒｅｒヘッダ１００１が付加されている。ｒｅｆｅｒｒｅｒヘッダは、設定されたヘッダの一例である。
ｒｅｆｅｒｒｅｒヘッダはＷｅｂブラウザ３０２に表示されているフレーム内のリンクがユーザによってクリックされることによってＷｅｂブラウザ３０２がＨＴＴＰリクエスト５０３に付加するヘッダである。
ｒｅｆｅｒｒｅｒヘッダの値としてフレームを生成した管理用ＨＴＴＰサーバ３０４が設定されている。
【００２６】
図１３は、実施形態４のＨＴＴＰサーバ２０３のリクエスト受信・レスポンス送信処理の一例を示すフローチャートである。Ｓ７０１〜７０８は実施形態１と同じ、Ｓ９０１〜９０３は実施形態２と同じである。
Ｓ９０２において、レスポンス送信部６０３は、Ｓ９０１で許可サーバを取得できたかを判定する。レスポンス送信部６０３は、取得できていればＳ９０３に遷移し、取得できていない場合はＳ１１０１に遷移する。
Ｓ１１０１において、レスポンス送信部６０３は、ＨＴＴＰリクエスト６０５から「ｒｅｆｅｒｒｅｒ」ヘッダを取得する。
次にＳ１１０２において、レスポンス送信部６０３は、「ｒｅｆｅｒｒｅｒ」ヘッダを取得できたかを判定する。レスポンス送信部６０３は、取得できなかった場合はＳ１１０３に遷移し、取得できていればＳ１１０４に遷移する。
Ｓ１１０３において、レスポンス送信部６０３は、リクエスト処理関数の返値に含まれるレスポンスヘッダにレスポンスヘッダ「Ｘ−ＦＲＡＭＥ−ＯＰＴＩＯＮＳ：ＳＡＭＥＯＲＩＧＩＮ」を追加して、Ｓ７０７に遷移する。
【００２７】
Ｓ１１０４において、レスポンス送信部６０３は、Ｓ１１０４でＨＴＴＰリクエスト６０５を送信してきたリクエスト送信元のＰＣ３０１のアドレスを取得する。
Ｓ１１０５において、レスポンス送信部６０３は、Ｓ１１０４で取得したリクエスト送信元のＰＣ３０１とＳ１１０１で取得したＲｅｆｅｒｒｅｒヘッダに記載されているサーバとが同一のドメインにあるかを判定する。レスポンス送信部６０３は、同一ドメインであればＲｅｆｅｒｒｅｒヘッダに記載されているホストは攻撃サイトではないと判定できるのでＳ７０７に遷移し、同一ドメインでなければＳ１１０６に遷移する。同一ドメインであればＸ−ＦＲＡＭＥ−ＯＰＴＩＯＮＳヘッダはＨＴＴＰレスポンス６０６に追加されない。
Ｓ１１０６において、レスポンス送信部６０３は、リクエスト処理関数の返値に含まれるレスポンスヘッダにレスポンスヘッダ「Ｘ−ＦＲＡＭＥ−ＯＰＴＩＯＮＳ：ＳＡＭＥＯＲＩＧＩＮ」を追加して、Ｓ７０７に遷移する。
【００２８】
図１４は、Ｓ１１０５の具体的な処理の一例を示すフローチャートである。
Ｓ１２０１において、レスポンス送信部６０３は、同一ドメイン判定処理を開始する。
Ｓ１２０２において、レスポンス送信部６０３は、Ｓ１１０１で取得したＲｅｆｅｒｒｅｒヘッダに記載されているサーバのホスト名を取得する。
Ｓ１２０３において、レスポンス送信部６０３は、Ｓ１１０４で取得したクエスト送信元のＰＣ３０１のホスト名を取得する。
Ｓ１２０４において、レスポンス送信部６０３は、Ｓ１２０２で取得したホスト名とＳ１２０３で取得したホスト名とを比較し、ホスト名のなかの組織名を示す階層まで一致するかを判定する。レスポンス送信部６０３は、一致していればＳ１２０５に遷移し、非一致であればＳ１２０６に遷移する。
Ｓ１２０５において、レスポンス送信部６０３は、同一ドメインと判定を行なう。
そして、Ｓ１２０７において、レスポンス送信部６０３は、図１４に示すフローチャートの処理を終了する。
Ｓ１２０６において、レスポンス送信部６０３は、非同一ドメインと判定を行なう。
そして、Ｓ１２０７において、レスポンス送信部６０３は、図１４に示すフローチャートの処理を終了する。
【００２９】
図１５は、Ｓ１１０５の具体的な処理の一例を示すフローチャートである。
Ｓ１３０１において、レスポンス送信部６０３は、同一ドメイン判定処理を開始する。
Ｓ１３０２において、レスポンス送信部６０３は、Ｓ１１０１で取得したＲｅｆｅｒｒｅｒヘッダに記載されているホストがＩＰ  Ｒｅａｃｈａｂｌｅであるかを判定する。レスポンス送信部６０３は、Ｐｒｏｘｙサーバを経由せずにＩＰ的に接続可能であれば画像処理装置１００とＲｅｆｅｒｒｅｒヘッダに記載されているホストとは同じＰｒｏｘｙサーバの内部、つまり同じドメイン内に存在していると判定できる。レスポンス送信部６０３は、ＩＰ  ＲｅａｃｈａｂｌｅであればＳ１３０３に遷移し、ＩＰ  ＲｅａｃｈａｂｌｅでなければＳ１３０５に遷移する。
Ｓ１３０３において、レスポンス送信部６０３は、取得したクエスト送信元のＰＣ３０１がＩＰ  Ｒｅａｃｈａｂｌｅであるかを判定する。レスポンス送信部６０３は、Ｐｒｏｘｙサーバを経由せずにＩＰ的に接続可能であれば画像処理装置１００とクエスト送信元のＰＣとは同じＰｒｏｘｙサーバの内部、つまり同じドメイン内に存在していると判定できる。レスポンス送信部６０３は、ＩＰ  ＲｅａｃｈａｂｌｅであればＳ１３０４に遷移し、ＩＰ  ＲｅａｃｈａｂｌｅでなければＳ１３０５に遷移する。
【００３０】
画像処理装置１００とＲｅｆｅｒｒｅｒヘッダのホストとが同じドメイン、画像処理装置１００とクエスト送信元ＰＣとも同じドメインであるので、レスポンス送信部６０３は、Ｒｅｆｅｒｒｅｒヘッダのホストとクエスト送信元ＰＣとも同じドメインであると判定できる。
Ｓ１３０４において、レスポンス送信部６０３は、同一ドメインと判定を行なう。
そして、Ｓ１３０６において、レスポンス送信部６０３は、図１５に示すフローチャートの処理を終了する。
一方、Ｓ１３０５において、レスポンス送信部６０３は、非同一ドメインと判定を行なう。
そして、Ｓ１３０６において、レスポンス送信部６０３は、図１５に示すフローチャートの処理を終了する。
【００３１】
図１４、１５で説明した方法は一例であり、レスポンス送信部６０３は、他の方法で同一ドメインであるかを判定してもよいし、複数の方法を組み合わせて同一ドメインであるかを判定してもよい。
例えば、レスポンス送信部６０３は、Ｒｅｆｅｒｒｅｒヘッダで示されるホストが管理者の使用するクエスト送信元ＰＣと同じドメイン内にあるならば、クリックジャッキングの攻撃サーバではないとみなすことができる。
以上の処理によりＨＴＴＰサーバ２０３はＨＴＴＰリクエスト５０３のリクエストパスに対応する許可サーバが許可サーバ８０１にない場合も適切なＸ−ＦＲＡＭＥ−ＯＰＴＩＯＮＳヘッダをＨＴＴＰレスポンス６０６に付与できる。
したがって、Ｗｅｂブラウザ３０２は、管理用ＨＴＴＰサーバ３０４の生成するフレームにＨＴＴＰサーバ２０３の生成するＨＴＴＰのコンテンツデータを挿入して表示できる。
よって、管理者は一つのＷｅｂブラウザのウインドウで、複数の画像処理装置を管理することができる。
【００３２】
＜その他の実施形態＞
本発明は、上述の実施形態の１以上の機能を実現するプログラムを、ネットワーク又は記憶媒体を介してシステム又は装置に供給する。そして、そのシステム又は装置のコンピュータにおける１つ以上のプロセッサーがプログラムを読み出し実行する処理でも実現可能である。また、１以上の機能を実現する回路（例えば、ＡＳＩＣ）によっても実現可能である。
【００３３】
以上、本発明の実施形態の一例について詳述したが、本発明は係る特定の実施形態に限定されるものではない。
画像処理装置１００のハードウェア構成として、ＣＰＵ１０１等は複数あってもよく、複数のＣＰＵがＲＯＭ１０２、外部記憶装置１０４等に記憶されたプログラムに基づき処理を実行するようにしてもよい。また、画像処理装置１００のハードウェア構成として、ＣＰＵ１０１に替えてＧＰＵ（Ｇｒａｐｈｉｃｓ  Ｐｒｏｃｅｓｓｉｎｇ  Ｕｎｉｔ）を用いることとしてもよい。
また、上述した実施形態を任意に組み合わせて実施してもよい。
【００３４】
以上、上述した各実施形態によれば、画像処理装置がクリックジャッキングの脆弱性問題に対応しても管理用ＨＴＴＰサーバを使用して複数の画像処理装置を簡単に管理することを可能にすることができる。
【符号の説明】
【００３５】
１００  画像処理装置
１０１  ＣＰＵ
２０３  ＨＴＴＰサーバ
【図１】
2019045889.tif 000003
【図２】
2019045889.tif 000004
【図３】
2019045889.tif 000005
【図４】
2019045889.tif 000006
【図５】
2019045889.tif 000007
【図６】
2019045889.tif 000008
【図７】
2019045889.tif 000009
【図８】
2019045889.tif 000010
【図９】
2019045889.tif 000011
【図１０】
2019045889.tif 000012
【図１１】
2019045889.tif 000013
【図１２】
2019045889.tif 000014
【図１３】
2019045889.tif 000015
【図１４】
2019045889.tif 000016
【図１５】
2019045889.tif 000017