JP2007535017A - アプリケーション層セキュリティ方式およびアプリケーション層セキュリティシステム - Google Patents

Abstract

本発明は、信頼できない環境から受信した不正なまたは有害な動作要求により引き起こされる、意図する正規の範囲外で信頼できるコンピュータアプリケーションが実行されることを防ぐアプリケーション層セキュリティ方式およびアプリケーション層セキュリティシステムを提供する。本発明の１つの実施の形態では、防御層が、信頼できるアプリケーションと信頼できないアプリケーションの動作要求との間に実装される。動作中、防御層は、各動作要求のアプリケーションのパスを同定する。同定されたアプリケーションのパスにより、１以上のセキュリティパイプが、動作要求のアプリケーションの内容を精査して、その動作要求がアプリケーションまたは周りの環境に対して不正または有害であるか否かを判断する。

Description

本発明は、情報セキュリティ、特に信頼できるコンピュータアプリケーションが、未知のまたは信頼できない発信源からの不正なまたは有害な動作要求を実行することを防ぐアプリケーション層セキュリティ方式およびアプリケーション層セキュリティシステムに関する。

インターネットの気楽さ、アクセスのしやすさ、および便利さにより、人々がコンピュータを使用し、情報にアクセスする方法が急速に変わった。しばしばウェブとも呼ばれるワールドワイドウェブ（“ＷＷＷ”）は、インターネット上の情報を取り出す最も一般的な手段の１つである。ウェブにより、世界中に位置するサーバから、ハイパーテキストトランスファープロトコル（ＨＴＴＰ）により、取り出される相互リンクされたハイパーテキストドキュメントなどの、ほとんど無限の数のリソースにアクセスできる。ウェブは基本的なクライアントサーバ構成で動作し、サーバは、ある方法でリソースを実行する専用コンピュータアプリケーションまたは個々のコンピュータアプリケーションであり、例えば、それらのアプリケーションは、ウェブドキュメントまたはバイナリオブジェクトを、ネットワーク上のクライアントコンピュータに格納および送信する。例えば、ユーザは、取り出された情報を見るために、または、サーバ上のアプリケーションに要求を出して所望の方法で動作させるために、ウェブブラウザを通してサーバとやりとりできる。

ウェブページと呼ばれるウェブ上のドキュメントは、典型的に、ハイパーテキストマークアップ言語（“ＨＴＭＬ”）またはそれに似た言語で記述され、ユニフォームリソースロケータ（“ＵＲＬ”）により同定され、ＵＲＬは、ファイルまたはリソースにアクセスできる特定のマシンまたはパス名を指定する。しばしばタグと呼ばれ、ＨＴＭＬドキュメントの中に組み込まれるコードは、ユーザがキーを押すことにより、またはマウスでクリックすることにより他のファイルやページにアクセスできるように、ＵＲＬを持つドキュメントの中の特定の語および画像を関連付ける。これらのファイルは、一般的に、例えば、ＪａｖａまたはＡｃｔｉｖｅＸで記述されたアプレットまたは他の組み込みソフトウェアプログラムだけでなくテキスト、画像、映像、音を含み、それらは、ユーザがハイパーリンクをクリックすることにより動作指示を出した時に実行される。例えば、ユーザにより与えられた要求に関する情報を、フォームを使用してサーバに転送し、ファイルトランスファープロトコル（“ＦＴＰ”）によりファイルをダウンロードし、ユーザのチャットルームへの参加を容易にし、セキュアトランザクションを実施し、ウェブページ上のリンクを使用して電子メールで他のユーザにメッセージを送信するコンポーネントと、ウェブページを閲覧しているユーザがやりとりできる。

典型的に、正規のユーザが望むか、ウェブサイトを見事にできそうであるか、人気を集めるコンポーネントは、悪意があり、信頼できず、犯罪意識を持った個人からの攻撃に対して脆弱なサーバおよびその周りのネットワーク環境となりうる。これは「ウェブハッキング」と呼ばれ、サーバアプリケーション自体を経由して、ウェブ設計の誤りまたは脆弱性を利用することによって生じる。ウェブハッキングは、攻撃が一般的にアプリケーション層のプロトコルにより行われるので、従来のシステムまたはアプリケーションのハッキングとは異なる。一般的に、クライアントがウェブページ経由でサーバアプリケーションと直接やりとりしやすくなればなる程、誰かがそれらアプリケーションをハッキングしやすくなる。典型的な攻撃は、グラフィックの削除、それらのグラフィックの不正な加工または時にはどぎついグラフィックとの置き換えによるページの外観の損傷、パスワードファイルの変更または盗難、データファイルの削除、著作権の侵害、クレジットカード番号、デビットカード番号、または他の顧客情報の改ざん、民間企業情報の公開、秘密または権限のない情報へのアクセス、および内部データベースの検索を含むけれども、これらに限定されない。したがって、ウェブハッキングは、ユーザ、顧客、事業、およびサーバのオペレータに対して、不便であって、おそらく元に戻せない損害を引き起こす。一般的に、従来のコンピュータセキュリティ方式はウェブハッキングの懸案事項を解決するために努力することに失敗するか、完全に無視している。

国際標準化機構（“ＩＳＯ”）は、コンピュータが互いに接続でき、可能な限りエラーのない情報を交換できるように設計された一連のプロトコル標準を開発した。コンピュータの通信全体を標準化するために一般的に取り入れられたそのプロトコルは、ＯＳＩ参照モデルとして知られる７層のハードウェアおよびソフトウェアガイドラインとして指定された。このプロトコルモデルは、価値のある基準を形成し、データ通信に使用される言語の多くを定義する。図１に示されているように、アプリケーション層は、ＯＳＩ参照モデルの基準の最上位層である。

従来のセキュリティモデルは、典型的に、ファイアウォールを使用して、データリンク層または物理層のどちらかの間で実現されるか、セキュアソケットレイヤー（“ＳＳＬ”）または公開鍵基盤（“ＰＫＩ”）を使用して、セッション層またはトランスポート層の間で実現されるかであった。ファイアウォールは、データリンク層において、インターネットなどの他のネットワークからの外部の脅威に対して、信頼できる環境またはネットワークを守るように実現された一種のセキュリティである。ファイアウォールは、ファイアウォールより内側のコンピュータを、外部のコンピュータが直接信頼できるネットワークと通信することから防ぐ。代わりに、全ての通信は、プロキシサーバを経由して信頼できるネットワークの外にルーティングされ、プロキシサーバは、１組のフィルタに基づいて、特定のメッセージタイプまたはファイルタイプを、信頼できるネットワークに通過させても安全か否かを決定する。セキュアソケットレイヤーは、ネットスケープコミュニケーションズ（登録商標）により開発されたオープンスタンダードであり、クレジットカード情報などの重要な情報の傍受を防ぐためのセキュアで暗号化された通信チャンネルを確立する。ＳＳＬを使用する主な目的は、ウェブなどの公衆ネットワーク上で、セキュアで暗合化された電子トランザクションを可能にすることである。公開鍵基盤または信頼階層は、通信セッションの中に含まれる各個人、法人、または団体を検証および認証するデジタル証明書、認証局、および他の登録認証局のシステムである。ＰＫＩは現在進化していて、１つのＰＫＩのみが存在するのでもなく、１つの合意済のＰＫＩの定められた標準が存在するのでもない。

上に記載の従来の技術の１つの欠点は、アプリケーション層プロトコルの検査を実施していないことであり、すなわち、到着する要求のアプリケーションの内容を精査していないことである。したがって、これらの技術は、動作要求のアプリケーションコンテンツを経由して行われるウェブハッキング攻撃を防ぐことが出来ない。

ウェブハッカーはウェブ設計の不具合および脆弱性を悪用してコンピュータシステムを容易に攻撃できる。例えば、初期設定スクリプトにより、ウェブサーバ上にファイルをアップロードでき、ウェブサーバの環境変数の取り扱いを悪用でき、サードパーティ製品の「バックドア」または不具合の存在により、不正なアクセスが可能となる。これらの技術は強力な攻撃となりうり、従来の技術によっては、一般的に防御するのが困難である。毎月新しいソフトウェアの脆弱性が発見されるけれども、多くのシステムオペレータは、これらのホールにパッチを当てないままにし、これらのシステムを防御可能な攻撃に対して開放したままにしている。しっかりと構成されたファイアウォール、ＰＫＩ、およびＳＳＬの実装を利用している主要な会社および政府機関は、既知のアプリケーション層の侵入を使用するハッカーに侵入されてきた。これらの侵入は、アプリケーションに送られて、意図するか許可された実行の範囲を超えてアプリケーションを実行させる不正で有害な要求を典型的に含む。これにより、アプリケーションを悪用してアプリケーション自体、ファイル、バッファ、他のアプリケーション、性能、または情報の機密性に被害を与える。

２つの従来のアプローチによりこれらの問題のいくつかを解決する努力が図られる。１つの技術は、サーバのオペレーティングシステムを追跡し、ファイルの削除またはディスクの初期化などの怪しいイベントを同定する。しかしこのタイプの復古的な技術は、典型的に、損傷の始まった後か完了した後でのみ有効となる。第２の技術は、アプリケーションの外側にネットワークフィルタをインストールし、アプリケーションに影響しうる既知のパターンを備えたフィルタデータベースを更新する。しかし、この技術は、フィルタデータベースに登録されていない未知のパターンを同定できない点で機能に制限がある。言い換えると、この技術の能力は、パターンが取り出されるフィルタデータベースの包括性に直接関係する。能力を増強するために、フィルタデータベースの継続的な更新が必要となる。さらに、これらの技術は、環境変数の操作およびアプリケーションの操作されたプロセスに対して防御できる。

加えて、従来のセキュリティソリューションは、電子商取引（“ｅ−ｃｏｍｍｅｒｃｅ”）用途、移動用途、およびインタラクティブＴＶ（“ｉＴＶ”）用途
の急増により生ずる増加したハッキングの機会を解決するために努力し損なった。これらの用途は、一般的に、異なる技術を使用して異なるプラットフォーム上で全て共に動作する数々のコンポーネントの組み合わせを必要とする。例えば１つのアプリケーションは、複数のコンポーネントを含み、それらは、ウェブサーバアプリケーション、トランザクションサーバアプリケーション、データベース、Ｊａｖａ、ＡｃｔｉｖｅＸおよびフラッシュアプレットであって、全て共に動作する。一般的に、従来のセキュリティソリューションは、複数のコンポーネントシステムの中の各コンポーネント独特のセキュリティのニーズを満たすことが出来ない。

本発明は、関連技術のこれらのおよび他の欠陥を、アプリケーション層セキュリティ方式およびアプリケーション層セキュリティシステムを設けることにより克服し、上記セキュリティ方式およびセキュリティシステムは、信頼できるコンピュータアプリケーションおよび関連するリソースが、アプリケーション自体を経由して、不正なユーザにより直接アクセスされるか実行されることから防ぐ。

本発明の１つの実施の形態では、信頼できない環境から受信した不正で有害な動作要求を実行することからアプリケーションを防御する方法は、到着する動作要求に１以上のパイプを適用するステップを含む。不正で有害な動作要求により、アプリケーション、他のアプリケーション、信頼できるネットワーク、１以上のデータファイル、メモリ、バッファ、性能、機密情報、ハードウェア、ソフトウェア、データベース、情報サーバ等に障害を生じさせうり、それらに対して不正なアクセスが可能となる。例えば、不正で有害な動作要求は、データベース操作、既知のＩＩＳの脆弱性またはアプリケーションの脆弱性に関する攻撃、ＵＲＬ操作、プロセス操作等である。動作要求が不正または有害であると同定されると、それらの要求は完全に拒絶されるか、または、正当で無害な動作要求に変更されるか置き換えられる。

本発明の１つの実施の形態では、セキュリティシステムは、実行の前か後に、アプリケーションサーバからまたはアプリケーションリクエスタ（クライアント）から届いたパケットまたはパケットのストリームの中で受信され、同定されたアプリケーションの動作要求または応答をルーティングする。動作において、到着するパケットまたはパケットのストリームは識別モジュールに転送され、識別モジュールは、動作要求の中のアプリケーションの１以上の命令、パラメータ、またはそれらの一部を同定する。同定された命令またはパラメータは、次に、ルータに転送され、ルータは、例えば、命令の種類、要求されているアプリケーション、クライアントの同定、またはそれらの組合せにより、各コマンドまたは全ての要求を適切なトンネルに導く。本発明の特徴は、異なるパイプが、動作要求の異なる部分に適用できることである。

本発明の１つの実施の形態では、要求または応答の同定されたアプリケーションの属性に基づいた要求または応答に１以上のパイプが使用される。

本発明の１つの実施の形態では、データベース駆動のパイプがデータベースの動作を必要とし、データベース要求の中の悪意を示すパターンを見つけることを目的としている。特に、到着するデータベース要求の内容は、使用されるデータベースの種類および１以上の組み込まれた有害なＳＱＬ命令に基づく許可された構文に関して検査される。

本発明のもう１つの実施の形態では、決定性タイプのパイプは、既知の脆弱性パターンに関して、到着する動作要求を検査する。全ての既知のアプリケーションの脆弱性およびそれらを利用する要求の各々は、保存され、到達する要求と比較される。比較して一致すると、到着した要求はブロックされ、アプリケーションに進むことを許可されない。さらに、このパイプは、アクセスされるか実行されるとアプリケーション環境またはサーバに悪影響を与えるか不正なアクセスを許す実行ファイル、メソッド、およびスクリプトの使用を排除することにより、未知の脆弱性に対してアプリケーションを防御できる。

本発明のもう１つの実施の形態では、アプリケーションの属性を保護するパイプは、アプリケーションにより設定される属性値がどのような変更もされずにクライアントから返されるように保証する。特に、属性識別モジュールは、ある所定の属性を暗号化し、そのある所定の属性はクライアントから返されて、クライアントが属性を操作することを防ぐことができる。

本発明のもう１つの実施の形態では、アプリケーションノードをブロックするパイプにより、リモートユーザの要求が、アプリケーションの所有者により制限されるように指定されるアプリケーションのパスに入ることを制限する。アプリケーションの所有者は、たとえアプリケーション内の脆弱性が知られていても、パッチが入手可能になるまで、事業損失の恐れのためにアプリケーションを継続動作させることもある。このパイプを使用して、アプリケーションの所有者は、他のアプリケーションのパスがクライアントにより使用可能なままで、脆弱性のあるアプリケーションのパスをアクセスできないようにブロックできる。

本発明のもう１つの実施の形態では、パイプは、信頼できない動作要求を、信頼できるネットワークの中の信頼できる環境またはゾーンに転送できないようにブロックする。このパイプを実装することにより、管理者は、リモートユーザの特定のメッセージを許可するように指定されたものだけに制限できる。

本発明のもう１つの実施の形態では、パイプは、あらかじめ定義された式の規則に従って、到着するパラメータ値を認証する。

本発明のもう１つの実施の形態では、クッキーに基づいたパイプが、クライアント側のクッキーをユーザが変更または操作することから防ぐ。このパイプにより、クッキーの中に保存された内部情報を、ユーザが入手できないけれども、アプリケーション自体に任意の変更を加えることなく、アプリケーションには透過的に伝えられることが保証される。

本発明のもう１つの実施の形態では、ＳＯＡＰパイプは、ウェブサービスが有害なクライアント要求を出すことを防ぎ、リモートクライアントまたは特定のクライアントが呼び出すことを許可されていないサービスの要求を防ぐ。特に、このパイプにより、ウェブサービスが、アプリケーションの所有者により指定され、実装されたように動作することが保証され、全てのクライアント要求が、リモートクライアントが要求を出すことを許可されたそれらのサービスのみへのアクセスを許可するだけでなく、ウェブサービスの定義およびデータ構造に一致することが保証される。

本発明のもう１つの実施の形態では、学習技術により、要求の中のパラメータがチューニングされて、クライアントに入力される最も一般的な値、すなわち統計モデルから決定されるリクエスタにより入力される値に、より一致させることが出来る。入力された値のダイナミックレンジは、クライアントが送信した要求の中の各パラメータに関してつくられる。実装される統計モードに基づいて、可能性の範囲、すなわち、最もよく入力されるか期待される値が計算され、動作要求パラメータの値は、アプリケーションからの応答に基づいて調整できる。

本発明の１つの実施の形態では、アプリケーション層のセキュリティ方式は、アプリケーションにより実行される動作要求を受信するステップ、アプリケーションの動作要求の属性を同定するステップ、同定されたアプリケーションの属性に関するアプリケーションのパスを同定するステップ、動作要求を同定されたアプリケーションのパスに導くステップを含む。アプリケーションのパスを同定するステップは、同定されたアプリケーションの属性と、確認されたアプリケーションの属性の所定のリストとを比較するステップを含む。同定されたアプリケーションのパスは、アプリケーションへの信頼できるリンクまたは、デフォルトのアプリケーションのパスであってもよい。１以上のパイプは、動作要求に対して使用され、多くの、そして個々の種類の１以上のパイプが同定されたアプリケーションのパスにしたがって定められる。

本発明のもう１つの実施の形態では、信頼できるアプリケーションを防御するアプリケーションのセキュリティシステムは、信頼できるアプリケーションへまたは信頼できるアプリケーションから導かれたメッセージのアプリケーションの属性を同定し、同定されたアプリケーションの属性に関連するアプリケーションのパスを同定するアプリケーションの属性識別モジュール、メッセージに関連する上記同定されたアプリケーションのパスへメッセージをルーティングするメッセージルータ、および多くのセキュリティパイプを含み、セキュリティパイプの数の一部は、同定されたアプリケーションのパスに関連付けられ、メッセージのアプリケーションのパスへのルーティングに際してメッセージに関して実行される。アプリケーションの属性の識別モジュールおよび上記メッセージルータはアプリケーションレベルのスイッチの中で使用できる。メッセージ識別モジュールがさらに含まれて、上記メッセージと確認されたメッセージのリストとを比較できる。上記メッセージが確認されたメッセージであるとすると、どのセキュリティパイプも使用されず、メッセージはアプリケーションにルーティングされる。

本発明のもう１つの実施の形態では、アプリケーションのセキュリティ方式は、信頼できるアプリケーションへまたは信頼できるアプリケーションから導かれたメッセージのアプリケーションの属性を分類するステップ、および、アプリケーションの属性の分類に基づいて所定の数のセキュリティパイプをメッセージに関して実装するステップを含む。メッセージと確認されたメッセージのリストとの比較が実行でき、一致する結果が出ると、どのセキュリティパイプも使用されない。確認されたメッセージのリストは、必要に応じて更新できる。

本発明の効果は、正当で、無害な要求のみが、信頼されたネットワークおよびその中の全ての信頼できるアプリケーションに渡されることである。もう１つの効果は、１つまたは複数のアプリケーションサーバ上のどのソフトウェアも変更せず、どのソフトウェアをインストールもしないで、それらのサーバ上にインストールされた無限の数のアプリケーションを防御することである。本発明のもう１つの効果は、動作要求の一部が異なるセキュリティ技術により精査できることである。本発明のもう１つの効果は、パイプの任意の組合せが、アプリケーションの正確なセキュリティのニーズにしたがってアプリケーションのパスに使用できることである。

本発明は、アプリケーション層経由の攻撃の問題に対する強固で、拡張性があり、動的で、効果的で、洗練されたソリューションを提供する。

本発明の前述のおよび他の特徴および効果は、以下の発明を実施するための最良の形態、添付の図面、および請求の範囲から、より明らかとなる。

以下、添付の図を参照して発明の実施の形態を説明する。

本発明の好ましい実施の形態およびそれらの効果は、図２から図１７を参照すると理解できる。これらの実施の形態は、インターネット、イントラネット、移動体通信ネットワーク、インタラクティブＴＶネットワーク、ハイブリッドネットワーク、またはＨＴＴＰと、ＨＴＴＰｓと、ＨＴＴＰｄと、シンプルオブジェクトアクセスプロトコル（“ＳＯＡＰ”）と、ウェブダブ（“ＷｅｂＤＡＶ”）と、シンプルメールトランスファープロトコル（ＳＭＴＰ）等であるが、これらに限定されないアプリケーションプロトコルを使用する任意の他のアプリケーション環境に使用できる。それにもかかわらず、発明の概念は、信頼できるアプリケーションまたはネットワークと、信頼できない通信環境との間で情報が交換される任意のタイプの通信システムで実施できる。発明の概念は、アプリケーションサービスプロバイダ（“ＡＳＰ”）ネットワーク環境、ＢｔｏＣネットワーク環境、およびＢｔｏＢネットワーク環境に特に適している。

本発明は、アプリケーション層を経由して直接要求された信頼できるコンピュータアプリケーションまたはリソースの不正使用を防ぐ。アプリケーション層は、アプリケーションの要件に関係していて、クライアントとサーバ間のデータの送信を制御する下位層とは反対に、クライアントから要求されるアプリケーション動作を手助けする。一般的に、全てのアプリケーション動作は、アプリケーション層経由で供給されるパラメータおよび関連する値などの要素を使用する。本発明の実施の形態にかかるアプリケーション層セキュリティ方式およびアプリケーション層セキュリティシステムは、ここではパイプと呼ぶ１以上のセキュリティを接続する技術を実現し、パイプは、単独または組合せのどちらかで動作し、１以上のアプリケーション層セキュリティプロセスを含み、アプリケーション層セキュリティプロセスは、クライアントのメッセージのアプリケーションの内容、すなわち信頼できない動作要求または到着するデータストリームを精査して、信頼できるアプリケーションまたはその周りの環境への不正または有害な命令を同定する。したがって、アプリケーション層に対して、特にウェブ関連の脅威に対して信頼できるアプリケーションを防御する。アプリケーション層セキュリティ方式およびアプリケーション層セキュリティシステムが実装されて、アプリケーション、共有アプリケーション、分散アプリケーション、または複数のアプリケーションを、意図する動作範囲外の実行要求から防御できるようになる。したがって、アプリケーション自体、データファイル、バッファ、他のアプリケーション、サーバの性能、または情報の機密性にそのようなアプリケーションが悪影響を与えないようにする。有害または不正であると同定される動作要求は、完全に拒絶でき、無害で正当な要求に変更できるか置き換えることができる。したがって、無害で正当な要求は、実行するためにアプリケーションに渡される。

本発明の実施の形態では、セキュリティシステムは１以上のアプリケーションを含む信頼できる環境の外側に位置する。セキュリティシステムは、信頼できるアプリケーションと到着する信頼できないアプリケーション動作要求との間のアプリケーション層に防御層を実装し、上記到着する信頼できないアプリケーション動作要求は、未知で信頼できない環境から、またはその環境経由で受信される。防御層は、フォーム、コンテンツ、またはその両方に関して、これらの要求を検査して、正当で無害な要求のみが信頼できる環境にまわされることを保証する。セキュリティシステムは、ハードウェア、ソフトウェア、またはその両方を含んで、防御層を実現できる。

図２Ａは本発明の実施の形態にかかるアプリケーション層セキュリティシステム２００を示す。特に、防御層２１０は、信頼できないネットワークと信頼できるネットワークとの間に実装され、信頼できるネットワークは１以上のウェブサーバ２２０に備わっている１以上のアプリケーション（図示されていない）を含む。防御層２１０は、信頼できない発信元経由で送られる悪意のある動作要求から、信頼できるアプリケーションを防御する。到着する動作要求の各々は、アプリケーションにより実行される複数の要求命令、パラメータ、およびパラメータ値を含む。到着する動作要求は、１以上のポート２３０を経由する外部のＨＴＴＰトラフィックとして受信できる。各アプリケーションは、専用または共有サーバ上に実装でき、複数のサーバに渡って分散していてもよくて、ＨＴＭＬドキュメント、ウェブサーバソフトウェア、コモンゲートウェイインタフェース（“ＣＧＩ”）スクリプト、パールスクリプト、データベース情報、または任意のタイプの情報リソースまたは実行可能プログラムなどであるけれども、それらに限定されないリソースを含んでもよい。アプリケーションのパスは、特定のアプリケーションのタスクまたはコマンドを実行するアプリケーションのリソースの位置を表す。リソースの位置は、ウェブサーバ上に備わっている物理アドレスであってもよいし、仮想アドレスであってもよい。例えば、図２Ｂは、サブディレクトリ“／Ｍｙ＿Ａｐｐ／Ｉｍａｇｅｓ”および“／Ｍｙ＿Ａｐｐ／ＤＯＣＳ”からなる仮想サブディレクトリ“／Ｍｙ＿Ａｐｐ”を示す。これらのサブディレクトリの各々は、各画像またはドキュメントの位置を指定するアプリケーションのパスを表す。

セキュリティシステム２００は、１つの分散または共有アプリケーションを支持するトンネル２４０を含む。トンネル２４０は、信頼できない環境と信頼できる環境との間のＴＣＰ／ＩＰ接続などのプロトコルベースである。各トンネルを通って到着または発信されるデータパケットを含むネットワークのトラフィックは、データパケットのアプリケーションの内容から取り出される適切なアプリケーションのパスに基づいて切り離される。例えばＨＴＴＰでは、アプリケーションのパスは、ウェブサーバ２２０上に定められた仮想ディレクトリであってもよく、ウェブサーバ２２０は特定のトンネルを介してアクセスできる。各トンネル２４５は、例えばＨＴＴＰ、ＨＴＴＰｓ、ＳＯＡＰ、ＷｅｂＤＡＶ、ＦＴＰ、Ｔｅｌｎｅｔ等の指定されたアプリケーションプロトコルを実装および認証できる。代わりに、各トンネル２４０は、単純に、到着するデータパケットストリームおよび発信されるデータパケットストリームを転送できる。

図２Ｃは、信頼できないネットワーク側の検査するアドレスおよびポートと、信頼できるネットワーク側の接続ローカルアドレスとの間の情報を通信する典型的なトンネル２４０を示す。検査するアドレスおよびポートは、到着するアプリケーション動作要求を受信する。接続ローカルアドレスはトンネル２４０を経由して受信した情報を受け取り、バックエンドアプリケーションの接続アドレスおよびポートで検査するバックエンドアプリケーションにその情報を転送する。図２Ｄは、特にトンネル＃３と呼ぶトンネル２４０の典型的なトンネルの実装を示し、トンネル＃３は、サブディレクトリ／ＤＯＣＳに関連付けられる。この例では、あるドキュメント、例えばＨＴＴＰプロトコルの中のアプリケーションの命令ＧＥＴ／ＤＯＣＳを含むアプリケーションの表示要求はトンネル＃３を経由して対応するアプリケーションに送信される。

システム２００は、アプリケーションの機能を防御および監視するために設けられた１以上のパイプ２５０をさらに含む。特に、１以上のパイプ２５０は、トンネル内を通っているトラフィックに関して実行される。例えば、第１のパイプは、既知の脆弱性からアプリケーションを防御し、第２のパイプはデータベース操作を防ぎ、第３のパイプはパラメータのポイゾニングを防ぐ。特定のパイプの実施の形態および実現は、以下に詳細に説明する。当業者ならば、追加のパイプが他の特定のまたは一般的なセキュリティの懸案事項に対応できることが分かるであろう。

図２Ａと、特に図２Ｅとを参照すると、システム２００は１以上のウェブアプリケーション２６０を含み、ウェブアプリケーション２６０は、２以上のトンネル２４０、アプリケーションのパス、および１以上のパイプ２５０をまとめてグループ化し、それらは、共に、信頼できるアプリケーションを防御する。いくつかのウェブサーバ２２０の間に分散したアプリケーション、すなわち、異なるマシン上に存在する分離したＨＴＭＬページを防御する時は、１つのウェブアプリケーションのエンティティが分散していることを表す。例えば、ウェブアプリケーション２６０は、選択されたアプリケーションのパスを越える全てのトラフィックを精査および監視する。デフォルトのウェブアプリケーションは、ウェブアプリケーション２６０で定められていない全てのトンネル越しの全てのトラフィックに関して、セキュリティ防御を表す論理的エンティティである。さらに、ウェブアプリケーション２６０は、パイプの実行を、特定のアプリケーションのパス用にカスタマイズできる。

セキュリティシステム２００は、防御層２１０を実現するハードウェア、ソフトウェア、またはその両方を備えてもよい。本発明の１つの実施の形態では、防御層２１０はスタンドアローンサーバ上に実現される。代わりの実施の形態では防御層２１０は「プラグアンドプレイ」ハードウェア等として実現され、そのハードウェアは既存のサーバに設置できる。本発明のもう１つの実施の形態では、防御層２１０が１以上のサーバ上にインストールされたソフトウェアコンポーネントにより実現される。

本発明の１つの実施の形態では、アプリケーション層セキュリティ方式は、到着するおよび／または発信されるメッセージまたはデータパケットの内容を検査して、意図するまたは許可された範囲外で実行され、信頼できるアプリケーションに関連するアプリケーションの命令またはパラメータを同定するステップを含む。メッセージの内容は、メッセージヘッダ、メッセージ本文、クエリー文字列、およびユニフォームリソース識別子（“ＵＲＩ”）を含み、特に、アプリケーションが実行または傍受するアプリケーション変数および命令などのアプリケーション層の要素を含む。内容のチェックは、１以上のパイプを適用するステップを含み、各パイプは、アプリケーション層の内容に対して特定の保護を提供し機能性を監視する。

本発明の１つの実施の形態では、セキュリティ方式３００は、到着するアプリケーションの動作要求のアプリケーション層の内容を精査するために使用される。図３Ａの左側を参照すると、アプリケーションのパスの同定およびトンネルの構築は、到着する動作要求に関して、第１に実施される（ステップ３０２からステップ３２２）。特に、信頼できないネットワークから送信されたデータパケットまたはパケットのストリームを形成する動作要求は、好ましくはキューイングされたソケットサーバなどの受信手段により最初に受信され（ステップ３０２）、それにより、バッファオーバーフロー攻撃により生じるサービスの拒否を防止でき、バッファオーバーフロー攻撃とは、与えられた時間内に受信する多量の冗長または不正な要求がサーバの扱える数を超えると、正当な要求に対してサービスの拒否を引き起こすか、またはオーバーフローさせる要求が不当な処理に進むのを許すことである。他の実施の形態では、データ通信を受信および扱える他の従来の受信手段が使用でき、それらの同定および実現は、当業者には明らかである。要求を受け取ると、バイナリストリームリーダはサーバのキューからデータパケットを読み込む（ステップ３０４）。好ましい実施の形態では、内部エンティティ、すなわちネットワークセッションオブジェクトは、システム内での各メッセージの存在時間の間、各メッセージを扱う。

プロトコルメッセージコンストラクタは、プロトコルの任意のタイプに従って最初に形式を整えられた受信した動作要求から、プロトコルの規格３０７により指定された所望の形式を持つ内部メッセージを構築（ステップ３０６）する。プロトコルの規格３０７は、ＨＴＴＰ、ＨＴＴＰｓ、ＳＯＡＰ、ＨＴＴＰｄ、ＦＴＰ、ＷｅｂＤＡＶ等の任意のタイプのアプリケーションプロトコルであってもよく、それは信頼できるアプリケーションにより実現される。内部メッセージの構築もトンネルの構築として呼ばれ、動作要求は、信頼できるアプリケーションプロトコルのデータ形式に組み込まれる。本発明の１つの実施の形態では、例えば余分なパラメータがないために正当なプロトコルメッセージをつくることが出来ない等の理由により、動作要求を内部メッセージの形式に整えられないと、その動作要求は即座に拒絶される。内部メッセージに形式が整えられると、メッセージはインデクシングされ（ステップ３０８）、後の解析用に分類されるので、必要ならばアプリケーションの内容が上記要求から集められ、一時バッファまたは不揮発性記憶装置に蓄積される。以下の詳細な議論のように、集められた内容は、アプリケーションによる要求の実行から返された対応する応答と、それに続く他の動作要求および応答との比較に有用である。

拒絶されないと、パイプコンポーネントが理解できる既知のエンコーディング言語にメッセージが変換される（ステップ３１０）。既知のエンコーディング言語は、任意のタイプのエンコーディング言語であってもよい。本発明の好ましい実施の形態では、使用されるエンコーディング言語はユニコードまたは拡張ユニコードである。ユニコードは、ＨＴＴＰアプリケーションプロトコルを使用する時に特に好ましい。動作中、要求はユニコード文字に変換される。例えば受信した要求がＡＳＣＩＩまたは任意の他のエンコーディング規格でエンコードされていると、メッセージはユニコードまたは拡張ユニコードに変換される。変換により、要求の中に含まれている任意のシンボルが予想外か否かを決定することにより、動作要求の、分離し、独立した検査が出来るようになる。言い換えると、予想外の文字を含む任意の要求は、完全に拒絶できる。変換により、後に続くセキュリティプロセスが、予想できるエンコーディング基準に関して実施されるので、予想外の文字によるセキュリティの妥協のリスクを最小化できる。さらに、変換により、変換されたメッセージから元のメッセージを分離して、変換されたメッセージに関して、全てのパイプが適切に実行されることが保証される。本発明の１つの実施の形態では、プロトコル規格３０７を更新すると、既知のエンコーディング言語がすぐに更新される。他の実施の形態ではＡＳＣＩＩまたは任意の他のエンコーディング基準はエンコーディング言語として使用できる。

構築と、インデクシングと、変換とに成功すると、信頼できない動作要求は、ユニコードでエンコードされ、形式がきちんと整えられたプロトコルメッセージに変換される。これらのステップは、１以上のパイプを適用することによる内容の集中的精査に渡される前の要求の形式の仮の審査として動作する。言い換えると、これらのステップは、隠されて、読めるように識別できない不正なまたは有害な命令に関する要求の内容をチェックする前に、明らかに予期できない予想外の要求を除去する。

変換に続いて、動作要求の中の各命令またはパラメータ、またはそれらの一部が、動作要求の意図したアプリケーションのパスと共に同定され（ステップ３１２）、次に論理的に管理されたエンティティ、すなわち指定されたルーティングスキームを使用するウェブアプリケーションに関係付けられる（ステップ３１４）。本発明の１つの実施の形態では、命令またはパラメータの同定されたアプリケーションのパスが既知であると、すなわち、ウェブアプリケーションおよびルーティングスキームに関連するアプリケーションのパスとの一致が見つかると、ルーティングスキームにしたがって命令がルーティングされる（ステップ３１６）。命令のアプリケーションのパスが存在しないか、完全には同定できないか、任意の既知のアプリケーションのパスに一致しないと、デフォルトのトンネルを経由してメッセージがルーティングされ（ステップ３１８）、デフォルトのトンネルは、セキュリティを最高にするために好ましくは全ての適用可能なパイプを適用する。デフォルトのトンネルは、最初のトンネル構築の間、セキュリティに問題のあることが見つかった任意のメッセージに適用できる。デフォルトのトンネルの実装は、エラーを示すウェブページ、セキュリティ警告を示すウェブページ、または同様な手段を表示させて、エラーが発生し、悪意があると推定される攻撃は信頼できるアプリケーションから避けられたことを知らせることが出来る。しかし、デフォルトのトンネルが指定されないと、要求は拒否される（ステップ３２０）。適切なアプリケーションのパスに対応する各命令またはパラメータは、ルーティングスキームにしたがってルーティングされるので、指定されたトンネルを経由して各コマンドをルーティングし、指定されたトンネルは、指定された数と組合せのパイプを上記アプリケーションのパスに順番に適用する。ステップ３１２からステップ３２０は、動作要求の中に含まれる追加の命令およびパラメータに関して繰り返される（ステップ３２２）。

図３Ａの右側を参照すると、次に１以上のパイプが、ルーティングスキームで決定されているように到着する動作要求の各々に順番に適用されて（ステップ３２４、ステップ３２６、およびステップ３２８）、要求の中に含まれる指示、命令、クエリー文字列、環境変数、およびパラメータなどのアプリケーション層の内容を精査する。各パイプは、一意のタイプの解析または監視の機能性を提供する。特定の数であって、複数のタイプの適用されるパイプは、所望のセキュリティの程度に依存し、各トンネルおよび／またはアプリケーションのパスのタイプおよびニーズにとっては典型的である。例えば、１つのトンネルは３つの適用されるパイプを持ってもよく、もう１つのトンネルは２つの適用されるパイプを持ってもよい。

パイプは一般的にスタティックまたはダイナミックとして分類され、そのどちらでも、以下に説明する「学習」技術を任意で実装できる。スタティックなタイプのパイプは、典型的に、ハッキングパターン、または既知の、すなわち同定された脆弱性に関連する静的に格納された情報と比較して、アプリケーションの内容を精査する。例えば、比較により一致が見つかると、その要求は拒絶、変更、または置換できる。ダイナミックなタイプのパイプは、到着する要求と発信される応答との両方を精査し、可能ならば、それらの間の変化する、すなわちダイナミックな関係を精査する。これらのタイプのパイプのどちらも、学習技術を利用でき、その学習技術は、要求および／または応答から情報を集めて、精査するパイプの範囲を「微調整」する。それにもかかわらず１つのパイプが、学習技術を備えるかまたは備えないスタティックおよびダイナミックなタイプのパイプに関連する多くの特徴を組み合わせることができる。具体的なパイプ構成および実装は以下の明細書に記載されている。適切な数とタイプのパイプを利用すると、動作要求のアプリケーションの内容の正当性および／または有害性が決定される。動作要求が精査に合格すると、その動作要求は、処理用の信頼できるアプリケーションに送られる（ステップ３３０）か、または少なくとも進むことを許可される（ステップ３３２）。

典型的なクライアントサーバ通信セッションでは、一旦、アプリケーションが動作要求を処理すると、要求を出したクライアントに返すために各応答が生成される。例えば、応答は、ＨＴＭＬドキュメント、画像、データベース情報、映像、またはサーバ経由でアクセスできる他のリソースであってもよい。図３Ｂを参照すると、動作要求の実行後に発生する方法のステップ３００が示されている。発信される応答は、読み取られ（ステップ３３４）、次に、指定されたアプリケーションのプロトコル３３７に基づいて構築されて、内部メッセージとなる（ステップ３３６）。本発明の１つの好ましい実施の形態では、アプリケーションプロトコル３３７はアプリケーションプロトコル３０７と同一である。到着する動作要求に適用される任意のパイプが、返される応答の検査を必要とすると、ステップ３３８から３５６が実行される。特に、応答メッセージと元の要求との間の比較が任意の実装されたパイプに必要であると、応答メッセージがインデクシングされて（ステップ３３８）、元の要求に戻る。メッセージをインデクシングすると、応答メッセージが、到着するデータストリームに関して使用されるエンコーディング言語に変換される（ステップ３４０）。発信される応答は、以前格納された変換され、インデクシングされた要求および変換され、インデクシングされた応答メッセージを使用して認証される（ステップ３４２）。特にこのステップにより、発信される応答が事実上普通であることが保証される。例えば、上記応答はサーバからの発信が許可された情報のみを含んでもよい。クライアントから届く普通でない応答は拒否される（ステップ３４４）。新しいアプリケーションのパスだけでなく全ての可能なパラメータ名およびパラメータ値が、応答の中で同定される（各々、ステップ３４６およびステップ３４８）。この情報は、適切なダイナミックなタイプのパイプまたは実装された学習技術を更新するために使用される（ステップ３５０、ステップ３５２、およびステップ３５４）。更新する時、応答は、プロトコル３５にしたがって、メッセージに再構築され（ステップ３５６）、必要ならば、動作を要求するクライアントに送られる（ステップ３５８）。好ましい実施の形態では、プロトコル３５７はプロトコル３０７と同一である。動作要求が、応答の検査を必要とする適用されるパイプを持たないと、ステップ３３８からステップ３５６はスキップされる。

図４Ａは、アプリケーションサーバから、またはクライアントから到着するパケットまたはパケットのストリームの中で受信または同定されるアプリケーション動作要求または応答をルーティングするセキュリティシステム４００を示す。特にシステム４００は、クライアント４１０、要求識別モジュール４２０、要求ルータ４２４、Ｎ個のパイプ４３０Ａ−Ｎ、サーバ４４０、応答識別モジュール４５０、および応答ルータ４５４を含む。クライアント４１０は、分散ネットワーク内に位置していると推定される。サーバ４４０は、信頼できるネットワーク内に存在し、クライアント４１０とサーバ４４０または追加の分散サーバ（図示されていない）上にある１以上のアプリケーション（図示されていない）とのやりとりを制御する。動作中、クライアント４１０により送信されたパケットまたはパケットのストリームを含む到着する要求は、通信リンク４１２経由で要求識別モジュール４２０に転送される。要求識別モジュール４２０は、要求の中の命令、パラメータ、またはそれらの一部等の１以上のアプリケーションの属性を同定する。同定されたアプリケーションの属性は、次に通信リンク４２２を経由して要求ルータ４２４に転送される。

要求ルータ４２４は、アプリケーションの各属性または要求自体の全体を、適切なアプリケーションのパス４２６Ａから４２６Ｍの１つに導き、Ｍは、適用できるパイプ４３０Ａからパイプ４３０Ｎの一意のまたは指定された組合せの数である。例えば、示されているように、アプリケーションのパス４２６Ａは、全てのＮ個のパイプを動作要求に適用するけれども、アプリケーションのパス４２６Ｂは２つのパイプのみを適用する。アプリケーションのパスの全体数Ｎおよびパイプの全体数Ｎは等しくない。本発明の１つの好ましい実施の形態では、要求ルータ４２４は、ルーティングスキームを使用し、そのルーティングスキームは、例えば、要求される動作のタイプ、命令のタイプ、パラメータ名、パラメータ値、要求されている特定のアプリケーション、要求されるアプリケーションのパス、クライアントの同定、またはそれらの組合せに基づいた各アプリケーションの属性にとって適切なアプリケーションのパスを決定する。さらに、要求ルータ４２４は、指定されるか、同定不可能なクライアントアドレスから受信したアプリケーションの属性またはリクエスト自体全体を、例えば全ての可能なパイプを適用するデフォルトのアプリケーションのパスに導く。パイプ４３０Ａ等の、あるパイプに関しては、要求または属性に関するパイプの適用から確かめられる情報が、通信リンク４３１経由で要求ルータ４２４により指定されるルーティングスキームをダイナミックに変更するために使用される。このルーティングスキームは、通信リンク４６３経由で発信される応答に関するパイプ動作により確かめられる情報により同様に変更できる。さらに、ルーティングスキームへの更新または変更は、システム４００の外部の発信源（図示されていない）から受信できる。パラメータ等の動作要求のサブコンポーネントへ全ての適切なパイプを適用するに際して、動作要求は、全てのサブコンポーネントを受け付けることができると考えられると、処理のためにサーバ４４０に転送される。要求ルータ４２４は、動作要求の同定されたアプリケーションの属性を分類し、それらを、更なる検査のために、アプリケーションのパスまたはデフォルトのアプリケーションのパスに転送する。このアプローチの本質は、積極的なセキュリティモデルを提供することであり、その積極的なセキュリティモデルでは、（ネガティブパターンを除く全てのパターンが許可されるアンチウイルスアプローチとは異なり）既知の属性のみが許可されてアプリケーションに渡され、認識されないアプリケーションの属性は、拒絶されるか、デフォルトのアプリケーションのパスに導かれる。

パケットまたはパケットのストリームを含む発信される応答は、要求の処理により生成され、到着するストリームと同じ精査を受ける。特に、サーバ４４０により生成される発信されるパケットまたはパケットのストリームは、通信リンク４４２経由で応答識別モジュールに転送され、応答識別モジュール４５０は、パラメータ名およびパラメータ値、またはそれらに含まれる他の当該アプリケーション層の属性などで、それらに限定されないアプリケーションの属性を同定する。これらの同定されたパラメータおよび要素は、通信リンク４５２経由で、応答ルータ４５４に転送される。応答ルータ４５４は、各要素を、１つの適切なアプリケーションのパス４５６Ａから４５６Ｍに導き、Ｍは、パイプ４６０Ａから４６０Ｎの一意または指定された組合せの数であり、パイプ４６０Ａから４６０Ｎは、発信されるパラメータまたは要素の各々に適用されてもよい。パイプ４６０Ａから４６０Ｎの一部は、パイプ４３０Ａから４３０Ｎの一部と同じであってもよい。本発明の１つの好ましい実施の形態では、応答ルータ４５４はルーティングスキームを使用し、そのルーティングスキームは、例えば、応答のタイプ、パラメータのタイプ、パラメータの値、要素のタイプ、応答を生成したアプリケーション、クライアントの受信応答の同定、またはそれらの組み合わせに基づいた各要求、各パラメータ、各パラメータ値、または各要素を決定する。応答ルーティングスキームは、要求ルータ４２４に使用されているルーティングスキームと同一であってもよいけれども必ずしもそうである必要はない。発信されるパラメータまたは要素に関して示されているようなパイプ４６０等のパイプにより確かめられる情報は、通信パス４６１経由で応答ルータ４５４により実装されるルーティングスキームを変更するために使用できる。さらに、到着する要求に関して動作するパイプ４３０Ａにより確かめられる情報は、通信パス４３３経由で、このルーティングスキームをダイナミックに変更できる。さらに、応答ルーティングスキームの更新または変更は、システム４００の外部の発信源（図示されていない）から受信できる。アプリケーションのパス４５６に関連する全ての適切なパイプ４６０を適用すると、受け入れることのできる結果が、通信チャネル４６２経由でクライアント４１０に返される。

上記の実施の形態は、通信リンク４２２、４３３、４５２、および４６３と共に示され、それらは、要求識別モジュール４２０、要求ルータ４２４、応答識別モジュール４５０、または応答ルータ４５４に適切に接続されている。本発明の１つの実施の形態では、識別モジュール４２０、応答ルータ４２４、応答識別モジュール４５０、および応答ルータ４５４は、パイプ４３０および４６０とは別個のソフトウェアとして実装されていてもよく、パイプ４３０および４６０はソフトウェアまたはハードウェアのいずれで実現されていてもよい。例えば、通信リンク４２２、４３３、４５２、および４６３は、実際の物理的接続部ではなく、ソフトウェアモジュール間の仮想接続部である。通信リンク４１２、４３２、４４２、および４６２は、ここで同定されている任意の他のリンクと同様に、どの従来の通信媒体であってもよく、それらの実装は当業者には明らかである。代わりの実施の形態では、要求識別モジュール４２０、要求ルータ４２４、応答識別モジュール４５０、および応答ルータ４５４は、パイプ４３０Ａ−Ｎおよび４６０Ａ−Ｎを持つまたは持たない１つのハードウェアコンポーネントの中に実装される。

本発明の１つの実施の形態では、システム４００は、上に説明したように、アプリケーションレベルのスイッチを使用して、要求識別モジュール４２０、要求ルータ４２４、応答識別モジュール４５０、および応答ルータ４５４の機能を実装する。アプリケーションレベルのスイッチは、（ネットワークレベルの属性に基づいて同じことをするネットワークスイッチと異なり）到着する要求の中で同定される１以上のアプリケーションレベルの属性のあらかじめ決められたリストまたはスイッチングテーブルに基づいて、特定の対象サーバに、到着するトラフィックを導く装置であって、その実現は当業者にとって明らかである。ウェブアプリケーションがＬｏｇｉｎ．ｈｔｍｌと呼ばれる１つのＨＴＭＬページと、２つの画像ファイル（ｘ．ｇｉｆ、ｙ．ｇｉｆ）とを持つ典型的なシナリオを考える。ウェブアプリケーションは２つのウェブサーバを使用して配置され、それらのうち１つはＬｏｇｉｎ．ｈｔｍｌファイルを保持し（例えばＨＴＭＬファイルサーバ）、もう１つは２つの画像ファイルを保持する（例えば画像ファイルサーバ）。アプリケーションレベルのスイッチは、２つのウェブサーバの外側に設置され、画像に関する全ての要求を画像サーバにスイッチし、ＨＴＭＬファイルに関するすげての要求をＨＴＭＬファイルサーバにスイッチする。リモートユーザが、ｘ．ｇｉｆファイルを要求する要求をウェブアプリケーションに送ると、アプリケーションレベルのスイッチは、ユーザの要求、この場合ｘ．ｇｉｆからアプリケーションの属性を得て、最終的な目的地として画像ファイルサーバにその要求をスイッチする。注記：有効な要求はネットワークの属性およびアプリケーションの属性の両方の属性を持つ。スイッチングテーブルと一致しないアプリケーションの属性を持つどのリモートユーザのリクエスト（例えばＨＴＭＬまたは画像）も、完全に拒絶され、所定のデフォルト位置にスイッチされる。

図４Ｂは、応答および要求ルーティングスキームを実現するアプリケーションレベルのスイッチ４７０トポロジー、および、上に説明したように、要求識別モジュール４２０、要求ルータ４２４、応答識別モジュール４５０、および応答ルータ４５４により使用される識別モジュール処理を示す。このトポロジーを使用して、アプリケーションレベルのスイッチ４７０は、要求または応答から１以上のアプリケーションの属性をフェッチし、システム４００のアプリケーションのパス４２６Ａ−Ｎまたは４５６Ａ−Ｎの１つのような適切なアプリケーションのパスのそのような属性に基づいた要求または応答の到着地をスイッチし、パイプ４３０Ａ−Ｎおよび／または４６０Ａ−Ｎの任意の所望の組合せが、それに続いて適用される。フェッチされたアプリケーションのパスの属性がスキームに含まれていないと、アプリケーションレベルのスイッチは要求または応答を拒絶４７０する。このアプローチを使用すると確認された、すなわち予想された要求および／または応答のメッセージのみがセキュリティシステム４００の中で処理されるので、性能が改善し、積極的なセキュリティモデルが実現される。上で説明した典型的なシナリオを再度参照すると、２つのサーバ、例えばＨＴＭＬサーバ４４０Ａおよび画像ファイルサーバ４４０Ｂが設けられ、画像の属性を持つ要求がアプリケーションのパス４２６Ｂにスイッチされる（ＨＴＭＬ属性を持つ要求がＨＴＭＬサーバ４４０Ａのアプリケーションのパスにスイッチされる）ことをルーティングスキーマが定める。したがって、ｘ．ｇｉｆに関する要求が受信されると、アプリケーションレベルのスイッチ４７０がこの要求をアプリケーションのパス４２６Ｂにスイッチし、パイプ４３０Ａおよび４３０Ｂが適用され、次に、それらに続いて、要求が、これらのパイプの適用に基づいて受け入れられると考えられると、要求が画像ファイルサーバ４４０Ｂと通信される。

セキュリティパイプの任意の組合せが、各アプリケーションのパスに適用できるので、すなわちセキュリティのタイプと強度が、アプリケーションレベルのスイッチ４７０を使用して特定のタイプのアプリケーションの属性に調整できるので、それに注意するのは重要である。別の言い方では、アプリケーションレベルのスイッチ４７０は、分類された各アプリケーションの属性に調整されたセキュリティ方式を実現するために、アプリケーションの属性を分類する。

図４Ｃは、もう１つのアプリケーションレベルのスイッチ４７０のトポロジーを示し、確認されたた要求および／または応答のリストは、アプリケーションレベルのスイッチでダイナミックに更新される。特に、アプリケーションレベルのスイッチ４７０は、要求（または応答）からアプリケーションの属性をフェッチし、それらを、アプリケーションのパス４２６Ａ−Ｎ（または４５６Ａ−Ｎ）のリストと比較し、確認された要求（または応答）として定められる受け付けた要求（または応答）と比較する。到着する要求が確認された要求、すなわち、要求が、アプリケーションレベルのスイッチ４７０のリストで入手可能であると、アプリケーションレベルのスイッチ４７０は、それを、さらにパイプ処理せずに、適切なサーバに直接転送する。到着する要求が、アプリケーションレベルのスイッチ４７０の中の確認された要求のいずれとも一致しないと、アプリケーションレベルのスイッチ４７０は、要求を適切なアプリケーションのパス４２６Ａ−Ｎ（または４５６Ａ−Ｎ）に導いて、さらにパイプで処理する。処理中に、受け付けることのできる要求が、確認されたと定められ、したがって、アプリケーションレベルのスイッチ４７０の中の確認された要求のリストに加えられるので、それに続く同じ要求は、確認された要求として扱われる。別の言い方では、ユーザからの将来到着する要求が、追加のパイプ処理を必要とせずに、アプリケーションレベルのスイッチ４７０でのみ処理されるように、アプリケーションレベルのスイッチ４７０が、リンク４３１または４６１経由で新しく確認される要求と共に、ダイナミックに更新される。このアプローチを使用して、アプリケーションの属性がスイッチの中で設定されるので、積極的な機能性が実現され、それにより、全ての他の要求が分散要求として処理される間に、信頼できる要求がアプリケーションにスイッチされる。

上で紹介したアプリケーションレベルのスイッチのトポロジーは、アプリケーションレベルの属性に基づいて、スイッチ、ルートおよび／またはトラフィックバランスを管理するどの他の非セキュリティ製品と共に組み合わせても実現できる。

図５は、本発明の実施の形態にかかるハードウェア構成を持つセキュリティシステム５００を示す。特に、セキュリティシステム５００は、セキュリティモジュール５１０を備え、そのセキュリティモジュール５１０は信頼できるコンピュータアプリケーション５２０および信頼できないネットワーク環境の間に位置する。モジュール５１０はアプリケーション５２０の不正使用を防ぐための防御層を実装する。本発明の実施の形態では、モジュール５１０は、プロセッサ５３０およびパイプのロジック５４０を備える。用語プロセッサは、任意のロジック、回路、コード、ソフトウェア等を示し、ここに記載されている機能を実行するよう構成されている。プロセッサ５３０は、アプリケーション５２０から信頼できない環境経由で受信した動作要求を分離する内部エンティティを実装することにより、上に記載したように、最初のトンネル構築、インデクシング、および変換を実施する。内部エンティティは、識別モジュール、ルータ５３４、および解析機５３８に信頼できない要求を送り届ける。識別モジュールおよびルータ５３４は、もし必要ならば、到着する要求ストリームまたは発信される応答ストリームに全ての既存のアプリケーションのパスを適用して、もし存在すれば、パラメータおよび値だけでなく、アプリケーションの中の動作要求の所望の対象を同定する。解析機５３８は、パイプのロジック５４０に格納された１以上のパイプを動作要求またはその一部に適用する。

典型的なパイプの説明
単独または組合せで、到着する動作要求および発信される応答に適用できる典型的なパイプの詳細な説明を以下に示す。従来の技術に指向したセキュリティ処理などのここに記載されていない追加のパイプも適用でき、それらの同定および実装は当業者には明らかである。

１．Ｍａｒａｂｕ
本発明の実施の形態では、ここでは“Ｍａｒａｂｕ”と呼ぶ第１のパイプが、１以上のアプリケーションのパスに適用される。Ｍａｒａｂｕは、内容（コンテンツ）駆動のパイプであって、動作要求の中の悪意を示すパターンを見つけることを目的としている。Ｍａｒａｂｕは、好ましくは、データベース動作を含むアプリケーションのパスに適用される。特に、Ｍａｒａｂｕは、到着する要求のアプリケーションの内容を、要求されたデータベースのタイプに基づく許可された構文に関して検査し、１以上の組み込まれた有害なＳＱＬ命令の存在を検査する。有害な命令は、ＳＱＬタイプのデータベースまたはＯｒａｃｌｅタイプのデータベース等の要求されたデータベースのタイプに関して受け付けることができると考えられる複数のストアドデータベース命令との一致を見つけることができないと、同定される。受け付けることのできる命令との一致が見つからないと、要求は拒絶されて、再設計される。すなわち、正当で無害な受け付けることのできるフォームに変更されるか置き換えられる。このパイプは、データベースまたはその環境にとって有害と考えられるよく整形されて部分的なＳＱＬコマンドを捕らえる。

本発明の１つの実施の形態では、データベースクエリーパーサーエンジンが実現されて、動作要求の式の各々のフォームおよび機能を同定する。パーサーエンジンは個々の式、すなわち分離した解析に関する要素を構文解析する。Ｍａｒａｂｕは式の各々の構文が単純であり、ステートオートメート（ｓｔａｔｅ−ａｕｔｏｍａｔｅ）および限られたアルファベットを使用することによりだまされやすくなることに注目している。特にＭａｒａｂｕは、ステートオートメートを構築するステップ、許される全ての構文および限定されたアルファベットにかかる式の各々および全てを検査するステップ、およびステートオートメートを式の各々および全てに適用するステップを含む適切な構文を実施する方法を使用する。ステートオートメートは、アプリケーションの現在および他の可能な状態を表すノードの相関である。各ノードは、アプリケーションの状態を変更する式に基づく他のノードへの接続部を持ってもよい。例えば、アプリケーションの現在の状態を表す第１のノードは、特定の式、例えばＤＥＬＥＴＥ命令が実行された時、現在の状態から到達可能な状態を表すもう１つのノードに接続されている。全ての接続部は一方向接続、すなわち、一旦状態がもう１つの状態へ変化すると、その変更が元に戻せない接続であると推定される。

本発明の１つの実施の形態では、アルファベットは、文字、数字、例えばａ，ｂ，ｃ，＿，‘，等の他のエンコードされた文字、ＤＥＬＥＴＥまたはＡＬＴＥＲ等の文字のブロック、およびＤＥＬＥＴＥ、ＡＬＴＥＲ、およびＣＲＥＡＴＥを構成要素として含むＳＱＬグループなどのブロックのグループを含む。動作要求の中の式の各々は１回以上走査される。式の各々が、受け入れることができるとして同定された文字および数字の連続からなると、要求が承認され、パイプの実行が停止される。式が、文字、数字、コメント、ＭＳＳＱＬ−／＊＊／または−−などの特にコメントを表すデータベース特定の文字の受け付けることのできる連続から成っていないと、式の内側は省略され、ステートオートメートを使用することにより式が検査される。式または関数の引数に関連する全ての所定のアルファベット文字は、オートメートの現在の状態を、繋がっている可能な状態に変化させる。

本発明の１つの実施の形態では、ステートオートメートを使用すると、到達した状態のタイプにより異なる処理が実施される。例えば、ステートオートメートがブーリアン状態に達すると、‘１５’＝‘１’＋‘５’および‘６＞５ＯＲ５＝５’などの「常に真」の式に関して式がチェックされる。常に真の式は、通常は要求を受け付けるべきでない時、データベースをだまして、要求を受け付けさせることができる。式のツリーにより常に真の式を同定できる。特に式は、例えばＡＮＤ、ＯＲ、＝等の演算子またはフィールドなどの変数としてノードを持つツリーに反復的に分解される。ツリーが構築された後、異なる式の値が挿入される。後順に走査すると、結果としてＴＲＵＥまたはＦＡＬＳＥを決定できる。変数に対して抜け目なく値をサンプリングすると、全ての可能な解の範囲をカバーするので、式が常に真か否かを決定し、それ故要求を拒絶するか否か決定できる。ステートオートメートがＳＱＬ状態に達すると、辞書に格納されたＳＱＬプロトタイプを使用して、式が認証される。プロトタイプは、弧で連結された異なる状態のグラフを使用して実現される。２方向の弧により、再帰的な式、すなわち、自分自体を指す弧を持つ状態、および、入力に合わせようとするための延伸が可能になる。ステートオートメートがトラップ状態に達すると、式が否定され、パイプの実行が停止される。これらの状態のどれもが発生せず、上記の状態の検査が、式の拒否となると、式が承認されパイプの実行が停止される。

図６は、本発明の実施の形態にかかるＭａｒａｂｕパイプを実現する方法６００を示す。特に、例えばＳＱＬのバージョンのタイプに基づく支持データベースのパラメータの構成が、プロセッサにロードされる（ステップ６１０）。任意で、これらの構成パラメータに対するどの改良版もロードされる（ステップ６２０）。動作要求がロードされ（ステップ６３０）、要素を構文解析して、動作要求内に含まれるパラメータ名および値などの式を同定する（ステップ６４０）。次に、Ｍａｒａｂｕパイプが各パラメータに適用されて（ステップ６５０）、組み込みＳＱＬ命令が受け付けることができるか否かを決定する（ステップ６６０）。受け付けることができないと、動作要求全体は拒絶されうる（ステップ６７０）。受け付けることができると、パラメータが最後のパラメータか否かを決定する（ステップ６８０）。パラメータが最後のパラメータでないと、ステップ６４０−６８０が繰りかえされる。パラメータが最後のパラメータであると、どの不正で有害なＳＱＬ命令も同定されず、動作要求は受け付けられ（ステップ６９０）、先に進むことが許可される。

以下は、インターネットに一般的に広く広がっていて、典型的な操作タイプの攻撃であって、このパイプにより捕らえることのできるデータベース攻撃の２つの一般的なタイプである。第１のタイプはテーブルの中の全てのレコードを削除する要求を示す。例えば、全レコード削除攻撃では、
ｈｔｔｐ：／／ｗｗｗ．ｙｏｕｒｓｉｔｅ．ｃｏｍ／ｐｈｏｎｅｓ／ｐｈｏｎｅｌｉｓｔ．ｃｇｉ？ｐｈｏｎｅｉｄ＝３４
などのデータベースサーバ上のＳＱＬ命令を実行して、”ｐｈｏｎｅｉｄ”が３４に等しい“ｈｔｔｐ：／／ｗｗｗ．ｙｏｕｒｓｉｔｅ．ｃｏｍ／ｐｈｏｎｅｓ”の内容を選択して報告する元のリンクが、ＤＥＬＥＴＥ命令を結合した変更されたリンク、例えば、
ｈｔｔｐ：／／ｗｗｗ．ｙｏｕｒｓｉｔｅ．ｃｏｍ／ｐｈｏｎｅｓ／ｐｈｏｎｅｌｉｓｔ．ｃｇｉ？ｐｈｏｎｅｉｄ＝３４；ＤＥＬＥＴＥ
に変更される。後者は、データベース上のＳＱＬコマンドを実行して、“ｐｈｏｎｅｉｄ”が３４に等しいｈｔｔｐ：／／ｗｗｗ．ｙｏｕｒｓｉｔｅ．ｃｏｍ／ｐｈｏｎｅｓ”の内容を削除する。このパイプを使用すると、ＤＥＬＥＴＥ命令が不正なコマンドとして認識されるので、要求を完全に拒絶するか、ＤＥＬＥＴＥ命令を含まない元のリンクのような正当な要求に、この要求を置き換える。続く第２のタイプの不正な要求では、パスワードを使用せずにログインが試みられる。例えば
ｈｔｔｐ：／／ｗｗｗ．ｙｏｕｒｓｉｔｅ．ｃｏｍ／ｌｏｇｏｎ．ａｓｐ？ｌｏｇｉｎ＝ｙｏｕｒｎａｍｅ；ｐｗｓ＝１２３
はデータベースサーバ上でＳＱＬ命令を実行してｌｏｇｉｎ＝‘ｙｏｕｒｎａｍｅ’であり、ｐａｓｓｗｏｒｄ＝‘１２３’であるユーザリストから名前を選択する。変更されたリンクは、「常に真」のブーリアン・フレーズ（句）を加えて、アプリケーションをだまして無効なパスワードを受け付けさせる。例えば、
ｈｔｔｐ：／／ｗｗｗ．ｙｏｕｒｓｉｔｅ．ｃｏｍ／ｌｏｇｏｎ．ａｓｐ？ｌｏｇｉｎ＝ｙｏｕｒｎａｍｅ’ｏｒ‘１’＝‘１’；ｐｗｓ＝８
はデータベースサーバ上でＳＱＬ命令を実行して、ｌｏｇｉｎ＝‘ｙｏｕｒｎａｍｅ’または‘１’＝‘１’であり、ｐａｓｓｗｏｒｄ＝‘１２３’であるユーザリストから名前を選択する。このパイプを適用すると、‘１’＝‘１’の部分的命令は無効であると認識され、要求は意図した実行の達成を許可されない。

アプリケーションデータベースを操作するユーザおよびクライアントアプリケーションに対して完全なデータベースの防御が提供される。Ｍａｒａｂｕパイプは、データベース内に保存された情報に損害を与えることのできるデータ操作に対するシールドとして作用する。さらに、これは、他のパイプと組み合わせた時、データベースシステム管理者に追加のレベルの防御を提供し、アプリケーションのバグが事務管理部門のデータベースに影響しないことを保証する。

２．Ｍｉｎｉｍｅ
本発明の１つの実施の形態では、ここでは“Ｍｉｎｉｍｅ”と呼ぶ第２のパイプが１以上のアプリケーションのパスに適用される。Ｍｉｎｉｍｅは、既知の脆弱性パターンに関して到着する動作要求を検査する決定性パイプである。本発明の具体的な実施の形態では、全ての既知のアプリケーションの脆弱性、特にそれらを利用する各要求は、格納され、到着する要求と比較される。到着した情報の任意の部分と格納された情報の任意の部分との間で一致が見つかると、到着する要求は阻まれ、アプリケーションに進むことを許可されない。さらに、パイプは、スクリプト、命令、メソッド、および実行可能ファイルの使用を排除することにより未知で容易には同定できない脆弱性に対してアプリケーションをシールドでき、スクリプト、命令、メソッド、および実行可能ファイルは、例えば記憶領域をフォーマットするｆｏｒｍａｔ．ｅｘｅ、または、アクセスされるか実行されると、コマンドライン入力プロンプトを可能にするか、アプリケーション環境またはサーバへ悪影響を与えるか、または不正アクセスを許可するｃｍｄ．ｅｘｅなどである。

本発明の好ましい実施の形態では、格納された脆弱性情報は、将来の脆弱性が同定されると、更新されてもよい。特に、格納された情報は、情報源、例えば商用または政府の情報源からの専用中央サーバまたは複数のウェブサーバ等の情報源からダウンロードされた情報により更新できる。

本発明の１つの実施の形態では、Ｍｉｎｉｍｅパイプは、正確なパターンの一致方法を使用する。特に、この方法は、例えば動作要求の中の４つの連続した文字ごとなどの連続した文字に関するハッシュ値を計算するステップおよび計算されたハッシュ値の各々を不適切な要求に関連するハッシュ値のリストに対して比較するステップを含む。動作中、動作要求の最初の４文字は４文字ウィンドウに入力される。４文字の各々は、例えば
ａｂｃｄ＝［０１０００００１］［０１００００１０］［０１００００１１］［０１０００１００］
などの８ビットバイナリコードに変換される。次に第１のハッシュ値は、３２ビットの文字列（４文字×８ビット／文字）から計算される。第２のハッシュ値は、ウィンドウを１文字シフトする、すなわち文字２から文字５までにシフトすることにより計算される。第３のハッシュ値はウィンドウを再度１文字シフトする、すなわち文字３から文字６までにシフトすることにより、計算される。追加のハッシュ値は、動作要求の中の全ての文字が使い尽くされるまでそのような方法で計算される。したがって、動作要求の中にｎ文字あると、ｎ−３個のハッシュ値が計算される。各ハッシュ値は、不適切な要求に関連して格納されたハッシュ値と比較される。したがって、一致が見つかると、到着する要求は拒絶される。

本発明の好ましい実施の形態では、上記の方法が、ＨＴＴＰプロトコルで構築された動作要求に使用される。動作要求は、各々、メッセージＵＲＩ、クエリー文字列、メッセージヘッダ、およびメッセージ本体を表す４ゾーンに分割される。上に説明されたような脆弱性のパターンマッチングは、特定の４ゾーンの１以上に導かれる。パイプのアプリケーションは、１ゾーンまたは動作要求自体全体より少ない一部に導かれるので、性能が向上し、誤認検出が減る。文字列が疑わしいと判断されると、サンプル文字列全体のマッチングが実行される。

図７は、本発明の実施の形態にかかるＭｉｎｉｍｅパイプを実現する方法７００を示す。特に脆弱性パターンが、内部記憶装置または外部データベースのどちらかからプロセッサにロードされる（ステップ７１０）。任意で、脆弱性パターンのハッシュ値を含むテーブルが作成されて（ステップ７２０）有効なパターンマッチングを容易にする。４つの異なる走査ゾーンが作成され（ステップ７３０）、使用される指定されたハッシュ値に関係する。到着メッセージがロードされ（ステップ７４０）、１以上のメッセージゾーンが走査されて（ステップ７５０）、ハッシュ値などの脆弱性パターンが一致するか否かを決定する（ステップ７６０）。一致が見つからないと、メッセージは拒絶される（ステップ７７０）。一致が見つからないと、メッセージはもう１つのパイプまたはアプリケーションに進むことを許可される（ステップ７８０）。

以下は３つの一般的なＭｉｃｒｏｓｏｆｔ Ｉｎｔｅｒｎｅｔ Ｉｎｆｏｒｍａｔｉｏｎ Ｓｅｒｖｅｒ（登録商標）のブロックされる脆弱性である。ウェブサーバのハードディスク上の任意のファイル、例えば、
ｈｔｔｐ：／／ｗｗｗ．ｙｏｕｒｓｉｔｅ．ｃｏｍ／ｍｓａｄｃ／Ｓａｍｐｌｅｓ／ＳＥＬＥＣＴＯＲ／ｓｈｏｗｃｏｄｅ．ａｓｐ？ｓｏｕｒｃｅ＝／ｍｓａｄｃ／Ｓａｍｐｌｅｓ／．．／．．／．．／．．／．．／Ｂｏｏｔ．ｉｎｉ
を見る。任意のＳＱＬコード、を直接にデータベース、例えば、
ｈｔｔｐ：／／ｗｗｗ．ｙｏｕｒｓｉｔｅ．ｃｏｍ／ｍｓａｄｃ／ｓａｍｐｌｅｓ／ａｄｃｔｅｓｔ．ａｓｐ
に対して実行する。ＣｏｄｅＢｒｗｓ．ａｓｐを使用してＯｕｔｌｏｏｋメールフォルダ、例えば、
ｈｔｔｐ：／／ｗｗｗ．ｙｏｕｒｓｉｔｅ．ｃｏｍ／／ｉｉｓｓａｍｐｌｅｓ／ｅｘａｉｒ／ｈｏｗｉｔｗｏｒｋｓ／ｃｏｄｅｂｒｗｓ．ａｓｐ？ｓｏｕｒｃｅ＝／．．／．．／ｗｉｎｎｔ／Ｐｒｏｆｉｌｅｓ／Ａｄｍｉｎｉｓｔｒａｔｏｒ／Ａｐｐｌｉｃａｔｉｏｎ％２０Ｄａｔａ／Ｍｉｃｒｏｓｏｆｔ／Ｏｕｔｌｏｏｋ％２０Ｅｘｐｒｅｓｓ／Ｍａｉｌ／ｉｎｂｏｘ．ｍｂｘ
を見る。

Ｍｉｎｉｍｅパイプは、少なくとも以下の利益。アプリケーションの脆弱性を使用してシステムをハックしようとするリモートユーザからのアプリケーション防御；パッチが入手可能になり、サーバ上にインストールされるまでのアプリケーションに対する一時的保護；およびカスタムパターンが加えられ既存のパターンは記憶装置から削除される利益を提供する。

３．Ｈｉｄｅ＆Ｓｅｅｋ
本発明の１つの実施の形態では、ここでは“Ｈｉｄｅ＆Ｓｅｅｋ”と呼ぶ第３のパイプが、１以上のアプリケーションのパスに適用される。Ｈｉｄｅ＆Ｓｅｅｋは、ハイパーテキストマークアップ言語駆動パイプであって、その目的は、アプリケーションがアプリケーションの所有者により設計され、実装される動作を保証することである。ハイパーテキストマークアップ言語またはＨＴＭＬは、ここでは、任意のタイプのマークアップ言語、例えば、エクステンシブマークアップ言語（ＸＭＬ）、拡張可能ハイパーテキストマークアップ言語（ＸＨＴＭＬ）、およびワイヤレスマークアップ言語（ＷＭＬ）を含む。特に、パイプは発信されるＨＴＭＬ応答の各々を検査して、その内部のパラメータ名および値を同定し、次に、前に同定されたパラメータに対応する次のユーザ要求を認証するので、アプリケーションに対するそれに続くユーザ要求は、戻ってくることをアプリケーションが予期しているユーザ要求のみであることを保証する。

本発明の１つの実施の形態では、方法が、アプリケーションとやりとりをする１つのクライアントを同定するステップ、クライアントに送られるアプリケーションからの応答の中のパラメータ名または値等の要素を同定するステップ、アプリケーションへのクライアントのそれに続く応答が任意のパラメータまたは値を含むか否かを決定し、もし含むならば、それらのパラメータおよび値がアプリケーションにより予期されるか否かを決定するステップを含む。クライアントから受信したパラメータおよび値が、前の要素から決定される要素に対応する場合のみ、送信される対応するメッセージが、サーバに要求をアプリケーションに転送するように命じる。

本発明の１つの実施の形態では、アルゴリズムが、応答ドキュメントを構文分析するＨＴＭＬを実行し、クライアントにより受信される全てのＨＴＭＬタグを格納する。例えば、パーサは、アプリケーションから到着した各応答を読み込み、応答メッセージの中のｉｎｐｕｔ、ｓｅｌｅｃｔ、ｆｏｒｍ等の特定のＨＴＭＬ要素を同定する。同定された要素の各々に関し、パーサは要素の値を決定する。全ての解析された要素の名前および値は、サーバ上に位置するセッションオブジェクトの中に格納され、各セッションは１つのクライアントに関連する。クライアントを同定し、任意で、セッションオブジェクトを要求に付け加えた後で、追加のパーサが要求を構文分析する。この段階で、コンパレータが使用されて、ＨＴＭＬ要素に基づき要求を応答と一致させる。例えば要求パーサは、クライアントが、クライアントのその次の要求でパラメータ値を変更できるか否かを決定する。もし変更できれば、クライアントに、このパラメータを持つ任意の値の送信を許可する。例えば、アプリケーションの応答が＜ＩＮＰＵＴ＞タグを含むと、クライアントは値を入力することを要求される。

状態なしのプロトコル、すなわち、メッセージの内容ではなくて、発信元および到着先情報にのみ関連するプロトコルでクライアントを同定するために、セッションベースのクッキーが使用される。好ましくは、クッキーはクライアントのウェブブラウザ上で有効にされる。セキュリティの目的のため、クッキーが有効になっていないクライアントは、最少のアプリケーション動作に限定される「新しく」て不正なユーザであると考えられる。クッキーがクライアントにより有効にされると、サーバは、クライアントサーバ間のセッションの開始に際して、クライアントにセッションベースのクッキーを生成および格納する。本発明の１つの実施の形態では、セッションベースのクッキーは、クライアント同定情報を含むヘッダおよびセッションオブジェクトを同定する暗号化されたセキュリティ値を含むクッキー本体を含む。

以下は、Ｈｉｄｅ＆Ｓｅｅｋパイプの典型的な実装である。ログインおよびパスワードに関する典型的なＨＴＭＬドキュメントは以下の通りである。

このＨＴＭＬドキュメントは、クライアントが最初にサーバにアクセスすると、クライアントに送信される。構文分析をすると、以下の典型的な結果がセッションオブジェクトの中に格納される。

このセッションオブジェクトは、セッション値に関連し、クライアントのクッキーの中に格納される。クライアントの次のそれに続く要求、すなわち、ログイン名およびパスワードを問い合わせるサーバへのクライアントの応答に関して、Ｈｉｄｅ＆Ｓｅｅｋはクライアントからセッション値を得て、セッション値に関連するセッションオブジェクトを同定する。次に、パイプはセッションオブジェクトの中に格納された結果を得て、それらの結果に対する到着するパラメータ名および値を認証する。到着するパラメータおよび発信されるパラメータが一致すると、クライアントはどのパラメータも操作していないと推定される。しかし、到着するパラメータおよび対応する発信されるパラメータのいずれもが一致しないとユーザは要求を操作していると推定される。したがって、到着する要求は拒絶される。

本発明の１つの実施の形態では、改良版の宣言テーブルが使用されて、テキストフィールド、例えばログインフィールドを扱う。このテーブルは、パラメータおよびその予期されるデータ型、およびデータ長、許可されたＮＵＬＬ等を含む。

図８は、本発明の実施の形態にかかるＨｉｄｅ＆Ｓｅｅｋパイプを実現する方法８００を示す。特に構成パラメータが、サポートされるＨＴＭＬのバージョンにしたがってロードされる（ステップ８０５）。次に、所望により改良版が任意でロードされる（ステップ１０１０）。到着する動作要求メッセージが解析のためにロードされ（ステップ８１５）、次に、ＨＴＴＰクッキーヘッダの中のクライアント同定のために検査される（ステップ８２０）。それに続いて、クッキーの本体が得られ（ステップ８２５）、セッション値を得るために復号される（ステップ８３０）。セッション値に関連するセッションオブジェクト（ステップ８３５）が得られる。どのセッションオブジェクトも存在しないと、空のまたは新しいセッションオブジェクトが作成される。次に、到着するメッセージが、パラメータ名およびパラメータ値にまで構文分析される（ステップ８４０）。パラメータ、値、およびそれらの組合せは、セッションオブジェクトの中に格納された情報または改良版のテーブルと比較される（ステップ８４５）。次に一致の存在が判断される（ステップ８５０）。一致が見つからないと、そのメッセージは拒絶される（ステップ８５５）全てのパラメータが一致すると、メッセージが先に進むことが許可される（ステップ８６０）。ステップ８１５−８６０は、続いて到着する要求に関して繰り返される。

図９は、本発明の実施の形態にかかる、応答メッセージに関してＨｉｄｅ＆Ｓｅｅｋパイプを実現する方法９００を示す。第１に、応答メッセージが受信され（ステップ９１０）、ロードされて（ステップ９２０）、応答がＨＴＭＬドキュメントか否かを判断する（ステップ９３０）。ＨＴＭＬでないと、応答メッセージがクライアントに送信される（ステップ９４０）。ＨＴＭＬであると、応答メッセージがパラメータに構文分析される（ステップ９５０）。全ての構文分析された情報が、セッションオブジェクトの中に格納される（ステップ９６０）。セッションオブジェクトは、新しいバスケットであるか否かを同定される（ステップ９７０）。セッションオブジェクトが新しくないと、メッセージがクライアントに送信される（ステップ９８０）。セッションオブジェクトが新しいと、そのセッションを同定する情報を含む応答メッセージにヘッダが加えられ（ステップ９９０）、次に、メッセージ全体がクライアントに送信される（ステップ９９５）。

Ｈｉｄｅ＆Ｓｅｅｋは、アプリケーションの処理を操作するリモートユーザからアプリケーションを防御する。さらに、Ｈｉｄｅ＆Ｓｅｅｋは、操作技術を含むどの要求からもアプリケーションを防御し、アプリケーションの所有者に迅速で継続した防御を提供する。

４．Ｌｏｃｋｅｒ
本発明の１つの実施の形態では、ここでは“Ｌｏｃｋｅｒ”と呼ぶ第４のパイプが１以上のアプリケーションのパスに適用される。このパイプは、ＨＴＭＬのｈｉｄｄｅｎフィールド、ＵＲＬパラメータ、等であって、それらに限定されないアプリケーションの属性を、クライアントによる変更または操作から防御する。このパイプにより、アプリケーションにより設定される属性値が、どのような変更もなくクライアントから返されることが保証される。特に、属性識別モジュールは、クライアントに送られるある属性を暗号化して、クライアントがそれらを操作することを防ぐ。本発明の１つの実施の形態では、属性識別モジュールは、属性のタイプの所定のリストを使用して、各応答メッセージの中で暗号化される特定の属性を同定する。アプリケーションの属性は、応答メッセージから抽出されず、それに相応する要求の中のクライアントにより送られた属性と後で比較するためにデータベースの中に格納されない。代わりに、暗号が使用されて、クライアントによる属性の操作を防ぐ。どのタイプの暗号化技術も使用でき、その同定および実現は当業者には明らかである。

本発明の１つの実施の形態では、Ｌｏｃｋｅｒパイプはグローバルサーバ鍵、および、各メッセージ、すなわち応答に特有の秘密鍵を使用する。特に、グローバルサーバ鍵は、セキュリティサーバに格納された１つの暗号法の鍵であり、全ての応答メッセージに共通である。メッセージ特有の秘密鍵は、応答メッセージごとにランダムに生成でき、特定のクライアント用の全ての応答メッセージ用に生成される。動作中、メッセージ特有の秘密鍵は、応答の中のアプリケーションの属性の値を暗号化するために使用される。次に、メッセージ特有の秘密鍵は、暗号化した属性およびグローバルサーバ鍵を使用して暗号化され、それらの実現は当業者には明らかであり、暗号化された形で応答に付加され、次にクライアントに送られる。アプリケーションの属性の暗号化された値を持つメッセージ特有の秘密鍵を暗号化することにより、アプリケーションの全ての属性が、クライアントにより送信され、アプリケーションサーバには変更が加えられないことが保証される。グローバルサーバ鍵により、クライアントは、暗号化された属性値を使用してメッセージ特有の秘密鍵を解読できないことが保証される。したがって、クライアントは、たとえ特定の暗号化アルゴリズムが公開されても属性を変更できない。本発明のもう１つの実施の形態では、管理者は、暗号化されないアプリケーションの属性のリストを手動で設定できる。しかし、デフォルトで、全ての検出されたアプリケーションの属性のタイプが暗号化される。

図１０Ａは、本発明の実施の形態にかかる発信された応答メッセージにＬｏｃｋｅｒパイプを実現する方法１０００を示す。具体的には、応答がロードされ（ステップ１０１０）、次に、プロトコルの規格および／または属性のタイプの所定のリストにより定められるアプリケーションの属性を検索される（ステップ１０２０）。アプリケーションの属性が見つかると（ステップ１０３０）、メッセージ特有の秘密鍵、すなわち、上に説明したように、上記応答に特有の一意の暗号法の鍵を使用して、属性の値が暗号化される（ステップ１０３５）。適切なアプリケーションの属性の全ての値を暗号化すると、上に説明したように、暗号化された属性値およびグローバルサーバ鍵を使用して、メッセージ特有の秘密鍵が暗号化される（ステップ１０４０）。メッセージ特有の秘密鍵を暗号化する際に暗号化された属性値を使用すると、追加のレベルのセキュリティが加わって、不正な者がメッセージ特有の秘密鍵を決定することを防ぐ。メッセージ特有の秘密鍵を暗号化すると、次に、それに続いて応答が変更され（ステップ１０５０）て、暗号化された属性値および暗号化されたメッセージ特有の秘密鍵を反映し、もし適用できるならば次のセキュリティパイプおよび／またはクライアントに転送される。

図１０ＢはＬｏｃｋｅｒパイプにより変更される前の典型的な応答メッセージを示す。図１０Ｃは、Ｌｏｃｋｅｒパイプにより変更されたこの典型的な応答メッセージを示し、全ての属性値は暗号化され、メッセージ特有の秘密鍵が応答に付加される。図１０Ｄは、暗号化されたおよび暗号化されていない（変更されていない）アプリケーションの元の属性値を含むＬｏｃｋｅｒパイプにより変更されたもう１つの典型的な応答メッセージを示す。暗号化されていない形に維持された元のアプリケーションの値により、例えば、クライアントがこれらの元の値（読み取り専用）を見る必要がある状況では、クライアントが見ることが許可される。

図１１は、本発明の実施の形態にかかるＬｏｃｋｅｒパイプを到着する動作要求（例えば、図１０Ａのサーバから送信された変更された応答に応じて戻る要求）に実現する方法１１００を示す。到着する動作要求は処理用にロードされる（ステップ１１１０）。パイプは、クライアントから返されるアプリケーションの属性およびそれらの対応する暗号化された値を検索する（ステップ１１２０）。暗号化されたアプリケーションの属性値およびグローバルサーバ鍵は、暗号化されたメッセージ特有の秘密鍵を復号（ステップ１１３０）するために使用される。メッセージ特有の秘密鍵の適切な復号に失敗すると、１以上の暗号化されたアプリケーションの属性値の変更があり得ることを示し、順番に警告を発し、および／または要求を完全に拒絶する（ステップ１１４５）。アプリケーションの属性値の復号に成功すると、要求は、適用可能ならば、次のセキュリティパイプに転送されるか、またはさらに処理が適用される。どのアプリケーションの属性も見つからないと、ステップ１１３０および１１４０は実行されない。

５．Ｉｎｉｇｏ
本発明の１つの実施の形態では、ここでは“Ｉｎｉｇｏ”と呼ぶ第５のパイプが１以上のアプリケーションのパスに適用される。Ｉｎｉｇｏはアプリケーションノードのブロッキングパイプであり、アプリケーションの動作要求が、アプリケーションの所有者により制限するように指定されたアプリケーションのパスに入るのを制限する。ビジネスアプリケーションが実行中の環境では、アプリケーションの所有者は、アプリケーションのパスに関するバグが見つかると、典型的に管理上の問題に直面する。しかし、アプリケーションのパスに関連するアプリケーションの実行を全て止めると、アプリケーションが実行する１以上の処理に悪影響を与える。したがって、アプリケーションの所有者は、典型的に、そのアプリケーションの中に脆弱性が知られていても、パッチが入手可能になるまでアプリケーションを動作させ続ける。Ｉｎｉｇｏパイプを実装することにより、アプリケーションの所有者は、他のアプリケーションについてはユーザが使用可能にしながら、脆弱性のあるアプリケーションのパスにアクセスできないようにできる。

図１２は、本発明の実施の形態にかかるＩｎｉｇｏパイプを実現する方法１２００を示す。アプリケーションのパスはデータ源からロードされる（ステップ１２１０）。到着する要求メッセージはロジックにロードされる（ステップ１２２０）。次にメッセージの行き先が判断され（ステップ１２３０）、ブロックするように指定されたアプリケーションのパスに対して比較される（ステップ１２４０）。一致が見つかると、そのメッセージは拒絶される（ステップ１２６０）。一致が見つからないと、そのメッセージは通過を許可される（ステップ１２５０）。

例えば、リンク上の不正確な公の情報のために、プレスリリースのディレクトリをブラウズできなくするために、
ｈｔｔｐ：／／ｗｗｗ．ｙｏｕｒｓｉｔｅ．ｃｏｍ／ｍｙｓｉｔｅ／ｐｒｅｓｓ／ｎｅｗｓ．ａｓｐ？ｎｅｗｓｉｄ＝２３，
Ｉｎｉｇｏはこのアプリケーションのパスに関する要求を同定し、要求を完全に拒絶するか、
ｈｔｔｐ：／／ｗｗｗ．ｙｏｕｒｓｉｔｅ．ｃｏｍ／ｍｙｓｉｔｅ／ｄｅｆａｕｌｔ．ｈｔｍｌ，
などの異なるプレスリリースがクライアントに返るように要求をの出力先を変更する。

Ｉｎｉｇｏパイプは、プロダクションパイプが全てのサーバ上に実装されるのを待たずに、アプリケーションの所有者に迅速なトラフィックのブロッキング能力を提供するので、脆弱性が発見されたときに、１つまたは多量のアプリケーションを管理する複雑さを和らげる。

６．Ｏｇｉｎｉ
本発明の１つの実施の形態では、ここで“Ｏｇｉｎｉ”と呼ぶ第６のパイプが、１以上のアプリケーションのパスに適用される。Ｏｇｉｎｉは、信頼できない動作要求が信頼できる環境または信頼できるネットワーク内のゾーンに転送されるのを防ぐパイプである。このパイプを実装することにより、管理者は、クライアント特有のメッセージを、許可するように指定されたアプリケーションのパスにのみ制限できる。特に、許可されたメッセージのあらかじめ定められたリストが実装される。クライアントの要求メッセージがリストの中のどれかと一致すると、動作要求が受け付けられる。一致しない場合は、動作要求が拒絶される。管理者に容易な方法を提供して、許可されたメッセージのリストを更新するために、パイプは任意で学習技術をサポートし、受け付けることができると判断された全ての到着する要求メッセージは、後で到着する要求と比較するために、メモリに格納される。

図１３はＯｇｉｎｉパイプを実現する方法１３００を示す。特に、受け付けることのできる動作要求のリストが処理手段にロードされる（ステップ１３１０）。到着するメッセージはロードされ（ステップ１３２０）、リストと比較されて（ステップ１３３０）、一致が存在するか否かを判断する（ステップ１３４０）。一致が見つかると、動作要求は通過を許可される（ステップ１３５０）。一致が見つからないと動作要求は拒絶される（ステップ１３６０）。

７．Ｍｉｌｏｂａ
本発明の１つの実施の形態では、ここではＭｉｌｏｂａと呼ぶ第７のパイプが１以上のアプリケーションのパスに適用される。Ｍｉｌｏｂａは、あらかじめ定められた式のルールにしたがって、到着するパラメータの値を認証するパイプである。例えば、オンライン書店では、顧客は、各注文で１冊から５冊の本を注文できる。書店は、ｏｒｄｅｒ＿ｑｔｙパラメータを使用して、注文された本の数を表す。Ｍｉｌｏｂａは、ユーザのｏｒｄｅｒ＿ｑｔｙパラメータ値が１から５の間の値を持つ整数データ型と一致するかを検証する。本発明の１つの実施の形態では、各パラメータのあらかじめ定められた式のルールを同定および構築するために、連続した処理の中で学習技術が実施され、以前に送信された動作要求に基づいて、あらかじめ定められたルールを更新することにより、動作要求の中の新しい受け付けることができるパラメータを同定する。

図１４は、本発明の実施の形態にかかるＭｉｌｏｂａパイプを実現する方法１４００を示す。あらかじめ定められたルールが、データ源からロードされる（ステップ１４１０）。到着する動作要求は処理手段にロードされる（ステップ１４２０）。動作要求の中に含まれたパラメータ名および値は判断される（ステップ１４３０）。パラメータの各タイプに関して、そのパラメータに関する特定のルールが、あらかじめ定められたルールから同定され（ステップ１４４０）、次に到着するパラメータ値に適用される（ステップ１４５０）。したがって、ルールが満たされるか否かが判断される（ステップ１４６０）。ルールが満たされると、パラメータ値が受け付けられる（ステップ１４７０）。ルールが満たされないと、動作要求は拒絶される（ステップ１４８０）。

８．クッキー
本発明の１つの実施の形態では、ここでクッキーと呼ぶ第８のパイプが、１以上のアプリケーションのパスに適用される。このパイプは、クライアント側（セッションベース、または永続）のクッキーが、クライアントにより変更または操作されるのを防ぐ。このパイプにより、クッキーに格納された情報がクライアントには入手不可能であるけれども、アプリケーション自体にどの変更も加えずにアプリケーションに透過になることを保証する。特に、要求およびその位置に関連するクッキーを同定するクッキーの同定は、クライアントがクッキーの同定を判断することを防ぐためにクライアント側で暗号化されている。任意のタイプの暗号化方法が使用でき、その実現は当業者には明らかである。

図１５は、本発明の実施の形態にかかる到着する動作要求に関するクッキーパイプを実現する方法１５００を示す。到着する動作要求はプロセッサにロードされる（ステップ１５１０）。パイプは、動作要求の中のプロトコル規格により定められるようにクッキーの同定を検索する（ステップ１５２０）。次に、パイプは、クッキーの同定が見つかったか否かを判断する（ステップ１５３０）。もし見つかると、クッキー情報が復号され、暗号化されたクッキー情報の代わりに、復号されたクッキー情報を用いることにより、動作要求が変更される（ステップ１５４０）。次にクッキーは次のセキュリティパイプに転送される（ステップ１５５０）。クッキー情報が見つからないと。ステップ１５４０は実行されない。

図１６は、本発明の実施の形態にかかる応答メッセージに関するクッキーパイプを実現する方法１６００を示す。応答はロードされ（ステップ１６１０）、プロトコル規格により定められるように、クッキーの同定に関して走査される（ステップ１６２０）。クッキーの同定が見つかると（ステップ１６３０）、その情報は暗号化される（ステップ１６４０）。次に、続いて応答が変更されて暗号化された値を反映する。次にメッセージが次のセキュリティパイプまたはクライアントに転送される（ステップ１６５０）。

９．ＳＯＡＰ
本発明のもう１つの実施の形態では、ＳＯＡＰパイプは、ウェブサービスが有害なクライアント要求にサービスを提供し、リモートクライアントまたは特定のクライアントが呼ぶことを認められていないサービスの要求を防止する。特にこのパイプにより、ウェブサービスが、アプリケーションの所有者により設計され、実装されたように動作し、全てのクライアントの要求が、リモートクライアントが要求することを認められているサービスのみへのアクセスを許可するだけでなく、ウェブサービスの定義およびデータ構造に一致することが保証される。

図１７は、本発明の実施の形態にかかる到着する動作要求に関してＳＯＡＰパイプを実現する方法１７００を示す。あらかじめ定められたルールがデータ源からロードされる（ステップ１７１０）。例えばＸＭＬが使用されると、有効なＸＭＬメッセージ構文、有効なＸＭＬ名前空間、動作名、動作構造、パラメータ名、およびパラメータデータタイプを指定する。到着する動作要求は、処理手段にロードされる（ステップ１７１５）。到着する要求のウェブサービスのメッセージ形式が同定される（ステップ１７２０）。次に、ウェブサービスメッセージ形式により同定されるあらかじめ定められた構文にしたがって、要求メッセージのＸＭＬ構文が検証される（ステップ１７２５）。次に、メッセージの名前空間が、あらかじめ定められたリストにしたがって検証される（ステップ１７３０）。ステップ１７２５または１７３０の検証に失敗すると、対応する要求は拒絶される（ステップ１７６０）。動作要求の中に含まれる動作名、動作構造、パラメータ名、タイプ、および値はフェッチされ（ステップ１７３５）、次に同定されるサービスに関連する特定のルールがそれらに適用される（ステップ１７４０）。したがって、ルールが満たされるか否かが判断される（ステップ１７４５）。ルールが満たされると、動作名、パラメータ名、およびパラメータ値の内部リストが、さらに他のシステムのパイプによるパラメータ値の検証用に作成され、格納される（ステップ１７５０）。パラメータリストが作成され、格納された後、要求メッセージが、値の検査のために他のパイプへ転送される（ステップ１７５５）。ルールを満たさないと動作要求が拒絶される（ステップ１７６０）。

１０．学習
本発明の１つの実施の形態では、１以上のアプリケーションのパスに適用される１以上のパイプに、学習技術が使用される。学習技術の使用により、クライアント、すなわち、統計モデルにより決定されるリクエスタにより入力される最も一般的な値によりよく一致するように、要求の中のパラメータを「微調整」できる。特に、各アプリケーションのパスに対する全ての動作要求は、集められて、仮想記憶領域に格納される。次に、入力された値のダイナミックレンジが、クライアントが送信する要求の中の各パラメータに関してつくられる。実装される統計モードに基づいて、可能性のある、すなわち最も頻繁に入力され、期待される値が計算される。さらに、パラメータの値が、アプリケーションからの応答に基づいて調整できる。

例えば、格納されたフィールド“Ｆ”の内容がリクエスタに報告を返すことを要求するデータベースの動作要求を考える。要求の９０パーセントを決定する指定された統計モデルは、９から１８の範囲内の特定のＦを求める。さらにＦをこの範囲内に制限することが所望される。この例では、９から１８の間の任意のＦ値をアプリケーションに渡すことが許可されて、実行されるけれども、２０のＦ値は、完全に拒絶されるか、または最も近い受け付けることのできる値、例えば１８等の別の値に調整される。

長期間にわたって要求されたパラメータ値および／またはアプリケーションのパスから蓄積された情報により、調整または「学習」するこの技術の能力のために、この技術は学習技術と呼ばれる。言い換えると、統計モデルは変更されないけれども、最も一般的な値の範囲は、多くの動作要求から「学習」した値によりダイナミックに変化する。例えば、元の一般的な値の範囲外の値をさらに受信すると、最も一般的な値の境界が変更されうる。学習技術は、アプリケーション層防御を強化するもう１つの方法を提供する。学習動作は、別々に、または適用可能なトンネルに関して各ウェブアプリケーションに適用できる。

本発明の１つの実施の形態では、ウェブアプリケーションは、２モードの動作、例えば、学習モードまたは有効モードを含む。学習モードでは、ウェブアプリケーションは、パイプにより決定される全てのセキュリティエラーを集める方法を使用する。各エラーに関して、ウェブアプリケーション、トンネル、アプリケーションのパス、および要求されたアプリケーションなどの動作要求のプロパティ、動作メッセージパラメータ、およびこのセキュリティイベントを判断するパイプが記録される。当該パイプに関する改良版推奨レコードが、当該パイプで作成される。改良版推奨レコードは、各パイプに適用するための学習技術によりシステム管理者に提供される構成情報を含む。有効モードの動作では、到着する動作要求の各々に関して、動作要求をパイプに渡すことにより、その動作要求が承認されたメッセージであるか否かをウェブアプリケーションが判断する。承認されているならば、その動作要求は信頼できると考えられる。承認されていないならば、その動作要求はさらなるパイプ検査にまわされる。

正規表現に関する各パラメータを同定するために、学習技術は、各パラメータ値を積算する統計的標準分布を使用する。現在の分散に基づき、アルゴリズムが、現在のパラメータの正規表現認証方法を使用する。例えば、動作要求は以下のような価格パラメータを含む。

ｘステップは、学習技術が持つ最後の正規表現を表す。パラメータの正規表現の分散が小さい時に、最終段階に到達する。

本発明は、従来のセキュリティ技術を完全にできる。例えば、本システムの１つの実施の形態では、ファイアウォールが信頼できないネットワークとセキュリティシステムの間に含まれて、そのセキュリティシステムにより、信頼できない動作要求がアプリケーション層で精査される前に、信頼できない動作要求に関してデータリンク層で、ファイアウォールがセキュリティ方式を実施できる。他の実施の形態では、発明の概念は、ＳＳＬまたはＰＫＩ等の任意の下部層セキュリティ技術と組み合わせることができる。

本発明は、いくつかの好ましい実施の形態を参照して具体的に示し説明してきたけれども、添付の請求の範囲に定義された発明の範囲から離れずに形式および詳細に関し種々の変更が可能であることは当業者であれば理解できるであろう。

３つの従来のセキュリティ技術が動作するＯＳＩ参照モデルおよびプロトコル層を示す図 本発明の実施の形態にかかるアプリケーション層のセキュリティシステムを示す図 本発明の実施の形態にかかるアプリケーション層のセキュリティシステムを示す図 本発明の実施の形態にかかるアプリケーション層のセキュリティシステムを示す図 本発明の実施の形態にかかるアプリケーション層のセキュリティシステムを示す図 本発明の実施の形態にかかるアプリケーション層のセキュリティシステムを示す図 本発明の実施の形態にかかるアプリケーション層のセキュリティ方式を示す図 本発明の実施の形態にかかるアプリケーション層のセキュリティ方式を示す図 本発明の実施の形態にかかるアプリケーション層のルーティングシステム 本発明の実施の形態にかかるアプリケーション層のルーティングシステム 本発明の実施の形態にかかるアプリケーション層のルーティングシステム 本発明の実施の形態にかかるアプリケーション層のセキュリティシステム 本発明の実施の形態にかかる第１のパイプ 本発明の実施の形態にかかる第２のパイプ 本発明の実施の形態にかかる第３のパイプ 本発明の実施の形態にかかる第３のパイプ 本発明の実施の形態にかかる第４のパイプ Ｌｏｃｋｅｒパイプにより変更される前の典型的な応答メッセージ Ｌｏｃｋｅｒパイプにより変更されたこの典型的な応答メッセージ 暗号化されたおよび暗号化されていない（変更されていない）アプリケーションの元の属性値を含むＬｏｃｋｅｒパイプにより変更されたもう１つの典型的な応答メッセージ 本発明の実施の形態にかかる第４のパイプ 本発明の実施の形態にかかる第５のパイプ 本発明の実施の形態にかかる第６のパイプ 本発明の実施の形態にかかる第７のパイプ 本発明の実施の形態にかかる第８のパイプ 本発明の実施の形態にかかる第８のパイプ 本発明の実施の形態にかかる第１０のパイプ

符号の説明

２００ アプリケーション層セキュリティシステム
２１０ 防御層
２２０ ウェブサーバ
２３０ ポート
２４０ トンネル
２５０ パイプ
２６０ ウェブアプリケーション
３００ セキュリティ方式
４００ セキュリティシステム
４１０ クライアント
４１２ 通信リンク
４２０ 要求識別モジュール
４２２ 通信リンク
４２４ 要求ルータ
４２６Ａ−Ｎ アプリケーションのパス
４３０Ａ−Ｎ パイプ
４３１ 通信リンク
４３２ 通信リンク
４３３ 通信リンク
４４０ サーバ
４４２ 通信リンク
４５０ 応答識別モジュール
４５２ 通信リンク
４５４ 応答ルータ
４５６Ａ−Ｎ アプリケーションのパス
４６０Ａ−Ｎ パイプ
４６３ 通信リンク
４６１ 通信パス
４６２ 通信チャネル
５００ セキュリティシステム
５１０ セキュリティモジュール
６００ Ｍａｒａｂｕパイプを実現する方法
７００ Ｍｉｎｉｍｅパイプを実現する方法
８００ Ｈｉｄｅ＆Ｓｅｅｋパイプを実現する方法
９００ Ｈｉｄｅ＆Ｓｅｅｋパイプを実現する方法
１０００ Ｌｏｃｋｅｒパイプを実現する方法
１１００ Ｌｏｃｋｅｒパイプを到着する動作要求に実現する方法
１２００ Ｉｎｉｇｏパイプを実現する方法
１３００ Ｏｇｉｎｉパイプを実現する方法
１４００ Ｍｉｌｏｂａパイプを実現する方法
１５００ クッキーパイプを実現する方法
１６００ クッキーパイプを実現する方法
１７００ ＳＯＡＰパイプを実現する方法

Claims (30)

1. アプリケーション層のセキュリティ方式であって、
   アプリケーションにより実行される動作要求を受信するステップ、
   上記動作要求のアプリケーションの属性を同定するステップ、
   上記同定されたアプリケーションの属性に関してアプリケーションのパスを同定するステップ、および
   上記同定されたアプリケーションのパスに対して上記動作要求を導くステップ
   を含む方法。
2. 請求項１に記載の方法であって、アプリケーションのパスを同定する上記ステップが、
   上記同定されたアプリケーションの属性と確認されたアプリケーションの属性のあらかじめ定められたリストとを比較するステップ
   を含む方法。
3. 請求項２に記載の方法であって、上記同定されたアプリケーションのパスが、上記アプリケーションへの信頼できるアプリケーションのパスである方法。
4. 請求項２に記載の方法であって、上記同定されたアプリケーションのパスがデフォルトのアプリケーションのパスである方法。
5. 請求項１に記載の方法であって、
   １以上のパイプを上記動作要求に適用するステップをさらに含み、上記１以上のパイプの数および各々のタイプが、上記同定されたアプリケーションのパスにしたがって定められる
   方法。
6. 請求項５に記載の方法であって、上記１以上のパイプの１つが、不適切なデータベース要求の構文または１以上の組み込みデータベース命令に関する上記動作要求を検査するステップを含む方法。
7. 請求項５に記載の方法であって、上記１以上のパイプの１つが、既知の脆弱性パターンに関し上記動作要求を検査するステップを含む方法。
8. 請求項５に記載の方法であって、上記１以上のパイプの１つが、
   上記同定されたアプリケーションのパスが上記アプリケーションの所有者により制限されるように指定されていると、上記動作要求をブロックするステップ
   を含む方法。
9. 請求項５に記載の方法であって、上記１以上のパイプの１つが、上記動作要求が上記アプリケーションの信頼できるネットワーク内の指定されたゾーンに転送されるのをブロックするステップを含む方法。
10. 請求項５に記載の方法であって、上記１以上のパイプの１つが、あらかじめ定められた式のルールに従って、上記動作要求のパラメータを認証するステップを含む方法。
11. 請求項５に記載の方法であって、上記１以上のパイプの１つが、上記動作要求の中の、上記アプリケーションにより設定された属性値が変更されるのを防ぐステップを含む方法。
12. 請求項５に記載の方法であって、上記１以上のパイプの１つが、上記動作要求のウェブサービスの定義およびデータ構造を認証するステップを含む方法。
13. 請求項５に記載の方法であって、上記動作要求を上記同定されたアプリケーションのパスに導く上記ステップが、アプリケーションレベルのスイッチにより実現される方法。
14. 信頼できるアプリケーションを防御するアプリケーションセキュリティシステムであって、
    上記信頼できるアプリケーションへまたは上記信頼できるアプリケーションから導かれるメッセージのアプリケーションの属性を同定し、上記同定されたアプリケーションの属性に関連するアプリケーションのパスを同定するアプリケーションの属性識別モジュール；
    各メッセージを、上記メッセージに関連する上記同定されたアプリケーションのパスにルーティングするメッセージルータ；および
    その一部が、上記同定されたアプリケーションのパスに関連し、上記メッセージを上記アプリケーションのパスにルーティングするに際して、上記メッセージに関して実施される多くのセキュリティパイプ
    を含むアプリケーションセキュリティシステム。
15. 請求項１４に記載のアプリケーションセキュリティシステムであって、上記アプリケーションの属性識別モジュールおよび上記メッセージルータがアプリケーションレベルのスイッチの中で使用されるアプリケーションセキュリティシステム。
16. 請求項１４に記載のアプリケーションセキュリティシステムであって、確認されたメッセージのリストを含み、上記メッセージを上記確認されたメッセージのリストと比較して、上記メッセージが確認されたメッセージか否かを同定するメッセージ識別モジュールをさらに含むアプリケーションセキュリティシステム。
17. 請求項１６に記載のアプリケーションセキュリティシステムであって、上記メッセージルータが、確認されたメッセージを、０個のセキュリティパスが実装されたアプリケーションのパスにルーティングするアプリケーションセキュリティシステム。
18. アプリケーションセキュリティ方式であって、
    信頼できるアプリケーションへまたは信頼できるアプリケーションから導かれるメッセージのアプリケーションの属性を分類するステップ；および
    上記アプリケーションの属性の上記分類に基づいて、あらかじめ定められた数のセキュリティパイプを上記メッセージに関して実装するステップ
    を含む方法。
19. 請求項１８に記載のアプリケーションセキュリティ方式であって、上記メッセージが要求であり、
    上記要求を確認された要求のリストと比較し、上記要求が上記確認された要求のリストの１つと一致すると、上記あらかじめ定められた数が０であるステップ
    をさらに含む方法。
20. 請求項１９に記載のアプリケーションセキュリティ方式であって、もう１つの確認された要求を持つ上記確認された要求のリストをダイナミックに更新するステップをさらに含む方法。
21. メッセージの中の少なくとも１つのアプリケーションの属性を防御する方法であって、
    少なくとも１つのアプリケーションの属性を含み、受信モジュールに導かれたメッセージを傍受するステップ；
    上記少なくとも１つのアプリケーションの属性を暗号化して、暗号化されたアプリケーションの属性を生成するステップ；
    上記少なくとも１つのアプリケーションの属性の代わりに上記暗号化されたアプリケーションの属性を用いることにより上記メッセージを変更するステップ；および
    上記変更されたメッセージを上記受信モジュールに転送するステップ
    を含む方法。
22. 請求項２１に記載の方法であって、上記受信モジュールがアプリケーションのクライアントである方法。
23. 請求項２１に記載の方法であって、暗号化する上記ステップが第１の暗号鍵を使用して実行される方法。
24. 請求項２３に記載の方法であって、第２の暗号鍵を使用して上記第１の暗号鍵を暗号化するステップをさらに含む方法。
25. 請求項２４に記載の方法であって、上記暗号化された第１の暗号鍵を上記変更されたメッセージに付加するステップをさらに含む方法。
26. 請求項２１に記載の方法であって、上記第１の暗号鍵を使用して上記暗号化されたアプリケーションの属性を復号するステップをさらに含む方法。
27. アプリケーションを防御する方法であって、メッセージの中の少なくとも１つのアプリケーションの属性が、
    受信モジュールに導かれ、少なくとも１つの暗号化されたアプリケーションの属性を含むメッセージを傍受するステップ；
    上記少なくとも１つの暗号化されたアプリケーションの属性を復号するステップ；
    上記少なくとも１つの暗号化されたアプリケーションの属性の代わりに上記復号されたアプリケーションの属性を用いることにより上記メッセージを変更するステップ；および
    上記変更されたメッセージを上記受信モジュールに転送するステップ
    を含む方法。
28. 請求項２７に記載の方法であって、上記受信モジュールがアプリケーションである方法。
29. 請求項２７に記載の方法であって、上記復号ステップが、第１の暗号鍵を使用して実施される方法。
30. 請求項２９に記載の方法であって、上記第１の暗号鍵が、暗号化されたフォームの中の上記傍受されたメッセージから得られ、第２の暗号鍵を使用して上記暗号化された第１の暗号鍵を復号するステップをさらに含む方法。

Images