JP4878193B2

JP4878193B2 - 判定プログラム、判定方法及び判定装置

Info

Publication number: JP4878193B2
Application number: JP2006092513A
Authority: JP
Inventors: 登車井
Original assignee: Fujitsu Ltd
Current assignee: Fujitsu Ltd
Priority date: 2006-03-29
Filing date: 2006-03-29
Publication date: 2012-02-15
Anticipated expiration: 2026-03-29
Also published as: US20070233818A1; JP2007265291A

Description

本発明は、サーバ機のアプリケーションのフレームワークに関し、特に、クライアント機に提供される入出力画面データを生成するサーバ機での、コマンドの合致判定を行う判定プログラム、判定方法及び判定装置に関する。

クライアント機から通信ネットワークを介してアクセスされるアプリケーションサーバ機の処理に、入出力画面生成処理がある。この入出力画面生成処理は、例えばクライアント機からサーバ機内の所定のサーバ・アプリケーションにアクセスがあった場合などにおける各画面の生成処理であり、画面遷移に大きく寄与する。

この入出力画面生成処理では、一般的に、クライアント機に表示されている画面で発行されたリクエスト情報からパラメータを抽出して、そのパラメータで指定された処理を例えば所定の業務処理部へ振り分けるなどして実行し、その処理結果を基にクライアント機へ送信する次の画面（応答画面）を生成する。

サーバ機は、上記入出力画面生成処理により、クライアント機から送られてくるリクエスト情報に対応した画面をクライアント機に提供している。
また、上記画面生成処理に関連して、この他に、クライアント機で複数のブラウザが起動された場合などの情報管理方法を開示した特許文献がある。この文献には、リクエストが発行された画面の状態に対応するアプリケーションの処理情報をサーバ機で再現する機能が開示されている（特許文献１参照）。
特開２００４−２５９０１６号公報

上述したように、入出力画面生成処理ではクライアント機で発行されたリクエスト情報に与えられているパラメータに基づいて応答画面を生成する処理が行われる。
このため、悪意のあるユーザが意図的にそのパラメータを操作して、そのリクエスト情報をサーバ機へ送信した場合には、想定外の手順となるため問題である。

図１２は、リクエスト情報の中に改竄されたパラメータが含まれている場合に入出力画面生成処理で生成する画面の遷移を示した図である。
同図は、パラメータに応じた業務処理をビジネスクラスに振り分けて処理させる構成のものをモデルとして示したものである。また、生成画面は、各生成画面内に構成されているボタンがその度ごとに押下されることにより、画面１から画面４に順に遷移するものとする。

本例では、本来は画面１のボタンが押されてそのリクエスト情報がサーバ機に送信されるところを、あたかも画面３のボタンが押されたかのように改竄されたリクエスト情報がサーバ機に送信された場合の画面遷移を一例として示している。

この例の場合、本来はボタン１のコマンド情報に対応するビジネスクラスで処理が実行され、その結果として画面２が生成されるはずであるが、実際にはボタン３のコマンド情報を受け取ったため、ボタン３のコマンド情報に対応する実行すべきでないビジネスクラスで処理が実行されることになり、その結果として他の画面（本例では画面４）が生成される。

つまり、本来の画面遷移（画面１の次は画面２に遷移）とは異なる画面遷移（画面１から画面４）が当然のことのように実行されてしまうことになる。
本来、サーバ・アプリケーションなどはビジネスクラスが順番に実行されることを想定して設計されるため、このような飛び越し処理が行われると問題が発生することがある。例えば、発注システムでは、在庫数の確認処理を飛ばして発注処理が行われてしまうなどの恐れがあり、この場合、在庫が残っているにもかかわらず補充のための発注がおこなわれてしまうなどの問題が発生してしまう。

そこで本発明では、予め決まっている所定の順番で画面遷移を行わせることが可能なサーバ機で実行する判定プログラム、判定方法及び判定装置を提供することを目的とする。

本発明は上記課題を解決するために以下のように構成する。
本発明のプログラムの態様の一つは、コンピュータに、処理要求コマンドと対応付けられた表示要素を含む画面についての画面情報を、他のコンピュータに送信する場合に、前記画面情報に含まれる前記処理要求コマンドを記憶手段に記憶し、前記他のコンピュータから、処理要求コマンドを含むデータを受信した場合に、受信した前記データに含まれる処理要求コマンドが、前記記憶手段に記憶されている前記処理要求コマンドと合致するか否かの判定を行なう、ことを実行させることを特徴とする判定プログラムである。

なお、前記判定の結果、合致しない場合に、前記データに含まれる処理要求コマンドの実行を抑止することが好ましい。

また、前記判定の結果、合致する場合に、前記記憶手段に記憶された前記処理要求コマンドを削除することが好ましい。

本発明の方法の態様の一つは、コンピュータに、処理要求コマンドと対応付けられた表示要素を含む画面についての画面情報を、他のコンピュータに送信する場合に、前記画面情報に含まれる前記処理要求コマンドを記憶手段に記憶し、前記他のコンピュータから、処理要求コマンドを含むデータを受信した場合に、受信した前記データに含まれる処理要求コマンドが、前記記憶手段に記憶されている前記処理要求コマンドと合致するか否かの判定を行なう、ことを実行させることを特徴とする判定方法である。
本発明の装置の態様の一つは、処理要求コマンドと対応付けられた表示要素を含む画面についての画面情報を、他のコンピュータに送信する場合に、前記処理要求コマンドを前記画面情報から抽出する抽出手段と、前記抽出手段が抽出した前記処理要求コマンドを記憶する記憶手段と、前記他のコンピュータから、処理要求コマンドを含むデータを受信した場合に、受信した前記データに含まれる処理要求コマンドが、前記記憶手段に記憶されている前記処理要求コマンドと合致するか否かの判定を行なう判定手段と、を含むことを特徴とする判定装置である。

本発明では、所定の順番で画面を遷移させることが可能になる。また、画面順に従わない不正に改竄されたリクエスト情報がクライアントから送信された場合であっても、予定にない画面遷移を抑止できるようになる。

以下、本発明を実施するための最良の形態について、図面を参照しながら詳細に説明する。
先ず、本発明のプログラムを適用する対象について概要説明し、その次に、本発明のプログラムについて詳しく説明する。

本発明のプログラムは、クライアント機とサーバ機とが通信ネットワークにより接続された通信システムにおいてサーバ機側に適用されるものである。特に、アプリケーション（サーバ・アプリケーション）を実装し、そのサーバ・アプリケーションが有する特有の機能をクライアント機からのリクエスト情報に応じて自機内で実行させる環境をもつサーバ機（例えばアプリケーションサーバ機など）で実行される。

本発明のプログラムは、そのサーバ・アプリケーションの入出力画面生成機能（特に、不正な画面遷移を抑止する機能）を実現するために適用されるものである。この入出力画面生成機能とは、対クライアント送信用の入出力画面情報（例えばＨｔｔｐ通信でＷｅｂサーバからＷｅｂブラウザに転送するための画面情報など）をクライアント機からのリクエスト情報に応じて生成する機能である。

以下、本発明のプログラムについて説明する。
本発明のプログラムは、本プログラム内に記述されている次の2つの処理ステップに特徴を有している。

一つ目の特徴的な処理ステップ（第一の特徴的な処理）は、クライアント機へ入出力画面情報を送信する前に、その入出力画面情報に含まれているコマンド情報（例えばＷｅｂブラウザに表示されたその入出力画面に含まれる所定のボタンをクライアントが入力指定したときに発行されるコマンド名などの情報）をサーバ機内のＲＡＭ（Random Access Memory）などのメモリに記憶させるステップである。

二つ目の処理ステップ（第二の特徴的な処理）は、クライアント機からリクエスト情報が送信されてきた場合に、そのリクエスト情報に含まれているコマンド情報が上記メモリに記憶されているコマンド情報と対応しているか否か（例えば一致しているか否か）を判定するステップである。ただし、これらの判定は、互いに共通のセッション内（同一セッション内）の情報を対象に行うものとする。

本プログラムを含むサーバ・アプリケーションが上述のサーバ機に実装され、そこで実行されると、クライアント機へ送信する入出力画面情報（この画面識別番号を「１」とする）の生成処理段階からその画面識別番号「１」の入出力画面情報のクライアントからの応答（サーバ機に対するリクエスト）を受信する受信処理段階までを1サイクルとして、上記2つのステップがその順に１回実行され、そのセッションが終了するまでの複数サイクルに渡って繰り返し実行される。

つまり、本プログラムがサーバ機で実行されると、サーバ機は、クライアント機から次に送られてくるであろうコマンド情報を常に予測できるようになり、それ以外のコマンド情報をリクエスト情報として受け取った場合は、これを検出し、その後に続く処理を振り分けることができる。

この振り分け方の一例を次に示す。
先ず、各コマンド情報が一致していた場合について示す。この場合はそのリクエスト情報は改竄のない正当なものと期待できる。そのため、続く処理では、通常の入出力画面生成処理を行い、そのリクエスト情報に応じた入出力画面情報を得る。

次に、各コマンド情報が一致していなかった場合について示す。この場合はそのリクエスト情報は改竄されていると考えられる。このため、続く処理では、例外処理を行い、この改竄されたリクエスト情報に基づいて通常の入出力画面生成処理をした場合における予定外の入出力画面情報の生成を抑止する。

このように、クライアント機から送信されたリクエスト情報が改竄されたものであった場合は、それをサーバ機で検出する事が可能になり、クライアント機に提供する入出力画面の不当な遷移を抑止し、その画面遷移順を正当な順番に維持できる。

上述したように、本発明のプログラムは、上記サーバ・アプリケーションの入出力画面生成機能（特に、不正な画面遷移を抑止する機能）をサーバ機で実現させるものである。そのプログラムのサーバ機への実装方法としては、例えば、本発明のプログラムを含むサーバ・アプリケーションを一から開発して、そのサーバ・アプリケーションをサーバ機のＲＡＭやＲＯＭなどのメモリに読み込ませるなどして実装することができる。また、予め、本発明のプログラムをフレームワークとして提供し、このフレームワークを適宜組み込んでアプリケーションを完成させ、これらをサーバ機のＲＡＭやＲＯＭなどのメモリに読み込ませるなどして実装してもよい。このように本プログラムをサーバ機に実装することにより、上述した入出力画面生成機能（特に、不正な画面遷移を抑止する機能）がサーバ機上で実現する。

以下に、本機能をフレームワークで実現した場合の例を説明する。
この例では、Ｗｅｂブラウザを実装したクライアント機とアプリケーションサーバよりなるサーバ機とが、ＬＡＮやインターネットなどの通信ネットワークにより接続された構成を前提にしている。

上記アプリケーションサーバには、Ｗｅｂサーバや、上記フレームワークを実行するための各種のプログラムやファイルや、このフレームワークを取り入れて完成したＷｅｂアプリケーションなどが実装されている。本例では上記フレームワークをサーブレットやＪＳＰ（Java(登録商標) Server Pages）を使用してＪＡＶＡ(登録商標)ベースで構築したため、それらを動かすサーブレットコンテナやＪＳＰコンテナが更に実装されている。

この構成下では、Ｗｅｂブラウザから所定のアドレスが指定されることで、クライアント機からのリクエスト情報がＷｅｂサーバを介してサーブレット／ＪＳＰコンテナへ渡される。そして、サーブレットやＪＳＰが実行されることにより、このリクエスト情報に基づいてフレームワークが実行される。例えば、制御処理などはサーブレットが行い、表示関係はＪＳＰが行う。

図１はそのフレームワークの一例である。
このフレームワーク１は、所定の業務処理をビジネスクラスで行うように設計し、またクライアント機に出力する入出力画面情報の合成処理をＪＳＰファイルで行うように設計し、更に、ビジネスクラスとの情報の受け渡しをデータＢｅａｎ（Ｊａｖａ(登録商標)Ｂｅａｎ形式のクラス）で行うように設計したものである。このため、本例では、予め、ビジネスクラス２とＪＳＰファイル３、及び、これらの関係定義ファイル（コマンドマップ４及びページマップ５）を用意している。

また、上述のようにビジネスクラスとの情報の受け渡しをデータＢｅａｎで行うように設計しているため、リクエスト情報内（具体的にはリクエストパラメータ）に、データBean名（データ格納名とも呼ぶ）とコマンド名の値を含ませる。

ビジネスクラス２は、業務ごとのビジネスロジックが記述されたＪａｖａ(登録商標)のクラスである。
ＪＳＰファイル３は、例えば各種形態のフォームを備えた入出力画面情報を得るためのＪＳＰファイルである。

上記コマンドマップ４は、リクエスト情報とビジネスクラス２（より具体的にはビジネスクラス及びメソッド）とを対応付けた定義ファイルである。本例では、リクエスト情報にコマンド名とデータＢｅａｎ名を含ませるため、コマンドマップ４には、次のようにデータBean名、コマンド名、ビジネスクラス名、メソッド名の対応関係を記述しておきます。

＜記述形式＞
# [入力のデータBeanのクラス名］；［コマンド］=［ビジネスクラス名］；［メソッド名］
例）calc.BodyBean;add=calc.CalcHandler.add

上記ページマップ５は、ビジネスクラス２の結果情報とＪＳＰファイル３のファイル名を対応付けた定義ファイルである。

そして、セッションクラス６やアプリケーションクラス７は、フレームワーク内に構成されている。特に、セッションクラス６は、セッション管理を行なうセッション管理テーブルや、コマンド情報（具体的には、データＢｅａｎ名及びコマンド名である。以下では、必要に応じてこの具体的な内容で示すこととする。）を管理するコマンド情報管理テーブルをオブジェクトとしてもっている。セッションクラスでは、初めてＷｅｂアプリケーションにアクセスがあったときにそのクライアント機のセッションオブジェクトを生成し、そのセッションを閉じるまでの一定期間、そのクライアント機とそのＷｅｂアプリケーション間の通信をそこでもつセッションの識別番号で管理する。前者のセッション管理テーブルは、そのための管理テーブルに使用されるものである。なお、後者のコマンド情報管理テーブルについては、後述することとする。

以上の条件の下に、本フレームワーク１の全体の流れを説明する。
ＦＳ１では、フレームワーク１がクライアント機側からリクエスト情報を受け取り、セッションクラスを用いてそのリクエスト情報に対する正当性検証の処理を行う。この処理は、上記第二の特徴的な処理に相当するものである。なお、この処理については、後で、更に詳しく説明する。

ＦＳ２では、フレームワーク１が、コマンドマップ２を参照して、リクエスト情報に合ったビジネスクラス４を決定する。
ＦＳ３では、処理がビジネスクラス４に移行され、このビジネスクラス４が実行される。

ＦＳ４では、そのビジネスクラス４の実行結果がフレームワーク１に返却される。
ＦＳ５では、フレームワーク１が、ページマップ３を参照して、ビジネスクラス４の実行結果に合ったJSPファイル７を決定する。

ＦＳ６では、処理がJSPファイル７に移行され、JSPファイル７が実行される。
ＦＳ７では、JSPファイル７の実行結果（これは、次にクライアント機へ出力されるＪＳＰの入出力画面情報である）がフレームワーク１に返却され、このＪＳＰの入出力画面情報を基にフレームワーク１がコマンド情報を抽出処理し、セッションクラスのコマンド情報管理テーブルに格納処理する。これらの処理は、上記第一の特徴的な処理に相当するものである（この処理についても、後で、更に詳しく説明する）。なお、このステップでは、上記JSPの入出力画面情報にビジネスクラスの結果情報を反映する処理なども行われる。

ＦＳ８では、上記入出力画面情報をＷｅｂサーバを介してクライアント機側に返却する。
図２は、上記フレームワークの機能ブロック図である。

同図には、当該フレームワークとデータの授受を行う関連ファイルや関連クラスなども共に明示している。これらにおいて、図１と同一のものについては、図１と同じ番号を付している。

本例のフレームワーク１は、制御部１０、コマンド一覧情報チェック部１２、及びコマンド一覧情報保持部１４で構成されている。
制御部１０は、図１に示したフレームワークの全体の制御、及びＪＳＰの入出力画面情報からのコマンド情報の抽出処理やこの抽出したコマンド情報を後述のコマンド一覧情報保持部へ格納する処理（上記第一の特徴的な処理）を司る。

コマンド一覧情報チェック部１２は、制御部１０がクライアント側から受け取ったリクエスト情報の正当性を検査する処理部である。この処理部では、上記制御部１０からリクエスト情報を受け取ると、そのリクエスト情報が属するセッション内のコマンド情報を後述のコマンド一覧情報保持部１４から抽出して上記リクエスト情報と上記コマンド情報との対応関係をチェックする。そして、その結果情報を制御部１０に返す。

コマンド一覧情報保持部１４は、コマンド情報を記憶したコマンド情報管理テーブルである。このコマンド情報管理テーブルは、例えばセッション識別番号などによって上述したセッション管理テーブルと対応づけられており、制御部１４から格納されたコマンド情報をセッション識別番号と関連付けて所定期間保持し、コマンド一覧情報チェック部１２からの抽出依頼に応じて該当のセッション識別番号のコマンド情報を上記コマンド一覧情報チェック部に渡す。ただし、制御部１４からコマンド情報が格納される際は、そのセッション識別番号に既に対応付けて保持されているコマンド情報（以前に格納されたコマンド情報）を削除して、新たに格納されるコマンド情報をそのセッション番号に対応づけ、１つのセッション識別番号に対してコマンド情報を一つだけ対応するようにするものとする。また、セッションが切れると、そのコマンド情報を削除する。

図３は、上記制御部の処理（前段部分の処理）を構成するプログラムのフロー図である。
本フロー図には、リクエスト情報を受信してからビジネスクラスへ処理を振り分けるまでの処理が記述されている。

ステップＳ10は、リクエスト情報を受信する処理である。
ステップＳ12は、そのリクエスト情報を解析し、コマンド名及びデータＢｅａｎ名を抽出する処理である。

ステップＳ14は、リクエスト正当性検証処理（図５の処理）をコマンド一覧情報チェック部１２に行わせる処理である。この処理で、ステップＳ１２で抽出したリクエストパラメータをコマンド一覧情報チェック部１２へ渡し、コマンド一覧情報チェック部１２からその検証処理結果を受け取る。

ステップＳ16は、上記リクエストパラメータに対応するビジネスクラスおよびメソッドを上記コマンドマップ２から決定する処理である。
ステップＳ18は、ステップＳ14でコマンド一覧情報チェック部12から受け取った検証処理結果にエラー情報が含まれているか否かを判定する処理である。

ステップＳ20は、ステップＳ18でエラー情報を含まないと判定された場合に行う処理であり、この処理では、ステップＳ16で決定したビジネスクラス及びメソッドに実行処理（通常処理）を通知する。

ステップＳ22は、ステップＳ18でエラー情報を含むと判定された場合に行う処理であり、この処理では、ステップＳ16で決定したビジネスクラス及びメソッドに例外の実行処理（例外処理）を通知する。

図４は、リクエスト正当性検証処理プログラムのフロー図である。
本プログラムは、図３の制御部の処理ステップ14にコマンド一覧情報チェック部１２で実行される処理である。以下に示す処理は、制御部からリクエスト情報を受け取った後に実行される。

ステップＳ140は、当該リクエスト情報に対してセッションが発行されているか否かを判定する処理である。
ここでは、セッション管理テーブルにその識別情報番号がない（ＮＵＬＬ）であった場合に、セッション識別番号が付与されていない始めてのリクエストであると判定し、ＮＵＬＬで無かった場合に、すでにセッション番号が付与されている２回目以降のリクエストであると判定する。

若し、ＮＵＬＬであった場合は、セッション識別番号を発行してセッション管理テーブルに登録するなどして本処理を終了し、検証処理結果としてエラー無しの情報を制御部へ渡す。

ステップＳ142は、ステップＳ140でＮＵＬＬでないと判定された場合の処理で、コマンド情報管理テーブルからそれと同一セッションに属するコマンド情報格納位置から情報を取得する。

ステップＳ144は、コマンド情報の有無を判定する処理である。ステップＳ142で抽出した情報にコマンド情報が含まれているか否かを判定する。
ステップＳ146は、ステップＳ144でコマンド情報が含まれていないと判定された場合の処理である。この処理では、リクエスト情報にコマンド情報が含まれているか否かを更に判定する。特に、この処理でリクエスト情報にコマンド情報が含まれていないと判定された場合は、このリクエスト情報の送信の基になった画面内にコマンド情報が元々含まれていないことを表わしている。そのため、その判定結果の場合には、このリクエストは、クライアントによるリクエストの改竄のない正当なリクエストであると判断されるため、この場合には本処理を終了し、検証処理結果としてエラー無しの情報を制御部へ渡す。
ステップＳ148は、ステップＳ146でリクエスト情報にコマンド情報が含まれていると判定された場合の処理である。この判定結果の場合、クライアント機で改竄された不当なリクエストであると判断されるため、例外処理を保存して本処理を終了し、検証処理結果としてエラー有りの情報を制御部へ渡す。

ステップＳ150は、ステップＳ144でコマンド情報が含まれていると判定された場合の処理である。この処理では、そのコマンド情報のコマンド名及びデータＢｅａｎ名と、リクエスト情報内のコマンド名とデータＢｅａｎ名とが一致しているか否かを判定する。特に、この処理で一致していると判定された場合は、このリクエストの送信の基になった画面に基づいて正しくコマンド情報が発行されてきたものと判断される。このため、その判定結果の場合には、本処理を終了し、検証処理結果としてエラー無しの情報を制御部へ渡す。

ステップＳ152は、ステップＳ150で一致していないと判定された場合の処理である。この判定結果の場合、クライアント機で改竄された不当なリクエストであると判断されるため、例外処理を保存して本処理を終了し、検証処理結果としてエラー有りの情報を制御部へ渡す。

図５は、ＪＳＰファイルの解析処理の処理フローである。
ステップＳ500は、ＪＳＰの入出力画面情報内に拡張タグ（本例では、共通ＪＳＰインタフェース（ＵＪＩ））があるか否かを判定する処理である。この処理で拡張タグがないと判定されると、本処理を終了する。

ステップＳ502は、ステップＳ500で拡張タグがあると判定された場合に実行する処理である。この処理では、クライアント機に入力フォームを提供するフォームに関する拡張タグ（ＦＯＲＭタグ）があるか否かを判定する。この処理でフォームに関する拡張タグがないと判定されると、ステップＳ504の処理をとばしてステップＳ506の処理に移行する。
ステップＳ504は、ステップＳ502でフォームに関する拡張タグがあると判定された場合の処理である。この処理では、その拡張タグに含まれるコマンド名及びデータＢｅａｎ名をコマンド情報管理テーブルに保存する。

ステップＳ506は、当該ＪＳＰの入出力画面情報を基に、画面を構築する処理である。
なお、ステップＳ500からＳ506までの一連の処理は、一つの入出力画面においてフォーム単位で行われ、一つの入出力画面内に複数のフォームが繰り返し記述されている場合は、全てのフォームを対象にその処理が実行されるまで繰り返される。

図６は、プログラムの実行時に制御部から見た場合の、図５の処理（ＪＳＰファイルの解析処理）の順番を示した図である。
ステップＳ50は、図３のステップＳ20の通知をトリガに実行されるビジネスクラスの処理である。

ステップＳ52は、上記ＪＳＰファイルの解析処理である。
このように、ＪＳＰファイルの解析処理は、上記ビジネスクラスの実行結果を制御部が受け取った後に行われるように設定する必要がある。

ここで、上記ＪＳＰの入出力画面及びコマンド情報管理テーブルの具体例をあげる。
図７は、ＪＳＰファイルから出力されるＪＳＰの入出力画面情報（言い換えると、制御部で取得されるＪＳＰの入出力画面情報）の具体例である。

同図に示されるように、本入出力画面情報３０はＪＳＰで記述されている。
１行目と２行目は、拡張タグ（本例では、ujiタグ）を使用していることの宣言文などを示している。

３行目は、この入出力画面情報に対応するデータＢｅａｎの名前（id）を定義している。また更に、クライアント機の画面が複数ウインドウまたはフレーム分割された場合であって、そのうちの一画面領域に本入出力画面情報を対応させる場合の例として、本入出力画面情報が対応する画面領域を示す情報（本例では、ＨＥＡＤ領域とＢＯＤＹ領域の２領域のうちのＢＯＤＹ領域を示す情報）を定義している。

そして、４行目から最後の行までのフォームタグ内で、クライアント機側で上記画面領域に表示させる入力フォームを記述している。
本例では、その４行目のフォームの開始タグ（＜uji:form＞）の中に、入力フォームに使用するコマンド名や、対応するデータＢｅａｎ名などを全て纏めて記述した態様をとっている。具体的には、verbsに指定されている値（login）がコマンド名であり、beanIdに指定されている値（body）が上記画面領域の名前であり、BeanClsに指定されている値（security.BodyBean）が、上記Ｂｅａｎ名である。なお、画面領域の名前はサーバ機で対応するＢｅａｎ名に置き換えられる。また、クライアント機では、そのフォーム内のボタンが押下されることでそのボタンのコマンド名（login）が発行され、データＢｅａｎ名と共にリクエスト情報に含ませてサーバ機に送信される。

この入出力画面情報を対象に図６のＪＳＰファイルの解析処理を実行すると、本入出力画面情報３０のＦＯＲＭタグ（＜uji:form＞）に含まれる上記コマンド名（login）及び画面領域名（body）、また必要に応じてデータＢｅａｎ名（security.BodyBean）も抽出され、コマンド情報管理テーブルに格納される。コマンド情報としては、コマンド名及びデータＢｅａｎ名があれば構成できるが、必要に応じて、データＢｅａｎ名に画面領域名を加えたり、またはデータＢｅａｎ名に換えて画面領域名を使用するなどして良い。

なお、本例ではコマンド情報を一組（loginとbodyの一組）としたが、複数組ある場合は、当然、それらの全てを抽出し、コマンド情報管理テーブルに格納する。
また、本例では、一画面領域（ＢＯＤＹ領域）に一つのフォーム（開始タグ（＜uji:form＞）と終了（＜/uji:form＞）の一組で示されるフォーム）しか構成されていないが、フォームが複数ある場合は、各フォームごとにコマンド情報を抽出し、コマンド情報管理テーブルに格納する。

図８は、コマンド情報管理テーブルの一例である。
一般的に、Ｗｅｂアプリケーションでは、１画面内に複数の送信ボタンが存在する場合や、フレームで画面が分割されている場合や、さらには複数のウィンドウで１つのアプリケーションを構成している場合がある。これらを考慮して、本例では、以下の形式でコマンド情報を保持するようにする。

コマンド情報の最小単位は、データ格納名（データＢｅａｎ名や画面領域名）及びコマンド名の組み合わせとする。この場合、一つのデータ格納名に対して複数のコマンド名が組み合わさる場合もある。

上記コマンド情報をフォームの単位に纏めて保持する。
上記フォーム単位で纏められたコマンド情報をフレーム単位またはウインドウ単位に纏めて保持する。

このような形態では、例えば、フレーム名やウインドウ名をキーに利用するなどして、対象のコマンド情報を抽出したり、対象の領域にコマンド情報を格納したり、または対象の領域のコマンド情報を削除したりすることができる。

以上示してきた、図３から図６に示される手順のプログラムや、図７に示されるＪＳＰの入出力画面情報を出力するＪＳＰファイルや、図８に示されるコマンド情報管理テーブルや、その他、定義ファイルやビジネスクラスなどの必要なファイルを含むＷｅｂアプリケーション、また、この実行環境として当然に必要とされる各種プログラムやデータは、サーバ機にインストールしておき、クライアントからリクエストを受けた時に直ぐにＣＰＵで実行されるように、活性化しておく。

こうすることにより、図３に示す機能がサーバ機上で実現され、クライアント機から送信されたリクエスト情報を基に、図２に示す処理フローが行われるようになる。
図９は、そのサーバ機のシステム構成図の一例である。

本サーバ機は、ＣＰＵ（中央演算処理装置）１０００、ＲＯＭやＲＡＭなどのメモリ１００２、ハードディスク１００４、通信部１００６、記録媒体読取部１００８、及びキーボードやモニタなどと接続される入出力部１０１０がバス１０１２に接続されて構成されている。

上記各プログラムやファイルは、ハードディスク１００４からメモリ１００２に読み込まれるなどして、ＣＰＵ１０００により処理が実行される。
なお、以上説明してきた各プログラムやファイルは、その一部若しくは全部を、図１０に示されるようなフロッピー(登録商標)ディスク（登録商標）、ＣＤ−ＲＯＭ、或いはＤＶＤなどの記録媒体１１００に記録させて配布したり、または、図１１に示されるような公衆網等で用いられる伝送媒体１２００を介して配信するようにしたりすることができる。

ユーザのコンピュータは図９に示される構成と同様であるため、図９に示されるサーバ機の構成を用いて上記ケースを説明すると、それを受けとったユーザは、記録媒体読取部１００８や通信部１００６を介して上記プログラムやファイルをハードディスク１００４にコピーすることができる。そして、ハードディスク１００４にコピーした各プログラムやファイルをメモリ１００２に読み込んでＣＰＵ１０００で処理を実行させることにより、ユーザのコンピュータ上で、上記各機能を実現させることが可能になる。

以上より、クライアント機から送信されたリクエスト情報が改竄されたものであった場合は、それをサーバ機で検出する事が可能になり、クライアント機に提供する入出力画面の不当な遷移を抑止し、その画面遷移順を正当な順番に維持できる。

（付記１）
対クライアント送信用の入出力画面情報を生成する機能をサーバ機で実現させることが可能なプログラムであって、クライアント機へ送信する上記入出力画面情報のコマンド情報をメモリに記憶させるステップと、クライアント機からリクエスト情報が送信されてきた場合に、上記メモリに記憶した同一セッション内のコマンド情報に上記リクエスト情報が対応しているか否かを判定するステップと、をサーバ機で実行することが可能なプログラム。
（付記２）
クライアント機へ送信する上記入出力画面情報のコマンド情報をメモリに記憶させるステップでは、上記コマンド情報を記憶する際に同一セッション内で以前に記憶されたコマンド情報を削除する、ことを特徴とする付記１に記載のプログラム。
（付記３）
Ｗｅｂアプリケーションの入出力画面の生成機能をサーバ機に実現させることが可能なプログラムであって、業務処理を行うビジネスクラスと、同一セッションの画面をセッション識別番号で管理するセッションクラスと、複数種類のＪＳＰファイルと、を有し、クライアント機から送信されたコマンド名とデータ格納名との組み合わせに基づいて上記ビジネスクラスを決定するステップと、上記ビジネスクラスから得た結果情報に基づいて上記複数種類のＪＳＰファイルの中からＪＳＰファイルを決定するステップと、上記ＪＳＰファイルから得られる入出力画面情報を基に、上記コマンド名とこれに対応するデータＢｅａｎ名とを抽出し、上記セッションクラスにセッション識別番号と対応付けて格納するステップと、クライアント機からデータＢｅａｎ名とコマンド名とを受信した際に、該データＢｅａｎ名と該コマンド名とが上記セッションクラスに格納した同一セッション内のデータＢｅａｎ名とコマンド名とに対応しているか否かを判定するステップと、対応していないと判定された場合に、例外処理を行うステップと、をサーバ機で実行することが可能なプログラム。
（付記４）
上記ＪＳＰファイルから得られる入出力画面情報を基に、上記コマンド名とこれに対応するデータＢｅａｎ名とを抽出し、上記セッションクラスにセッション識別番号と対応付けて格納するステップにおいて、上記コマンド名とこれに対応するデータＢｅａｎ名とをセッション識別番号と対応付けて格納する際に、上記セッションクラスに以前に格納された同一セッション識別番号の上記コマンド名とデータＢｅａｎ名とを削除する、ことを特徴とする付記３に記載のプログラム。
（付記５）
上記ＪＳＰファイルから得られる入出力画面情報を基に抽出される上記コマンド名は、上記入出力画面情報のＪＳＰ拡張タグの位置に示されるコマンド名である、ことを特徴とする付記３または４に記載のプログラム。
（付記６）
上記ＪＳＰファイルから得られる入出力画面情報を基に抽出される上記コマンド名は、上記入出力画面情報のＦＯＲＭタグの位置に示されるコマンド名である、ことを特徴とする付記５に記載のプログラム。
（付記７）
付記１乃至６の内の何れか一つに記載のプログラムを格納した記録媒体。
（付記８）
付記１乃至６の内の何れか一つに記載のプログラムをＣＰＵで実行可能なように実装したサーバ機。
（付記９）
対クライアント送信用の入出力画面情報の生成時に不正な画面遷移をサーバ機で抑止する方法であって、クライアント機へ送信する上記入出力画面情報のコマンド情報をメモリに記憶し、クライアント機からリクエスト情報が送信されてきた場合に、上記メモリに記憶した同一セッション内のコマンド情報に上記リクエスト情報が対応しているか否かを判定し、対応していない場合に、例外処理を行う、ことを特徴とする方法。
（付記１０）
上記コマンド情報を記憶する際に、同一セッション内で以前に記憶されたコマンド情報を削除する、ことを特徴とする付記９に記載の方法。
（付記１１）
Ｗｅｂアプリケーションの入出力画面を生成する際に不正な画面遷移をサーバ機で抑止する方法であって、クライアント機から送信されたコマンド名とデータ格納名との組み合わせに基づいてビジネスクラスを決定し、上記ビジネスクラスから得た結果情報に基づいて複数種類のＪＳＰファイルの中からＪＳＰファイルを決定し、上記ＪＳＰファイルから得られる入出力画面情報を基に、上記コマンド名とこれに対応するデータＢｅａｎ名とを抽出して、セッションクラスにセッション識別番号と対応付けて格納し、クライアント機からデータＢｅａｎ名とコマンド名とを受信した際に、該データＢｅａｎ名と該コマンド名とが上記セッションクラスに格納した同一セッション内のデータＢｅａｎ名とコマンド名とに対応しているか否かを判定し、対応していないと判定された場合に、例外処理を行う、ことを特徴とする方法。
（付記１２）
上記コマンド名とこれに対応するデータＢｅａｎ名とをセッション識別番号と対応付けて格納する際に、上記セッションクラスに以前に格納された同一セッション識別番号の上記コマンド名とデータＢｅａｎ名とを削除する、ことを特徴とする付記１１に記載の方法。
（付記１３）
上記ＪＳＰファイルから得られる入出力画面情報に基づき、ＪＳＰ拡張タグの位置に示されるコマンド名を抽出する、ことを特徴とする付記１１または１２に記載の方法。
（付記１４）
上記ＪＳＰファイルから得られる入出力画面情報に基づき、ＦＯＲＭタグの位置に示されるコマンド名を抽出する、ことを特徴とする付記１３に記載の方法。

フレームワークの一例である。フレームワークの機能ブロック図である。制御部の処理（前段部分の処理）を構成するプログラムのフロー図である。リクエスト正当性検証処理プログラムのフロー図である。ＪＳＰファイルの解析処理の処理フローである。ＪＳＰファイルの解析処理の順番を示した図である。ＪＳＰファイルから出力されるＪＳＰの入出力画面情報の具体例である。コマンド情報管理テーブルの一例であるサーバ機のシステム構成図の一例である。記録媒体の図伝送媒体の図従来の不正な画面遷移図

符号の説明

１フレームワーク
２ビジネスクラス
３ＪＳＰファイル
４コマンドマップ
５ページマップ
６セッションクラス
７アプリケーションクラス

Claims

コンピュータに、
処理要求コマンドと対応付けられた表示要素を含む画面についての画面情報を、他のコンピュータに送信する場合に、前記画面情報に含まれる前記処理要求コマンドを記憶手段に記憶し、
前記他のコンピュータから、処理要求コマンドを含むデータを受信した場合に、受信した前記データに含まれる処理要求コマンドが、前記記憶手段に記憶されている前記処理要求コマンドと合致するか否かの判定を行なう、
ことを実行させることを特徴とする判定プログラム。
前記コンピュータに、
前記判定の結果、合致しない場合に、前記データに含まれる処理要求コマンドの実行を抑止する、
ことを実行させることを特徴とする請求項１に記載の判定プログラム。
前記コンピュータに、
前記判定の結果、合致する場合に、前記記憶手段に記憶された前記処理要求コマンドを削除する、
ことを実行させることを特徴とする請求項１又は請求項２に記載の判定プログラム。
コンピュータに、
処理要求コマンドと対応付けられた表示要素を含む画面についての画面情報を、他のコンピュータに送信する場合に、前記画面情報に含まれる前記処理要求コマンドを記憶手段に記憶し、
前記他のコンピュータから、処理要求コマンドを含むデータを受信した場合に、受信した前記データに含まれる処理要求コマンドが、前記記憶手段に記憶されている前記処理要求コマンドと合致するか否かの判定を行なう、
ことを実行させることを特徴とする判定方法。
処理要求コマンドと対応付けられた表示要素を含む画面についての画面情報を、他のコンピュータに送信する場合に、前記処理要求コマンドを前記画面情報から抽出する抽出手段と、
前記抽出手段が抽出した前記処理要求コマンドを記憶する記憶手段と、
前記他のコンピュータから、処理要求コマンドを含むデータを受信した場合に、受信した前記データに含まれる処理要求コマンドが、前記記憶手段に記憶されている前記処理要求コマンドと合致するか否かの判定を行なう判定手段と、
を含むことを特徴とする判定装置。