JP5929175B2 - 情報処理装置、情報処理システムおよびプログラム - Google Patents

Description

本発明は、ウェブ・アプリケーションに関し、より詳細には、脆弱性対策が施されたウェブ・アプリケーションを実現する情報処理装置、情報処理システムおよびプログラムに関する。

近年のネットワーク技術およびウェブ技術の発達および普及により、オンライン・ショッピングのようなインターネット・サービスのみならず、複合機などの組み込み機器にもウェブ技術が導入されている。例えば、複合機に設定用のウェブ・インタフェースを設けることにより、ウェブ・ブラウザを通じて複合機の各種設定を簡便に行えるようになっている。

一方、近年ウェブ・アプリケーション特有の脆弱性も懸念されており、ＳＱＬインジェクション、ＸＳＳ（クロス・サイト・スクリプティング）、ＣＳＲＦ（Cross Site Request Forgeries：クロス・サイト・リクエスト・フォージェリ)などと呼ばれる種々の脆弱性が知られている。ＣＳＲＦは、悪意のあるページを閲覧した際に、ＪａｖａＳｃｒｉｐｔ（登録商標）等が実行されて、ブラウザが複合機のウェブ・ユーザインタフェースへ向けて、悪意のあるパラメータをポストする：その際に、ブラウザに保存されているＣｏｏｋｉｅ値が用いられるので、正規のｈｔｔｐセッションとして受理される：という脆弱性である。

上述したようなウェブ・アプリケーション特有の脆弱性は、オンライン・ショッピングのようなインターネット上のサービスのみならず、複合機などの組み込み機器においても問題となっている。例えば、複合機であれば、ＣＳＲＦにより、正規の管理者ユーザによる要求であるかのように複合機の各種設定が勝手に変更させられてしまう等の問題がある。

上記ＣＳＲＦ脆弱性に対するウェブ・アプリケーション設計者側の対策としては、ユーザに対しユーザＩＤおよびパスワードなどの認証情報の入力を求める手法、Ｃｏｏｋｉｅとともにワンタイムまたは固定の認証用トークンを付してメッセージのやり取りする手法が知られている。上記認証用トークンを用いる手法は、入力フォームに推測されにくい文字列をサーバ側で管理し、その文字列をhiddenパラメータなどとして指定し、そのパラメータの整合性をチェックする手法である。

上述したウェブ・アプリケーション特有の脆弱性に対処する従来技術としては、その他特開２０１０−１１３５６６号公報（特許文献１）が知られている。特許文献１は、ネットワークを介した攻撃に対する堅牢性を向上させることを目的として、ウェブ・アプリケーションのソースコードを修正せず、フック処理を経由することで攻撃を防止する構成を開示する。より具体的には、特許文献１は、ネットワークを介して受信される処理要求に応じ要求された処理に対して予め定義されたタイミングでフックし、該タイミングにおいて所定の処理を割り込ませ、呼び出しに応じ、アクセスの内容と処理要求ごとに処理実行手段に対するリソースへのアクセス権限が定義された第一の定義情報とに基づいてアクセスの許否を判定する構成を開示する。

上述したように従来技術においても、種々のＣＳＲＦ脆弱性の対策が知られている。しかしながら、上記認証情報の入力を求める手法では、利用者側からの視点では、既にログイン画面で認証を行っているにもかかわらず再度認証情報を入力するのは煩雑な操作でとなってしまう。上記従来技術の認証用トークンを利用する従来技術の手法では、ユーザ毎にリクエスト検証のための認証用トークンを生成し、それをメモリ上に保管しておく必要があり、メモリ効率が低下するという問題があった。メモリ効率の低下は、複合機などのリソースに制約がある組み込み機器や、膨大な量のページ処理や膨大なユーザがログインするウェブ・アプリケーションにおいて特に問題となる。また、上記特許文献１に開示される技術は、ＣＳＲＦ脆弱性に対処する技術であるが、メモリ効率を改善できるものではなかった。

本発明は、上記従来技術における問題点に鑑みてなされたものであり、本発明は、ユーザ毎にリクエスト検証のための認証用トークンを別途メモリ上に保管しておく必要がなく、またユーザに対し認証情報の入力を求める手間をかけず、リクエストの正当性の検証が可能な情報処理装置、情報処理システムおよびプログラムを提供することを目的とする。

本発明では、上記課題を解決するために、下記特徴を有する、情報処理装置、上記情報処理装置を含む情報処理システム、および上記情報処理装置を実現するためのプログラムを提供する。本発明の情報処理装置は、ネットワークを介したリクエストおよびレスポンスを含むトランザクションを管理する第１セッション管理手段と、認証されたユーザの認証識別情報を管理する第２セッション管理手段を含む。本情報処理装置は、さらに、第１のリクエストに応答して、要求元ユーザの認証識別情報を取得し、内部で管理される管理値を用いて、第１レスポンスに含めるトークン値を生成するトークン生成手段と、第２のリクエストに応答して、要求元ユーザの認証識別情報を取得し、前記管理値を用いて計算されたトークン値と、該リクエストに含まれるトークン値とを比較して、リクエストの正誤を検証するトークン検証手段とを含む。

上記構成によれば、認証されたユーザの認証識別情報を用いて計算したトークン値を認証用トークンとして用いることにより、ウェブ・アプリケーション内部で認証用トークンをメモリ上で管理することを要さず、メモリ効率高く脆弱性対策を行うことが可能となる。その際には、ユーザに対し認証情報の入力等を求めなくともよいため、利用者に手間もかけない。

本実施形態による複合機が配置されるネットワーク環境を示す構成図。 本実施形態による複合機のハードウェア構成図。 本実施形態による複合機のソフトウェア構成およびハードウェア構成を示す図。 本実施形態による複合機が実現するシステム設定用ウェブ・アプリケーションのブロック図。 本実施形態による複合機が実現する、システム設定用ウェブ・アプリケーションの詳細なブロック図。 本実施形態におけるクライアント端末−複合機間で実行される設定処理フローを示すシーケンス図。 クライアント端末のウェブ・ブラウザ上に表示される各種画面を例示する図。 本実施形態における複合機においてトークン生成部が実行する、トークン生成処理を示すフローチャート。 本実施形態における複合機においてトークン検証部が実行する、トークン検証処理を示すフローチャート（１／２）。 本実施形態における複合機においてトークン検証部が実行する、トークン検証処理を示すフローチャート（２／２）。 管理者ユーザが正規に設定が要求された場合の動作を説明する図。 ＣＳＲＦ攻撃を受けた場合の動作を説明する図。 本実施形態のトークン処理によるメモリ効率化を説明する図。 他の実施形態におけるウェブサーバが配置されるネットワーク環境を示す構成図。 他の実施形態によるウェブサーバが実現するウェブ・アプリケーションのブロック図。

以下、本発明の実施形態について説明するが、本発明の実施形態は、以下に説明する実施形態に限定されるものではない。なお、以下に説明する実施形態では、情報処理装置として、外部のクライアント端末からネットワークを介して各種設定を行うためのウェブ・アプリケーションを備える複合機を一例に説明する。

以下、図１を参照して、本実施形態による複合機が配置されるネットワーク環境の全体構成について説明する。図１は、本実施形態による複合機が配置されるネットワーク環境を示す構成図である。図１に示すネットワーク環境１０は、インターネットやローカル・エリア・ネットワーク（ＬＡＮ）などのネットワーク１２と、それぞれネットワーク１２に接続されるクライアント端末１４と、複合機２０とを含む。

複合機２０は、コピー、スキャナ、プリント、ファクシミリなどの各種画像機能を備えており、ユーザに対して固有の画像サービスを提供する。複合機２０は、さらに、外部のクライアント端末１４に対し、上記画像機能等に関連した各種設定を行うためのウェブ・ユーザインタフェースを提供し、管理者からのリモート設定を受け付ける。正当な管理ユーザによりなされた設定変更のみを受け付けることが好ましいことから、本実施形態の複合機２０は、ＣＳＲＦ脆弱性の不正リクエストに対処するべく、詳細を後述するトークン処理を実装している。

クライアント端末１４は、ウェブ・ブラウザを実装しており、複合機２０の管理者ユーザが操作する端末である。管理者ユーザは、クライアント端末１４上で動作するウェブ・ブラウザを用いて、複合機２０が提供するウェブ・ユーザインタフェースにアクセスし、クライアント端末１４が備えるディスプレイ上に表示された各種設定画面から各種設定を行うことができる。本実施形態のクライアント端末１４は、正当な管理ユーザであることを示すため、複合機２０から発行された認証用トークンを付してリクエストを送信する。

以下、本実施形態の複合機２０のハードウェア構成について説明する。図２は、本実施形態による複合機のハードウェア構成図である。図２に示す複合機２０は、ハードウェア構成として、ＣＰＵ（Central Processing Unit）２２と、メモリ２４と、ＮＩＣ（Network Interface Card）２６と、オペレーション・パネル２８と、スキャナ３０と、プロッタ３２と、ＨＤＤ（Hard Disk Drive）３４とを含み構成される。

ＣＰＵ２２は、複合機２０の全体制御を行う制御手段である。メモリ２４は、ＣＰＵ２２によるプログラム処理を可能とする実行記憶空間を提供し、描画用メモリ、コピー用画像バッファや符号バッファとしても用いられる。ＣＰＵ２２は、内部バス３６を介してＨＤＤ３４に接続される。ＨＤＤ３４は、ＣＰＵ２２からの入出力要求に応答してデータの書込または読み出しを実行する。ＨＤＤ３４は、複合機２０の各画像機能に対応するプログラムを格納し、画像データ、文書データ、プログラム、フォントデータやフォームデータなども蓄積する。

ＣＰＵ２２は、また、内部バス３６を介してＮＩＣ２６と接続する。ＮＩＣ２６は、複合機２０をインターネットやＬＡＮなどのネットワークに接続するインタフェース機器であり、ネットワーク１２を介した各種指令を受付ける。ＣＰＵ２２は、さらに、内部バス３６を介して、ハードキーおよびタッチパネルなどの入力装置および液晶ディスプレイなどの表示装置を備えるオペレーション・パネル２８に接続されておいる。オペレーション・パネル２８は、オペレータからの各種指示の入力を受付けや画面表示を行うためのユーザ・インタフェースを提供する。

スキャナ３０は、原稿台にセットされた原稿を読み込み、原稿から生成した文書データをメモリ２４やＨＤＤ３４に保存する。プロッタ３２は、要求に応じて、ＣＰＵ２２における画像処理の結果を印刷出力する。

なお、詳細な説明は割愛するが、上記クライアント端末１４としては、パーソナル・コンピュータやワークステーションなどの汎用コンピュータ装置、および携帯電話やスマートフォン、タブレット端末、ＰＤＡ（Personal Digital Assistance）などの携帯情報端末を挙げることができる。クライアント端末１４は、ハードウェア構成として、例えば、ＣＰＵ、メモリ、ＨＤＤ、ＮＩＣ、ディスプレイ装置、マウスやキーボードなどの入力装置を備える。

図３は、本実施形態による複合機２０のソフトウェア構成およびハードウェア構成を示す図である。図３に示す複合機２０は、種々のソフトウェア・コンポーネントが含まれるソフトウェア部４２と、複合機起動部４４と、種々のハードウェア・リソースが含まれるハードウェア部４６とを含み構成される。

ハードウェア部４６は、モノクロ・レーザプリンタ（Ｂ＆ＷＬＰ）５６と、カラー・レーザプリンタ（ＣｏｌｏｒＬＰ）５８と、メディア・リンク・コントローラ（ＭＬＣ）６０と、スキャナやファクシミリなどのハードウェア・リソース６２とを含む。ソフトウェア部４２は、複合機としての機能を提供するための各種アプリケーション６４〜７０が含まれるアプリケーション層４８と、プラットフォーム層５０とを含む。

アプリケーション層４８は、プリンタ、コピー、ファックスおよびスキャナなどの画像処理に関するユーザ・サービス固有の処理を行う。図３に示した実施形態では、アプリケーション層４８は、プリンタ機能を提供するプリンタ・アプリケーション６４と、コピー機能を提供するコピー・アプリケーション６６と、スキャナ機能を提供するスキャナ・アプリケーション６８と、詳細を後述するウェブ・アプリケーション７０とを含む。

プラットフォーム層５０は、ＯＳ５４とともに、アプリケーション６４〜７０からの処理要求を解釈して、ハードウェア資源の獲得要求を発生するコントロール・サービス層５２を含む。上記ＯＳとしては、例えば、ＵＮＩＸ（登録商標）を採用することができるが、ＷＩＮＤＯＷＳ（登録商標）やその他のいかなるＯＳを採用することを妨げない。ソフトウェア部４２の各ソフトウェア・コンポーネントは、ＵＮＩＸ（登録商標）などのＯＳ上に、プロセス単位で並列的に起動される。

各種コントロール・サービスとしては、図３に示した実施形態では、ネットワーク制御サービス（ＮＣＳ）７２と、デリバリー制御サービス（ＤＣＳ）７４と、オペレーションパネル制御サービス（ＯＣＳ）７６と、ファクシミリ制御サービス（ＦＣＳ）７８と、エンジン制御サービス（ＥＣＳ）８０と、メモリ制御サービス（ＭＣＳ）８２と、ユーザ情報制御サービス（ＵＣＳ）８４と、システム制御サービス（ＳＣＳ）８６とが含まれる。

ＳＣＳ８６は、各種アプリケーションの管理、システム画面表示、ＬＥＤ表示、ハードウェア資源の管理および割込みアプリケーションの制御などを行う。ＵＣＳ８４は、ユーザ情報を管理する。ＭＣＳ８２は、画像メモリの取得および解放、画像データの圧縮・伸張等のメモリ制御などを行う。ＥＣＳ８０は、モノクロ・レーザプリンタ５６、カラー・レーザプリンタ５８、スキャナなどのエンジンを制御し、画像読取処理および画像形成処理を実行する。

ＦＣＳ７８は、ＧＳＴＮインタフェースと接続し、ＧＳＴＮ網を使用したファクシミリ送受信、バックアップメモリで管理されている各種ファクシミリ・データの登録／引用、ファクシミリ読み取りなどを制御する。ＯＣＳ７６は、オペレータと本体制御との間のインタフェースとなるオペレーションパネルの制御を行う。ＤＣＳ７４は、ＨＤＤなどに蓄積された蓄積文書の配信を制御を行う。ＮＣＳ７２は、ＮＩＣを制御して、複合機２０をイーサネット（登録商標）と接続させ、ネットワークＩ／Ｏを必要とするアプリケーションに対して共通に利用可能なサービスを提供する。

プラットフォーム層５０とアプリケーション層４８との間には、アプリケーション・プログラム・インタフェース（ＡＰＩ）８８を有する。プラットフォーム層５０は、ＡＰＩ８８に含まれる予め定義された関数により、各種アプリケーション６４〜７０からの処理要求を受信する。プラットフォーム層５０とハードウェア部４６との間には、エンジン・インタフェース９０が設けられる。

複合機起動部４４は、複合機２０の電源投入時に最初に実行され、上述までのプラットフォーム層５０およびアプリケーション層４８のソフトウェア群（プロセス）に対応する制御プログラムを、図示しないＲＯＭやＨＤＤ３４などから読出す。そして、複合機起動部４４は、読み出した制御プログラムを、ＣＰＵ２２の実行記憶空間を提供するメモリ２４上に展開し、各プロセスを起動することにより、上述した、および後述するソフトウェア手段および各処理を実現する。

複合機２０は、上述のソフトウェア群により、ハードウェア・リソースを制御し、ユーザ指令や外部コンピュータからの入力に応答して、コピー、ファクシミリ、カラーコピーなど複合機としての機能をユーザに提供する。本実施形態による複合機２０は、外部のクライアント端末に対し、上記アプリケーション６４〜６８や各種コントロール・サービス７２〜８６に関連した各種設定を行うためのウェブ・アプリケーション７０を提供する。本実施形態によるウェブ・アプリケーション７０は、後述するトークン処理により、ＣＳＲＦ脆弱性による不正リクエストに対処しながら、正当な管理者からのリモート設定を受け付ける。

なお、上述したアプリケーション、コントロール・サービスおよびハードウェアは、種々の組み合わせにより構成することができ、特定の用途、機種に対応して追加・削除することができる。また、図３に示した実施形態では、複合機としての各アプリケーションや制御サービスにおける共通部分を抽出して、プラットフォーム化した構成として参照したが、複合機２０のハードウェア構成およびソフトフェアの構成は、特に限定されるものではない。

以下、本実施形態によるトークン処理を実装したシステム設定用ウェブ・アプリケーションについて、図４〜図１０を参照しながら説明する。図４は、本実施形態による複合機２０が実現するシステム設定用ウェブ・アプリケーションに関連したブロック図である。図４には、システム設定用ウェブ・アプリケーションに関連する構成として、ＨＴＴＰデーモン１０２と、システム設定用ウェブ・アプリケーション１１０と、アプリケーション／コントロール・サービス１２６と、画面定義部１２８と、ＸＭＬ（eXtensible Markup Language）スキーマ１３０と、言語リソースＸＭＬ１３２と、ＸＳＬ（XML Stylesheet Language）１３４とが示されている。

ＨＴＴＰデーモン１０２は、ウェブサーバ・プログラムである。ＨＴＴＰデーモン１０２は、クライアント端末１４からのリクエストに応答して、複合機２０に実装されるシステム設定用ウェブ・アプリケーション１１０に要求を渡し、処理結果をレスポンスとしてクライアント端末１４に送信する。

システム設定用ウェブ・アプリケーション１１０は、モジュールとして、ライブラリ群１１２と、ウェブページ・ハンドラ（以下、ＷＰＨと参照する。）１１８と、ウェブページ・ファンクション（以下、ＷＰＦと参照する。）１２２と、ウェブサービス・ファンクション１２４とを含み構成される。

図４中の画面定義部１２８は、システム設定用ウェブ・アプリケーションの各画面の入力データおよび出力データの構造を定義する画面定義データを保持する。本実施形態では、画面定義データにはトークン処理が適用される保護対象のアプリケーション画面であるか否かも定義される。ＷＰＦ１２２およびＷＰＨ１１８は、画面定義部１２８が保持する画面の入出力データの定義に従って生成され、各画面のウェブページを実現するための処理関数を構成する。

図４に示すライブラリ群１１２は、ＷＰＦ１２２およびＷＰＨ１１８から呼び出される各種ライブラリ１１４，１１６を含む。フレームワーク・ライブラリ１１４は、ウェブ・アプリケーションのフレームワークとして提供されるものであり、ウェブ・アプリケーション共通の処理ＡＰＩを提供する。本実施形態によるトークン処理は、フレームワーク・ライブラリ１１４により提供される。

図４に示す複数のライブラリ１１６に含まれるウェブページ・ライブラリは、ウェブ・アプリケーション１１０とＨＴＴＰデーモン１０２との仲介を行っており、ＨＴＴＰデーモン１０２が受け付けたクライアント端末１４からのリクエストをウェブ・アプリケーション１１０に渡すとともに、ウェブ・アプリケーション１１０による処理結果をＨＴＴＰデーモン１０２に渡し、処理結果を含むレスポンスをクライアント端末１４へ返信させる。図４に示す複数のライブラリ１１６に含まれるＨＴＴＰライブラリは、ＨＴＴＰリクエストを解析するためのライブラリであり、ＸＭＬライブラリは、ＸＭＬを扱うライブラリである。

アプリケーション／コントロール・サービス１２６は、図３に示したアプリケーション層４８の各アプリケーション６４〜６８およびコントロール・サービス層５２の各コントロール・サービス７２〜８６を代表したものである。ウェブサービス・ファンクション１２４は、アプリケーション／コントロール・サービス１２６から各種情報を取り出して、ＷＰＦ１２２に渡す。ＷＰＦ１２２は、ウェブページの表示に関する画面固有の処理を実行するものであり、上記ウェブサービス・ファンクション１２４を介して取得した複合機２０内部で管理される情報を用いて、ウェブページへ変換するために必要なデータ変換を行い、データをＷＰＨ１１８に渡す。ＷＰＦ１２２は、また、レスポンスから必要なデータを選択して、ウェブサービス・ファンクション１２４を介してアプリケーション／コントロール・サービス１２６にデータを渡す。

ＷＰＨ１１８は、ウェブページの操作を管理しており、入出力データのＤＯＭ（Document Object Model）ツリーを生成する。タイプライブラリ１２０は、文字または文字列の型を扱うライブラリである。上述したＤＯＭツリーは、画面生成前のデータをツリー構造としたデータであり、このＤＯＭツリーから、ＸＭＬスキーマ１３０を用いてタイプライブラリ１２０がＸＭＬで記述し、ＸＳＬＴプロセッサ１０４が言語リソースＸＭＬ１３２およびＸＳＬ１３４を用いてＨＴＭＬデータに変換する。そして、ＨＴＴＰデーモン１０２が、変換されたＨＴＭＬデータをクライアント端末１４に送信する。

図５は、本実施形態による複合機２０が実現する、システム設定用ウェブ・アプリケーションの詳細なブロックを示す。本システム設定用ウェブ・アプリケーション１１０おいて、保護対象となる処理は、少なくとも２段階のＨＴＴＰトランザクションを経て行われる。例えばある設定項目を登録しようとする場合、クライアント端末１４と複合機２０との間で、設定用フォームを要求する第１リクエストおよび設定用フォームを含む第１レスポンスからなる第１のトランザクションと、設定用フォームから設定内容の登録を要求する第２リクエストおよび登録処理結果を含む第２レスポンスからなる第２のトランザクションとが行われる。実装によっては、登録処理前に、設定用フォームから設定内容の確認を要求する第３リクエストおよび内容確認画面を含む第３レスポンスからなる第３のトランザクションなど、付加的なトランザクションが行われる場合もある。

図５には、上記設定用フォームを要求する第１リクエストおよび設定内容登録を要求する第２リクエストを処理するための処理関数１１８ａ，１１８ｂ，１２２ａ，１２２ｂが示されている。ｗｐｆ＿ＳｅｔｔｉｎｇＩｎｐｕｔＦｏｒｍ（）１２２ａと、ＳｅｔｔｉｎｇＩｎｐｕｔＦｏｒｍ＿ｈａｎｄｌｅｒ（）１１８ａとは、上記第１リクエストに対応して、設定用フォーム画面にかかる処理を実行する設定フォーム処理関数Ｆｏｒｍ（）を構成する。同様に、ｗｐｆ＿ＳｅｔｔｉｎｇＲｅｇｉｓｔｒａｔｉｏｎ（）１２２ｂと、ＳｅｔｔｉｎｇＲｅｇｉｓｔｒａｉｏｎ＿ｈａｎｄｌｅｒ（）１１８ｂとは、上記第２リクエストに対応して、設定内容登録処理を実行する登録処理関数Ｒｅｇｉｓｔ（）を構成する。ここで、登録処理関数Ｒｅｇｉｓｔ（）に対応する画面が、保護対象のアプリケーション画面であると定義されている。

また、本実施形態のシステム設定用ウェブ・アプリケーション１１０は、２階層のセッション管理を行っており、ＨＴＴＰセッション管理部１３６と、認証セッション管理部１３８とを含む。ＨＴＴＰセッション管理部１３６は、ＨＴＴＰセッションＩＤの発行および管理を行い、クライアント端末１４のウェブ・ブラウザ１５０と、複合機２０のウェブ・アプリケーション１１０との間のネットワークを介したＨＴＴＰトランザクションのセッション管理を行っている。認証セッション管理部１３８は、ログイン認証をしたクライアント端末１４を操作するユーザに対して与える認証セッションＩＤの発行および管理を行う。

上記認証セッションＩＤは、ログインしているユーザに紐付けられるものであり、複合機２０とウェブ・ブラウザ１５０との両方で保持される。認証セッションＩＤは、本実施形態における認証されたユーザの認証識別情報である。これに対して上記ＨＴＴＰセッションＩＤは、ログインの有無にかかわらず、クライアント（ユーザ）に紐付けられるものであり、同様に複合機２０とウェブ・ブラウザ１５０の両方で保持される。ＨＴＴＰセッションＩＤは、本実施形態におけるトランザクションの認証識別情報である。

ライブラリ群１１２のフレームワーク・ライブラリ１１４は、より詳細には、トークン生成部１４０と、トークン検証部１４２とを含む。トークン生成部１４０は、上記第１のリクエストへ応答する第１レスポンスに含めるために認証用トークンを生成する機能を有し、ＡＰＩを介してこの機能をＷＰＨ１１８に提供する。トークン検証部１４２は、上記第２リクエストを受信した際に、該第２リクエストに含まれる認証用トークンの正誤を検証する機能を有し、ＡＰＩを介してこの機能をＷＰＨ１１８およびＷＰＦ１２２に提供する。

本実施形態のトークン生成部１４０およびトークン検証部１４２は、上記認証セッション管理部１３８が管理する認証されたユーザの認証セッションＩＤを試みて、取得が成功した場合は、認証セッションＩＤをシードとして用いてトークンの値を計算し、これを用いて認証用トークンの生成および検証を行う。トークン生成部１４０およびトークン検証部１４２は、一方でユーザの認証セッションＩＤが取得されなかった場合には、取得可能な識別情報から段階的にトークン計算のためのシードの取得を試みる。

上記シードの候補となる取得可能な識別情報としては、上記ＨＴＴＰセッションＩＤを用いることができ、その他、ウェブ・ブラウザ１５０のユーザエージェント情報を用いることができる。ユーザエージェント情報は、ユーザが使用しているブラウザの情報、ＯＳの情報を含んでおり、上記認証セッションＩＤおよびＨＴＴＰセッションＩＤとは異なり、ブラウザ側で生成され複合機２０に送られる情報である。

ＷＰＨ１１８は、クライアント端末１４からの全リクエスト（上記第１リクエストが含まれる。）に対し、フレームワーク・ライブラリ１１４のＡＰＩを使用してトークン生成部１４０の機能を呼び出し、認証トークンを生成させて、認証用トークンのＤＯＭツリーを生成する。認証用トークンのＤＯＭツリーを元に、ＸＳＬで定義されたスタイルシートが適用されて、ＨＴＴＰレスポンスが含むＨＴＴＰデータ内に認証用トークンが埋め込まれる。

ＷＰＨ１１８は、上記第２リクエストなど保護対象として指定されたＷＰＨ１１８へのリクエスト時には、フレームワーク・ライブラリ１１４のＡＰＩを使用してトークン検証部１４２の機能を呼び出し、トークンの正誤を判定する。ＷＰＨ１１８は、正誤判定の結果に応じて処理を分岐させる。また、ＷＰＦ１２２も、保護対象として指定されたＷＰＨ１１８へのリクエスト時には、フレームワーク・ライブラリ１１４のＡＰＩを使用してトークン検証部１４２の機能を呼び出し、トークンの正誤を判定する。例えば同一ＵＲＬに対して参照および設定処理が混在する場合には、ＷＰＦ１２２側でトークンの正誤の判定を行うよう構成される。

以下、図６を参照しながら、クライアント端末１４および複合機２０間で実行される、トークン処理を含む設定処理について説明する。図６は、本実施形態におけるクライアント端末１４−複合機２０間で実行される設定処理フローを示すシーケンス図である。

図６に示す処理は、例えば管理者がウェブ・ブラウザを用いて設定用ウェブ・アプリケーションの設定用フォームのＵＲＬを指定したことに応答して開始し、ステップＳ１００では、ウェブ・ブラウザ１５０は、複合機２０に対し、設定フォーム画面を要求する設定フォーム・リクエストを送信する。複合機２０は、設定フォーム・リクエストを受信すると、設定フォーム処理関数Ｆｏｒｍ（）を起動する。設定フォーム処理関数Ｆｏｒｍ（）は、図５に図示したｗｐｆ＿ＳｅｔｔｉｎｇＩｎｐｕｔＦｏｒｍ（）１２２ａと、ＳｅｔｔｉｎｇＩｎｐｕｔＦｏｒｍ＿ｈａｎｄｌｅｒ（）１１８ａとから構成され処理関数である。

ステップＳ１０１では、設定フォーム処理関数Ｆｏｒｍ（）は、フレームワーク・ライブラリ１１４のＡＰＩを使用してトークン生成処理を実行する。ステップＳ１０２では、設定フォーム処理関数Ｆｏｒｍ（）は、生成されたトークン値を設定用フォームに埋め込んで、認証用トークンが含まれる設定用フォームのＨＴＭＬデータをレスポンスとして、ウェブ・ブラウザ１５０に送信する。上記設定用フォームのＨＴＭＬデータは、受信したクライアント端末１４のウェブ・ブラウザ１５０に対し、埋め込まれた認証用トークンを含めて設定登録リクエストを送信するよう指令するコードを含む。ウェブ・ブラウザ１５０は、受信したレスポンスに含まれるＨＴＭＬから設定フォーム画面２００を作成し、ディスプレイ上に表示する。

図７（Ａ）は、クライアント端末１４のウェブ・ブラウザ１５０上に表示される設定フォーム画面２００を例示する図である。図７（Ａ）に示すように、設定フォーム画面２００は、設定項目を選択するためのプルダウンメニュー２０２，２０４と、設定をキャンセルするための戻るボタン２０６と、設定ボタン２０８とを含む。設定ボタン２０８には、埋め込まれた認証用トークンを含めて設定登録リクエストを送信するよう指令するコードが関連付けられており、設定ボタン２０８のクリック・イベントに応答して、設定登録要求が送信されるよう構成されている。

再び図６を参照すると、管理者が設定フォーム画面２００において設定内容を入力し、設定ボタン２０８をクリックしたことに応答して、ステップＳ１０３では、ウェブ・ブラウザ１５０は、上記コードに従って、複合機２０に対し、認証トークンとともに設定登録リクエストを送信する。複合機２０は、設定登録リクエストを受信すると、登録処理関数Ｒｅｇｉｓｔ（）を起動する。登録処理関数Ｒｅｇｉｓｔ（）は、図５に図示したｗｐｆ＿ＳｅｔｔｉｎｇＲｅｇｉｓｔｒａｔｉｏｎ（）１２２ｂと、ＳｅｔｔｉｎｇＲｅｇｉｓｔｒａｔｉｏｎ＿ｈａｎｄｌｅｒ（）１１８ｂとから構成される処理関数である。

ステップＳ１０４では、登録処理関数Ｒｅｇｉｓｔ（）は、フレームワーク・ライブラリ１１４のＡＰＩを使用して認証トークン検証処理を実行する。ここで、フレームワーク・ライブラリ１１４からリクエストに含まれる認証用トークンが正しい旨の回答を受けた場合は、登録処理関数Ｒｅｇｉｓｔ（）は、渡された設定内容を反映させる処理を実行する。この場合、ステップＳ１０５では、登録処理関数Ｒｅｇｉｓｔ（）は、設定内容が成功裡に反映されたことを表す設定成功画面のＨＴＭＬデータをレスポンスとしてウェブ・ブラウザ１５０に送信する。ウェブ・ブラウザ１５０は、レスポンスを受信して、受信したレスポンスに含まれるＨＴＭＬから設定成功画面２１０を作成し、表示する。

図７（Ｂ）は、クライアント端末１４のウェブ・ブラウザ１５０上に表示される設定成功画面２１０を例示する図である。図７（Ｂ）に示すように、設定成功画面２１０は、設定内容の表示２１２と、設定フォーム前の画面に戻るための戻るボタン２１４とを含む。戻るボタン２１４には、例えば、システム設定のトップ画面に戻るリンクが埋め込まれる。

再び図６を参照すると、登録処理関数Ｒｅｇｉｓｔ（）は、一方で、フレームワーク・ライブラリ１１４からリクエストに含まれる認証用トークンが不正である旨の回答を受けた場合は、渡された設定内容の反映処理をキャンセルする。この場合、ステップＳ１０６では、登録処理関数Ｒｅｇｉｓｔ（）は、設定内容の反映が失敗した旨を表す設定失敗画面のＨＴＭＬデータをレスポンスとしてウェブ・ブラウザ１５０に送信する。ウェブ・ブラウザ１５０は、受信したレスポンスに含まれるＨＴＭＬから設定失敗画面２２０を作成し、表示する。

図７（Ｃ）は、クライアント端末１４のウェブ・ブラウザ１５０上に表示される設定失敗画面２２０を例示する図である。図７（Ｃ）に示すように、設定失敗画面２２０は、設定が失敗した旨の表示２２２と、設定フォーム前の画面に戻るための戻るボタン２２４とを含む。

以下、図８、並びに図９および図１０を参照しながら、複合機２０が実行するトークン処理について詳細を説明する。図８は、本実施形態における複合機２０において、フレームワーク・ライブラリ１１４のトークン生成部１４０が実行する、トークン生成処理を示すフローチャートである。図８に示す処理は、ＷＰＨ１１８からＡＰＩを介してトークン生成部１４０が呼び出されたことに応答して、ステップＳ２００から開始される。

ステップＳ２０１では、トークン生成部１４０は、ＷＰＨ１１８から渡された引数をチェックする。ステップＳ２０１で、引数が正しいと判定された場合（正常）は、ステップＳ２０２へ処理が進められる。ステップＳ２０２では、トークン生成部１４０は、ライブラリ１１６のＨＴＴＰライブラリを用いて、認証セッションＩＤの取得を試みる。ステップＳ２０３では、トークン生成部１４０は、認証セッションＩＤの取得が成功したか否かを判定する。認証セッションＩＤは、システム設定用ウェブ・アプリケーション１１０にユーザが正常にログインし、ログイン状態が維持されている場合には取得に成功するが、未ログイン状態では取得に失敗する。

ステップＳ２０３で、認証セッションＩＤの取得が成功したと判定された場合（ＹＥＳ）は、ステップＳ２０７へ直接処理が進められる。一方、ステップＳ２０３で、認証セッションＩＤの取得が失敗したと判定された場合（ＮＯ）には、ステップＳ２０４へ処理が分岐される。ステップＳ２０４では、トークン生成部１４０は、ライブラリ１１６のＨＴＴＰライブラリを用いて、ＨＴＴＰセッションＩＤの取得を試みる。ステップＳ２０５では、トークン生成部１４０は、ＨＴＴＰセッションＩＤの取得が成功したか否かを判定する。ＨＴＴＰセッションＩＤは、ＨＴＴＰセッションＩＤの有効期限経過前であれば、ログイン済であるか否かに関わらず取得されるが、全くの初回アクセスであったり、ＨＴＴＰセッションＩＤの有効期限が過ぎていたりした場合は取得に失敗する。

ステップＳ２０５で、ＨＴＴＰセッションＩＤの取得が成功したと判定された場合（ＹＥＳ）には、ステップＳ２０７へ直接処理が進められる。一方、ステップＳ２０５で、認証セッションＩＤに引き続いてＨＴＴＰセッションＩＤの取得も失敗したと判定された場合（ＮＯ）には、ステップＳ２０６へ処理が分岐される。ステップＳ２０６では、トークン生成部１４０は、ウェブ・ブラウザ１５０のユーザエージェント情報を取得し、Ｕｓｅｒ−Ａｇｅｎｔの”／”直後の所定文字数（例えば２）の文字列をデフォルト値とし、ステップＳ２０７へ処理を進める。

ステップＳ２０７では、上述までに取得された認証セッションＩＤ、ＨＴＴＰセッションＩＤまたはデフォルト値をトークン計算のための第１シードとして決定する。ステップＳ２０８では、トークン生成部１４０は、トークン計算のため第２シードとして、複合機２０内部で管理され、通常外部から参照ができない内部管理値を取得する。内部管理値としては、特に限定されるものではないが、複合機２０で動作しているプログラムのプロセスＩＤなどを用いることができる。この内部管理値は、特に限定されるものではないが、当該システム設定用ウェブ・アプリケーション１１０が実行している間、不変である値を用いることが好ましい。

ステップＳ２０９では、トークン生成部１４０は、上記取得された第１シードと第２シードとを用いて、認証用トークンの値を計算する。トークン値の計算は、簡便には、第１シードと第２シードを乗算した値を用いることができる。トークン値の計算は、特に限定されるものではなく、その他、適当なハッシュ関数を用いて計算することができ、第１シードおよび第２シードをハッシュ関数に入力し、計算された出力値を認証用トークンとして用いることができる。

ステップＳ２１０では、トークン生成部１４０は、認証用トークンの生成が成功したか否かを判定する。ステップＳ２１０で、認証用トークンの生成が成功したと判定された場合（ＹＥＳ）は、ステップＳ２１１で、トークン生成部１４０は、要求元のＷＰＨ１１８またはＷＰＦ１２２に認証トークンを出力し、ステップＳ２１３で本処理を終了する。一方、ステップＳ２０１で、引数が不正であると判定された場合（不正）、ステップＳ２１０で、認証用トークンの生成が失敗した場合（ＮＯ）は、ステップＳ２１２で、要求元のＷＰＨ１１８にエラーを出力し、ステップＳ２１３で本処理を終了する。

図９および図１０は、本実施形態における複合機２０において、フレームワーク・ライブラリ１１４のトークン検証部１４２が実行する、トークン検証処理を示すフローチャートである。なお、図９および図１０は、ポイントＡおよびポイントＢを経由して連結されていることに留意されたい。図９および図１０に示す処理は、ＷＰＨ１１８またはＷＰＦ１２２からＡＰＩを介してトークン検証部１４２が呼び出されたことに応答して、ステップＳ３００から開始される。

ステップＳ３０１では、トークン検証部１４２は、ＷＰＨ１１８またはＷＰＦ１２２から渡された引数をチェックする。ステップＳ３０１で、引数が正しいと判定された場合（正常）は、ステップＳ３０２へ処理が進められる。ステップＳ３０２では、トークン検証部１４２は、ライブラリ１１６のウェブページ・ライブラリを用いて、ＨＴＴＰリクエストに含まれるリクエスト情報の取得を試みる。ステップＳ３０３では、トークン検証部１４２は、リクエスト情報の取得が成功したか否かを判定する。ステップＳ３０３で、リクエスト情報の取得が成功したと判定された場合（ＹＥＳ）は、ステップＳ３０４へ処理が進められる。

ステップＳ３０４では、トークン検証部１４２は、ライブラリ１１６のＨＴＴＰライブラリを用いて、リクエスト情報からＨＴＴＰリクエストに埋め込まれた認証用トークンの取得を試みる。ステップＳ３０５では、トークン検証部１４２は、埋め込まれた認証用トークンの取得が成功したか否かを判定する。ステップＳ３０５で、埋め込まれた認証用トークンの取得が成功したと判定された場合（ＹＥＳ）は、ステップＳ３０６へ処理が進められる。

ステップＳ３０６では、トークン検証部１４２は、ライブラリ１１６のＨＴＴＰライブラリを用いて、認証セッションＩＤの取得を試みる。ステップＳ３０７では、トークン検証部１４２は、認証セッションＩＤの取得が成功したか否かを判定する。ステップＳ３０７で、認証セッションＩＤの取得が成功したと判定された場合（ＹＥＳ）は、ステップＳ３１１へ直接処理が進められる。一方、ステップＳ３０７で、認証セッションＩＤの取得が失敗したと判定された場合（ＮＯ）には、ステップＳ３０８へ処理が分岐される。

ステップＳ３０８では、トークン検証部１４２は、ライブラリ１１６のＨＴＴＰライブラリを用いて、ＨＴＴＰセッションＩＤの取得を試みる。ステップＳ３０９では、トークン検証部１４２は、ＨＴＴＰセッションＩＤの取得が成功したか否かを判定する。ステップＳ３０９で、ＨＴＴＰセッションＩＤの取得が成功したと判定された場合（ＹＥＳ）には、ステップＳ３１１へ直接処理が進められる。一方、ステップＳ３０９で、ＨＴＴＰセッションＩＤの取得も失敗したと判定された場合（ＮＯ）には、ステップＳ３１０へ処理が分岐される。ステップＳ３１０では、トークン検証部１４２は、ウェブ・ブラウザ１５０のユーザエージェント情報からデフォルト値を取得し、ステップＳ３１１へ処理を進める。

ステップＳ３１１では、トークン検証部１４２は、上述までに取得された認証セッションＩＤ、ＨＴＴＰセッションＩＤまたはデフォルト値を第１シードとして決定する。ステップＳ３１２では、トークン検証部１４２は、第２シードとして内部管理値を取得する。ステップＳ３１３では、トークン検証部１４２は、上記取得された第１シードと第２シードとを用いて、上述したトークン生成部１４０で用いたものと同一の関数を用いて検証用トークンの値を計算する。

ステップＳ３１４では、トークン検証部１４２は、検証用トークンの生成が成功したか否かを判定する。ステップＳ３１４で、検証用トークンの生成が成功したと判定された場合（ＹＥＳ）は、ポイントＡを経由して、図１０に示すステップＳ３１５へ処理を進める。ステップＳ３１５では、トークン検証部１４２は、ステップＳ３０４で取得された、埋め込まれた認証用トークンと、ステップＳ３１３で計算された検証用トークンの値とを比較する。ステップＳ３１６では、トークン検証部１４２は、埋め込まれた認証用トークンと、計算された検証用トークンの値とが一致しているか否かを判定する。ステップＳ３１６で、一致すると判定された場合（ＹＥＳ）は、ステップＳ３１７へ処理が進められる。ステップＳ３１７では、トークン検証部１４２は、戻り値を「ＴＲＵＥ」に設定し、ステップＳ３２０で本処理を終了させる。戻り値「ＴＲＵＥ」は、リクエストに含まれる認証用トークンが正しい旨を表している。

一方、ステップＳ３１６で、一致しないと判定された場合（ＮＯ）は、ステップＳ３１８へ分岐される。ステップＳ３１８では、トークン検証部１４２は、デバッグ出力をし、ステップＳ３１９で、戻り値を「ＦＡＬＳＥ」に設定し、ステップＳ３２０で本処理を終了させる。戻り値「ＦＡＬＳＥ」は、リクエストに含まれる認証用トークンが誤っている旨を表す。

ステップＳ３０１で引数が不正であると判定された場合（不正）、ステップＳ３０３でリクエスト情報の取得が失敗した場合（ＮＯ）、ステップＳ３０５で認証用トークンの取得に失敗した場合（ＮＯ）、ステップＳ３１４で検証用トークンの再計算が失敗した場合（ＮＯ）は、ポイントＢを経由して、同様にステップＳ３１８へ分岐させられる。ステップＳ３１８では、トークン検証部１４２は、デバッグ出力をし、ステップＳ３１９で、戻り値を「ＦＡＬＳＥ」に設定し、ステップＳ３２０で本処理を終了させる。

図１１は、管理者ユーザにより正規に設定が要求された場合の動作を説明する図である。これに対し図１２は、不正に設定が要求された場合（ＣＳＲＦ攻撃を受けた場合）の動作を説明する図である。なお、図１１および図１２の両方の場合において、クライアント端末１４は、正規の管理者ユーザとして複合機２０のシステム設定用ウェブ・アプリケーション１１０にログインしているものとする。つまり、ＨＴＴＰセッションＩＤおよび認証セッションＩＤの両方が、ウェブ・ブラウザ１５０と複合機２０との間で共有されているものとする。

図１１を参照して、正規の設定が要求される場合の動作について説明する。正規の設定が要求される場合は、まずステップＳ４０１で、クライアント端末１４は、第１リクエストとして、ＣｏｏｋｉｅにＨＴＴＰセッションＩＤ（ｓｅｓｉｄ＝１５３８５９６３）を含めて、所定のＵＲＬを指定するＧＥＴリクエストを複合機２０に送信する。ここではＧＥＴリクエストとしているが、ＰＯＳＴリクエストでもよい。これを受けて、複合機２０は、トークン生成部１４０を用いて認証用トークン（ｓｅｓｉｄＳＴＲ＝ａ３ｅ５３ｄ５ａｂａ）を生成し、適宜有効期限を設定する。ステップＳ４０２では、複合機２０は、設定フォーム画面に認証用トークンを埋め込んで、第１レスポンスを返信する。

クライアント端末１４は、第１レスポンスを受信すると、設定フォーム画面を表示する。ステップＳ４０３では、クライアント端末１４は、第２リクエストとして、設定フォーム画面を介して設定された設定内容とともに第１レスポンスに含まれる認証用トークンを付して、所定のＵＲＬを指定するＰＯＳＴリクエストを複合機２０に送信する。これを受けて、複合機２０は、トークン検証部１４２を用いて認証用トークン（ｓｅｓｉｄＳＴＲ＝ａ３ｅ５３ｄ５ａｂａ）の検証を行う。ここでは、ＨＴＴＰセッションＩＤが一致し、埋め込まれた認証用トークンと、再計算された検証用トークとも一致するので、リクエストの正当性が確認され、設定内容の登録処理を実行する。ステップＳ４０４では、複合機２０は、設定変更が成功裡に完了した旨を第２レスポンスとして返信する。

図１２を参照して、不正に設定が要求される場合、すなわちＣＳＲＦ攻撃を受けた場合の動作について説明する。ＣＳＲＦは、悪意のあるページを閲覧した際に、Ｊａｖａｓｃｒｉｐｔ（登録商標）等が実行されたりして、ブラウザが複合機のウェブ・ユーザインタフェースへ向けて、悪意のあるパラメータをポストし、これが正規のＨＴＴＰセッションとして受理されてしまうという脆弱性である。

不正に設定が要求される場合として、ここでは、ステップＳ５０１で、クライアント端末１４が悪意のあるウェブサーバ１８にリクエストを送信し、ステップＳ５０２で、悪意のあるウェブページを含むレスポンスを受信したケースを考える。この悪意のあるウェブページには、複合機２０のシステム設定用アプリケーション１１０のＵＲＬを指定し、悪意のあるパラメータをポストする悪意のあるコードが含まれる。図１２中に例示する悪意のあるウェブページ２３０では、戻るボタン２３２がクリックされることにより、複合機２０に悪意のあるパラメータをポストするコードが埋め込まれおり、このコードには、何らかのトークンが埋め込まれる場合もある。

ステップＳ５０３では、クライアント端末１４は、上記悪意のあるコードの実行結果として、複合機２０に対し、第２リクエストとして、悪意のある設定内容とともにＰＯＳＴリクエストを複合機２０に送信する。上記悪意のウェブページは、クライアント端末１４のウェブ・ブラウザ１５０で開かれ、ＰＯＳＴリクエストは、クライアント端末１４のウェブ・ブラウザ１５０から行われるので、リクエスト自体は、クライアント端末１４からのＨＴＴＰセッションとして受理される。

これを受けて、複合機２０は、トークン検証部１４２を用いて認証用トークンの検証を行うが、この場合、ＨＴＴＰセッションＩＤが一致するものの、付されたトークン値と、認証セッションＩＤなどを用いて計算された検証用トークとが一致しないため、リクエストの正当性が否定され、設定内容をキャンセルする。ステップＳ５０４では、複合機２０は、設定変更が失敗した旨をレスポンスとして返信する。

図１３は、本実施形態のトークン処理によるメモリ効率化を説明する図である。従来技術のトークン処理では、ＨＴＴＰセッションＩＤおよび認証セッションＩＤに加え、これらの関連付けて、リクエスト検証のためトークン値をメモリ上に保持しなければならなかった。これに対して、本実施形態のトークン処理では、認証セッションＩＤおよび内部管理値をシードとしてリクエスト毎に検証用トークン値が計算されて比較が行われるため、別途トークンをメモリ上に管理しておく必要がなく、高いメモリ効率が達成される。

以上説明した実施形態によれば、リクエストを検証するための検証用トークンが、アプリケーションの認証セッションＩＤを用いて再計算されるため、ユーザ毎に検証用トークンをメモリ上に保持する必要がない。このため、別途トークンを保持する実装に比較してメモリ効率を向上させることができる。また、トークンの計算は、認証セッションＩＤに加えて内部管理値を用いて行われるため、認証セッションＩＤが漏洩してしまうことも防止される。

また、上記実施形態では、ログイン前に表示されるアプリケーション画面、ログイン後に表示されるアプリケーション画面、また保護対象として明示的に定義されたアプリケーション画面など、各種画面に応じて用いる認証情報を変更することで、トークンの生成方法を変更することもできる。また、認証セッションＩＤが取得できない場合の代替手段として、ＨＴＴＰセッションＩＤなど他の認証情報を利用したり、ユーザエージェント情報を利用したりすることができるので、メモリ効率を落とさずに、全てのユーザに対して脆弱性対応が可能となる。

なお、上述までの実施形態では、複合機２０が備えるシステム設定用ウェブ・プリケーションに適用した場合を一例として説明してきた。しかしながら、上述したトークン処理が適用可能な構成は、上記複合機が備えるシステム設定用ウェブ・アプリケーションに限定されるものではない。例えば他の実施形態では、図１４に示すように、多数のクライアント端末３０４ａ〜３０４ｄに対して、オンライン・ショッピングなどのウェブ・アプリケーションを提供するウェブサーバ３１０として、情報処理装置を構成することもできる。

図１５は、ウェブサーバ３１０として構成した他の実施形態によるウェブサーバのブロック図を示す。図１５に示すように、ウェブサーバ３１０は、機能構成として、ＨＴＴＰデーモン４０２と、ウェブ・アプリケーション４１０と、画面定義部４２８と、ＸＭＬスキーマ４３０と、言語リソースＸＭＬ４３２と、ＸＳＬ４３４とを含む。この実施形態では、ウェブサーバ３１０は、図３に示すアプリケーション／コントロール・サービス１２６に代えて、ウェブ・アプリケーション上で提供される各種データ４２６を備える。トークン生成部およびトークン検証部を含む他の構成については、上述した複合機２０による実施形態と同様とすることができる。

以上説明したように、上述までの実施形態によれば、本発明は、ユーザ毎にリクエスト検証のための認証用トークンをメモリ上に保管しておく必要がなく、ユーザに対し認証情報の入力を求める手間をかけず、リクエストの正当性の検証が可能な、情報処理装置、情報処理システムおよびプログラムを提供することができる。

なお、上記機能部は、アセンブラ、Ｃ、Ｃ＋＋、Ｃ＃、Ｊａｖａ（登録商標）、などのレガシープログラミング言語やオブジェクト指向プログラミング言語などで記述されたコンピュータ実行可能なプログラムにより実現でき、ＲＯＭ、ＥＥＰＲＯＭ、ＥＰＲＯＭ、フラッシュメモリ、フレキシブルディスク、ＣＤ−ＲＯＭ、ＣＤ−ＲＷ、ＤＶＤ−ＲＯＭ、ＤＶＤ−ＲＡＭ、ＤＶＤ−ＲＷ、ブルーレイディスク、ＳＤカード、ＭＯなど装置可読な記録媒体に格納して、あるいは電気通信回線を通じて頒布することができる。

これまで本発明の実施形態について説明してきたが、本発明の実施形態は上述した実施形態に限定されるものではなく、他の実施形態、追加、変更、削除など、当業者が想到することができる範囲内で変更することができ、いずれの態様においても本発明の作用・効果を奏する限り、本発明の範囲に含まれるものである。

１０，３００…ネットワーク環境、１２，３０２…ネットワーク、１４，３０４…クライアント端末、１８…悪意のあるウェブサーバ、２０…複合機、２２…ＣＰＵ、２４…メモリ、２６…ＮＩＣ、２８…オペレーション・パネル、３０…スキャナ、３２…プロッタ、３４…ＨＤＤ、３６…内部バス、４２…ソフトウェア部、４４…複合機起動部、４６…ハードウェア部、４８…アプリケーション層、５０…プラットフォーム層、５２…コントロール・サービス層、５４…ＯＳ、５６…モノクロ・レーザプリンタ、５８…カラー・レーザプリンタ、６０…ＭＬＣ、６２…ハードウェア・リソース、６４…プリンタ・アプリケーション、６６…コピー・アプリケーション、６８…スキャナ・アプリケーション、７０…ウェブ・アプリケーション、７２…ＮＣＳ、７４…ＤＣＳ、７６…ＯＣＳ、７８…ＦＣＳ、８０…ＥＣＳ、８２…ＭＣＳ、８４…ＵＣＳ、８６…ＳＣＳ、８８…ＡＰＩ、９０…エンジン・インタフェース、１０２，４０２…ＨＴＴＰデーモン、１０４，４０４…ＸＳＬＴプロセッサ、１１０…システム設定用ウェブ・アプリケーション、１１２，４１２…ライブラリ群、１１４，４１４…フレームワーク・ライブラリ、１１６，４１６…ライブラリ、１１８，４１８…ＷＰＨ、１２０，４２０…タイプライブラリ、１２２，４２２…ＷＰＦ、１２４，４２４…ウェブサービス・ファンクション、１２６，４２６…アプリケーション／コントロール・サービス、１２８，４２８…画面定義部、１３０，４３０…ＸＭＬスキーマ、１３２，４３２…言語リソースＸＭＬ、１３４，４３４…ＸＳＬ、１３６…ＨＴＴＰセッション管理部、１３８…認証セッション管理部、１４０…トークン生成部、１４２…トークン検証部、１５０…ウェブブラウザ、２００…フォーム画面、２０２…プルダウンメニュー、２０４…プルダウンメニュー、２０６…戻るボタン、２０８…設定ボタン、２１０…設定成功画面、２１２…表示、２１４…戻るボタン、２２０…設定失敗画面、２２２…表示、２２４…戻るボタン、２３０…悪意のあるウェブページ、２３２…戻るボタン、３１０…ウェブサーバ、４１０…ウェブ・アプリケーション、４２６…各種データ

特開２０１０−１１３５６６号公報

Claims (9)

1. ネットワークに接続される情報処理装置であって、
   前記ネットワークを介したリクエストおよびレスポンスを含むトランザクションを管理する第１セッション管理手段と、
   認証されたユーザの認証識別情報を管理する第２セッション管理手段と、
   第１のリクエストに応答して、要求元ユーザの認証識別情報を取得し、内部で管理される管理値を用いて、第１レスポンスに含めるトークン値を生成するトークン生成手段と、
   第２のリクエストに応答して、要求元ユーザの認証識別情報を取得し、前記管理値を用いてトークン値を計算するトークン計算手段と、
   前記第２のリクエストに応答して、前記トークン計算手段によって計算されたトークン値と、前記第２のリクエストに含まれるトークン値とを比較して、正誤を検証するトークン検証手段と
   を含む、情報処理装置。
2. 前記トークン生成手段および前記トークン計算手段は、それぞれ、要求元ユーザの認証識別情報が取得されなかった場合に、取得可能な識別情報から段階的にトークン計算のための第１シードの取得を試み、取得された第１シードと、第２シードとして前記管理値とを用いて、トークン値を計算する、請求項１に記載の情報処理装置。
3. 前記トークン生成手段および前記トークン計算手段は、それぞれ、要求元ユーザの認証識別情報が取得されなかった場合に、トランザクションの認証識別情報を取得し、前記要求元ユーザの認証識別情報に代えて前記トランザクションの認証識別情報を第１シードとし、前記管理値を第２シードとして、トークン値を計算する、請求項１または２に記載の情報処理装置。
4. 前記トークン生成手段および前記トークン計算手段は、それぞれ、要求元ユーザの認証識別情報が取得されず、トランザクションの認証識別情報が取得されなかった場合に、ユーザエージェント情報を取得し、前記ユーザエージェント情報を前記第１シードとしてトークン値を計算する、請求項３に記載の情報処理装置。
5. 前記トークン生成手段によるトークン値の生成と、前記トークン検証手段によるトークン値の検証とを適用する保護対象のアプリケーション画面が定義されている、請求項１〜４のいずれか１項に記載の情報処理装置。
6. 前記第１レスポンスは、受信したクライアントに対し、該第１レスポンスが含むトークン値を含めて第２リクエストを送信するよう指令するデータを含む、請求項１〜５のいずれか１項に記載の情報処理装置。
7. 前記第１セッション管理手段は、ＨＴＴＰリクエストおよびＨＴＴＰレスポンスを含むＨＴＴＰトランザクションを管理し、前記第２セッション管理手段は、ウェブ・アプリケーションでのログイン認証されたユーザのセッションを管理し、前記トークン値は、ハッシュ関数を用いて算出される、請求項１〜６のいずれか１項に記載の情報処理装置。
8. ネットワークを介して接続されるサーバとクライアントとを含む情報処理システムであって、前記サーバは、
   前記ネットワークを介した前記クライアントとのリクエストおよびレスポンスを含むトランザクションを管理する第１セッション管理手段と、
   認証されたユーザの認証識別情報を管理する第２セッション管理手段と、
   第１のリクエストに応答して、前記クライアントのユーザの認証識別情報を取得し、内部で管理される管理値を用いて、第１レスポンスに含めるトークン値を生成するトークン生成手段と、
   第２のリクエストに応答して、前記クライアントのユーザの認証識別情報を取得し、前記管理値を用いてトークン値を計算するトークン計算手段と、
   前記第２のリクエストに応答して、前記トークン計算手段によって計算されたトークン値と、前記第２のリクエストに含まれるトークン値とを比較して、正誤を検証するトークン検証手段と
   を含み、前記クライアントは、前記サーバから前記第１レスポンスを受信し、前記第１レスポンスが含むトークン値を付して第２リクエストを前記サーバに送信するブラウザ手段を含む、情報処理システム。
9. ネットワークに接続される情報処理装置であって、前記ネットワークを介したリクエストおよびレスポンスを含むトランザクションを管理する第１セッション管理手段、認証されたユーザの認証識別情報を管理する第２セッション管理手段、第１のリクエストに応答して、要求元ユーザの認証識別情報を取得し、内部で管理される管理値を用いて、第１レスポンスに含めるトークン値を生成するトークン生成手段、第２のリクエストに応答して、要求元ユーザの認証識別情報を取得し、前記管理値を用いてトークン値を計算するトークン計算手段、および前記第２のリクエストに応答して、前記トークン計算手段によって計算されたトークン値と、前記第２のリクエストに含まれるトークン値とを比較して、正誤を検証するトークン検証手段を含む、当該情報処理装置の各手段として、コンピュータを機能させるためのプログラム。