JP4629291B2

JP4629291B2 - Method and system for verifying client requests

Info

Publication number: JP4629291B2
Application number: JP2001533487A
Authority: JP
Inventors: モラン、タル; − ハナニ、ユヴァルエル; ラーナン、ギル; レシェフ、エラン
Original assignee: International Business Machines Corp
Current assignee: International Business Machines Corp
Priority date: 1999-10-25
Filing date: 2000-10-25
Publication date: 2011-02-09
Anticipated expiration: 2020-10-25
Also published as: ATE398798T1; EP1232425A4; EP1232425A2; WO2001031415A2; EP1232425B1; AU7944100A; IL149322A0; JP2003513349A; WO2001031415A3; DE60039248D1

Abstract

A system and method are presented for authorizing execution of requested actions (104A) transmitted between clients (122) and servers (100) of a data processing system. The method includes receiving a message (104B) including a set of actions and simulating execution of the set of actions. A list representing allowable actions (118) and user-definable inputs to the simulated actions is defined. The list of allowable actions (118) and user definable inputs to the allowable action (118) is then compared to user requested actions and inputs. When elements within the user requested actions and inputs are included in the allowable actions (118) and input list, the user requested actions and inputs are authorized for execution (124).

Description

【０００１】
（著作権の注意）
本出願ドキュメントの部分は、著作権保護を受ける内容を含む。著作権の所有者は、特許事務所または商標事務所の特許ファイルまたは記録にあるように、誰もが出願ドキュメントまたは出願の開示をファクシミリで再生することに異存はないが、そうでない場合、すべての著作権を保有する。
【０００２】
（関連する出願）
本出願は、以下の同時係属中の出願に関連する。
・１９９９年１０月２５日に出願された、弁理士整理番号第３２６９／８号であるＭＥＴＨＯＤＡＮＤＳＹＳＴＥＭＦＯＲＶＥＲＩＦＹＩＮＧＡＣＬＩＥＮＴＲＥＱＵＥＳＴという名称の米国仮特許出願第６０／１６１，４７３号
・１９９９年７月１日に出願された、弁理士整理番号第３２６９／６号であるＭＥＴＨＯＤＡＮＤＳＹＳＴＥＭＦＯＲＥＸＴＲＡＣＴＩＮＧＡＰＰＬＩＣＡＴＩＯＮＰＲＯＴＯＣＯＬＣＨＡＲＡＣＴＥＲＩＳＴＩＣＳという名称の米国特許出願番号第０９／３４５，９２０号
・１９９８年９月９日に出願された、弁理士整理番号第３２６９／３号であるＭＥＴＨＯＤＡＮＤＳＹＳＴＥＭＦＯＲＰＲＯＴＥＣＴＩＮＧＯＰＥＲＡＴＩＯＮＳＯＦＴＲＵＳＴＥＤＩＮＴＥＲＮＡＬＮＥＴＷＯＲＫＳという名称の米国特許出願番号第０９／１４９，９１１号
・１９９８年９月９日に出願された、弁理士整理番号第３２６９／４号であるＭＥＴＨＯＤＡＮＤＳＹＳＴＥＭＦＯＲＭＡＩＴＡＩＮＩＮＧＲＥＳＴＲＩＣＴＥＤＯＰＥＲＡＴＩＮＧＥＮＶＩＲＯＮＭＥＮＴＳＦＯＲＡＰＰＬＩＣＡＴＩＯＮＰＲＯＧＲＡＭＳＯＲＯＰＥＲＡＴＩＮＧＳＹＳＴＥＭＳという名称の米国特許出願番号第０９／１５０，１１２号
・ＰＣＴ出願ＰＣＴ／ＩＬ９８／３２６９／４
・ＰＣＴ出願ＰＣＴ／ＩＬ９８／００４４３
・ＰＣＴ出願ＰＣＴ／ＩＬ００／００３７８
これらの出願の開示は、参照することによって、完全に本明細書に組み込まれている。
【０００３】
（発明の背景）
本発明は、一般に、プライバシおよびセキュリティのシステムに関し、より詳細には、データ処理システム内において、クライアント装置とホスト装置との間で送信された要求、データ、情報内容、アプリケーション、および他の情報を認可する方法およびシステムに関する。
【０００４】
（従来の技術）
クライアント／サーバ・データ処理システムでは、いくつかのパーソナル・コンピュータ、ワーク・ステーション、携帯式および／または手持ち式装置など（「クライアント」）は、１つまたは複数のホスト・コンピュータ（「サーバ」）と連結され、かつ通信している。サーバは、ネットワーク上でクライアントによって共有されている情報および／またはアプリケーション・プログラムに対するクライアントからの要求を処理する。ますます、クライアント／サーバ・ネットワークは、例えば、それ自体がワールド・ワイド・ネットワークの一部である、すなわち、インターネットのワールド・ワイド・ウェブの一部（「ウェブ」）であることが可能であるイントラネットおよびエキストラネットなど、より広範な「ネットワークのネットワーク」を形成するために、連結されるようになってきた。ネットワークを連結することにより、クライアントは、ネットワークにわたって、リソース（例えば、情報およびアプリケーション・プログラム）を供給することが可能になる。
【０００５】
潜在的にワールド・ワイド・ネットワーク上で、共有されている情報およびアプリケーション・プログラムの利用可能性が増大するにつれ、個々のクライアント／サーバ・ネットワークの各々の脆弱性が増大している。例えば、ネットワークの１つに記憶されている所有権を主張できる情報およびアプリケーション・プログラムを検索および／または損傷しようとする不謹慎な個人は、所有権を主張できる情報およびアプリケーション・プログラムにアクセスして、無認可の方式で、それを使用する可能性がある。そのような無認可の使用を防止する努力では、多くのネットワークは、「ファイアウォール」を通して、他のネットワークに接続されている。従来のファイアウォールは、内部ネットワーク・リソース（例えば、特有のウェブ・サーバまたはフォルダ）へのアクセス制御に対処し、ネットワークの部分へのアクセスを制限し、および、それに記憶されている所有権を主張できる情報およびアプリケーション・プログラムに対する無認可の検索または損傷を防止するように設計されたハードウェアおよび／またはソフトウェア・システムを含む。
【０００６】
しかし、多くの従来のファイアウォール・システムは、アプリケーション・レベルでは認可に対処せず、認可されたクライアントであると偽った不謹慎な個人によって機能しなくなる可能性がある。例えば、多くのウェブ・アプリケーションは、アプリケーションのユーザは、実際に彼／彼女のブラウザ上でアプリケーションのモバイル・エージェントを実行していると想定している。しかし、悪意のあるユーザは規格のウェブ・ブラウザ・ソフトウェアを使用せずにウェブ・サーバに接続することができ、したがって、そのユーザはブラウザ側で強化することが可能である制限になんら束縛されず、悪意のあるユーザは、標準的なクライアントであると偽って、ウェブ・サーバに破壊的なまたは捏造したデータを送信することができる。
【０００７】
共通して譲受された米国特許出願第０９／３４５，９２０号には、標準的なＨＴＭＬドキュメントのユーザからの要求を確認するための解決法が記載されている。その解決法は、ＨＴＭＬドキュメントの内容（「認可されたアクション」）に基づいて、ブラウザ・ソフトウェアが取ることが可能であるアクションのセットまたはパターン（ＨＴＴＰ要求）を抽出することに基づいている。次いで、この認可されたアクションのセットは、クライアントのアプリケーションによって送信された要求に対して整合される。ユーザが、規格のブラウザの１つを使用していない場合であっても、アクションの法的または認可されたセット内からの要求のみが、ウェブ・サーバに渡されることになる。
【０００８】
以上の内容を考慮して、本発明の発明者は、上述した確認技術を、ウェブ・サーバの代わりにクライアント・システム上で実行する論理（例えば、ＨＴＭＬページに埋め込まれたＪａｖａＳｃｒｉｐｔ（ＴＭ）プログラム）に拡張する必要性を認識した。特に、本発明者は、外部データとその上で起きている事象を入手および確認するために、クライアント・サイドの論理の実行をシミュレーションする必要性を認識した。
【０００９】
（発明の簡単な概要）
本発明の目的は、サーバ・システムの代わりに、クライアント・システム上で実行する論理のための確認技術を提供することである。
【００１０】
本発明の他の目的は、クライアント・サイドの論理（例えば、ＨＴＭＬページに埋め込まれたＪａｖａＳｃｒｉｐｔプログラム）のための確認技術を提供することである。この技術は、外部データとそこで起きている事象を入手および確認するために、論理の実行をシミュレーションする。
【００１１】
本発明のさらに他の目的は、外部データと事象とに対する認可された要求のみが、クライアントから保護されたサーバに渡されるように、論理の実行をシミュレーションするクライアント・サイドの論理のための確認技術を提供することである。
【００１２】
本発明の他の目的および利点は、図面とそれに続く記載を考慮することから、より明らかになるであろう。
【００１３】
以上および他の問題点は、克服され、目的は、システムおよび方法が、クライアントとデータ処理システムのサーバとの間で送信された要求されたアクションの実行を認可するために提示されている、本発明の実施形態による方法および装置によって実現される。該方法は、アクションのセットまたはプログラム（例えば、ＨＴＭＬページに埋め込まれたＪａｖａＳｃｒｉｐｔプログラム）を含んでいるメッセージを受信することと、アクションのセットの実行をシミュレーションすることとを含む。リストは、実行されたアクションと、実行されたアクションへのユーザが定義可能な入力とを表すように定義される。次いで、実行されたアクションと、実行されたアクションへのユーザが定義可能な入力のリストとは、許容可能なアクションと入力のリストと比較される。実行リスト内の要素が許容可能なアクションと入力のリストに含まれているとき、メッセージとアクションの含まれていたセットは認可される。
【００１４】
本発明は、例示的であり、限定的でないことを意図している添付の図面の図に示されている。図では、同じ参照符号は、同じまたは対応する部分を指すことを意図している。
【００１５】
（好ましい実施形態の詳細な説明）
図１Ａは、本発明の一実施形態により構成されかつ動作するクライアント／サーバ・データ処理ネットワーク１０を示す。データ処理ネットワーク１０は、１つまたは複数のホスト／サーバ・コンピュータと連結され、かつ通信している、パーソナル・コンピュータ、ワーク・ステーション、携帯式および／または手持ち式装置など、複数のクライアント・システムを含む。図示を明瞭にするために、複数のクライアントは、クライアント・システム１２によって表し、１つまたは複数のサーバは、サーバ１４によって表している。クライアント１２とサーバ１４は、例えばインターネットのワールド・ワイド・ウェブの部分（「ウェブ」）、イントラネット、エキストラネット、または他の個人的なネットワークなど、通信ネットワーク１６に有線接続または無線接続を介して結合された、遠隔装置および／または局所装置とすることが可能であることを理解されたい。
【００１６】
本発明によれば、認可プロキシ・システム１８は、クライアント１２とサーバ１４の間で結合されており、クライアント１２とサーバ１４の間でセキュリティ・ポリシ・プロトコルを強化する。例えば、認可プロキシ・システム１８は、認可されたアクション（以下で定義）のみが、クライアント１２とサーバ１４との間で送信された要求、メッセージ、データ、情報内容、アプリケーション、および他の情報などの内部において実施されることを保証する。認可プロキシ・システム１８は、クライアント１２とサーバ１４との間で送信された要求、メッセージ、データ、情報内容、およびアプリケーションの内部にあるコマンド、フィールド、ユーザ選択可能入力オプション、ＨＴＴＰ要求など（例えば、「要求されたアクション」）の実行をシミュレーションし、要求されたアクションが、許容可能なアクション（例えば、「認可されたアクション」）のセット内において定義されることを保証する。許容可能なアクションのセット内に存在しないあらゆるアクションは、アクションの標的（例えば、サーバ１４またはクライアント１２）に到達し、おそらくはそれを破壊する前に、認可プロキシ１８によって拒否される。
【００１７】
認可プロキシの実装戦略を変更することは、本発明の範囲内にあることを理解されたい。例えば、図１Ａは、サーバ１４とは分離した別個のネットワーク１０のハードウェア構成要素１８として認可プロキシを示す。図１Ｂでは、認可プロキシは、サーバ２０上で実行するアプリケーション・プログラミング論理（「プラグイン」論理２６）として実装されている。また、サーバ２０は、例えばデータ・ストア２８に含まれている、またはウェブ・ページ３０の上に含まれている、サーバ２０にあるアプリケーション・プログラム、情報内容、およびデータを、要求のあり次第クライアント１２に提供するためのプラグイン論理２２および２４を含む。本発明によれば、認可プラグイン論理２６は、送信する前に、クライアント１２に提供されるプログラム、内容、およびデータを確認するために、サーバ２０の上で実行される。
【００１８】
別法として、図１Ｃは、ネットワーク１０’上のルータまたはハブ４２に結合されたスニファ装置４０内において侵入検出システムとして動作する認可プロキシを示す。一般に知られているように、ハブ４２は、ネットワーク１０’内において通信を向ける。図１Ｃに示したように、ハブ４２は、ネットワーク１０’上の直接通信から、ウェブ・サーバ４４を隔離する。スニファ４０は、ウェブ・サーバ４０を標的にした送信を検出し、遮断する。スニファ４０は、遮断した送信を評価し、送信内において要求されたアクションを、例えば、記憶装置４６内に含まれている認可されたアクションのリストと比較するために、以下で詳述する方法を実行する。受容可能でない場合、スニファ４０は、メッセージを変更するか、または、ネットワーク上の他のシステムにメッセージを渡す。
【００１９】
本発明の実施形態について、ウェブをベースとするアプリケーションとして特定のアプリケーションを有するように記載しているが、本明細書に記載されているシステムおよび方法が、任意のクライアント／サーバ通信システム、特に、無認可の要求、データ、およびアプリケーションからサーバを保護するのが望ましい通信システム内において適用可能であることは、本発明の範囲内にあることを理解されたい。
【００２０】
以下で詳述するように、本発明の認可プロキシは、サーバ・システムの代わりに、クライアント・システム上で実行される論理を確認するために、２つの技術を使用する。第１の技術では、認可プロキシは、クライアント・サイドの論理の実行をシミュレーションし、各可能なコマンド、フィールド、ユーザが選択可能な入力オプション、およびＨＴＴＰ要求を呼び出すおよび／またはトリガする。その結果、許容可能なブラウザ・アクションの完全なセットが識別され、実際のクライアント・セッションからの後の要求を確認するために使用される。第２の技術では、プロキシは、実際のクライアント・セッション中に、クライアントサイドの論理の実行を追跡する。追跡の結果は、サーバ・リソースに対する要求内において、認可プロキシに送信される。応答して、認可プロキシは、クライアント・サイドの論理の実行をシミュレーションし、シミュレーション中に入力オプションまたは外部データに対する他の要求に遭遇するとき、追跡結果が使用される。成功したシミュレーションは、サーバ・リソースに対するクライアント要求の承認となり、認可プロキシは、実際の処理のために、要求を適切なサーバに渡す。
【００２１】
２つの確認技術は、技術が未知のデータとユーザ介入事象とに関するクライアント論理の問合わせに応答する方法の点で異なっている。これらの技術については、以下で詳述する。
【００２２】
本発明の第１の態様では、認可プロキシ（例えば、プロキシ１８、「プラグイン」論理２６、およびスニファ４０）は、クライアントとサーバとの間の送信を評価する方法を呼び出し、サーバから発信されたメッセージ（例えば、ＪａｖａＳｃｒｉｐｔオブジェクト）に組み込まれているクライアント・サイドの論理をシミュレーションし、可能な要求されたアクションのリストを抽出する方法を呼び出す。クライアントが、要求を送信する場合、要求されたアクションは、認可されたアクションのリストに対して確認される。アクションが許容可能である場合、送信は、意図した標的の上に渡され、したがって、意図したアプリケーションに矛盾しない要求のみが実施される。
【００２３】
図２は、データ処理システムのクライアントとサーバとの間における伝送を確認するためのプロセス（例えば、前述した評価プロセス、シミュレートするプロセス、および抽出プロセス）を示す流れ図である。例えば、図２は、ウェブ・サーバからクライアント（例えば、図１のサーバ１４およびクライアント１２）への伝送（例えば、ＨＴＭＬウェブ・ページ１０２）を描いている。ブロック１００で、サーバ１４が、ＨＴＭＬウェブ・ページ１０２をクライアント１２に伝送する。伝送は、図２において線１０４Ａおよび１０４Ｂで表されている。図１Ａ〜１Ｃおよび図２に示すとおり、クライアント１２に対するどの伝送も、それぞれ、認可プロキシ１８、２６、４０によって代行受信される。これに応答して、認可プロキシは、確認プロセス（その詳細を破線１０６内に示す）を呼び出す。
【００２４】
ブロック１０８で、評価プロセスが呼び出される。評価プロセスには、例えば、ＨＴＭＬページ１０２を構文解析して、内容およびＨＴＭＬタグ、ならびにその中に組み込まれたクライアント側論理（例えば、ＪａｖａＳｃｒｉｐｔコード）を識別することが含まれる。ＨＴＭＬページ１０２中に存在する構成要素が識別されると、認可プロキシは、ページ１０２の構成要素の実行をシミュレートして（例えば、シミュレートされたブラウザ環境）、可能なすべての要求された処理を伝送の中で識別することができ、認可された処理のリストに提供できるようにする。
【００２５】
シミュレートされたブラウザ環境には、シミュレートされたブラウザのＤｏｃｕｍｅｎｔＯｂｊｅｃｔＭｏｄｅｌ（「ＤＯＭ」）およびブラウザ・オブジェクトが再現される、それぞれ、ブロック１１０および１１２、ＪａｖａＳｃｒｉｐｔランタイム環境が含まれる。ＪａｖａＳｃｒｉｐｔ標準オブジェクトのいくつかは、以下にさらに詳細に説明するとおり、置き換える必要がある。認可プロキシが、シミュレートされた環境内でＨＴＭＬページ１０２の構成要素を実行する。環境内のフックが、あらゆるトリガされたブラウザ処理、例えば、ＷＥＢサーバからドキュメントを検索する処理、またはＷＥＢサーバに書式をサブミットする処理を認可プロキシに知らせる。シミュレーションが完了すると、これらの処理は、以下に説明するとおり、クライアントの実際の要求（ブロック１２０における）に対してマッチされた認可された処理のリストを補足する。
【００２６】
前述したとおり、オブジェクトのいくつかおよびそのメソッドは、クライアント・ブラウザ環境を表すようにシミュレートされる必要がある。その第１に来るのは、ＨＴＭＬドキュメント１０２から作成されるＤＯＭである。さらに、Ｎａｖｉｇａｔｏｒなどのブラウザ・オブジェクトが存在し、このオブジェクトは、Ｎｅｔｓｃａｐｅにおいて、ブラウザ・コンテキストおよぶブラウザ・ウインドウに関する情報を提供する。列挙エンジン（ブロック１１４における）が、ＤＯＭ構成要素およびＪａｖａＳｃｒｉｐｔ構成要素のシミュレーションを調整する。また、時間オブジェクト、ランダム関数などのオブジェクトも、列挙エンジンによってシミュレートされる。これらのオブジェクトすべては、スクリプトがクライアントの環境内、例えば、クライアント・ブラウザ１２２上でそれらにアクセスした場合、スクリプトが獲得するものと整合性を有していなければならない。例えば、ＤＯＭのテキスト領域は、ユーザがブラウザ１２２に入力した値を返さなければならず、ランダム関数は、クライアント・スクリプトがユーザのブラウザ１２２内で獲得したのと同じ値を返さなければならず、またｎａｖｉｇａｔｏｒ．ｕｓｅｒＡｇｅｎｔは、クライアント・ブラウザ１２２の名前を戻さなければならない。
【００２７】
理解されるとおり、ブラウザ・オブジェクトに入力されるデータのいくつかは、エンベロープ・データから推論され、例えば、ｎａｖｉｇａｔｏｒ．ｕｓｅｒＡｇｅｎｔは、クライアント１２から送信されたＨＴＴＰヘッダから獲得することができる（例えば、ＨＴＭＬページ１０２のオリジナルの要求の中で）。ただし、いくつかのデータは、クライアント側で辿られる実際のシナリオに依存する。ＪａｖａＳｃｒｉｐｔ中に存在するイベント・ハンドラ（例えば、ユーザの行動に応答して実行されるコード）にさらなる複雑さが導入される。ＪａｖａＳｃｒｉｐｔのＨＴＭＬスクリプト・タグは、ロードされると実行されるが、ある種のコード（例えば、イベント・ハンドラ）は、ユーザの介入があったときにだけ実行される。例えば、ＨＴＭＬ言語の入力コントロールの多くに関するｏｎＣｌｉｃｋイベント・ハンドラが存在する。対応するイベント・ハンドラは、ユーザがコントロールを選択した（例えば、「クリックした」）ときだけ実行される。
【００２８】
列挙エンジン（ブロック１１４）が、カバレッジ・メソッドを行う。例えば、エンジンは、ＨＴＭＬページ１０２中のすべのてイベントをトリガすることにより、またユーザによる可能な様々な入力に対する複数のシミュレートされた実行を行うことにより、ブラウザ１２２による可能なすべての処理をカバーするものと想定する。理解されるとおり、この環境の実行時間は、多くの入力コントロールに依存するスクリプトの場合、指数関数的に増大する。また、この環境内でランダム関数を扱うのが困難である可能性がある。シミュレートされた実行は、その実行がユーザ入力を要求するまで進行する。要求の時点で、様々な可能な入力値でさらなる実行を記録し、シミュレートするのにユーザの行動が必要とされる。シミュレーション・メソッドのこの態様は、図３を参照して以下により詳細に述べる。
【００２９】
シミュレーションが完了すると、サーバから発信されたＨＴＭＬページ（および関連するクライアント側論理）と整合性を有する可能なすべてのブラウザ処理のリストが提供される。これらの可能な処理は、ブロック１１８で集約され、「正規の処理」として識別される。正規の処理は、認可プロキシによって利用されて、クライアント・ブラウザ１２２におけるＨＴＭＬページ１０２の特定の実行から受信される要求の処理を確認する。ブロック１２０で、クライアントの要求の処理が認可プロキシに戻され、認可プロキシによってＨＴＭＬページ１０２のシミュレーションから生成された正規の処理のリスト１１８と比較される。したがって、認可プロキシは、正規の処理のリスト１１８中にその要求および有効なユーザ入力が存在するか、存在しないかに応じてクライアントの要求を受け入れるか、または拒否する（例えば、対応する正規の処理が認可プロキシによって識別されなかった場合、要求の処理は拒否される）。正規の処理のリスト１１８は、クライアント・ブラウザ１２２からの要求の処理の受信における遅延に対応するように記憶するのが可能である（例えば、データ・ストア３０（図１Ｂ）または４６（図１Ｃ）に）ことを理解されたい。
【００３０】
図３を参照して、以下に、ＨＴＭＬページ１０２のシミュレートされた実行のなかでユーザ入力の要求および複数の可能な入力された値を扱うオプションを説明する。前述したとおり、ブロック１５０で、認可プロキシが、ＨＴＭＬページ１０２中に含まれるブラウザ・コマンドおよびクライアント論理の実行をシミュレートする。シミュレートされた実行は、入力コントロールが現れるまで（ブロック１５５で）続くか、または他のユーザ入力の要求が行われる（ブロック１６５で）。ブロック１５５で、例えば、＜ＴＥＸＴ＞、＜ＰＡＳＳＷＯＲＤ＞＆＜ＴＥＸＴＡＲＥＡ＞のＨＴＭＬタグなどのフリー・テキスト入力コマンドが、ＨＴＭＬページ１０２中で検出される。フリー・テキスト入力コマンドが現れた場合、コントロールは、ブロック１６０に進み、クライアントから受信した入力を表す固有プレース・ホルダが割り当てられる。ブロック１６０で割り当てられるプレース・ホルダは、例えば、ユーザの行動に応答してフリー・テキスト入力コマンドから生成された入力として生成されたＵＲＬ内で後に認識されるフィールドである。この後の段階で、認可プロキシは、受信したクライアント要求とのパターン照合を行う（図２のブロック１２０）。パターン照合は、「安全な」表現だけを許可するように実施する。好ましいパターン照合の技法は、本出願の出願人に共通で譲渡された米国特許出願第０９／３４５９２０号（弁理士整理番号３２６９／６）に記載されるＨＴＭＬリンク抽出器からもたらされる。プレース・ホルダを含む文字列に基づいて分岐判定（文の場合）を認識するフックが、ＪａｖａＳｃｒｉｐｔ環境の中に組み込まれる。そのような場合、これは、入力がスクリプトの論理進行に影響を与えることを意味するので、実行が無効にされる。システムは、プレース・ホルダが、生成されたＵＲＬ中に直接に現れることにより、またはプログラムの実行フローに影響を与えることにより間接に、生成されたＵＲＬに影響を与える場合、リンクを有効にすることができる。
【００３１】
制御は、ブロック１６０からブロック１６５に進むか、またはフリー・テキスト入力コマンドが全く現れない場合、ブロック１５５からブロック１６５に進む。ブロック１６５で、認可プロキシが、いくつかの可能な入力値の１つからのユーザによるコマンド要求入力の出現を検出する。そのようなコマンドが現れた場合、コントロールは、ブロック１７０に進み、現れなければ、コントロールは、ブロック１８０に進む。ブロック１７０で、列挙された入力コントロールに対する第１の入手可能な値が割り当てられる。他の可能な正規の入力値も入手可能であるので、制御は、ブロック１７５に進み、バックトラック・ログ１１６（図２）中にエントリが行われる。このエントリは、ＨＴＭＬページ１０２中の現在の実行の相対位置（例えば、実行における深さ）、ならびに可能な正規のエントリの残りの数を記録する。ログ１１６は、制御が、前の実行のポイント（深さ）にループバックし、可能な正規の入力値の次の値を選択し、次の正規の入力値で実行を続けるのを可能にすることを理解されたい。ループバックして、ＨＴＭＬページ１０２に対するすべての入力の実行をシミュレートすることにより、可能なすべてのブラウザ・コマンドおよびそれに対するユーザ入力が、前述した可能な正規の処理のリスト１１８中に収集される。
【００３２】
提供された値をログ記録した後、ブロック１８０で実行が継続する。ブロック１８０で、シミュレータが、コードの終りを検出する。終りが検出された場合、制御は、可能なバックトラック処理のためにブロック１８５に進む。終りが現れない場合、制御は、ブロック１５０にループバックし、前述したとおり、シミュレーションが継続する。ブロック１８５で、バックトラック・ログ１１６を評価して、さらなる可能な入力値が、さらなる可能な正規の処理の検出を駆動するかどうかが判定される。エントリがバックトラック・ログ１１６中に残っている場合、深さ変数を利用して、現れた複数の入力コマンドのどれかのところに実行が再配置される。再配置された後、入力コマンドの次の値が割り当てられ、シミュレーションが、相対ロケーションから先にコードの終りまで進む。そのようなループバック実行は、バックトラック・ログ１１６中の各値が尽きるまで継続される。
【００３３】
本発明者は、ＪａｖａＳｃｒｉｐｔ環境におけるバックトラッキングの一実施形態は、バックトラッキング・ポイントまで同一の値で実行を再開することであるのを確認した。別の正規の入力がこの時点で提供され、ログ記録される。このプロセスは、列挙されるすべての値が処理されるまで繰り返される。
【００３４】
前述したとおり、シミュレーション・プロセス中の可能なすべての入力およびイベントによってトリガされるすべてのブラウザ処理を集約することにより、認可プロキシは、ＷＥＢサーバで発信されるスクリプトと整合性を有する、クライアントからの実質的にすべてではないにしても、ほとんどの可能な要求のリストを獲得する。いくつかの実施形態では、このシステムは、以下に説明する追跡実施形態に対する補助として使用されて、より良好なパフォーマンスを得る。
【００３５】
以下に、本発明のシミュレーション実施形態の例を説明する。
ＨＴＭＬページ（例えば、ＨＴＭＬページ１０２）が、３つの入力コントロールを含む。
・２つの国、米国＆イスラエルのオプション・リスト（もちろん、完全なリストが可能である）
・性別、男性＆女性のラジオ選択
・ユーザの名前に関するテキスト入力
【００３６】
ＨＴＭＬ中に組み込まれたＪａｖａＳｃｒｉｐｔが、以下のパターンに従ってＵＲＬを構成する。
ｈｔｔｐ：／／ｓｉｔｅ．ｃｏｕｎｔｒｙ．ｐｅｒｆｅｃｔｏｔｅｃｈ．ｃｏｍ／ｇｅｎｄｅｒ／ｎａｍｅ．ｈｔｍｌ
ここで、ｃｏｕｎｔｒｙは、国別により「ｕｓ」または「ｉｌ」であり、ｇｅｎｄｅｒは、「ｂｏｙｓ」または「ｇｉｒｌｓ」という値であり、またｎａｍｅは、入力テキスト・フィールドである。
【００３７】
以下が、ＨＴＭＬページ・コードである。

【００３８】
前述したシミュレーション・プロセスは、以下のとおりコードを扱う。
１．ドキュメントの検査により、ＪａｖａＳｃｒｉｐｔを実行するイベントは、ＧｅｔＭｙＰａｇｅボタンの上でクリックすることだけであることが与えられる。このイベントがトリガされる。これが、バックトラック・ログ１１６中に記録され、これがトリガするイベントはこれだけであるという注釈が付けられ、これにより、このエントリが使い果たされる。使い果たしは、後続のステップでより詳細に説明する。
２．ブランチＡに到達するまでコードが実行される。
３．ｓｅｌｅｃｔｅｄＩｎｄｅｘ内で国を表す値が供給され、可能な２つの値、０（米国を表す）および１（イスラエルを表す）が存在する。第１の値が供給され、０の値がブランチＡで供給されたことが記録される。
４．実行が、ブランチＢに進み、Ｇｅｎｄｅｒラジオ・ボックスのチェックされた値がチェックされる。可能な２つの値、真（ｂｏｙｓ）および偽（ｇｉｒｌｓ）が存在する。真の値が供給されて、バックトラック・ログ１１６に記録される。
５．実行が、アクセスＣに到達するまで進み、テキスト・フィールドの値が必要とされる。プレース・ホルダが供給される。このプレース・ホルダは、通常の状況の下では現れる可能性のないＵＮＩＣＯＤＥ文字列である。このプレース・ホルダには、＜ＰＨｎａｍｅ＞というマークが付けられる。バックトラック・ログ１１６にこれをログ記録する必要はない。というのは、この値を対象とするバックトラッキングは、必要とされないからである。＜ＰＨｎａｍｅ＞のタイプが、最大長１０のテキストとして記録される。
６．オブジェクトｗｉｎｄｏｗのＪａｖａＳｃｒｉｐｔ関数ｏｐｅｎが、要求されたＵＲＬを記録する関数にシミュレートされた環境内でフックされる。構成されたＵＲＬは、次のようなものである。
ｈｔｔｐ：／／ｓｉｔｅ．ｕｓ．ｐｅｒｆｅｃｔｏｔｅｃｈ．ｃｏｍ／ｂｏｙｓ／＜ＰＨｎａｍｅ＞．ｈｔｍｌ．
７．ポリシー・エンフォーサが、最大長１０の任意のテキストに対して＜ＰＨｎａｍｅ＞をマッチさせるのが可能であるという注釈とともに、この新しい可能な処理のことを通知される。
８．実行が再開する。値が次の可能な値、つまり偽で置き換えられた最も深いバックトラッキング・エントリ（ブランチＢ）を例外として、同じステップが辿られる。ブランチＢの可能なすべての値は、使い果たされているので、バックトラック・ログ１１６中で、使い果たされているというマークが付けられる。
９．したがって、「ｇｉｒｌｓ」の値がｇｅｎｄｅｒフィールド内で提供され、生成されるリンクは、ｈｔｔｐ：／／ｓｉｔｅ．ｕｓ．ｐｅｒｆｅｃｔｏｔｅｃｈ．ｃｏｍ／ｇｉｒｌｓ／＜ＰＨｎａｍｅ＞．ｈｔｍｌである。
１０．実行が再開する。今度は、ブランチＢが最も深い分岐であり、次に許可される値、つまりイスラエルを表す１が提供される。
１１．再びブランチＢに到達し、今度は、バックトラック・ログ１１６は存在せず、したがって、（再）更新されたエントリがログ記録され、第１の正規の処理、すなわち、真（ｂｏｙｓ）が提供される。
１２．実行が、同じパターンで再開し、今度、獲得されるリンクは、次のとおりである。
ｈｔｔｐ：／／ｓｉｔｅ．ｉｌ．ｐｅｒｆｅｃｔｏｔｅｃｈ．ｃｏｍ／ｂｏｙｓ／＜ＰＨｎａｍｅ＞．ｈｔｍｌ
１３．このプロセスは、すべてのバックトラック・ログが尽きるまで反復して（例えば、性別フィールドに対する「ｇｉｒｌｓ」の値を提供して、もう一度）続く。したがって、可能なさらなる実行パスは、存在しない。
【００３９】
ＪａｖａＳｃｒｉｐｔコードを検査する際、要求ｈｔｔｐ：／／ｓｉｔｅ．ｉｎｔｌ．ｐｅｆｅｃｔｏｔｅｃｈ．ｃｏｍ／．．．を生成する可能性がある理論上の実行パスが見られたが、ＤＯＭは、０または１以外の国に対するｓｅｌｅｃｔｅｄＩｎｄｅｘを提供しなかったので、このパスは辿られなかった。これは、どのようにＪａｖａＳｃｒｉｐｔコードとＤＯＭの両方が、許可された要求に影響を与えるかの例である。国に関して可能な値は２つしか存在しなかったので、第３の実行パスは、正規のパスではない。
【００４０】
本発明の第２の態様では、認可プロキシ（例えば、プロキシ１８、「プラグイン」論理２６、およびスニファ４０）が、クライアントとサーバとの間の伝送を評価するためのメソッドを呼び出す。第１に、クライアント側論理が、コードに挿入されることによってインストルメント化され、クライアント・システム１２上でクライアント側論理の実行を追跡する。クライアント・システム１２上でユーザによって実行されると、サーバ・リソースの要求が、実際の実行の結果（追跡結果）とともに認可プロキシにおいて受信される。認可プロキシは、クライアント側論理の実行をシミュレートして、入力オプションまたは外部データの他の要求がシミュレーション中に現れたとき、追跡結果が利用される。成功したシミュレーションは、サーバ・リソースのクライアント要求の承認をもたらし、認可プロキシが、実際の処理のためにその要求を適切なサーバに渡す。例えば、受入れ可能な処理を有する伝送が、意図された目標に伝えられ、これにより、意図されたアプリケーションと整合性のある要求だけが実行される。
【００４１】
図４は、データ処理システムのクライアントとサーバとの間の伝送を確認するためのプロセス（例えば、前述した追跡するプロセスおよびシミュレートするプロセス）を示す流れ図である。例えば、図４が、ＷＥＢサーバ２００からクライアント２５０への伝送（例えば、ＨＴＭＬウェブ・ページ２０２）を描いている。本発明によれば、認可プロキシ（例えば、それぞれ、図１Ａ、１Ｂ、１Ｃのプロキシ１８、２６、４０）が、伝送２０２を代行受信する。シミュレーション・プロセスに入る前に、認可プロキシは、クライアント・ブラウザ２５０上で生じる値およびイベントの追跡を可能にするコマンドを受信するための伝送を準備する。ブロック２０４で、伝送（例えば、ＨＴＭＬページ２０２）が構文解析されて、内容およびＨＴＭＬタグならびにクライアント側論理（例えば、ＪａｖａＳｃｒｉｐｔコード）を識別する。クライアント側論理は、ブロック２０６に進み、ブラウザ処理（例えば、入力値の要求、および実際の入力値、イベント等）を追跡するためのコードが追加される。次に、変更されたコード、つまりインストルメント化されたコードが、要求された伝送の中（例えば、ＨＴＭＬページ中２０２）でクライアント・ブラウザ２５０に渡される。
【００４２】
前述したとおり、インストルメント化されたコードは、ブラウザ処理を追跡して、追跡の結果を認可プロキシに戻す（さらなる処理の要求の中で、またはその要求に加えて）。クライアント・ブラウザ２５０が、サーバ・リソースを要求したとき、ブラウザ処理のトレース（例えば、クライアント・ブラウザ２５０上で行われた入力およびイベント）が、評価のために認可プロキシに戻される。この実施形態では、すべての入力を列挙する代りに（図２に概要を述べたシミュレーション・プロセスに関連して説明したとおり）、ブラウザが、その要求とともに、ブラウザ環境内で実際のユーザ・セッション中にスクリプトが獲得したすべての値のトレースを送信する。このトレースは、トレース・フィーダにおいて認可プロキシの中で保持される（ブロック２１２）。
【００４３】
追跡の結果が受信されると、認可プロキシが、ブロック２１０で、オリジナルの伝送（例えば、ＨＴＭＬページ２０２）の中のコードおよびＤＯＭ構成要素をシミュレートする。図４に示すとおり、シミュレーション・ステップに対する入力は、オリジナルのクライアント側コード（例えば、追跡サポート・コードを有さないクライアント側論理）、ＤＯＭ構成要素（ブロック２０８からの）、およびトレース・フィーダ（ブロック２１２）からの追跡結果を含む。追跡されたオブジェクトが、シミュレートされた環境内で照会されたとき（ブロック２１０で）、認可プロキシは、（トレース・フィーダを介して）クライアントから受信された追跡された値に関して検査する。また、追跡された値は、オブジェクトの論理上の内容規則に照らしても検査され、例えば、テキスト・フィールド内に許容可能な文字の最大数、または可能な２つの値（真／偽）のどちらかだけでしかないチェックボックス値、他のどの値も不正である。シミュレーションの結果は、ブロック２１４に渡される受入れ可能な、つまり認可されたブラウザアクションのリストである。ただし、この実施形態では、認可されたブラウザアクションは、第１の確認プロセスに関連して前述したとおり、クライアント・ブラウザにおける特定の実行から決定された値（トレースの中からの入力およびイベント）に基づき、可能なすべてのブラウザ要求に基づくのではない。クライアントアクション（ブロック２５０から渡された）をブロック２１４で認可されたアクション（ブロック２１０から渡された）と比較して、特定のクライアント・ブラウザ実行（ブロック２５０）の要求の１つまたは複数のアクションが認可されるかどうかの判定を行うことができる。
【００４４】
理解されるとおり、ブラウザは、デフォルトで追跡を行うこと、および／または追跡の結果を送信することはしない。したがって、ブラウザに送信されるコード（例えば、ＨＴＭＬドキュメント２０２）が、シミュレーションに先立って、ブロック２０６で行われる前述したステップで変更されて（インストルメント化されて）、このコードが、ブラウザ環境内（ブロック２５０）のブラウザアクションのトレースを作成して戻す。コードに関する例としてのインストルメント化プロセスは、以下を含む。
・ＪａｖａＳｃｒｉｐｔコードが、ＪａｖａＳｃｒｉｐｔアセンブリにコンパイルされる。
・アセンブリが、検査され、すべてのｇｅｔ＿ｐｒｏｐｅｒｔｙ、ｓｅｔ＿ｐｒｏｐｅｒｔｙ、および関数コールにマークが付けられる
・ｇｅｔ＿ｐｒｏｐｅｒｔｙ命令が、関係のあるプロパティ名に照らして検査される。
・関数コールが、追跡された関数値（例えば、ランダム）およびアクション関数（例えば、新しいＵＲＬで新しいウインドウを開くｗｉｎｄｏｗ．ｏｐｅｎ（））に照らして検査される。
・関係のある命令のそれぞれが、オブジェクトが追跡に関係があるか否かを検査する前に関数コールが挿入される。
・ｇｅｔ＿ｐｒｏｐｅｔｙとして、追跡されるオブジェクトの値が、実行トレースに追加される。
・新しいＵＲＬをロードさせるオブジェクトのｓｅｔ＿ｐｒｏｐｅｒｔｙとして、トレースがＵＲＬに付加される。
・新しいＵＲＬをロードする関数コールとして、トレースがＵＲＬに付加される。
・アセンブラが逆コンパイルされて（組み込まれた逆コンパイラを使用して）ＪａｖａＳｃｒｉｐｔに戻る。
・変更されたＪａｖａＳｃｒｉｐｔコードが、オリジナルのＪａｖａＳｃｒｉｐｔコードの代りに送信される。
【００４５】
以下は、ブラウザに送信されるコードおよび変更されたコードの例である。
【００４６】
オリジナルのコードは、以下のとおりである。

ＨＴＭＬドキュメントは、以下の書式を有する。

変更されたコードは、以下のとおりである。

ＨＴＭＬ形式に対する変更は、以下のとおりである。

【００４７】
変更されたコードは、ｄｏｃｕｍｅｎｔ．ｆｏｒｍ［０］のｇｅｔ＿ｐｒｏｐｅｒｔｙ上のａｓ＿．ｐｒｏｐを呼び出して、それが書式であることを検査し、次にｅｌｅｍｅｎｔｓ．ｄａｙ．ｖａｌｕｅに関して検査する。ａｓ＿．ｐｒｏｐ関数は、値が追跡されるべきかどうか（テキスト・フィールドの値の場合と同様に）を検査し、その値を追跡変数に追加する。ｓｅｔ＿ｐｒｏｐｅｒｔｙが、変更されてトレースが要求されたＵＲＬに追加される。ａｓ＿．ｉｎｉｔが、スクリプトのヘッドとイベント・ハンドラの両方において追加される。イベント・ハンドラがトリガされたとき、イベントがトレースに追加される。トレースは、認可プロキシに送信されると、前述したとおり処理される。
【００４８】
以下は、ユーザが月曜のチケットを購入するのを選択するプロセスの説明である。コードは、上記にリストしたとおりインストルメント化されている。ただし、ユーザは、コードがインストルメント化されていない場合に見るものと同一の非常に簡単な書式を自らのブラウザ内で見る。
・チケット購入の曜日を選択しなければならないことを明記するテキスト
・「ｓｕｎｄａｙ」というデフォルト値を有する簡単なテキスト・ボックス
・要求を送信するボタン
【００４９】
ユーザが、「ｔｕｅｓｄａｙ」を入力して、送信ボタンを選択することによって要求を送信するものと想定する。実際に行われるのは、以下のとおりである。ブラウザ内で、
・送信ボタンを選択することにより、ｍｙ＿ｓｅｎｄ関数を呼び出すイベント・ハンドラが起動される。ただし、イベント・ハンドラを起動することは、追跡されるアクションであり、したがって、インストルメント化されたコード中のａｓ＿ｉｎｉｔによって実行トレースに追加される。
・ＪａｖａＳｃｒｉｐｔ関数であるｍｙ＿ｓｅｎｄが呼び出される。この関数は、曜日が、平日の１つの曜日にマッチすることを確認し、ページをマッチするページ、ｎｅｗ＿ｐａｇｅ？ｄａｙで置き換えるものとされる。
・ｍｙ＿ｓｅｎｄ値で、ｄｏｃｕｍｅｎｔ．ｆｏｒｍｓ［０］．ｅｌｅｍｅｎｔ．ｄａｙ．ｖａｌｕｅがアクセスされて、ａｓ＿ｐｒｏｐによって追跡される値として識別される。したがって、値「ｄｏｃｕｍｅｎｔ．ｆｏｒｍｓ［０］．ｅｌｅｍｅｎｔ．ｄａｙ．ｖａｌｕｅ＝ｔｕｅｓｄａｙ」が、トレースに追加される。
・コードであるｗｉｎｄｏｗ．ｌｏｃａｔｉｏｎ．ｈｒｅｆ＝「ｎｅｗ＿ｐａｇｅ？」＋ｄａｙが、インストルメント化されたコード中で実行されたとき、ａｓ＿ｓｅｔｐｒｏｐが、その変数を追跡されるイベント変数として識別する。通常、新しく設定されたＵＲＬに対して単一の要求が生成されていることになる。インストルメント化されたコードの中で、生成されたトレースを含む追加の要求がサーバに送信される。
【００５０】
この時点で、サーバ内に、要求とトレースの両方がある。
・オリジナルのコードがシミュレートされた環境内で実行される。
・トレース・フィーダが、送信ボタンに関するイベント・ハンドラの起動を識別し、イベント・ハンドラがトリガされる。
・イベント・ハンドラが、ｍｙ＿ｓｅｎｄを呼び出す
・ｍｙ＿ｓｅｎｄが、追跡されるオブジェクトである変数「ｄｏｃｕｍｅｎｔ．ｆｏｒｍｓ［０］．ｅｌｅｍｅｎｔｓ．ｄａｙ．ｖａｌｕｅ」にアクセスしようと試みる。
・これにより、トレース・フィーダが、実行トレースから値「ｔｕｅｓｄａｙ」を検索する。
・トレース・フィーダが、サイズ２０のテキスト・ボックス内の正規の入力にマッチすることを確認する。
・値が、ＪａｖａＳｃｒｉｐｔコードに提供される。
・ＪａｖａＳｃｒｉｐｔコードが、「ｔｕｅｓｄａｙ」は、実際に平日であることを確認し、ｗｉｎｄｏｗ．ｌｏｃａｔｉｏｎ．ｈｒｅｆ＝「ｎｅｗ＿ｐａｇｅ？ｔｕｅｓｄａｙ」に設定する。
・この属性を設定することにより、正しくマッチする実際の要求に対して「ｎｅｗ＿ｐａｇｅ？ｔｕｅｓｄａｙ」のシミュレートされた要求をマッチさせるイベントが生じる。
【００５１】
クライアント・システムのユーザ（例えば、ハッカー・オペレーティング・クライアント１２）が、サイズ２０のテキスト・フィールドに対する正規の入力を構成しない値（例えば、２１文字の入力）を提供しようと試みた場合、トレース・フィーダは、その値に不正な入力としてマークを付け、その実行を停止することにより、その値をブロックすることになる。ユーザが、不正な要求を提供しようと試みた場合には、シミュレートされた環境処理を実際の要求とマッチさせることに失敗する。
【００５２】
本発明を好ましい実施形態で説明し図示してきたが、当分野の技術者には明らかなとおり、本発明の趣旨および範囲を逸脱することなく、多くの変形および変更を加えることができ、したがって、そのような変形形態および変更形態も本発明の範囲に含まれるものとするので、本発明は、以上に記載した方法または構成の正確な詳細に限定されるべきものではない。
【図面の簡単な説明】
【図１Ａ】本発明の一実施形態により構成されかつ動作する、クライアント／サーバ・データ処理ネットワークのブロック図である。
【図１Ｂ】本発明の他の実施形態により構成されかつ動作する、クライアント／サーバ・データ処理ネットワークのブロック図である。
【図１Ｃ】本発明のさらに他の実施形態により構成されかつ動作する、クライアント／サーバ・データ処理ネットワークのブロック図である。
【図２】本発明の一実施形態によるシミュレーション方法を使用して、クライアントとサーバの間で要求を確認する例示的なプロセスを示すフロー・チャートである。
【図３】図２のシミュレーション方法へのユーザの入力を受け取る例示的なプロセスを示すフロー・チャートである。
【図４】本発明の第２実施形態による追跡方法を使用して、クライアントとサーバとの間で要求を確認する例示的なプロセスを示すフロー・チャートである。[0001]
(Copyright notice)
The portion of this application document contains content that is subject to copyright protection. The copyright owner has no objection to the facsimile reproduction of the application document or the disclosure of the application, as in the patent file or record of the patent or trademark office. All rights reserved.
[0002]
(Related application)
This application is related to the following co-pending applications:
• US Provisional Patent Application No. 60 / 161,473, filed October 25, 1999, entitled “METHOD AND SYSTEM FOR VERIFYING A CLIENT REQUEST”, patent attorney number 3269/8.
・ US Patent Application No. 09 / 345,920, filed on July 1, 1999, named Patent and Practice for EXTRACTING APPLICATION PROTOCOL CHARACTISTISTS, Patent Attorney No. 3269/6
-US Patent Application No. 09 / 149,911, filed on September 9, 1998, patent attorney docket number 3269/3, named METHOD AND SYSTEM FOR PROTECTING OPERATIONS OF TRUSTED INTERNAL NETWORKS
-Patent Application No. 9 / Patent Application No. 0, US Patent Application No. 9 / METHOD AND SYSTEM FOR MAINTAINING RESTRICTED OPERATION ENVIRONMENTS FOR APPLICATION PROGRAM OR OPERATING SYSTEM 150 Application No. 3269/4 filed on September 9, 1998 issue
・ PCT application PCT / IL98 / 3269/4
PCT application PCT / IL98 / 00443
・ PCT application PCT / IL00 / 00378
The disclosures of these applications are fully incorporated herein by reference.
[0003]
(Background of the Invention)
The present invention relates generally to privacy and security systems, and more particularly to requests, data, information content, applications, and other information transmitted between a client device and a host device within a data processing system. It relates to a method and system for authorizing.
[0004]
(Conventional technology)
In a client / server data processing system, several personal computers, work stations, portable and / or handheld devices (“clients”) and one or more host computers (“servers”) Connected and communicating. The server processes requests from clients for information and / or application programs shared by the clients over the network. Increasingly, a client / server network, for example, can itself be part of the World Wide Network, ie, part of the Internet's World Wide Web ("Web"). It has become concatenated to form a broader “network of networks” such as intranets and extranets. Linking networks allows clients to supply resources (eg, information and application programs) across the network.
[0005]
As the availability of shared information and application programs increases, potentially on the world wide network, the vulnerability of each individual client / server network increases. For example, an unscrupulous individual attempting to retrieve and / or damage information and application programs that can claim ownership that is stored in one of the networks has access to information and application programs that can claim ownership. May use it in an unauthorized manner. In an effort to prevent such unauthorized use, many networks are connected to other networks through “firewalls”. Traditional firewalls can handle access control to internal network resources (eg, specific web servers or folders), restrict access to parts of the network, and claim ownership stored in them Includes hardware and / or software systems designed to prevent unauthorized retrieval or damage to information and application programs.
[0006]
However, many conventional firewall systems do not deal with authorization at the application level and may fail by an unscrupulous individual who pretends to be an authorized client. For example, many web applications assume that the user of the application is actually running the application's mobile agent on his / her browser. However, a malicious user can connect to a web server without using standard web browser software, so the user is not bound by any restrictions that can be enforced on the browser side. A malicious user can send destructive or forged data to a web server, pretending to be a standard client.
[0007]
Commonly assigned U.S. patent application Ser. No. 09 / 345,920 describes a solution for confirming a user's request for a standard HTML document. The solution is based on extracting a set or pattern of actions (HTTP requests) that the browser software can take based on the content of the HTML document (“authorized actions”). This authorized set of actions is then matched to the request sent by the client application. Even if the user is not using one of the standard browsers, only requests from within the legal or authorized set of actions will be passed to the web server.
[0008]
In view of the above contents, the inventor of the present invention has a logic (for example, a JavaScript (TM) program embedded in an HTML page) for executing the above-described confirmation technique on a client system instead of a web server. Recognized the need to extend to. In particular, the inventor has recognized the need to simulate the execution of client-side logic in order to obtain and confirm external data and the events occurring thereon.
[0009]
(Summary of the invention)
It is an object of the present invention to provide a verification technique for logic executing on a client system instead of a server system.
[0010]
Another object of the present invention is to provide a verification technique for client side logic (eg, a JavaScript program embedded in an HTML page). This technique simulates the execution of logic to obtain and confirm external data and what is happening there.
[0011]
Yet another object of the present invention is a verification technique for client-side logic that simulates the execution of logic so that only authorized requests for external data and events are passed from the client to the protected server. Is to provide.
[0012]
Other objects and advantages of the present invention will become more apparent from consideration of the drawings and the following description.
[0013]
These and other problems have been overcome, and the objective is to present a system and method for authorizing execution of requested actions sent between a client and a server of a data processing system. Implemented by a method and apparatus according to embodiments of the invention. The method includes receiving a message that includes a set of actions or a program (eg, a JavaScript program embedded in an HTML page) and simulating the execution of the set of actions. The list is defined to represent performed actions and user definable inputs to the performed actions. The performed action and the list of user-definable inputs to the performed action are then compared to the list of acceptable actions and the input. When an element in the execution list is included in the list of acceptable actions and inputs, the included set of messages and actions is authorized.
[0014]
The present invention is illustrated in the figures of the accompanying drawings, which are intended to be illustrative and not limiting. In the figures, the same reference signs are intended to refer to the same or corresponding parts.
[0015]
Detailed Description of Preferred Embodiments
FIG. 1A illustrates a client / server data processing network 10 constructed and operative in accordance with one embodiment of the present invention. Data processing network 10 includes a plurality of client systems, such as personal computers, work stations, portable and / or handheld devices, coupled and in communication with one or more host / server computers. Including. For clarity of illustration, the clients are represented by client system 12 and the server or servers are represented by server 14. Client 12 and server 14 are coupled to communication network 16 via a wired or wireless connection, such as the World Wide Web portion of the Internet ("Web"), an intranet, an extranet, or other personal network, for example. It should be understood that it can be a remote device and / or a local device.
[0016]
In accordance with the present invention, the authorization proxy system 18 is coupled between the client 12 and the server 14 and enforces a security policy protocol between the client 12 and the server 14. For example, the authorization proxy system 18 can only request authorized actions (defined below) such as requests, messages, data, information content, applications, and other information sent between the client 12 and the server 14. Guarantees that it is implemented internally. The authorization proxy system 18 can send requests, messages, data, information content, and commands, fields, user-selectable input options, HTTP requests, etc. that are sent between the client 12 and the server 14 (e.g., The execution of the “requested action”) is simulated to ensure that the requested action is defined within a set of acceptable actions (eg, “authorized actions”). Any action that does not exist in the set of acceptable actions is rejected by the authorization proxy 18 before reaching the target of the action (eg, server 14 or client 12) and possibly destroying it.
[0017]
It should be understood that changing the authorization proxy implementation strategy is within the scope of the present invention. For example, FIG. 1A shows the authorization proxy as a hardware component 18 of a separate network 10 that is separate from the server 14. In FIG. 1B, the authorization proxy is implemented as application programming logic (“plug-in” logic 26) executing on the server 20. The server 20 also receives application programs, information content and data residing on the server 20 on request, for example, contained in the data store 28 or on the web page 30. 12 includes plug-in

logic

22 and 24. In accordance with the present invention, authorization plug-in logic 26 is executed on server 20 to verify the program, content, and data provided to client 12 prior to transmission.
[0018]
Alternatively, FIG. 1C shows an authorization proxy operating as an intrusion detection system within a sniffer device 40 coupled to a router or hub 42 on the network 10 ′. As is generally known, the hub 42 directs communication within the network 10 '. As shown in FIG. 1C, the hub 42 isolates the web server 44 from direct communication on the network 10 '. The sniffer 40 detects and blocks transmissions targeted to the web server 40. The sniffer 40 evaluates the blocked transmission and compares the requested action in the transmission to a method detailed below, for example, to compare with the list of authorized actions contained in the storage device 46. Execute. If not acceptable, the sniffer 40 modifies the message or passes the message to other systems on the network.
[0019]
Although embodiments of the present invention have been described as having specific applications as web-based applications, the systems and methods described herein can be used in any client / server communication system, particularly It should be understood that it is within the scope of the present invention to be applicable in communication systems where it is desirable to protect the server from unauthorized requests, data, and applications.
[0020]
As will be described in detail below, the authorization proxy of the present invention uses two techniques to verify the logic executed on the client system instead of the server system. In the first technique, the authorization proxy simulates the execution of client-side logic and invokes and / or triggers each possible command, field, user-selectable input options, and HTTP request. As a result, a complete set of acceptable browser actions is identified and used to confirm subsequent requests from the actual client session. In the second technique, the proxy tracks the execution of client-side logic during the actual client session. The result of the tracking is sent to the authorization proxy in a request for server resources. In response, the authorization proxy simulates the execution of client-side logic, and the tracking results are used when encountering input options or other requests for external data during the simulation. A successful simulation results in the approval of the client request for the server resource, and the authorization proxy passes the request to the appropriate server for actual processing.
[0021]
The two verification techniques differ in how they respond to client logic queries regarding unknown data and user intervention events. These techniques are described in detail below.
[0022]
In a first aspect of the invention, an authorization proxy (eg, proxy 18, “plug-in” logic 26, and sniffer 40) calls a method to evaluate transmissions between a client and a server and originates from the server. Invoke a method of simulating client-side logic embedded in a message (eg, a JavaScript object) and extracting a list of possible requested actions. When the client sends a request, the requested action is checked against a list of authorized actions. If the action is acceptable, the transmission is passed over the intended target, so only requests that are consistent with the intended application are performed.
[0023]
FIG. 2 is a flow diagram illustrating a process (eg, the evaluation process, the simulating process, and the extraction process described above) for confirming transmission between the client and server of the data processing system. For example, FIG. 2 depicts a transmission (eg, HTML web page 102) from a web server to a client (eg, server 14 and client 12 of FIG. 1). At block 100, the server 14 transmits the HTML web page 102 to the client 12. The transmission is represented by

lines

104A and 104B in FIG. As shown in FIGS. 1A-1C and FIG. 2, any transmissions to the client 12 are intercepted by the

authorization proxies

18, 26, 40, respectively. In response, the authorization proxy invokes a confirmation process (details of which are shown in dashed line 106).
[0024]
At block 108, the evaluation process is invoked. The evaluation process includes, for example, parsing the HTML page 102 to identify the content and HTML tags and client-side logic (eg, JavaScript code) embedded therein. Once the components present in the HTML page 102 are identified, the authorization proxy simulates the execution of the components of the page 102 (eg, a simulated browser environment) and all possible requested processing. Can be identified in the transmission and provided to the list of authorized processes.
[0025]
The simulated browser environment includes

blocks

110 and 112, respectively, a JavaScript runtime environment in which the simulated browser's Document Object Model ("DOM") and browser objects are reproduced. Some of the JavaScript standard objects need to be replaced as described in more detail below. An authorization proxy executes the components of the HTML page 102 in a simulated environment. A hook in the environment informs the authorization proxy of any triggered browser processing, for example, retrieving a document from a WEB server, or submitting a form to a WEB server. Once the simulation is complete, these processes supplement the list of authorized processes matched against the client's actual request (in block 120), as described below.
[0026]
As mentioned above, some of the objects and their methods need to be simulated to represent the client browser environment. First comes a DOM created from the HTML document 102. In addition, there is a browser object, such as Navigator, which provides information about the browser context and browser window in Netscape. The enumeration engine (at block 114) coordinates the simulation of the DOM component and the JavaScript component. Objects such as time objects and random functions are also simulated by the enumeration engine. All of these objects must be consistent with what the script acquires when the script accesses them in the client's environment, eg, on the client browser 122. For example, the DOM text area must return the value that the user entered into the browser 122, the random function must return the same value that the client script has acquired in the user's browser 122, and Also, navigator. The userAgent must return the name of the client browser 122.
[0027]
As will be appreciated, some of the data entered into the browser object is inferred from the envelope data, e.g., navigator. The userAgent can be obtained from the HTTP header sent from the client 12 (eg, in the original request for the HTML page 102). However, some data depends on the actual scenario followed on the client side. Additional complexity is introduced into event handlers that exist in JavaScript (eg, code that is executed in response to user actions). JavaScript HTML script tags are executed when loaded, but some code (eg, event handlers) is executed only upon user intervention. For example, there is an onClick event handler for many of the HTML language input controls. The corresponding event handler is executed only when the user selects a control (eg, “clicks”).
[0028]
The enumeration engine (block 114) performs the coverage method. For example, the engine does all possible processing by the browser 122 by triggering all events in the HTML page 102 and by performing multiple simulated executions on the various possible inputs by the user. Assume that it covers. As will be appreciated, the runtime of this environment increases exponentially for scripts that rely on many input controls. It may also be difficult to handle random functions within this environment. The simulated execution proceeds until the execution requires user input. At the time of the request, user actions are required to record and simulate further execution with various possible input values. This aspect of the simulation method is described in more detail below with reference to FIG.
[0029]
When the simulation is complete, a list of all possible browser processes that are consistent with the HTML page (and associated client-side logic) originating from the server is provided. These possible processes are aggregated at block 118 and identified as “regular processes”. Legitimate processing is utilized by the authorization proxy to confirm processing of requests received from a particular execution of the HTML page 102 in the client browser 122. At block 120, the processing of the client request is returned to the authorization proxy and compared to the list of regular processes 118 generated by the authorization proxy from the simulation of the HTML page 102. Thus, the authorization proxy either accepts or rejects the client's request (eg, the corresponding canonical process depending on whether the request and valid user input are present or not in the canonical process list 118. Request is rejected if it is not identified by the authorization proxy). The list of legitimate processes 118 can be stored to accommodate delays in receiving requests for processing from the client browser 122 (eg, data store 30 (FIG. 1B) or 46 (FIG. 1C). I want you to understand.
[0030]
With reference to FIG. 3, the following describes options for handling user input requests and multiple possible input values in the simulated execution of the HTML page 102. As previously described, at block 150, the authorization proxy simulates the execution of browser commands and client logic contained within the HTML page 102. The simulated execution continues until input control appears (at block 155) or a request for other user input is made (at block 165). At block 155, free text input commands such as, for example, <TEXT>, <PASSWORD>&<TEXTAREA> HTML tags are detected in the HTML page 102. If a free text input command appears, control proceeds to block 160 where a unique place holder representing the input received from the client is assigned. The placeholder assigned in block 160 is a field that is recognized later in the URL generated as an input generated from a free text input command in response to a user action, for example. At a later stage, the authorization proxy performs pattern matching with the received client request (block 120 in FIG. 2). Pattern matching is performed to allow only “safe” expressions. A preferred pattern matching technique comes from the HTML link extractor described in commonly assigned US patent application Ser. No. 09 / 345,920 (Attorney Docket No. 3269/6). A hook for recognizing a branch determination (in the case of a sentence) based on a character string including a place holder is incorporated in the JavaScript environment. In such cases, this means that the input affects the logical progression of the script, so execution is disabled. The system validates the link if the placeholder affects the generated URL, either directly by appearing in the generated URL or indirectly by affecting the execution flow of the program. Can do.
[0031]
Control proceeds from block 160 to block 165, or from block 155 to block 165 if no free text input command appears. At block 165, the authorization proxy detects the occurrence of a command request input by the user from one of several possible input values. If such a command appears, control proceeds to block 170; otherwise, control proceeds to block 180. At block 170, a first available value for the listed input control is assigned. Since other possible legal input values are also available, control proceeds to block 175 where an entry is made in the backtrack log 116 (FIG. 2). This entry records the relative position (eg, depth in execution) of the current execution in the HTML page 102, as well as the remaining number of possible legal entries. Log 116 allows control to loop back to the point (depth) of the previous execution, select the next value of possible normal input values, and continue execution with the next normal input value. Please understand that. By looping back and simulating the execution of all input to the HTML page 102, all possible browser commands and corresponding user input are collected in the list of possible legitimate processes 118 described above. .
[0032]
After logging the provided value, execution continues at block 180. At block 180, the simulator detects the end of code. If the end is detected, control proceeds to block 185 for possible backtrack processing. If the end does not appear, control loops back to block 150 and the simulation continues as described above. At block 185, the backtrack log 116 is evaluated to determine if further possible input values drive detection of further possible legitimate processing. If an entry remains in the backtrack log 116, the depth variable is used to relocate execution to any of the multiple input commands that appear. After being rearranged, the next value of the input command is assigned and the simulation proceeds from the relative location to the end of the code. Such loopback execution continues until each value in the backtrack log 116 is exhausted.
[0033]
The inventor has confirmed that one embodiment of backtracking in a JavaScript environment is to resume execution at the same value up to the backtracking point. Another legitimate input is provided at this point and logged. This process is repeated until all enumerated values have been processed.
[0034]
As described above, by aggregating all browser processing triggered by all possible inputs and events during the simulation process, the authorization proxy is sent from the client that is consistent with the script originating on the WEB server. Obtain a list of most, if not all, possible requests. In some embodiments, this system is used as an adjunct to the tracking embodiment described below to obtain better performance.
[0035]
Hereinafter, an example of the simulation embodiment of the present invention will be described.
An HTML page (eg, HTML page 102) includes three input controls.
• Options list of two countries, USA & Israel (of course a complete list is possible)
・ Gender, male & female radio selection
・ Text input about user's name
[0036]
JavaScript built into HTML constructs a URL according to the following pattern.
http: // site. country. perfectotech. com / gender / name. html
Here, country is “us” or “il” depending on the country, gender is a value of “boys” or “girls”, and name is an input text field.
[0037]
The following is the HTML page code.

[0038]
The simulation process described above handles code as follows:
1. Examining the document gives that the only event that executes JavaScript is to click on the Get My Page button. This event is triggered. This is recorded in the backtrack log 116 and annotated that this is the only event that triggers, thereby exhausting this entry. Use up will be explained in more detail in subsequent steps.
2. The code is executed until branch A is reached.
3. A value representing the country is supplied in the selectedIndex, and there are two possible values, 0 (representing the United States) and 1 (representing Israel). The first value is supplied and it is recorded that a value of 0 was supplied in branch A.
4). Execution proceeds to branch B and the checked value of the Gender radio box is checked. There are two possible values: boys and girls. A true value is provided and recorded in the backtrack log 116.
5. Execution proceeds until access C is reached and the value of the text field is required. A place holder is supplied. This place holder is a UNICODE string that may not appear under normal circumstances. This place holder is marked <PHname>. There is no need to log this in the backtrack log 116. This is because backtracking for this value is not required. The type of <PHname> is recorded as text with a maximum length of 10.
6). The Javascript function open of the object window is hooked in a simulated environment to a function that records the requested URL. The constructed URL is as follows.
http: // site. us. perfectotech. com / boys / <PHname>. html.
7). The policy enforcer is informed of this new possible processing, with the annotation that <PHname> can be matched against any text of maximum length 10.
8). Execution resumes. The same steps are followed with the exception of the deepest backtracking entry (branch B) whose value is replaced by the next possible value, ie false. All possible values for branch B have been used up, so they are marked in the backtrack log 116 as used up.
9. Thus, a value of “girls” is provided in the gender field and the generated link is http: // site. us. perfectotech. com / girls / <PHname>. html.
10. Execution resumes. This time, branch B is the deepest branch and the next allowed value is provided, ie 1 representing Israel.
11. Reaching branch B again, this time there is no backtrack log 116, so a (re) updated entry is logged, providing the first regular processing, ie, boys The
12 Execution resumes with the same pattern, and the links acquired this time are:
http: // site. il. perfectotech. com / boys / <PHname>. html
13. This process continues iteratively until all backtrack logs are exhausted (e.g., once again providing the value of "girls" for the gender field). Thus, there are no possible further execution paths.
[0039]
When inspecting the JavaScript code, request http: // site. intl. pefectotech. com /. . . There was a theoretical execution path that could generate DOM, but this path was not followed because DOM did not provide a selectedIndex for countries other than 0 or 1. This is an example of how both the JavaScript code and the DOM affect the granted request. Since there were only two possible values for the country, the third execution path is not a regular path.
[0040]
In a second aspect of the invention, an authorization proxy (eg, proxy 18, “plug-in” logic 26, and sniffer 40) invokes a method to evaluate transmissions between the client and server. First, client-side logic is instrumented by being inserted into the code to track the execution of client-side logic on the client system 12. When executed by a user on the client system 12, a request for server resources is received at the authorization proxy along with the actual execution result (tracking result). The authorization proxy simulates the execution of client-side logic, and trace results are utilized when input options or other requests for external data appear during the simulation. A successful simulation results in the approval of the client request for the server resource, and the authorization proxy passes the request to the appropriate server for actual processing. For example, transmissions with acceptable processing are communicated to the intended goal, so that only requests that are consistent with the intended application are executed.
[0041]
FIG. 4 is a flow diagram illustrating a process for verifying transmissions between a client and server of a data processing system (eg, the tracking process and the simulating process described above). For example, FIG. 4 depicts a transmission (eg, HTML web page 202) from the WEB server 200 to the client 250. In accordance with the present invention, an authorization proxy (eg,

proxy

18, 26, 40 of FIGS. 1A, 1B, and 1C, respectively) intercepts transmission 202. Prior to entering the simulation process, the authorization proxy prepares a transmission to receive commands that allow tracking of values and events that occur on the client browser 250. At block 204, the transmission (eg, HTML page 202) is parsed to identify the content and HTML tags and client-side logic (eg, JavaScript code). The client-side logic proceeds to block 206 and code is added to track browser processing (eg, input value requests and actual input values, events, etc.). The modified code, or instrumented code, is then passed to the client browser 250 in the requested transmission (eg, 202 in the HTML page).
[0042]
As previously mentioned, instrumented code tracks browser processing and returns the results of the tracking to the authorization proxy (in or in addition to the request for further processing). When the client browser 250 requests server resources, browser processing traces (eg, inputs and events made on the client browser 250) are returned to the authorization proxy for evaluation. In this embodiment, instead of enumerating all inputs (as described in connection with the simulation process outlined in FIG. 2), the browser, along with the request, during the actual user session within the browser environment. Send a trace of all the values the script has acquired. This trace is maintained in the authorization proxy in the trace feeder (block 212).
[0043]
Once the tracking results are received, the authorization proxy simulates the code and DOM components in the original transmission (eg, HTML page 202) at block 210. As shown in FIG. 4, the inputs to the simulation step are the original client side code (eg, client side logic without tracking support code), the DOM component (from block 208), and the trace feeder (block 212). When the tracked object is queried in the simulated environment (at block 210), the authorization proxy checks for the tracked value received from the client (via the trace feeder). The tracked value is also checked against the logical content rules of the object, for example, either the maximum number of characters allowed in a text field, or two possible values (true / false). Only the check box value, any other value is illegal. The result of the simulation is a list of acceptable or authorized browser actions that are passed to block 214. However, in this embodiment, the authorized browser action is the value determined from the specific execution in the client browser (inputs and events from the trace) as described above in connection with the first confirmation process. Not based on all possible browser requests. One or more actions of a request for a particular client browser execution (block 250) by comparing the client action (passed from block 250) with the action authorized in block 214 (passed from block 210) It can be determined whether or not is approved.
[0044]
As will be appreciated, the browser does not track by default and / or send tracking results. Accordingly, code sent to the browser (eg, HTML document 202) is modified (instrumented) in the above-described steps performed at block 206 prior to simulation, and this code is placed in the browser environment ( Create and return a browser action trace of block 250). An example instrumentation process for code includes:
• The JavaScript code is compiled into a JavaScript assembly.
The assembly is inspected and all get_property, set_property, and function calls are marked
The get_property instruction is checked against the relevant property name.
Function calls are checked against the tracked function value (eg random) and action function (eg window.open () which opens a new window with a new URL).
A function call is inserted before each relevant instruction checks whether the object is relevant for tracking.
As get_property, the value of the tracked object is added to the execution trace.
A trace is appended to the URL as set_property of the object that loads the new URL.
A trace is appended to the URL as a function call that loads a new URL.
The assembler is decompiled (using the built-in decompiler) and returns to JavaScript.
-The modified JavaScript code is sent instead of the original JavaScript code.
[0045]
The following are examples of code sent to the browser and modified code.
[0046]
The original code is as follows:

The HTML document has the following format.

The changed code is as follows:

The changes to the HTML format are as follows.

[0047]
The changed code is document. as_. on get_property of form [0]. call prop to check that it is a format, then elements. day. Check for value. as_. The prop function checks whether a value is to be tracked (as is the case with a text field value) and adds that value to the tracking variable. set_property is modified and added to the URL for which tracing was requested. as_. init is added both in the head of the script and in the event handler. When the event handler is triggered, an event is added to the trace. When the trace is sent to the authorization proxy, it is processed as described above.
[0048]
The following is a description of the process by which the user chooses to purchase a Monday ticket. The code is instrumented as listed above. However, the user sees the same very simple form in his browser that he sees when the code is not instrumented.
-Text stating that the day of the week for ticket purchase must be selected
A simple text box with a default value of “sunday”
-Button to send request
[0049]
Assume that the user sends a request by entering “tuesday” and selecting a send button. What is actually done is as follows. In the browser
• Selecting the send button invokes an event handler that calls the my_send function. However, invoking an event handler is a tracked action and is therefore added to the execution trace by as_init in the instrumented code.
-My_send which is a JavaScript function is called. This function confirms that the day of the week matches one day of the week, and the page that matches the page, new_page? It shall be replaced with day.
-With my_send value, document. forms [0]. element. day. The value is accessed and identified as the value tracked by as_prop. Therefore, the value “document.forms [0] .element.day.value = tuesday” is added to the trace.
-Code window. location. When href = “new_page?” + day is executed in the instrumented code, as_setprop identifies the variable as a tracked event variable. Usually, a single request is generated for the newly set URL. Within the instrumented code, an additional request containing the generated trace is sent to the server.
[0050]
At this point, there are both requests and traces in the server.
• The original code is executed in a simulated environment.
The trace feeder identifies the event handler activation for the send button and the event handler is triggered.
Event handler calls my_send
My_send attempts to access the variable “document.forms [0] .elements.day.value” which is the object being tracked.
This causes the trace feeder to retrieve the value “tuesday” from the execution trace.
Verify that the trace feeder matches the regular input in a size 20 text box.
A value is provided to the JavaScript code.
-The JavaScript code confirms that "tuesday" is actually a weekday, window. location. Set href = “new_page? tuesday”.
Setting this attribute causes an event to match the "new_page? Tuesday" simulated request to the actual request that matches correctly.
[0051]
If a client system user (eg, hacker operating client 12) attempts to provide a value (eg, 21 character input) that does not constitute legitimate input for a size 20 text field, the trace feeder Will block the value by marking the value as illegal input and stopping its execution. If the user attempts to provide an illegal request, it will fail to match the simulated environment process with the actual request.
[0052]
Although the present invention has been described and illustrated in preferred embodiments, it will be apparent to those skilled in the art that many variations and modifications can be made without departing from the spirit and scope of the invention. Since such variations and modifications are intended to be included within the scope of the present invention, the present invention should not be limited to the precise details of the method or construction described above.
[Brief description of the drawings]
FIG. 1A is a block diagram of a client / server data processing network constructed and operative in accordance with one embodiment of the present invention.
FIG. 1B is a block diagram of a client / server data processing network constructed and operative in accordance with another embodiment of the present invention.
FIG. 1C is a block diagram of a client / server data processing network constructed and operative in accordance with yet another embodiment of the invention.
FIG. 2 is a flow chart illustrating an exemplary process for confirming a request between a client and a server using a simulation method according to one embodiment of the present invention.
FIG. 3 is a flow chart illustrating an exemplary process for receiving user input to the simulation method of FIG.
FIG. 4 is a flow chart illustrating an exemplary process for confirming a request between a client and a server using a tracking method according to a second embodiment of the present invention.

Claims

A method of authorizing execution of a requested action sent between a client and a server of a data processing system by an authorization proxy coupled to the client and the server, comprising:
The authorization proxy receiving a first message comprising a set of actions from the server;
Simulating a processing environment in which the authorization proxy executes the set of actions, executing the set of actions in the processing environment, and constructing a list of actions resulting from the execution and inputs to the actions; ,
The authorization proxy receiving, as a second message , an action on the server resulting from the actual execution of the first message at the client and an input by the user of the client for the action from the client;
The authorization proxy comparing the action and the input in the list with the action for the server received from the client and the input;
A step wherein the lists, on condition that includes an input and the corresponding action and the action received and the input from the client, the authorization proxy, to authorize action against the server,
Including methods.

During the execution of the set of actions, the authorization proxy detects an input control requesting a data value entry , assigns a string to represent the data value, and records the condition that the string must satisfy And steps to
The authorization proxy comprising: determining whether the input corresponding to the string received from the client during the comparing step satisfies the recorded condition. Method.

While the authorization proxy is executing the set of actions,
Detecting an input control requesting to select one of a plurality of predefined data values;
Performing an ongoing action on each of a plurality of predefined data values, and listing each of the data values and each action resulting from the execution of the action on each of the data values in the list The method of claim 1 comprising.

The authorization proxy receives from the client input to the client made in actual execution of the first message at the client before performing the set of actions;
The authorization proxy providing the input received prior to execution of the set of actions in response to a user selectable input during execution of the set of actions. the method of.

An authorization proxy system coupled between a client and a server of a data processing system,
Evaluate the transmission between the client and the server, and an evaluation unit for identifying a set of information content and actions contained in the documents in the transmission,
A simulator for simulating a processing environment for executing the set of actions, wherein the simulator executes the set of actions in the processing environment and constructs a list of actions generated by the execution and inputs to the actions When,
Receives a transmission from the client that includes an action on the server that results from the actual execution of the document on the client and an input by a user of the client for the action, each corresponding to the received action and the input action that the input is, the condition that is included in said list, and a authorization unit passing said transmission to the front SL server, the authorization proxy system.

The simulator detects an input control requesting entry of a data value, assigns a character string to represent the data value, and records a condition to be satisfied by the character string, and the authorization unit receives from the client the input corresponding to the character string of received said transmitted, it determines whether recorded satisfying the condition, according to claim 5, the authorization proxy system.

The simulator detects an input control requesting to select one of a plurality of predefined data values, the execution of the actions being performed for each of the plurality of predefined data values repeating said a respective data value, to list each action arising from the execution of the actions in the list for the each to claim 5, the authorization proxy system.

The simulator receives input from the client to the client made when the document is actually executed at the client, and the input is selected by a user during execution of the set of actions. that provide in response to the possible inputs, according to claim 5, the authorization proxy system.