(57)【要約】図２Ａは、本発明の一実施形態によるアプリケーション・レイヤ・セキュリティ・システム（２００）を示す図である。具体的には、保護レイヤ（２１０）が、信頼できない環境と、１又は２以上のウェブ・サーバ（２２０）上に常駐する１又は２以上のアプリケーションを含む信頼できる環境の間で実施される。保護レイヤ（２１０）が、信頼できないソースを介して送信された悪意のあるオペレーション要求から、信頼できるアプリケーションを保護する。それぞれの着信オペレーション要求が、アプリケーションによって実施すべき、複数の要求されたコマンド、パラメータ、パラメータ値を有することができる。着信オペレーション要求を、１又は２以上のポート（２３０）を介して外部ＨＴＴＰトラフィックとして受信できる。セキュリティ・システム（２００）が、単一の、分散型の、又は共用アプリケーションをサポートするためのトンネル（２４０）を有する。トンネル（２４０）は、信頼できない環境と信頼できる環境の間の、プロトコル・ベースの、たとえばＴＣＰ／ＩＰ接続である。それぞれのトンネル（２４０）が、たとえば、ＨＴＴＰ、ＨＴＴＰｓ、ＳＯＡＰなどの特定のアプリケーション・プロトコルを実施し確認できる。システム（２００）が、アプリケーションの機能を保護するか又はモニタするために提供される１又は２以上のパイプ（２５０）を更に有し、システムはウェブ・アプリケーション（２６０）も有する。更に、ウェブ・アプリケーション（２６０）が、パイプ実行を特定のアプリケーション経路にカストマイズできる。
2004533676.tif 000002
【特許請求の範囲】
【請求項１】
信頼できない環境から受信された違法又は有害なオペレーション要求を実行することからアプリケーションを保護するための方法であって、
１又は２以上のパイプをオペレーション要求のアプリケーション−レイヤ・コンテンツに適用して、前記オペレーション要求が、前記アプリケーションの環境に対して違法又は有害であるか否かを判断するステップと、
前記アプリケーションが違法又は有害なオペレーション要求を実行するのを防止するステップと、
を含むことを特徴とする方法。
【請求項２】
前記違法及び有害なオペレーション要求は、前記アプリケーション、前記アプリケーション以外のアプリケーション、信頼できるネットワーク、１又は２以上のデータ・ファイル、メモリ、バッファ、性能、秘密情報、ハードウェア、ソフトウェア、データベース、情報サーバ、それらの任意の組合せからなる群から選択されるコンピュータ・システム要素又はパラメータにダメージを生じさせるか、該コンピュータ・システム要素又はパラメータに対する無許可のアクセスを可能にする請求項１記載の方法。
【請求項３】
前記違法及び有害なオペレーション要求が、
データベースの改ざん、インターネット情報サーバの脆弱性に対する攻撃、アプリケーションの脆弱性に対する攻撃、ＵＲＬの改ざん、アプリケーション要求の改ざん、ビジネス・プロセスの改ざん、ポイゾニング攻撃、アプリケーション・パラメータの改ざん、それらの任意の組合せからなる群から選択される請求項１記載の方法。
【請求項４】
前記防止するステップが、
前記違法又は有害なオペレーション要求を拒否するステップを含む請求項１記載の方法。
【請求項５】
前記防止するステップが、
前記違法又は有害なオペレーション要求を正当な又は無害なオペレーション要求に修正するステップを含む請求項１記載の方法。
【請求項６】
前記防止するステップが、
前記違法又は有害なオペレーション要求を正当な又は無害なオペレーション要求に置換するステップを含む請求項１記載の方法。
【請求項７】
前記１又は２以上のパイプのうちの１つが、データベースの改ざんを引き起こす埋め込まれたコマンドの存在についてチェックするステップを含む請求項１記載の方法。
【請求項８】
前記埋め込まれたコマンドが、ＳＱＬベースのコマンドの一部分である請求項７記載の方法。
【請求項９】
前記１又は２以上のパイプのうちの１つが、
前記オペレーション要求を１又は２以上の式に解析するステップと、
状態の自動化を構築するステップと、
第１のアルファベット内で定義されていない不適正な構文及びキャラクタのための前記１又は２以上の式を検査するステップと、
前記状態の自動化を前記オペレーション要求に適用するステップとを含む請求項７記載の方法。
【請求項１０】
前記アルファベットが、文字、ディジット、符号化されたキャラクタと、文字のブロックと、前記ブロックのグループと、それらの任意の組合せとからなる群から選択される請求項９記載の方法。
【請求項１１】
前記１又は２以上のパイプのうちの１つが、
格納された既知の脆弱性パターンに対して前記オペレーション要求を比較して、一致を判断するステップと、
一致が発見された場合に、前記オペレーション要求を阻止するステップとを含む請求項１記載の方法。
【請求項１２】
追加の脆弱性パターンとともに前記格納された脆弱性パターンを更新するステップを更に含む請求項１１記載の方法。
【請求項１３】
前記比較するステップが、
前記オペレーション要求内のあらゆる連続する特定の数のキャラクタをｎビットのバイナリ・コードに変換するステップと、
前記オペレーション要求内の前記あらゆる連続する特定の数のキャラクタのためのハッシュ値を計算するステップと、
あらゆるハッシュ値を、脆弱性パターンを表す格納されたハッシュ値と比較するステップとを含む請求項１１記載の方法。
【請求項１４】
ｎが８であり、前記特定の数が４である請求項１３記載の方法。
【請求項１５】
前記１又は２以上のパイプのうちの１つが、
前記オペレーション要求をゾーンに分割するステップと、
格納された既知の脆弱性パターンに対して前記ゾーンのそれぞれを比較して、一致を判断するステップと、
一致が発見された場合に、前記オペレーション要求を阻止するステップとを含む請求項１記載の方法。
【請求項１６】
前記ゾーンが、
前記オペレーション要求のＵＲＩから構成される第１のゾーンと、
前記オペレーション要求のクエリ・ストリングから構成される第２のゾーンと、
前記オペレーション要求のヘッダから構成される第３のゾーンと、
前記オペレーション要求の本体から構成される第４のゾーンとを有する請求項１５記載の方法。
【請求項１７】
正当な又は無害なオペレーション要求を前記アプリケーションに送信するステップと、
前記正当な又は無害なオペレーション要求への返信を受信するステップとを更に含む請求項１記載の方法。
【請求項１８】
前記１又は２以上のパイプのうちの１つが、
前記返信内に含まれるパラメータ名及び値を判断するステップと、
前記返信への応答を受信するステップと、
前記応答を前記パラメータ名及び値と比較して、前記応答が前記返信への有効な応答であるか否かを判断するステップと、
前記応答が前記返信への有効な応答でなかった場合に、前記応答が前記アプリケーションへ通過することを却下するステップとを含む請求項１７記載の方法。
【請求項１９】
単一のクライアントを識別して、前記アプリケーションとインタラクトするステップと、
前記返信内の第１の組のパラメータ名及び値を判断するステップと、
前記返信に応答して前記クライアントから第２のオペレーション要求を受信するステップと、
前記第２のオペレーション要求内のパラメータ名及び値を判断するステップとを更に含む請求項１７記載の方法。
【請求項２０】
前記１又は２以上のパイプのうちの１つが、
前記アプリケーションのアプリケーション経路を制限されたものとして指定するステップと、
前記オペレーション要求の宛先を判断するステップと、
前記宛先が前記指定されたアプリケーション経路に等しい場合は、前記オペレーション要求を阻止するステップとを含む請求項１記載の方法。
【請求項２１】
前記１又は２以上のパイプのうちの１つが、
受入れ可能なオペレーション要求のリストをコンパイルするステップと、
前記受入れ可能なオペレーション要求のリストに対して前記オペレーション要求を比較するステップとを含む請求項１記載の方法。
【請求項２２】
前記１又は２以上のパイプのうちの１つが、
前記オペレーション要求内に含まれているパラメータ値を判断するステップと、
前記パラメータ・タイプに基づいて定義済規則を前記パラメータに適用するステップとを含み、
前記定義済規則が、１又は２以上の受入れ可能なパラメータ値を定義する請求項１記載の方法。
【請求項２３】
前記１又は２以上のパイプのうちの１つが、
前記オペレーション要求に関連付けられたクッキーを識別するステップと、
前記クッキーの一部分を解読するステップと、
前記解読された一部分を反映するよう前記クッキーを修正するステップとを含む請求項１記載の方法。
【請求項２４】
前記１又は２以上のパイプのうちの１つが、
前記返信に関連付けられたクッキーを識別するステップと、
前記クッキーの一部分を暗号化するステップと、
前記暗号化された一部分を反映するよう前記クッキーを修正するステップとを含む請求項１７記載の方法。
【請求項２５】
複数のオペレーション要求を受信するステップと、
仮想記憶装置内に前記複数のオペレーション要求を格納するステップと、
前記複数のオペレーション要求内のそれぞれのパラメータのためのダイナミックな範囲の入力された値を構築するステップと、
それぞれの値のために前記ダイナミックな範囲の入力された値に適用された統計モデルに基づいて、それぞれのパラメータのための受入れ可能な範囲の値を計算するステップと、後続のオペレーション要求を受信するステップと、
前記後続のオペレーション要求内のパラメータ値を識別するステップと、
前記後続のオペレーション要求内の前記パラメータ値が前記受入れ可能な範囲の値内であるか否かを判断するステップとを更に含む請求項１記載の方法。
【請求項２６】
後続のオペレーション要求内の前記パラメータ値を前記ダイナミックな範囲に追加するステップと、
前記統計モデルを適用することにより、それぞれのパラメータのための前記受入れ可能な範囲の値を調整するステップとを更に含む請求項２５記載の方法。
【請求項２７】
前記１又は２以上のパイプのうちの１つが、
前記オペレーション要求のサービス名を識別するステップと、
前記サービス名に関連付けられたウェブ・サービス定義をロードするステップと、
前記ウェブ・サービス定義に基づく規則を前記オペレーション要求に適用するステップとを含む請求項１記載の方法。
【請求項２８】
アプリケーションが認証されたオペレーションの範囲外で実行するのを防止するための方法であって、
オペレーション要求内の１又は２以上のパラメータを識別するステップと、
それぞれのパラメータのためのアプリケーション経路を決定するステップと、
１又は２以上のパイプをそれぞれのパラメータに適用するステップとを含み、それぞれのパラメータに適用されたパイプの数及びタイプが、パラメータの前記決定されたアプリケーション経路に基づく方法。
【請求項２９】
指定された通信プロトコルに従って、前記オペレーション要求をフォーマットされたメッセージにフォーマットするステップと、
前記フォーマットされたメッセージを索引付けするステップと、
前記フォーマットされたメッセージを格納するステップと、
符号化スキームに従って、前記フォーマットされたメッセージを内部メッセージに翻訳するステップとを更に含み、前記指定された通信プロトコルが、ＨＴＴＰ、ＨＴＴＰｓ、ＨＴＴＰｄ、ＷｅｂＤＡＶ、ＳＯＡＰからなる群から選択される請求項２８記載の方法。
【請求項３０】
前記符号化スキームがユニコードである請求項２９に記載の方法。
【請求項３１】
前記１又は２以上のパイプのうちの１つが、
オペレーション要求を１又は２以上の式に解析するステップと、
状態の自動化を構築するステップと、
第１のアルファベット内に定義されていない不適正な構文及びキャラクタのための前記１又は２以上の式を検査するステップと、
前記状態の自動化を前記オペレーション要求に適用するステップとを含む請求項２８記載の方法。
【請求項３２】
前記アルファベットが、
文字、ディジット、符号化されたキャラクタと、文字のブロックと、前記ブロックのグループと、それらの組合せとからなる群から選択される請求項３１記載の方法。
【請求項３３】
前記１又は２以上のパイプのうちの１つが、
格納された既知の脆弱性パターンに対して前記オペレーション要求を比較して、一致を判断するステップと、
前記一致が発見された場合に前記オペレーション要求を阻止するステップとを含む請求項２８記載の方法。
【請求項３４】
追加の脆弱性パターンとともに前記格納された脆弱性パターンを更新するステップを更に含む請求項３３記載の方法。
【請求項３５】
前記比較するステップが、
前記オペレーション要求内のあらゆる連続する特定の数のキャラクタをｎビットのバイナリ・コードに変換するステップと、
前記オペレーション要求内の前記あらゆる連続する特定の数のキャラクタのためのハッシュ値を計算するステップと、
脆弱性パターンを表す格納されたハッシュ値にあらゆるハッシュ値を比較するステップとを含む請求項２８記載の方法。
【請求項３６】
前記ｎビットのｎが８であり、前記特定の数が４である請求項３５記載の方法。
【請求項３７】
前記１又は２以上のパイプのうちの１つが、
オペレーション要求をゾーンに分割するステップと、
格納された既知の脆弱性パターンに対して前記ゾーンのそれぞれを比較して、一致を判断するステップと、
前記一致が発見された場合に、前記オペレーション要求を阻止するステップとを含む請求項２８記載の方法。
【請求項３８】
前記ゾーンが、
前記オペレーション要求のＵＲＩから構成される第１のゾーンと、
前記オペレーション要求のクエリ・ストリングから構成される第２のゾーンと、
前記オペレーション要求のヘッダから構成される第３のゾーンと、
前記オペレーション要求の本体から構成される第４のゾーンとを有する請求項３７記載の方法。
【請求項３９】
正当な又は無害なオペレーション要求を前記アプリケーションに送信するステップと、
前記正当な又は無害なオペレーション要求への返信を受信するステップとを更に含む請求項２８記載の方法。
【請求項４０】
前記１又は２以上のパイプのうちの１つが、
前記返信内に含まれている第１の組の内部アプリケーション経路及びパラメータ値を判断するステップと、
前記返信への応答を受信するステップと、
前記応答内に含まれている第２の組のアプリケーション経路及びパラメータ値を判断するステップと、
前記第２の組を前記第１の組と比較して、前記応答が前記返信への有効な応答であるか否かを判断するステップと、
前記応答が前記返信への有効な応答でなかった場合に、前記応答が前記アプリケーションに通過することを却下するステップとを含む請求項３９記載の方法。
【請求項４１】
前記１又は２以上のパイプのうちの１つが、
単一のクライアントを識別して、前記アプリケーションとインタラクトするステップと、
前記返信内の第１の組のパラメータ名及び値を判断するステップと、
前記返信に応答して前記クライアントから第２のオペレーション要求を受信するステップと、
前記第２のオペレーション要求内の第２の組のパラメータ名及び値を判断するステップと、
前記第１の組が前記第２の組に一致した場合にのみ、前記第２の要求を前記アプリケーションに転送するステップとを含む請求項３９記載の方法。
【請求項４２】
前記１又は２以上のパイプのうちの１つが、
前記アプリケーションのアプリケーション経路を制限されたものとして指定するステップと、
前記オペレーション要求の宛先を判断するステップと、
前記宛先が前記指定されたアプリケーション経路に等しい場合に、前記オペレーション要求を阻止するステップとを含む請求項２８記載の方法。
【請求項４３】
前記１又は２以上のパイプのうちの１つが、
受入れ可能なオペレーション要求のリストをコンパイルするステップと、
前記受入れ可能なオペレーション要求のリストに前記オペレーション要求を比較するステップとを含む請求項２８記載の方法。
【請求項４４】
前記１又は２以上のパイプのうちの１つが、
前記オペレーション要求内に含まれているパラメータ値を判断するステップと、
前記パラメータ・タイプに基づいて定義済規則を前記パラメータに適用するステップとを含み、
前記定義済規則が、１又は２以上の受入れ可能なパラメータ値を定義する請求項２８記載の方法。
【請求項４５】
前記１又は２以上のパイプのうちの１つが、
前記オペレーション要求に関連付けられたクッキーを識別するステップと、
前記クッキーの一部分を解読するステップと、
前記解読された一部分を反映するよう前記クッキーを修正するステップとを含む請求項２８記載の方法。
【請求項４６】
前記１又は２以上のパイプのうちの１つが、
前記返信に関連付けられたクッキーを識別するステップと、
前記クッキーの一部分を暗号化するステップと、
前記暗号化された一部分を反映するよう前記クッキーを修正するステップとを含む請求項３９記載の方法。
【請求項４７】
前記１又は２以上のパイプのうちの１つが、
仮想記憶装置内に前記複数のオペレーション要求を格納するステップと、
前記複数のオペレーション要求内のそれぞれのパラメータのためのダイナミックな範囲の入力された値を構築するステップと、
それぞれの値のために前記ダイナミックな範囲の入力された値に適用された統計モデルに基づいて、それぞれのパラメータのための受入れ可能な範囲の値を計算するステップと、後続のオペレーション要求を受信するステップと、
前記後続のオペレーション要求内のパラメータ値を識別するステップと、
前記後続のオペレーション要求内の前記パラメータ値が前記受入れ可能な範囲の値内であるか否かを判断するステップとを含む請求項２８記載の方法。
【請求項４８】
後続のオペレーション要求内の前記パラメータ値をダイナミックな範囲に追加するステップと、
前記統計モデルを適用することにより、それぞれのパラメータのための前記受入れ可能な範囲の値を調整するステップとを更に含む請求項４７記載の方法。
【請求項４９】
前記１又は２以上のパイプのうちの１つが、
前記オペレーション要求のサービス名を識別するステップと、
前記サービス名に関連付けられたウェブ・サービス定義をロードするステップと、
前記ウェブ・サービス定義に基づく規則を前記オペレーション要求に適用するステップとを含む請求項２８記載の方法。
【請求項５０】
アプリケーションと信頼できないコンピュータ環境の間でアプリケーション・セキュリティ・レイヤを実施するためのシステムであって、
１又は２以上のパラメータを有するアプリケーション・オペレーション要求を受信するための手段と、
前記１又は２以上のパラメータを識別するための識別モジュールと、
経路設定スキームに従って、前記１又は２以上のパラメータのそれぞれを１又は２以上のアプリケーション経路に経路設定するためのルータ・モジュールとを備えたシステム。
【請求項５１】
前記オペレーション要求を、前記アプリケーションによって使用されたデータ・フォーマットにフォーマットするための手段を更に備えた請求項５０記載のシステム。
【請求項５２】
前記データ・フォーマットが、
ＨＴＴＰ、ＨＴＴＰｓ、ＨＴＴＰｄ、ＷｅｂＤＡＶ、ＳＯＡＰからなる群から選択される請求項５１記載のシステム。
【請求項５３】
前記受信手段が、待ち行列に入れられたソケット・サーバである請求項５０に記載のシステム。
【請求項５４】
１又は２以上のパイプを実施する論理を更に有し、いくつかの前記１又は２以上のパイプがそれぞれのアプリケーション経路に適用される請求項５０記載のシステム。
【請求項５５】
前記数が、それぞれのアプリケーション経路に依存する請求項５４記載のシステム。
【請求項５６】
アプリケーションと信頼できないコンピュータ環境の間でアプリケーション・セキュリティ・レイヤを実施するためのシステムであって、
アプリケーションのためのオペレーション要求を受信するための手段と、
前記オペレーション要求のための宛先アプリケーション・ノードを決定するための手段と、
１又は２以上のパイプを前記オペレーション要求に適用する手段とを含み、前記オペレーション要求に適用された数及びタイプのパイプが、前記オペレーション要求の前記決定された宛先ノードに基づくシステム。
【請求項５７】
前記アプリケーションによって使用されるデータ・フォーマットに前記オペレーション要求をフォーマットするための手段を更に含み、前記データ・フォーマットが、ＨＴＴＰ、ＨＴＴＰｓ、ＨＴＴＰｄ、ＷｅｂＤＡＶ、ＳＯＡＰからなる群から選択される請求項５６記載のシステム。
【請求項５８】
符号化スキームに従って前記オペレーション要求を符号化するための符号器を更に備え、前記符号化スキームがユニコードである請求項５６記載のシステム。
【請求項５９】
ファイアウォールを更に有する請求項５６記載のシステム。
【請求項６０】
１又は２以上のアプリケーションが意図されたオペレーションの範囲外で実行するのを防止するためのコンピュータ実行可能命令を有するコンピュータ読取り可能媒体であって、
命令が、
アプリケーション・オペレーション要求内の１又は２以上のパラメータを識別するステップと、
それぞれのパラメータのためのアプリケーション経路を決定するステップと、
１又は２以上のパイプをそれぞれのパラメータに適用するステップとを容易にし、
それぞれのパラメータに適用された数及びタイプのパイプが、パラメータの前記決定されたアプリケーション経路に基づくコンピュータ読取り可能媒体。
【請求項６１】
前記１又は２以上のパイプのうちの１つが、
前記パラメータを前記決定されたアプリケーション経路に経路設定するステップを含む請求項６０記載のコンピュータ読取り可能媒体。
【請求項６２】
命令が、前記アプリケーション経路が決定されていない場合に前記パラメータをデフォルト・アプリケーション経路に経路設定するステップを更に容易にする請求項６０記載のコンピュータ読取り可能媒体。
【請求項６３】
命令が、
指定された通信プロトコルに従って、それぞれのオペレーション要求をフォーマットされたメッセージにフォーマットするステップと、
前記フォーマットされたメッセージを索引付けするステップと、
前記フォーマットされたメッセージのコピーを格納するステップと、
符号化スキームに従って前記フォーマットされたメッセージを内部メッセージに翻訳するステップとを更に容易にし、
前記符号化スキームがユニコードである請求項６０記載のコンピュータ読取り可能媒体。
【請求項６４】
前記指定された通信プロトコルが、
ＨＴＴＰ、ＨＴＴＰｓ、ＨＴＴＰｄ、ＷｅｂＤＡＶ、ＳＯＡＰからなる群から選択される請求項６３記載のコンピュータ読取り可能媒体。
【請求項６５】
前記１又は２以上のパイプのうちの１つが、
オペレーション要求を１又は２以上の式に解析するステップと、
状態の自動化を構築するステップと、
第１のアルファベット内に定義されていない不適正な構文及びキャラクタのための前記１又は２以上の式を検査するステップと、
前記状態の自動化を前記オペレーション要求に適用するステップとを含む請求項６０記載のコンピュータ読取り可能媒体。
【請求項６６】
前記アルファベットが、
文字、ディジット、符号化されたキャラクタと、文字のブロックと、前記ブロックのグループと、それらの組合せとからなる群から選択される請求項６５記載のコンピュータ読取り可能媒体。
【請求項６７】
前記１又は２以上のパイプのうちの１つが、
格納された既知の脆弱性パターンに対して前記オペレーション要求を比較して、一致を判断するステップと、
前記一致が発見された場合に前記オペレーション要求を阻止するステップと
を含む請求項６０記載のコンピュータ読取り可能媒体。
【請求項６８】
命令が、追加の脆弱性パターンとともに前記格納された脆弱性パターンを更新するステップを更に容易にする請求項６０記載のコンピュータ読取り可能媒体。
【請求項６９】
前記比較するステップが、
前記オペレーション要求内のあらゆる連続する特定の数のキャラクタをｎビットのバイナリ・コードに変換するステップと、
前記オペレーション要求内の前記あらゆる連続する特定の数のキャラクタのためのハッシュ値を計算ステップと、
脆弱性パターンを表す格納されたハッシュ値に対してあらゆるハッシュ値を比較するステップとを含む請求項６５記載のコンピュータ読取り可能媒体。
【請求項７０】
前記ｎビットのｎが８であり、前記特定の数が４である請求項６９記載のコンピュータ読取り可能媒体。
【請求項７１】
前記１又は２以上のパイプのうちの１つが、
オペレーション要求をゾーンに分割するステップと、
格納された既知の脆弱性パターンに対して前記ゾーンのそれぞれを比較して、一致を判断するステップと、
前記一致が発見された場合に、前記オペレーション要求を阻止するステップとを含む請求項６０記載のコンピュータ読取り可能媒体。
【請求項７２】
前記ゾーンが、
前記オペレーション要求のＵＲＩから構成される第１のゾーンと、
前記オペレーション要求のクエリ・ストリングから構成される第２のゾーンと、
前記オペレーション要求のヘッダから構成される第３のゾーンと、
前記オペレーション要求の本体から構成される第４のゾーンとを有する請求項７１記載のコンピュータ読取り可能媒体。
【請求項７３】
命令が、
正当な又は無害なオペレーション要求を前記アプリケーションに送信するステップと、
前記正当な又は無害なオペレーション要求への返信を受信するステップとを更に容易にする請求項６０記載のコンピュータ読取り可能媒体。
【請求項７４】
前記１又は２以上のパイプのうちの１つが、
前記返信内に含まれている第１の組の内部アプリケーション経路及びパラメータ値を判断するステップと、
前記返信への応答を受信するステップと、
前記応答内に含まれている第２の組の内部アプリケーション経路及びパラメータ値を判断するステップと、
前記第２の組を前記第１の組と比較して、前記応答が前記返信への有効な応答であるか否かを判断するステップと、
前記応答が前記返信への有効な応答でなかった場合に、前記応答が前記アプリケーションに通過することを却下するステップとを含む請求項６０記載のコンピュータ読取り可能媒体。
【請求項７５】
前記１又は２以上のパイプのうちの１つが、
前記返信内の第１の組のパラメータ名及び値を判断するステップと、
前記返信に応答して前記クライアントから第２のオペレーション要求を受信するステップと、
前記第２のオペレーション要求内の第２の組のパラメータ名及び値を判断するステップと、
前記第１の組が前記第２の組に一致した場合にのみ、前記第２の要求を前記アプリケーション転送するステップとを含む請求項６０に記載のコンピュータ読取り可能媒体。
【請求項７６】
前記１又は２以上のパイプのうちの１つが、
前記アプリケーションのアプリケーション経路を制限されたものとして指定するステップと、
前記オペレーション要求の宛先を判断するステップと、
前記宛先が前記指定されたアプリケーション経路に等しい場合に前記オペレーション要求を阻止するステップとを含む請求項６０記載のコンピュータ読取り可能媒体。
【請求項７７】
前記１又は２以上のパイプのうちの１つが、
受入れ可能なオペレーション要求のリストをコンパイルするステップと、
前記受入れ可能なオペレーション要求のリストに前記オペレーション要求を比較するステップとを含む請求項６０記載のコンピュータ読取り可能媒体。
【請求項７８】
前記１又は２以上のパイプのうちの１つが、
前記オペレーション要求内に含まれているパラメータ値を判断するステップと、
前記パラメータ・タイプに基づいて定義済規則を前記パラメータに適用するステップとを含み、
前記定義済規則が、１又は２以上の受入れ可能なパラメータ値を定義する請求項６０記載のコンピュータ読取り可能媒体。
【請求項７９】
前記１又は２以上のパイプのうちの１つが、
前記オペレーション要求に関連付けられたクッキーを識別するステップと、
前記クッキーの一部分を解読するステップと、
前記解読された一部分を反映するよう前記クッキーを修正するステップとを含む請求項６０記載のコンピュータ読取り可能媒体。
【請求項８０】
前記１又は２以上のパイプのうちの１つが、
前記返信に関連付けられたクッキーを識別するステップと、
前記クッキーの一部分を暗号化するステップと、
前記暗号化された一部分を反映するよう前記クッキーを修正するステップとを含む請求項７３記載のコンピュータ読取り可能媒体。
【請求項８１】
前記１又は２以上のパイプのうちの１つが、
仮想ディレクトリ内に前記複数のオペレーション要求を格納するステップと、
前記複数のオペレーション要求内のそれぞれのパラメータのためのダイナミックな範囲の入力された値を構築するステップと、
それぞれの値のために前記ダイナミックな範囲の入力された値に適用された統計モデルに基づいて、それぞれのパラメータのための受入れ可能な範囲の値を計算するステップと、後続のオペレーション要求を受信するステップと、
前記後続のオペレーション要求内のパラメータ値を識別するステップと、
前記後続のオペレーション要求内の前記パラメータ値が前記受入れ可能な範囲の値内であるか否かを判断するステップとを含む請求項６０記載のコンピュータ読取り可能媒体。
【請求項８２】
後続のオペレーション要求内の前記パラメータ値をダイナミックな範囲に追加するステップと、
前記統計モデルを適用することにより、それぞれのパラメータのための前記受入れ可能な範囲の値を調整するステップとを更に含む請求項８１記載のコンピュータ読取り可能媒体。
【請求項８３】
前記１又は２以上のパイプのうちの１つが、
前記オペレーション要求のサービス名を識別するステップと、
前記サービス名に関連付けられたウェブ・サービス定義をロードするステップと、
前記ウェブ・サービス定義に基づく規則を前記オペレーション要求に適用するステップとを含む請求項６０記載のコンピュータ読取り可能媒体。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、情報セキュリティに関し、具体的には、信頼できるコンピュータ・アプリケーションを、未知の又は信頼できないソースから発信される違法又は有害なオペレーション要求を実行することから保護するためのアプリケーション・レイヤ・セキュリティ方法及びシステムに関する。
【背景技術】
【０００２】
インターネットの容易さ、アクセス可能性、便利さにより、人々がコンピュータを使用し、情報にアクセスする方法が急激に変わってきた。しばしば「ウェブ」と呼ぶワールド・ワイド・ウェブ（「ＷＷＷ」）は、インターネット上で情報を検索するための最も人気のある手段の１つである。ウェブにより、ユーザは、世界の各地に置かれているサーバからハイパーテキスト転送プロトコル（「ＨＴＴＰ」）を介して検索されるインターリンクされたハイパーテキスト・ドキュメントなどのほぼ無数のリソースにアクセスすることができる。ウェブは基本的なクライアント−サーバ・フォーマットで動作し、サーバは、ウェブ・ドキュメント又はバイナリ・オブジェクトを格納し、それをネットワーク上のクライアント・コンピュータに送信するなど、一定の方式でリソースを実行する専用コンピュータ又は個々のコンピュータ・アプリケーションである。たとえば、ユーザが、検索された情報を表示したり、又は所望の方式で動作するようサーバ上のアプリケーションに要求したりするために、ウェブ・ブラウザを通じてサーバとインタラクトできる。
【０００３】
ウェブ・ページと呼ぶウェブ上のドキュメントは、一般に、ハイパーテキスト・マークアップ言語（「ＨＴＭＬ」）又は同様の言語で書かれ、ファイル又はリソースにアクセスできる特定のマシン及びパス名を指定するユニフォーム・リソース・ロケータ（「ＵＲＬ」）によって識別される。ＨＴＭＬドキュメント内に埋め込まれた、しばしばタグと呼ぶコードが、ドキュメント内の特定の語及び画像をＵＲＬに関連づけ、その結果、ユーザがキーを押したりマウスをクリックしたりすることにより、別のファイル又はページにアクセスできるようになる。これらのファイルは、一般に、テキスト、画像、ビデオ、オーディオ、及び、ユーザがハイパリンクをクリックすることによって起動した場合に実行する、たとえばＪａｖａやＡｃｔｉｖｅＸで書かれた、アプレット又は他の埋め込まれたソフトウェア・プログラムを含む。ウェブ・ページを見ているユーザが、たとえば、ユーザにより供給された要求情報をフォームを使用してサーバに転送し、ファイル転送プロトコル（「ＦＴＰ」）を介してファイルをダウンロードし、チャット・ルームでのユーザ参加を容易にし、安全な商取引を行い、ウェブ・ページ上のリンクを使用することにより電子メールを介してメッセージを他のユーザに送信するコンポーネントとインタラクトすることもできる。
【０００４】
一般に、ユーザの望みを合法化し、ウェブ・サイトを見ごたえのある又は人気のあるものにするようなコンポーネントがまた、サーバ及び周囲のネットワーク環境を、悪意のある、無責任な、又は犯罪を犯す意図のある個人からの攻撃に対して脆弱なものにすることがある。これは、「ウェブ・ハッキング」と呼ばれ、一般に、サーバ・アプリケーション自体を通じてウェブ設計の間違いや脆弱性につけこむことに関係する。ウェブ・ハッキングは、攻撃が一般にアプリケーション・レイヤ・プロトコルを介して行われるので、これまでのシステムやアプリケーションのハッキングとは異なる。一般に、クライアントが、ウェブ・ページを通じてサーバ・アプリケーションと直接に話したりインタラクトすることが容易になればなる程、誰かがそれらのアプリケーションにハッキングすることが容易になる。代表的な攻撃には、グラフィックスを削除しそれらを不正に細工した、時にはけばけばしいグラフィックスに置換することによりページの外見を損なわせること、パスワード・ファイルを改変したり盗んだりすること、データ・ファイルを削除すること、著作権のある作品を侵害すること、クレジット及びデビット・カード番号、又は他の顧客情報を勝手に変更すること、プライベートなビジネス情報を公表すること、秘密情報又は無許可情報にアクセスすること、内部データベースを通じてサーチすることが含まれるが、それらに限定されるものではない。従って、ウェブ・ハッキングにより、ユーザ、顧客、ビジネス、１又は２以上のサーバのオペレータに対して、不便及び恐らくは元に戻らないような損害が引き起こされる。一般に、従来のコンピュータ・セキュリティ方法は、ウェブ・ハッキングの懸念に対処していないか又はそれを完全に無視している。
【０００５】
国際標準化機構（「ＩＳＯ」）が、コンピュータが互いに接続し合い、できるだけエラーを少なくして情報を交換することを可能にするよう設計された１組のプロトコル標準を開発した。コンピュータ通信全体を標準化するための一般に認められているプロトコルは、開放型システム間相互接続（「ＯＳＩ」）モデルとして既知である、７レイヤからなる１組のハードウェア及びソフトウェア・ガイドライン内で指定される。このプロトコル・モデルは、貴重な基準を形成し、データ通信で使用される言語の多くを定義する。図１に示されているように、アプリケーション・レイヤは、ＯＳＩモデル内の標準の最も高いレイヤである。
【０００６】
従来のセキュリティ方法は、一般に、ファイアウォール又はセッションを使用することによるデータ・リンク・レイヤ及び物理レイヤのいずれかと、安全なソケット・レイヤ（「ＳＳＬ」）又は公開鍵インフラストラクチャ（「ＰＫＩ」）を使用することによるトランスポート・レイヤの間で実施される。ファイアウォールは、インターネットなどの別のネットワークから発信されるデータ・リンク・レイヤで、外部からの脅威に対して信頼できる環境又はネットワークを保護するよう意図された１つのタイプのセキュリティの実施である。ファイアウォールは、コンピュータが、信頼できるネットワーク外のコンピュータと直接に通信することをファイアウォールで防ぐ。その代わりに、全ての通信が、信頼できるネットワークの外側にあるプロキシ・サーバを通じて経路設定され、プロキシ・サーバが、特定のメッセージ・タイプ又はファイル・タイプを、１組のフィルタに基づいて、信頼できるネットワークに通過させることが安全かどうかを判断する。安全なソケット・レイヤは、クレジット・カード情報などのクリティカルな情報の傍受を防ぐために、安全で暗号化された通信チャネルを確立するためのＮｅｔｓｃａｐｅ  Ｃｏｍｍｕｎｉｃａｔｉｏｎｓ（登録商標）によって開発された公開標準である。ＳＳＬを使用する主な目的は、ウェブなどの公衆ネットワーク上で安全で暗号化された電子トランザクションを可能にすることである。公開鍵インフラストラクチャ又は信頼階層は、通信セッションに関係するそれぞれの関係当局を検証し認証する、ディジタル認証、認証局、他の登録局のシステムである。ＰＫＩは、現在も発展し続けており、単一のＰＫＩもなければ、ＰＫＩを設定するための同意された単一の標準もない。上記の従来の技術の１つの欠点は、アプリケーション・レイヤ・プロトコルの検査を実施しない、すなわち着信要求のアプリケーション・コンテントを精査しないことである。従って、これらの技術は、オペレーション要求のアプリケーション・コンテントを通じて向かってくるウェブ・ハッキング攻撃を防ぐことができない。
【０００７】
ウェブ・ハッカは、ウェブ設計の欠陥及び脆弱性を悪用することにより、コンピュータ・システムを容易に攻撃することができる。たとえば、デフォルト・スクリプトにより、ファイルをウェブ・サーバにアップロードでき、環境変数のウェブ・サーバの処理を悪用でき、サード・パーティ製品の「バックドア」又は欠陥の存在により無許可のアクセスが可能となる。これらの技術は、強力な攻撃であり得、一般に従来の手段を通じて防御することは困難である。毎月新しいソフトウェアの脆弱性が発見されているが、多くのシステム・オペレータは通常、これらのホールをパッチせず、防ぐことが可能な攻撃から自分のシステムをオープンのまま放置している。上手に構成されたファイアウォール、ＰＫＩ、ＳＳＬの実施を利用している大企業及び政府関係機関が、ハッカにより既知のアプリケーション・レイヤを使用して潜入されてきた。これらの進入は、一般に、アプリケーションに送信して、意図された又は認証された範囲のオペレーション外のことを無理に実行させる違法で有害な要求を伴う。これは、アプリケーションを悪用して、アプリケーション自体、ファイル、バッファ、他のアプリケーション、性能、又は情報の機密性を損傷させることができる。
【０００８】
従来の２つのアプローチが、これらの問題のいくつかに対処することを試みている。１つの技術が、サーバ・オペレーティング・システムを追跡して、ファイルを削除したりディスクをフォーマットするなどの怪しい事象を識別することに関係する。しかし、このタイプの反応型技術は、一般に、損害が起きた後又は完了した後になって起動する。第２の技術が、アプリケーションの前にネットワーク・フィルタをインストールすること、及びアプリケーションに影響を及ぼすことのできる既知のパターンでフィルタ・データベースを更新することに関係する。しかし、この技術は、フィルタ・データベースにはまだ「既知」になっていないパターンを識別できないという点で限定されている。言い換えれば、この技術のケイパビリティは、パターンを引き出すフィルタ・データベースのわかりやすさに直接関係する。ケイパビリティを上げるために、フィルタ・データベースは継続的な更新を必要とする。更に、これらの技術は、環境変数又はアプリケーションの実施されるビジネス・プロセスの改ざんに対して保護しない。
【０００９】
更に、従来のセキュリティ・ソリューションは、一般に、電子商取引（「ｅコマース」）、モバイル、インタラクティブ・テレビジョン（「ｉＴＶ」）のアプリケーションの激増により増加しつつあるハッキングの機会に対処していない。これらのアプリケーションは、一般に、異なる技術を使用して全てがともに機能する、異なるプラットフォーム上で動作する数々のコンポーネントの組合せを必要とする。たとえば、単一のアプリケーションが、ウェブ・サーバ・アプリケーション、トランザクション・サーバ・アプリケーション、データベース、全てがともに機能するＪａｖａ、ＡｃｔｉｖｅＸ、Ｆｌａｓｈアプレットなどの、複数のコンポーネントを有することができる。  一般に、従来のセキュリティ・ソリューションは、多くのコンポーネント・システムにおけるそれぞれのコンポーネントの一意のセキュリティの必要を満たすことができない。
【発明の開示】
【発明が解決しようとする課題】
【００１０】
本発明は、信頼できるコンピュータ・アプリケーション及び関連するリソースを、アプリケーション自体を通じて直接に無許可のユーザによってアクセス又は実行されることから防ぐためのアプリケーション・レイヤ・セキュリティ方法及びシステムを提供することにより、従来の技術の上記の及び他の欠陥を克服する。
【課題を解決するための手段】
【００１１】
本発明の一実施形態では、信頼できない環境から受信された違法又は有害なオペレーション要求を実行することからアプリケーションを保護するための方法が、１又は２以上のパイプを着信オペレーション要求に適用するステップを含む。違法で有害なオペレーション要求により、アプリケーション、他のアプリケーション、信頼できるネットワーク、１又は２以上のデータ・ファイル、メモリ、バッファ、性能、秘密情報、ハードウェア、ソフトウェア、データベース、情報サーバなどが損傷したり、又はそれらへの無許可アクセスが可能になることがある。たとえば、違法で有害なオペレーション要求が、データベースの改ざん、既知のインターネット情報サーバの脆弱性又はアプリケーションの脆弱性に対する攻撃、ＵＲＬの改ざん、ビジネス・プロセスの改ざんなどであり得る。オペレーション要求が違法又は有害であると識別された場合は、これらの要求を完全に拒否するか、あるいは正当な又は無害なオペレーション要求に修正するか、又はそれらに置換することができる。
【００１２】
本発明の一実施形態では、セキュリティ・システムが、実行の前後に、アプリケーション・サーバから又はアプリケーション・リクエスタ（クライアント）から来る、１パケット又はストリームのパケット内で受信されたか又は識別されたアプリケーション・オペレーション要求又は結果をくまなく探す。オペレーションにおいては、着信パケット又はストリームのパケットが、オペレーション要求内の、１又は２以上のアプリケーション・コマンド又はパラメータあるいはその一部分を識別する識別子に転送される。次いで、識別されたコマンド又はパラメータが、たとえば、コマンドのタイプ、要求されているアプリケーション、クライアント識別、又はそれらの組合せにより、それぞれのコマンド又は要求全体を適切なトンネルに向ける経路設定スキームを有するルータに転送される。本発明の１つの特徴は、異なるパイプがオペレーション要求の異なる部分に適用できることである。
【００１３】
本発明の一実施形態では、データベース・ドリブン・パイプが、データベース・オペレーションに関係し、データベース要求内に悪意のある意図を示すパターンを見つけ出すことを目的とする。具体的には、着信データベース要求のコンテンツが、使用されるデータベースのタイプ及び１又は２以上の埋め込まれた有害なＳＱＬコマンドの存在に基づいて許容構文について検査される。
【００１４】
本発明の別の実施形態では、決定性タイプのパイプが、着信オペレーション要求を既知の脆弱性パターンについて検査する。全ての既知のアプリケーションの脆弱性、及びそれにつけこむ各要求が格納され、着信要求と比較される。比較結果が一致した場合は、着信要求は阻止され、アプリケーションに進むことができない。更に、このパイプは、アクセスされるか又は実行された場合に、否定的な影響を及ぼしたりアプリケーション環境又はサーバへの違法アクセスを可能にする恐れのある、実行可能プログラム、メソッド、スクリプトの使用を消去することにより、未知の脆弱性に対してアプリケーションを遮蔽できる。
【００１５】
本発明の別の実施形態では、ＨＴＭＬドリブン・パイプにより、アプリケーションが設計通りに動作し、アプリケーション・オーナによって実施されることが確実となる。具体的には、パイプは、それぞれの発信返信をそのパラメータ名及び値についてチェックし、次いで、着信パラメータと発信パラメータの間の比較に基づいて次のクライアントを確認する。この方法により、アプリケーションへの後続のユーザ要求が、アプリケーションの期待するユーザ要求のみであることが確実となる。
【００１６】
本発明の別の実施形態では、アプリケーション・ノードを阻止しているパイプが、リモート・ユーザ要求を、アプリケーション・オーナによって制限されたものとして指定されているアプリケーション経路を入力することから制限する。アプリケーション・オーナが、時々、たとえアプリケーション内で脆弱性が知られているにもかかわらず、生産パッチが使用可能になるまで、ビジネスを失うことを恐れてアプリケーションを実行し続けることがあり得る。このパイプを使用すると、アプリケーション・オーナは、他のアプリケーション経路をクライアントから使用可能にしたまま、脆弱なアプリケーション経路がアクセスされることを阻止できる。
【００１７】
本発明の別の実施形態では、パイプが、信頼できないオペレーション要求を、信頼できるネットワーク内の信頼できる環境又はゾーンに転送されることから阻止する。このパイプを実施することにより、アドミニストレータが、リモート・ユーザの特有のメッセージを許可されたものとして指定されたメッセージのみに制限できる。
【００１８】
本発明の別の実施形態では、パイプが、定義済式規則に従って着信パラメータ値を確認する。
【００１９】
本発明の別の実施形態では、クッキーベースのパイプが、クライアント側のクッキーを、ユーザによって修正されるか又は改ざんされることから保護する。このパイプにより、クッキー内に格納されている内部情報がユーザから使用不可能になるが、アプリケーション自体にはどのような変更も適用せずに、アプリケーションにはトランスペアレントにクリアであることが確実となる。
【００２０】
本発明の別の実施形態では、ＳＯＡＰパイプは、有害なクライアント要求にサービスすること、あるいはリモート・クライアント又は特定のクライアントが呼び出すことを許可されていないサービス要求を防ぐことから、ウェブ・サービスを保護する。具体的には、このパイプにより、ウェブ・サービスが設計通りに動作し、アプリケーション・オーナによって実施されることが確実となる。このパイプにより、全てのクライアント要求がウェブ・サービスの定義及びデータ構造に一致し、リモート・クライアントが要求することを認証されているサービスにのみアクセスできることが確実となる。
【００２１】
本発明の別の実施形態では、学習手法により、要求内のパラメータが、統計モデルから判断されたクライアント、すなわちリクエスタによって入力された最も一般的な値により良く一致するよう「微調整され」ることが可能となる。ダイナミックな範囲の入力された値が、クライアントが送信する要求内のそれぞれのパラメータについて構築される。実施された統計モードに基づき、確率の高い、すなわち最もしばしば入力された値又は期待された値の範囲が計算され、オペレーション要求パラメータの値が、アプリケーションからの返信に基づいて調整できる。
【００２２】
本発明の利点は、正当で無害な要求のみが、信頼できるネットワークへ及びそのネットワーク内の信頼できる全てのアプリケーションへ通過することである。別の利点は、本発明が、これらのサーバ上のどのようなソフトウェアも修正したりインストールしたりすることなく、単一の又は多くのアプリケーション・サーバにインストールされた無制限の数のアプリケーションを保護することである。本発明の別の利点は、オペレーション要求の一部分を異なるセキュリティ技術によって精査できることである。本発明の別の利点は、パイプのどのような組合せも、アプリケーションの正確なセキュリティの必要に従ってアプリケーション経路に適用できることである。
【００２３】
本発明は、アプリケーション・レイヤを通じて向けられた攻撃の問題に対して、頑強でスケーラブルでダイナミックで有効なかつあざやかなソリューションを提供する。
【００２４】
本発明の上記の及び他の特徴と利点は、本発明の好ましい実施形態についての以下のより具体的な説明、添付図面、特許請求の範囲から自明となろう。
【００２５】
本発明と本発明の目的及び利点をより完全に理解するために、添付図面と合わせて以下の説明について言及する。
【発明を実施するための最良の形態】
【００２６】
本発明の好ましい実施形態及びそれらの利点は、図２〜１５を参照することによって理解できるであろう。これらの実施形態は、インターネット、イントラネット、モバイル通信ネットワーク、ｉＴＶネットワーク、ハイブリッド・ネットワーク、又は、ＨＴＴＰ、ＨＴＴＰｓ、ＨＴＴＰｄ、ＳＯＡＰ（ｓｉｍｐｌｅ  ｏｂｊｅｃｔ  ａｃｃｅｓｓ  ｐｒｏｔｏｃｏｌ）、ＷｅｂＤＡＶ（ｗｅｂ  ｄｉｓｔｒｉｂｕｔｅｄ  ａｕｔｈｏｒｉｎｇ  ａｎｄ  ｖｅｒｓｉｏｎｉｎｇ）、メール転送プロトコル（ＳＭＴＰ）などのアプリケーション・プロトコルを使用するがそれらに限定されるものではない任意の他のアプリケーション環境内で用いることができる。その上、本発明のコンセプトは、信頼できるアプリケーション又はネットワークと信頼できない通信環境の間で情報が交換される、どのようなタイプの通信システムにおいても実践できる。本発明のコンセプトは、アプリケーション・サービス・プロバイダ（「ＡＳＰ」）、ビジネス対商取引、ビジネス対ビジネスのネットワーク環境を保護するのに特に適している。
【００２７】
本発明は、アプリケーション・レイヤを通じて直接要求された信頼できるコンピュータ・アプリケーション又はリソースの無許可使用を防ぐ。アプリケーション・レイヤは、アプリケーションの要件に関係し、クライアントとサーバの間のデータの伝送を制御するより低いレイヤとは異なり、クライアントによって要求されたアプリケーション・オペレーションを容易にする。一般に、全てのアプリケーション・オペレーションが、アプリケーション・レイヤを通じて提供される、要素、たとえばパラメータ及び関連付けられた値を使用する。本発明の一実施形態によるアプリケーション・レイヤ・セキュリティ方法及びシステムが、それのみで又は組み合わせて動作する、本明細書においてパイプと呼ぶ、１又は２以上のセキュリティ接続技術を実施し、信頼できるアプリケーション又は周囲の環境に対して違法な又は有害なコマンドを識別するために、クライアント・メッセージのアプリケーション・コンテント、すなわち信頼できないオペレーション要求又は着信データ・ストリームを精査する１又は２以上のアプリケーション・レイヤ・セキュリティ・プロセスを有する。従って、アプリケーション・レイヤ、特にウェブに関係する脅威に対して信頼できるアプリケーションを保護する。アプリケーション・レイヤ・セキュリティ方法及びシステムは、アプリケーション、共用アプリケーション、分散型アプリケーション、又は多くのアプリケーションを、意図された範囲のオペレーション外で実行するよう要求されることから保護するよう実施できる。それにより、このようなアプリケーションがアプリケーション自体、データ・ファイル、バッファ、他のアプリケーション、サーバ性能、又は情報の機密性を害するのを防止する。有害又は違法であると識別されたオペレーション要求が、完全に拒否されるか、あるいは無害な又は正当な要求に修正されるか、あるいはそれに置換できる。従って、無害で正当な要求のみが、実行のためにアプリケーションに通過する。
【００２８】
本発明の一実施形態では、セキュリティ・システムが、１又は２以上のアプリケーションを有する信頼できる環境の前に位置づけられる。セキュリティ・システムは、これらの１又は２以上の信頼できるアプリケーションと、未知の又は信頼できない環境から又はそれを通じて受信された信頼できない着信アプリケーション・オペレーション要求の間のアプリケーション・レイヤで保護レイヤを実施する。保護レイヤは、フォーム、コンテント、又は両方について、これらの要求を検査して、正当で無害な要求のみが信頼できる環境に通過することを確実にする。セキュリティ・システムは、保護レイヤを実施するための、ハードウェア、ソフトウェア、又は両方を有することができる。
【００２９】
図２Ａは、本発明の一実施形態によるアプリケーション・レイヤ・セキュリティ・システム２００を示す図である。具体的には、保護レイヤ２１０が、信頼できない環境と、１又は２以上のウェブ・サーバ２２０上に常駐する１又は２以上のアプリケーション（図示せず）を有する信頼できる環境の間で実施される。保護レイヤ２１０は、信頼できないソースを介して送信された悪意のあるオペレーション要求から、信頼できるアプリケーションを保護する。それぞれの着信オペレーション要求が、アプリケーションによって実施されるべき、複数の要求されたコマンド、パラメータ、パラメータ値を有することができる。着信オペレーション要求が、１又は２以上のポート２３０を介して外部ＨＴＴＰトラフィックとして受信されることがある。それぞれのアプリケーションを、専用又は共用サーバ上で実施する、あるいは多くのサーバ全体を通じて分散することができ、ＨＴＭＬドキュメント、ウェブ・サーバ・ソフトウェア、共通ゲートウェイ・インターフェース（「ＣＧＩ」）スクリプト、Ｐｅｒｌスクリプト、データベース情報、又は任意のタイプの情報リソース又は実行可能なプログラムなどのリソースを有することができるが、それらに限定されるものではない。アプリケーション経路は、特定のアプリケーション・タスク又はコマンドを実行するためのアプリケーションのリソース場所を表す。リソース場所は、ウェブ・サーバ２２０上に常駐する物理アドレス又は仮想アドレスであり得る。たとえば、図２Ｂは、サブディレクトリ、「／Ｍｙ  Ａｐｐ／Ｉｍａｇｅｓ」及び「／Ｍｙ  Ａｐｐ／ＤＯＣＳ」から構成される仮想サブディレクトリ「／Ｍｙ  Ａｐｐ」を表す。これらのサブディレクトリのそれぞれ１つが、各画像又はドキュメントの場所を指定するアプリケーション経路を表す。
【００３０】
セキュリティ・システム２００が、単一の、分散型、又は共用アプリケーションをサポートするためのトンネル２４０を有する。トンネル２４０は、信頼できない環境と信頼できる環境の間の、プロトコル・ベースの、たとえばＴＣＰ／ＩＰ接続である。それぞれのトンネルを通って進行する着信又は発信データ・パケットを有するネットワーク・トラフィックが、データ・パケットのアプリケーション・コンテントから導出された適切なアプリケーション経路に基づいて分離される。たとえば、ＨＴＴＰにおいて、アプリケーション経路は、特定のトンネルを介してアクセスできるウェブ・サーバ２２０上で定義された仮想ディレクトリであり得る。それぞれのトンネル２４５が、たとえば、ＨＴＴＰ、ＨＴＴＰｓ、ＳＯＡＰ、ＷｅｂＤＡＶ、ＦＴＰ、Ｔｅｌｎｅｔなどの特定のアプリケーション・プロトコルを実施し確認できる。あるいは、それぞれのトンネル２４０が、単に着信及び発信データ・パケット・ストリームを転送できる。
【００３１】
図２Ｃは、信頼できないネットワーク側の聴取アドレス及びポートと、信頼できるネットワーク側の接続ローカル・アドレスの間で情報を伝えるトンネル２４０の例を表す図である。聴取アドレス及びポートは、着信アプリケーション・オペレーション要求を受信する。接続ローカル・アドレスは、トンネル２４０を通って受信された情報を受信し、その接続アドレス及びポートで聴取しているバックエンド・アプリケーションにそれを転送する。図２Ｄは、サブディレクトリ／ＤＯＣＳに関連付けられた、具体的にはトンネル＃３と呼ぶトンネル２４０のトンネル実施の例を表す図である。この例においては、一定のドキュメント、たとえばＨＴＴＰプロトコルのアプリケーション・コマンドＧＥＴ／ＤＯＣＳを有するアプリケーションを表示するための要求が、トンネル＃３を通って対応するアプリケーションに送信される。
【００３２】
システム２００は更に、アプリケーションの機能を保護又はモニタするために提供された１又は２以上のパイプ２５０を有する。具体的には、１又は２以上のパイプ２５０が、トンネル内で動作しているトラフィック上で実行される。たとえば、第１のパイプは１又は２以上のアプリケーションを既知の脆弱性から保護し、第２のパイプはデータベースの改ざんを防ぎ、第３のパイプはパラメータのポイゾニングを防ぐ。特定のパイプ実施形態及び実装形態を、以下の説明で詳細に記述している。追加のパイプが他の特定の又は一般的なセキュリティ懸念を表すことができることは、当業者なら認識されるであろう。
【００３３】
図２Ａ及び特に図２Ｅを参照すると、システム２００が、複数のトンネル２４０をラッピング又はグルーピングする論理エンティティである１又は２以上のウェブ・アプリケーション２６０と、アプリケーション経路と、信頼できるアプリケーションをともに保護する１又は２以上のパイプ２５０とを有する。いくつかのウェブ・サーバ２２０間に分散されたアプリケーション、すなわち異なるマシン上に常駐する別個のＨＴＭＬページを保護する場合、単一のウェブ・アプリケーション・エンティティは分布を表す。たとえば、ウェブ・アプリケーション２６０が、選択されたアプリケーション経路を介する全てのトラフィックを精査しモニタする。デフォルト・ウェブ・アプリケーションが、ウェブ・アプリケーション２６０内で定義されていない全てのトンネルを介する全てのトラフィック上のセキュリティ保護を表す論理エンティティである。更に、ウェブ・アプリケーション２６０が、１又は２以上のパイプの実行を特定のアプリケーション経路にカストマイズできる。
【００３４】
セキュリティ・システム２００が、保護レイヤ２１０を実施するためのハードウェア、ソフトウェア、又は両方を有することができる。本発明の一実施形態では、保護レイヤ２１０が、スタンドアロン・サーバ上で実施される。代替実施形態では、保護レイヤ２１０が、既存サーバにインストールできる「プラグ・アンド・プレイ」ハードウェアなどとして実施される。本発明の別の実施形態では、保護レイヤ２１０が、１又は２以上のサーバにインストールされたソフトウェア・コンポーネントによって実施される。
【００３５】
本発明の一実施形態では、アプリケーション・レイヤ・セキュリティ方法が、着信及び／又は発信メッセージ又はデータ・パケットのコンテンツを検査して、意図された又は認証された範囲外で実行している信頼できるアプリケーションに関連付けられたアプリケーション・コマンド又はパラメータを識別するステップを含む。メッセージ・コンテンツが、アプリケーションが実行又は解釈する、メッセージ・ヘッダ、メッセージ本体、クエリ・ストリング、ユニフォーム・リソース識別子（「ＵＲＩ」）、及び特に、アプリケーションが実行したり解釈したりするアプリケーション変数やコマンドなどのアプリケーション・レイヤ要素を有する。コンテントをチェックすることには、１又は２以上のパイプを適用するステップが含まれ、それぞれのパイプが、特定の保護又はモニタ機能をアプリケーション・レイヤ・コンテントに提供する。
【００３６】
本発明の一実施形態では、セキュリティ方法３００が、着信アプリケーション・オペレーション要求のアプリケーション・レイヤ・コンテンツを精査するために用いられる。図３Ａの左側を参照すると、アプリケーション経路識別及びトンネル構築が、まず第１に、着信オペレーション要求上で実施される（ステップ３０２〜３２２）。具体的には、信頼できないネットワークから送信されたデータ・パケット又はストリームのパケットの形式のオペレーション要求が、まず第１に、バッファ・オーバーフロー攻撃、すなわち、サーバが扱うことのできる数を超える所与の時間内に受信された多数の冗長又は違法要求によって引き起こされるサービスの拒否が生じ、それにより、正当な要求に対してサービスの拒否が生じたり、又はオーバーフロー要求が無許可のまま進行することが可能となることを防ぐ、好ましくは待ち行列に入れられたソケット・サーバなどの受信手段で受信される（ステップ３０２）。他の実施形態では、データ通信を受信し扱うことのできる他の従来の受信手段が使用できるが、その識別及び実施については当業者には自明であろう。要求を受信すると、バイナリ・ストリーム・リーダが、サーバ待ち行列からデータ・パケットを読み取る（ステップ３０４）。好ましい実施形態では、内部エンティティ、すなわちネットワーク・セッション・オブジェクトが、システム内でその生存期間中それぞれのメッセージを扱う。
【００３７】
プロトコル・メッセージ生成関数が、任意のタイプのプロトコルに従って最初にフォーマットされた可能性のある、受信されたオペレーション要求を、プロトコル指定３０７によって指定された所望のフォーマットを有する内部メッセージに組み立てる（ステップ３０６）。プロトコル指定３０７は、信頼できるアプリケーションによって実施される、ＨＴＴＰ、ＨＴＴＰｓ、ＳＯＡＰ、ＨＴＴＰｄ、ＦＴＰ、ＷｅｂＤＡＶなどの、任意のタイプのアプリケーション・プロトコルであり得る。内部メッセージ構築はまたトンネル構築とも呼ばれ、オペレーション要求は、信頼できるアプリケーションのプロトコルのデータ・フォーマット内に埋め込まれている。本発明の一実施形態では、たとえばミッシング・パラメータやエキストラ・パラメータにより正当なプロトコル・メッセージを作成することができないなどの理由から、オペレーション要求が内部メッセージにフォーマットできない場合は、そのオペレーション要求は即時に拒否される。成功裏に内部メッセージにフォーマットされると、そのメッセージは、索引付けされ（ステップ３０８）、後に分析するために格納され、それにより、必要な場合には要求からアプリケーション・コンテントを集め、一時バッファ又は永久記憶装置デバイス内に蓄積することが可能となる。以下に詳細に説明するように、集められたコンテントは、要求のアプリケーションの実行から戻ってきた又は後続の他のオペレーション要求及び返信に戻る、対応する返信と比較するのに有用である。
【００３８】
拒否が起きなかった場合は、メッセージは、パイプ・コンポーネントによって理解される既知の符号化言語に翻訳される（ステップ３１０）。既知の符号化言語は、任意のタイプの符号化言語であり得る。本発明の好ましい実施形態では、使用される符号化言語は、ユニコード又は拡張ユニコードである。ユニコードは、ＨＴＴＰアプリケーション・プロトコルを使用する場合に特に好ましい。オペレーションにおいては、要求がユニコード・キャラクタに翻訳される。たとえば、受信された要求が、情報交換用米国標準コード（「ＡＳＣＩＩ」）又は任意の他の符号化標準に符号化されている場合、メッセージは、ユニコード又は拡張ユニコードに翻訳される。翻訳により、要求内に含まれた記号が予期しないものであるか否かを判断することにより、オペレーション要求の切り離され独立した検査が実現される。言い換えれば、予期しないキャラクタを含むどのような要求も、その全体を拒否できる。翻訳により、後続のセキュリティ・プロセスが期待される符号化標準で実施されることが確実となり、それにより、予期しないキャラクタによるセキュリティとの妥協のリスクが最小限に抑えられる。その上、翻訳により、元のメッセージを翻訳されたメッセージから切り離して、全てのパイプが翻訳されたメッセージ上で適切に実行することが確実となる。本発明の一実施形態では、プロトコル指定３０７のどのような更新も、既知の符号化言語の即時の更新となる。他の実施形態では、ＡＳＣＩＩ又は任意の他の符号化標準を符号化言語として使用できる。
【００３９】
成功裏に組み立て索引付けし翻訳した結果、信頼できないオペレーション要求が、ユニコードで符号化された、うまくフォーマットされたプロトコル・メッセージに変換される。これらのステップは、１又は２以上のパイプを適用することにより、コンテンツの徹底的な精査のために要求が通過する前の、要求のフォーマットの予備スクリーニングとして作用する。言い換えれば、これらのステップは、隠蔽された又は容易に識別可能でない違法又は有害なコマンドについて要求のコンテンツをチェックする前にまず、全く驚くべき又は予期しない要求をフィルタリングする。
【００４０】
翻訳に続いて、オペレーション要求内のそれぞれのコマンド又はパラメータあるいはそれの一部分が、その意図されたアプリケーション経路とともに識別され（ステップ３１２）、次いで、特定の経路設定スキームを用いて、論理管理されたエンティティ、すなわちウェブ・アプリケーションに関係づけられる（ステップ３１４）。本発明の一実施形態では、その識別されたアプリケーション経路が既知である場合、すなわち、ウェブ・アプリケーション及び経路設定スキームに関連付けられたアプリケーション経路との一致が発見された場合は、コマンドが経路設定スキームに従って経路設定される（ステップ３１６）。コマンドのアプリケーション経路が存在しない場合、又は完全には識別できなかった場合、又はどのような既知のアプリケーション経路にも一致しなかった場合は、メッセージは、好ましくは最大のセキュリティのために全ての使用可能なパイプに適用されるデフォルト・トンネルを通って経路設定される（ステップ３１８）。デフォルト・トンネルはまた、最初のトンネル構築中にセキュリティ問題を有することが発見された、どのようなメッセージにも適用できる。デフォルト・トンネルの実施により、エラー・ウェブ・ページ、セキュリティ警告ウェブ・ページ、又は同様の手段を表示して、エラーが起きたこと又は推定される悪意のある攻撃の宛て先が信頼できるアプリケーションから変更されたことを通知することがトリガされることがある。しかし、デフォルト・トンネルが指定されない場合は、要求は拒否される（ステップ３２０）。適切なアプリケーション経路に対応するそれぞれのコマンド又はパラメータが、経路設定スキームに従って経路設定され、それにより、指定されたトンネルを通ってそれぞれのコマンドを経路設定し、そのアプリケーション経路のための特定の数及び組合せのパイプが適用される。オペレーション要求内に含まれる追加のコマンド及びパラメータについて、ステップ３１２〜３２０を繰り返す（ステップ３２２）。
【００４１】
図３Ａの右側を参照すると、経路設定スキームによって決められた通りに、１又は２以上のパイプが、それぞれの着信オペレーション要求に順次に適用されて（ステップ３２４、３２６、３２８）、要求内に含まれる命令、コマンド、クエリ・ストリング、環境変数、パラメータなどのアプリケーション・レイヤ・コンテンツを徹底的に精査する。それぞれのパイプが、独自タイプの分析又はモニタ機能を提供する。適用されたパイプの特定の数及びタイプは、所望されるセキュリティの量、一般に、それぞれのトンネル及び／又はアプリケーション経路のタイプ及び必要に依存する。たとえば、一方のトンネルは適用された３つのパイプを有し、他方のトンネルは適用された２つのパイプを有することがある。
【００４２】
パイプは、一般に、スタティック又はダイナミックなパイプとして分類され、そのいずれかが、以下に記述する「学習」手法を任意に実施できる。スタティックなタイプのパイプが、一般に、ハッキング・パターン又は既知の、すなわち識別された脆弱性に関係する、静的に格納された情報との比較によりアプリケーション・コンテンツを精査する。たとえば、比較により一致が発見された場合は、要求は、拒否、修正、又は置換することができる。ダイナミックなタイプのパイプが、着信要求と発信返信の両方、及びそれらの間で恐らく変化している即ちダイナミックな関係を精査する。これらのタイプのパイプのいずれかが、要求及び／又は返信から情報を集めて、パイプのセキュリティ範囲を「微調整」する学習手法を適用できる。その上、単一のパイプが、学習手法のあるなしにかかわらず、スタティック及びダイナミックなタイプのパイプに関連付けられたいくつかの特性を組み合わせることができる。特定のパイプ構成及び実施を、以下の説明において記述する。適切な数及びタイプのパイプを適用すると、オペレーション要求のアプリケーション・コンテンツの合法性及び／又は有害性が判断される。オペレーション要求が精査に合格すると、その要求は、送信される（ステップ３３０）か又は少なくとも、処理のために信頼できるアプリケーションに進むことが可能となる（ステップ３３２）。
【００４３】
代表的なクライアント・サーバ通信セッションにおいて、いったんアプリケーションがオペレーション要求を処理すると、要求側のクライアントに戻るための各返信が生成される。たとえば、返信は、ＨＴＭＬドキュメント、画像、データベース情報、ビデオ、又はサーバを通じてアクセス可能な任意の他のリソースであり得る。図３Ｂを参照すると、オペレーション要求の実行の後に起きる方法３００のステップが示されている。発信返信が読み取られ（ステップ３３４）、次いで、特定のアプリケーション・プロトコル３３７に基づいて内部メッセージに組み立てられる（ステップ３３６）。本発明の好ましい実施形態では、アプリケーション・プロトコル３３７はアプリケーション・プロトコル３０７と同一である。着信オペレーション要求に適用されたパイプのいずれかが、リターン返信の検査を必要とする場合は、ステップ３３８〜３５６が実施される。具体的には、実施されたパイプのいずれかについて２つの間の比較が必要な場合には、返信メッセージが、元の要求に索引付けし戻される（ステップ３３８）。メッセージを索引付けすると、返信メッセージが、着信データ・ストリーム上で使用される符号化言語に翻訳される（ステップ３４０）。発信返信が、以前に格納された、翻訳され索引付けされた要求、及び翻訳され索引付けされた返信メッセージを使用して、確認される（ステップ３４２）。具体的には、このステップにより、発信返信が性質上些細なものであることが確実となる。たとえば、返信は、サーバから開放するために認証された情報のみを有することがある。些細ではない返信がクライアントに到達することが拒否される（ステップ３４４）。受入れ可能なパラメータ名及び値と新しいアプリケーション経路が、返信内で識別される（それぞれ、ステップ３４６及び３４８）。この情報を使用して、適切なダイナミックなタイプのパイプ又は実施された学習手法を更新する（ステップ３５０、３５２、３５４）。更新すると、必要な場合には、返信はプロトコル３５に従ってメッセージに再び組み立てられ（ステップ３５６）、オペレーションを要求しているクライアントに送信される（ステップ３５８）。好ましい実施形態では、プロトコル３５７はプロトコル３０７と同一である。オペレーション要求が、返信の検査を必要とする適用されたどのようなパイプも有さない場合は、ステップ３３８〜３５６がスキップされる。
【００４４】
図４は、アプリケーション・サーバから又はクライアントから来るパケット又はストリームのパケット内で受信されたか又は識別されたアプリケーション・オペレーション要求又は返信を経路設定するためのセキュリティ・システム４００を示す図である。具体的には、システム４００が、クライアント４１０、要求識別子４２０、要求ルータ４２４、Ｎ数のパイプ４３０Ａ〜Ｎ、サーバ４４０、返信識別子４５０、返信ルータ４５４を有する。クライアント４１０は、信頼できないネットワーク内に置かれていると推定される。サーバ４４０は、信頼できるネットワーク内に常駐し、サーバ４４０又は追加の分散型サーバ（図示せず）上に常駐する１又は２以上のアプリケーション（図示せず）との、クライアント４１０のインタラクションのホストとして働く。オペレーションにおいては、クライアント４１０によって伝送されたパケット又はストリームのパケットを有する着信要求が、通信リンク４１２を介して要求識別子４２０に転送される。要求識別子４２０は、要求内の１又は２以上のアプリケーション・コマンド又はパラメータあるいはそれの一部分を識別する。次いで、識別されたコマンド又はパラメータが、通信リンク４２２を介して要求ルータ４２４に転送される。
【００４５】
要求ルータ４２４が、それぞれのコマンド又はパラメータあるいは全要求自体を、アプリケーション経路４２６Ａ〜Ｍのうちの適切な１つに向ける。ここでＭは、適用できるパイプ４３０Ａ〜Ｎの一意の数又は特定の組合せである。たとえば、示されているように、アプリケーション経路４２６Ａは全てのＮパイプをオペレーション要求に適用し、アプリケーション経路４２６Ｂはただ２つのパイプを適用する。しかし、パイプのどのような組合せも、それぞれのアプリケーション経路に適用できる。アプリケーション経路の総数Ｍとパイプの数Ｎは、必ずしも等しくない。本発明の好ましい実施形態では、要求ルータ４２４が、たとえば、要求されたオペレーションのタイプ、コマンドのタイプ、パラメータ名、パラメータ値、要求されている特定のアプリケーション、要求されたアプリケーション経路、クライアント識別、又はそれらの組合せに基づいて、それぞれのコマンド又はパラメータのための適切なアプリケーション経路を判断する経路設定スキームを用いる。その上、要求ルータ４２４が、特定の又は識別不可能なクライアント・アドレスから受信されたコマンド又はパラメータを、全ての使用可能なパイプを適用するデフォルト・アプリケーション経路に向けることができる。パイプ４３０Ａなどの一定のパイプについては、要求、コマンド、又はパラメータ上でパイプを適用することから確かめられた情報を使用して、通信リンク４３１を介して要求ルータ４２４によって用いられた経路設定スキームを動的に修正する。この経路設定スキームは、通信リンク４６３を介して発信返信上を動作しているパイプによって確かめられた情報により、同様に修正できる。その上、経路設定スキームへの更新又は修正が、システム４００の外部のソース（図示せず）から受信できる。全ての適切なパイプがオペレーション要求のサブコンポーネント、たとえばパラメータなどに適用されると、全てのサブコンポーネントが受入れ可能と思われる場合に、オペレーション要求は、処理のためにサーバ４４０に転送される。
【００４６】
要求を処理した結果得られた、パケット又はストリームのパケットを有する発信返信が、着信ストリームと同様の精査を受ける。具体的には、サーバ４４０によって生成された発信パケット又はストリームのパケットは、通信リンク４４２を介して返信識別子４５０に転送され、返信識別子４５０が、その中に含まれている特定のパラメータ名及び値又は任意の他の関連アプリケーション・レイヤ要素を識別する。これらの識別されたパラメータ及び要素は、通信リンク４５２を介して返信ルータ４５４に転送される。返信ルータ４５４は、それぞれの要素をアプリケーション経路４５６Ａ〜Ｍのうちの適切な１つに向ける。ここでＭは、それぞれの発信パラメータ又は要素に適用できるパイプ４６０Ａ〜Ｎのうちの一意の数又は特定の組合せである。パイプ４６０Ａ〜Ｎの一部分は、パイプ４３０Ａ〜Ｎの一部分と同一であり得る。本発明の好ましい実施形態では、返信ルータ４５４が、たとえば、返信のタイプ、パラメータのタイプ、パラメータの値、要素のタイプ、返信を生成したアプリケーション、返信を受信するクライアントの識別、又はそれらの組合せに基づいて、それぞれの要求、パラメータ、パラメータ値、又は要素のための適切なアプリケーション経路を判断する経路設定スキームを用いる。返信経路設定スキームは、要求ルータ４２４内で用いられる経路設定スキームと同一であり得るが、必ずしも同一とは限らない。発信パラメータ又は要素上の、示されているパイプ４６０Ａなどのパイプによって確かめられた情報を使用して、通信経路４６１を介して返信ルータ４５４によって実施される経路設定スキームを修正できる。その上、着信要求上を動作しているパイプ４３０Ａによって確かめられた情報が、通信経路４３３を介してこの経路設定スキームを動的に修正できる。その上、返信経路設定スキームへの更新又は修正が、システム４００の外部のソース（図示せず）から受信できる。アプリケーション経路４５６に関連付けられた全ての適切なパイプ４６０を適用すると、受入れ可能な結果が、通信チャネル４６２を介してクライアント４１０に戻る。
【００４７】
上記の実施形態は、要求識別子４２０、要求ルータ４２４、返信識別子４５０、又は返信ルータ４５４に適切に接続された通信リンク４２２、４３３、４５２、４６３とともに例示されている。本発明の一実施形態では、識別子４２０、要求ルータ４２４、返信識別子４５０、返信ルータ４５４が、ソフトウェア又はハードウェアのいずれかとして実施される、パイプ４３０及び４６０とは別個のソフトウェアとして実施できる。従って、通信リンク４２２、４３３、４５２、４６３は、実際の物理接続ではなく、ソフトウェア・モジュール間の仮想接続である。通信リンク４１２、４３２、４４２、４６２、及びここで識別される任意の他のリンクは、任意の従来の通信媒体であり得るが、その実施については当業者には自明であろう。代替実施形態では、要求識別子４２０、要求ルータ４２４、返信識別子４５０、返信ルータ４５４が、パイプ４３０Ａ〜Ｎ及び４６０Ａ〜Ｎのあるなしにかかわらず、単一のハードウェア・コンポーネント内に実施される。
【００４８】
図５は、本発明の一実施形態に従ってハードウェア構成を有するセキュリティ・システム５００を示す図である。具体的には、セキュリティ・システム５００が、信頼できるコンピュータ・アプリケーション５２０と信頼できないネットワーク環境の間に位置づけられたセキュリティ・モジュール５１０を備える。モジュール５１０が、アプリケーション５２０の無許可使用を防ぐために保護レイヤを実施する。本発明の一実施形態では、モジュール５１０が、プロセッサ５３０及びパイプ論理５４０を有する。用語、プロセッサとは、本明細書に記述される機能を実施するよう構成された任意の論理、回路、コード、ソフトウェアなどを表す。プロセッサ５３０が、アプリケーション５２０から信頼できない環境を介して受信されたオペレーション要求を切り離す内部エンティティを実施することにより、上述した最初のトンネル構築、索引付け、翻訳を実施する。内部エンティティは、信頼できない要求を識別子／ルータ５３４及びアナライザ５３８に案内する。識別子／ルータ５３４が、必要な場合には着信要求ストリーム又は発信返信ストリーム上のあらゆる既存アプリケーション経路を適用して、アプリケーション内のオペレーション要求の所望の宛先と、またあればパラメータ及び値も識別する。アナライザ５３８が、パイプ論理５４０内に格納されている１又は２以上のパイプをオペレーション要求又はその一部分に適用する。
【００４９】
パイプの例についての記述
以下は、着信オペレーション要求及び発信返信に、単独で又は組み合わせて適用できるパイプの例の詳細な記述を表す。従来の技術を指向したセキュリティ・プロセスなどの、本明細書では言及しない追加のパイプも適用できるが、その識別及び実施については当業者には自明であろう。
【００５０】
１．Ｍａｒａｂｕ
本発明の一実施形態では、本明細書では「Ｍａｒａｂｕ」と呼ぶ第１のパイプが、１又は２以上のアプリケーション経路に適用される。Ｍａｒａｂｕとは、オペレーション要求において悪意のある意図を示すパターンを発見することを目的とするコンテント・ドリブン・パイプである。Ｍａｒａｂｕは、データベース・オペレーションに関係するアプリケーション経路に適用されることが好ましい。具体的には、Ｍａｒａｂｕは、要求されたデータベースのタイプ及び１又は２以上の埋め込まれた有害なＳＱＬコマンドの存在に基づいて、許容構文のための着信要求のアプリケーション・コンテンツを検査する。要求されたデータベースのタイプ、たとえばＳＱＬタイプのデータベースやオラクル（Ｏｒａｃｌｅ）・タイプのデータベースについて受入れ可能であると思われる複数の格納されたデータベース・コマンドとの一致が発見されなかったことにより、有害なコマンドが識別される。受入れ可能なコマンドとの一致が発見されなかった場合は、要求は、拒否されるか、あるい正当な又は無害な受入れ可能なフォームに改良、すなわち修正されるか、あるいはそれと置換される。このパイプが、データベース又はその環境に対して有害であると思われるウェルフォームドで部分的なＳＱＬコマンドをキャッチする。
【００５１】
本発明の一実施形態では、データベース・クエリ・パーサ・エンジンが、オペレーション要求のそれぞれの式のフォーム及び機能を識別するために実施される。パーサ・エンジンは、個々に分析するために、個々の式すなわち要素を解析する。Ｍａｒａｂｕは、「状態の自動化（ｓｔａｔｅ−ａｕｔｏｍａｔｅ）」であり限定されたアルファベットを適用することにより、それぞれの式の構文が明白であり軽信であることを確認することに注目する。具体的には、Ｍａｒａｂｕは、状態の自動化を構築するステップと、許容構文及び限定されたアルファベットに従ってあらゆる式を検査するステップと、あらゆる式に状態の自動化を適用するステップとを含む適正な構文を実施する方法を用いる。状態の自動化は、アプリケーションの現在の及び他の可能な状態を表すノードの相関である。それぞれのノードが、アプリケーションの状態を変更する式に基づいて他のノードとの接続を有することができる。たとえば、特定の式たとえばＤＥＬＥＴＥコマンドが実行された場合に、アプリケーションの現在の状態を表す第１のノードが、現在の状態から到達することが可能な状態を表す別のノードに接続される。全ての接続が、一方方向の接続である、すなわち、いったんある状態が別の状態に変更すると、その変更は元に戻らないと推定される。
【００５２】
本発明の一実施形態では、アルファベットは、文字、ディジット、及び他の符号化されたキャラクタ、たとえばａ、ｂ、ｃ、＿など、ＤＥＬＥＴＥやＡＬＴＥＲなどの文字のブロック、ＤＥＬＥＴＥ、ＡＬＴＥＲ、ＣＲＥＡＴＥをメンバとして含むＳＱＬグループなどのブロックのグループを有する。オペレーション要求内のそれぞれの式が、１回又は複数回スキャンされる。それぞれの式が、受入れ可能であるとして識別された文字及びディジットのシーケンスから構成される場合は、要求は承認され、パイプ実行が停止する。式が、文字及びディジットの受入れ可能なシーケンスから構成されていない場合は、式内の注釈、特に、ＭＳＳＱＬ−／＊＊／ｏｒ−−などの注釈を表すデータベース特有のキャラクタが省略され、状態の自動化を適用することにより式が検査される。式又は関数引き数に関連付けられたあらゆる定義済アルファベット文字が、自動化の現在の状態を接続している可能な状態に移動させる。
【００５３】
本発明の一実施形態では、状態の自動化を適用した場合に到達する状態のタイプにより、異なるプロセスが実施される。たとえば、状態の自動化がブール状態に到達した場合、式は、「１５」＝「１」＋「５」及び「６＞５  ＯＲ  ５＝５」などの「常に正しい（ａｌｗａｙｓ−ｔｒｕｅ）」式についてチェックできる。常に正しい式が、データベースをだまして、通常認めるべきではない要求を認めさせることができる。式トリーにより、常に正しい式の識別が可能となる。具体的には、式は、たとえばＡＮＤ、ＯＲ、＝などの演算子としてのノード、又はフィールドなどの変数を有するトリーに再帰的に分解される。トリー（tree）が構築された後に、異なる式値が挿入される。後行順スキャンにより、最終的にＴＲＵＥ又はＦＡＬＳＥ決定に導かれる。変数に賢明にサンプリングされた値が、全ての可能なソリューションの範囲をカバーし、それにより式が常に正しいかどうか、従って要求を拒否するかどうかを判断する。状態の自動化がＳＱＬ−状態に到達した場合は、式は、ディクショナリ内に格納されているＳＱＬプロトタイプを使用して確認される。プロトタイプは、アークによって接続された異なる状態のグラフを使用して実施される。双方向アークにより、再帰的式、すなわちそれら自体を指し、入力に適合するよう試みるために「引伸ばし（ｓｔｒｅｔｃｈｉｎｇ）」ているアークを有する状態が可能となる。状態の自動化がトラップ状態に到達した場合は、式は拒否され、パイプの実行が停止する。これらの状態のどれも起きないか又は上記の状態の検査の結果、式の拒否とならなかった場合は、式は承認され、パイプ実行が停止する。
【００５４】
図６は、本発明の一実施形態に従ってＭａｒａｂｕパイプを実施するためのプロセス６００を示す図である。具体的には、たとえばＳＱＬバージョンのタイプに基づいて、サポートされたデータベースのための構成パラメータが、プロセッサ内にロードされる（ステップ６１０）。任意に、これらの構成パラメータに対するどのような改良もロードされる（ステップ６２０）。オペレーション要求は、ロードされ（ステップ６３０）、要素に解析されて、オペレーション要求内に含まれる式、たとえばパラメータ名及び値を識別する（ステップ６４０）。次いで、Ｍａｒａｂｕパイプがそれぞれのパラメータに適用されて（ステップ６５０）、埋め込まれたＳＱＬコマンドが受入れ可能かどうかを判断する（ステップ６６０）。受入れ不可能であった場合は、全オペレーション要求が拒否される場合がある（ステップ６７０）。受入れ可能であった場合は、そのパラメータが最後のパラメータであるか否かが判断される（ステップ６８０）。そのパラメータが最後のパラメータでなかった場合は、ステップ６４０〜６８０を繰り返す。パラメータが最後のパラメータであった場合は、違法でなく有害でもないＳＱＬコマンドが識別され、オペレーション要求は認められ（ステップ６９０）、次に進むことができる。
【００５５】
以下は、このパイプによってキャッチできる、インターネットを介して一般に広がっており改ざんタイプの攻撃で代表的な、２つの共通なタイプのデータベース攻撃である。第１は、テーブル内の全てのレコードを削除するための要求を表す。たとえば、全てのレコードが攻撃する削除において、データベース・サーバ上でＳＱＬコマンドを実行して、「ｈｔｔｐ：／／ｗｗｗ．ｙｏｕｒｓｉｔｅ．ｃｏｍ／ｐｈｏｎｅｓ」（ここで、ｐｈｏｎｅｉｄは３４に等しい）のコンテンツを選択し報告する、
ｈｔｔｐ：／／ｗｗｗ．ｙｏｕｒｓｉｔｅ．ｃｏｍ／ｐｈｏｎｅｓ／ｐｈｏｎｅｌｉｓｔ．ｃｇｉ？ｐｈｏｎｅｉｄ＝３４
などの元のリンクが、
ｈｔｔｐ：／／ｗｗｗ．ｙｏｕｒｓｉｔｅ．ｃｏｍ／ｐｈｏｎｅｓ／ｐｈｏｎｅｌｉｓｔ．ｃｇｉ？ｐｈｏｎｅｉｄ＝３４；ＤＥＬＥＴＥ
などのＤＥＬＥＴＥコマンドを連結する修正されたリンクに変更できる。後者は、データベース上でＳＱＬコマンドを実行して、「ｈｔｔｐ：／／ｗｗｗ．ｙｏｕｒｓｉｔｅ．ｃｏｍ／ｐｈｏｎｅｓ」（ここで、「ｐｈｏｎｅｉｄ」は３４に等しい）のコンテンツを削除する。このパイプを適用する際に、ＤＥＬＥＴＥコマンドは無許可のコマンドとして認識され、従って、完全に要求を拒否するか、又はその要求をＤＥＬＥＴＥコマンドを含まない元のリンクなどの正当な要求に置換することができる。以下の第２のタイプの違法要求においては、パスワードを使用せずに、ログインが試みられる。たとえば、
ｈｔｔｐ：／／ｗｗｗ．ｙｏｕｒｓｉｔｅ．ｃｏｍ／ｌｏｇｏｎ．ａｓｐ？ｌｏｇｉｎ＝ｙｏｕｒｎａｍｅ；ｐｗｓ＝１２３
などの元のリンクが、データベース・サーバ上でＳＱＬコマンドを実行して、ユーザ・リストから名前を選択する（ここで、ログイン＝「ｙｏｕｒｎａｍｅ」及びパスワード＝「１２３」である）。修正されたリンクが、「常に正しい」ブール句を追加して、アプリケーションをだまして、無効なパスワード、たとえばデータベース・サーバ上でＳＱＬコマンドを実行して、ユーザ・リストから名前を選択した、
ｈｔｔｐ：／／ｗｗｗ．ｙｏｕｒｓｉｔｅ．ｃｏｍ／ｌｏｇｏｎ．ａｓｐ？ｌｏｇｉｎ＝ｙｏｕｒｎａｍｅ’ｏｒ‘１’＝‘１’；ｐｗｓ＝８
を認めさせる（ここで、ログイン＝「ｙｏｕｒｎａｍｅ」又は「１」＝「１」及びパスワード＝「１２３」である）。このパイプを適用した場合、「１」＝「１」部分コマンドは無効なものとして認識され、要求はその意図された実行を達成することができない。
【００５６】
アプリケーション・データベースを改ざんするユーザ及びクライアント・アプリケーションに対して、完全なデータベース保護が実現される。Ｍａｒａｂｕパイプが、データベース内に格納されている情報に損害を及ぼす可能性のあるデータ改ざんに対するシールドとして作用する。更に、他のパイプと組み合わされた場合には、Ｍａｒａｂｕパイプは、データベース・システム・アドミニストレータにさらなるレベルの保護も提供し、アプリケーション・バグがバック・オフィス・データベースに影響を及ぼさないことを確実にする。
【００５７】
２．Ｍｉｎｉｍｅ
本発明の一実施形態では、本明細書では「Ｍｉｎｉｍｅ」と呼ぶ第２のパイプが、１又は２以上のアプリケーション経路に適用される。Ｍｉｎｉｍｅとは、着信オペレーション要求を既知の脆弱性パターンについて検査する決定性パイプである。本発明の特定の実施形態では、全ての既知のアプリケーションの脆弱性、具体的にはそれにつけこむ各要求が格納され、着信要求と比較される。着信要求の任意の部分と格納された情報の任意の部分の間に一致が発見された場合は、着信要求は阻止され、アプリケーションに進むことができない。更に、パイプは、スクリプト、コマンド、メソッド、実行可能プログラム、たとえば記憶空間をフォーマットするｆｏｒｍａｔ．ｅｘｅ、あるいはアクセスされたり又は実行されたりした場合に、コマンド・ライン入力プロンプトが否定的な影響を及ぼすことを可能にする、あるいはアプリケーション環境又はサーバへの違法アクセスを可能にする、ｃｍｄ．ｅｘｅの使用を消去することにより、未知の又は容易に識別可能でない脆弱性に対してアプリケーションを遮蔽できる。
【００５８】
本発明の好ましい実施形態では、格納された脆弱性情報は、将来に脆弱性が識別された時に更新することができる。具体的には、格納された情報は、情報ソース、たとえば専用集中型サーバあるいは商用又は政府ソースからの多くのウェブ・サーバからダウンロードされた情報とともに更新できる。
【００５９】
本発明の一実施形態では、Ｍｉｎｉｍｅパイプは、正確なパターン一致方法を用いる。具体的には、本方法は、オペレーション要求内の連続するキャラクタ、たとえば４つ毎に連続するキャラクタのためのハッシュ値を計算するステップと、不適正な要求に関連付けられたハッシュ値のリストに対して計算されたそれぞれのハッシュ値を比較するステップとを含む。オペレーションにおいては、オペレーション要求の最初の４つのキャラクタが、４つのキャラクタ・ウィンドウ内に入力される。４つのキャラクタのそれぞれが、８ビットのバイナリ・コードたとえば、
ａｂｃｄ＝［０１０００００１］［０１００００１０］［０１０００１１］［０１０００１００］
に変換される。
【００６０】
次いで、第１のハッシュ値が、３２ビットのストリング（４キャラクタｘ８ビット／キャラクタ）から計算される。第２のハッシュ値が、１キャラクタだけ、すなわちキャラクタ２から５にウィンドウをシフトすることにより計算される。第３のハッシュ値が、再び１キャラクタだけ、すなわちキャラクタ３から６を使用してウィンドウをシフトすることにより計算される。追加のハッシュ値が、オペレーション要求内の全てのキャラクタが使い尽くされるまで、このような方式で計算される。従って、オペレーション要求内にｎのキャラクタがあった場合は、ｎ−３を有する値が計算される。それぞれのハッシュ値が、格納され不適正な要求に関連付けられたハッシュ値と比較される。従って、一致が発見された場合は、着信要求は拒否される。
【００６１】
本発明の好ましい実施形態では、上記の方法が、ＨＴＴＰプロトコルで組み立てられたオペレーション要求に適用される。オペレーション要求は、それぞれ、メッセージＵＲＩ、クエリ・ストリング、メッセージ・ヘッダ、メッセージ本体を表す４つのゾーンに分割される。上述した脆弱性パターン一致が、特定の４つのゾーンのうちの１又は２以上のゾーンに向けられる。パイプ・アプリケーションを、単一のゾーン又は全オペレーション要求自体より小さい一部分に向けることができるので、性能を向上し、擬似警報を減少することができる。ストリングが原因であると判断された場合は、全く単純なストリング一致が実施される。
【００６２】
図７は、本発明の一実施形態に従ってＭｉｎｉｍｅパイプを実施するためのプロセス７００を示す図である。具体的には、脆弱性パターンが、内部記憶装置又は外部データベースのいずれかからプロセッサ内にロードされる（ステップ７１０）。任意に、脆弱性パターンの値を含むテーブルが、効率的なパターン一致を容易にするために作成される（ステップ７２０）。４つの異なるスキャニング・ゾーンが構築され（ステップ７３０）、適用すべき指定されたハッシュ値に関連付けられる。着信メッセージはロードされ（ステップ７４０）、１又は２以上のメッセージ・ゾーンがスキャンされて（ステップ７５０）、脆弱性パターン、たとえばハッシュ値が一致するかどうかを判断する（ステップ７６０）。一致が発見された場合は、メッセージは拒否される場合がある（ステップ７７０）。一致が発見されなかった場合は、メッセージは別のパイプ又はアプリケーションに進むことができる（ステップ７８０）。どのような後続のオペレーション要求についても、ステップ７４０〜７８０を繰り返す。
【００６３】
以下は、阻止された、３つの共通なＭｉｃｒｏｓｏｆｔ  Ｉｎｔｅｒｎｅｔ  Ｉｎｆｏｒｍａｔｉｏｎ  Ｓｅｒｖｅｒ（登録商標）の脆弱性である。ウェブ・サーバ・ハード・ディスク上に任意のファイルを表示する。たとえば、
ｈｔｔｐ：／／ｗｗｗ．ｙｏｕｒｓｉｔｅ．ｃｏｍ／ｍｓａｄｃ／Ｓａｍｐｌｅｓ／ＳＥＬＥＣＴＯＲ／
ｓｈｏｗｃｏｄｅ．ａｓｐ？ｓｏｕｒｃｅ＝／ｍｓａｄｃ／Ｓａｍｐｌｅｓ／．．／．．／．．／．．／．．／ｂｏｏｔ．ｉｎｉ．
直接データベースに任意のＳＱＬコマンドを実行する。たとえば、
ｈｔｔｐ：／／ｗｗｗ．ｙｏｕｒｓｉｔｅ．ｃｏｍ／ｍｓａｄｃ／ｓａｍｐｌｅｓ／ａｄｃｔｅｓｔ．ａｓｐ．
ＣｏｄｅＢｒｗｓ．ａｓｐを使用して、Ｏｕｔｌｏｏｋメール・フォルダを表示する。たとえば、
ｈｔｔｐ：／／ｗｗｗ．ｙｏｕｒｓｉｔｅ．ｃｏｍ／ｉｉｓｓａｍｐｌｅｓ／ｅｘａｉｒ／ｈｏｗｉｔｗｏｒｋｓ／
ｃｏｄｅｂｒｗｓ．ａｓｐ？ｓｏｕｒｃｅ＝／．．／．．／ｗｉｎｎｔ／Ｐｒｏｆｉｌｅｓ／Ａｄｍｉｎｉｓｔｒａｔｏｒ／
Ａｐｐｌｉｃａｔｉｏｎ％２０Ｄａｔａ／Ｍｉｃｒｏｓｏｆｔ／Ｏｕｔｌｏｏｋ％２０Ｅｘｐｒｅｓｓ／Ｍａｉｌ／ｉｎｂｏｘ．ｍｂｘ
Ｍｉｎｉｍｅパイプは、少なくとも以下の利点を実現する。すなわち、アプリケーションの脆弱性を使用してシステムのハッキングを試みるリモート・ユーザからのアプリケーション保護と、パッチが使用可能となりサーバにインストールされるまでのアプリケーションに対する一時保護と、カスタム・パターンを追加でき、既存パターンを記憶装置から除去できることが少なくとも実現する。
【００６４】
３．Ｈｉｄｅ  ＆  Ｓｅｅｋ
本発明の一実施形態では、本明細書では「Ｈｉｄｅ  ＆  Ｓｅｅｋ」と呼ぶ第３のパイプが、１又は２以上のアプリケーション経路に適用される。Ｈｉｄｅ  ＆  Ｓｅｅｋとは、ハイパーテキスト・マークアップ言語ドリブン・パイプであり、その目的は、アプリケーションが設計通りに動作し、アプリケーション・オーナによって実施されることを確実にすることである。ハイパーテキスト・マークアップ言語又は本明細書においてはＨＴＭＬが、エクステンシブル・マークアップ言語（「ＸＭＬ」）、エクステンシブル・ハイパーテキスト・マークアップ言語（「ＸＨＴＭＬ」）、ワイヤレス・マークアップ言語（「ＷＭＬ」）などの任意のタイプのマークアップ言語を含む。具体的には、パイプが、それぞれの発信ＨＴＭＬ返信をチェックして、その内部パラメータ名及び値を識別し、次いで、次のユーザ要求が以前に識別されたパラメータに対応することを確認し、それにより、アプリケーションへの後続のユーザ要求が、アプリケーションが戻ることを期待しているか又は意図するユーザ要求のみであることが確実となる。
【００６５】
本発明の一実施形態では、方法には、単一のクライアントを識別して、アプリケーションとインタラクトすることと、アプリケーションからの返信内にクライアントに送信された要素、たとえばパラメータ名及び値を識別することと、アプリケーションへのクライアントの後続の要求が任意のパラメータ及び値を有しているかどうかを判断し、有していれば、これらのパラメータ及び値がアプリケーションによって期待されているものであるか否かを判断することとが含まれる。クライアントから受信されたパラメータ及び値が、以前の、送信された対応するメッセージから判断された要素に対応している場合にのみ、サーバは、要求をアプリケーションに転送する。
【００６６】
本発明の一実施形態では、アルゴリズムが、返信ドキュメント上でＨＴＭＬ解析を実施し、クライアントによって受信された全てのＨＴＭＬタグを格納する。たとえば、パーサが、アプリケーションから来るそれぞれの返信を読み取り、返信メッセージ内の特定のＨＴＭＬ要素、たとえば入力、選択、フォームなどを識別する。それぞれの識別された要素について、パーサは、要素値を判断する。全ての解析された要素名及び値が、サーバ上に置かれたセッション・オブジェクト内に格納され、それぞれのセッションが単一のクライアントに関連付けられている。クライアントを識別し、要求にセッション・オブジェクトを任意に付加した後に、追加のパーサが要求上で動作する。この段階で、コンパレータを使用して、ＨＴＭＬ要素に基づいて要求を返信に一致させる。たとえば、返信パーサは、クライアントが自分の次の要求でパラメータ値を変更できるかどうかを判断する。できる場合は、クライアントがこのパラメータを有する任意の値を送信できる。たとえば、アプリケーション返信が＜ＩＮＰＵＴ＞タグを有する場合、クライアントは、値を入力することが期待される。
【００６７】
ステートレス・プロトコル、すなわち、ソース及び宛先情報にのみ関係するがメッセージのコンテンツには関係しないプロトコル内のクライアントを識別するために、セッションベースのクッキーが利用される。好ましくは、クライアントのウェブ・ブラウザ上でクッキーが可能となる。セキュリティ目的で、可能となっているクッキーがないクライアントは、最小アプリケーション・アクティビティに限定された「新しい」又は無許可のユーザであると考えられる。クッキーがクライアントによって可能である場合は、サーバは、クライアント−サーバ・セッションの開始時に、クライアントでセッションベースのクッキーを生成し格納する。本発明の一実施形態では、セッションベースのクッキーは、クライアント識別情報を含むヘッダと、セッション・オブジェクトを識別する暗号化されたセキュリティ値を含むクッキー本体とを有する。
【００６８】
以下は、Ｈｉｄｅ  ＆  Ｓｅｅｋパイプの実施例である。ログイン及びパスワードのための代表的なＨＴＭＬドキュメントは、以下の通りである。
【００６９】
2004533676.tif 000003
2004533676.tif 000004
このＨＴＭＬドキュメントは、クライアントが最初にサーバにアクセスした時に、クライアントに送信される。解析すると、以下の結果が、セッション・オブジェクト内に格納される。
【００７０】
2004533676.tif 000005
このセッション・オブジェクトは、クライアントでクッキー内に格納されている、セッション値に関連付けられている。クライアントの次の後続の要求、すなわち、ログイン及びパスワードを求めているサーバに対するクライアントの応答で、Ｈｉｄｅ  ＆  Ｓｅｅｋが、クライアントからセッション値を取得し、セッション値に関連付けられたセッション・オブジェクトを識別する。次いで、パイプは、セッション・オブジェクト内に格納されている結果を取得し、これらの結果に対する着信パラメータ名及び値を確認する。着信パラメータと発信パラメータが一致した場合は、クライアントは、パラメータのいずれをも改ざんしていないと推定される。しかし、着信パラメータのいずれかと各発信パラメータとが一致しなかった場合は、ユーザは、要求を改ざんしたと推定される。従って、着信要求は拒否される。
【００７１】
本発明の一実施形態では、テキスト・フィールド、たとえばログイン・フィールドを扱うために改良宣言テーブルが用いられる。テーブルは、パラメータ及びその期待されるデータ・タイプ、長さ、ａｌｌｏｗ  ｎｕｌｌなどを含む。
【００７２】
図８は、本発明の一実施形態に従って、Ｈｉｄｅ  ＆  Ｓｅｅｋパイプを実施するためのプロセス８００を示す図である。具体的には、サポートされているＨＴＭＬバージョンに従って、構成パラメータがロードされる（ステップ８０５）。次いで、所望の場合には、改良が任意にロードされる（ステップ８１０）。分析のために着信オペレーション要求メッセージがロードされ（ステップ８１５）、次いで、ＨＴＴＰクッキー・ヘッダ内のクライアント識別についてチェックされる（ステップ８２０）。その後、クッキーの本体が取得され（ステップ８２５）、セッション値を得るために解読される（ステップ８３０）。セッション値に関連付けられたセッション・オブジェクトが取得される（ステップ８３５）。セッション・オブジェクトが存在しなかった場合は、ブランク又は新しいものが作成される。次いで、着信メッセージは、パラメータ名及び値に解析される（ステップ８４０）。パラメータ、値、それらの組合せが、セッション・オブジェクト内に格納されている情報と又は改良テーブルと比較される（ステップ８４５）。次いで、一致が存在するかどうかが判断される（ステップ８５０）。一致が発見されなかった場合は、メッセージは拒否される（ステップ８５５）。全てのパラメータが一致した場合は、メッセージは次に進むことができる（ステップ８６０）。後続の着信要求で、ステップ８１５〜８６０を繰り返す。
【００７３】
図９は、本発明の一実施形態に従って、返信メッセージ上でＨｉｄｅ  ＆  Ｓｅｅｋパイプを実施するためのプロセス９００を示す図である。まず第１に、返信メッセージが受信され（ステップ９１０）、ロードされて（ステップ９２０）、その返信がＨＴＭＬドキュメントであるか否かを判断する（ステップ９３０）。ＨＴＭＬでなかった場合は、返信メッセージはクライアントに送信される（ステップ９４０）。ＨＴＭＬであった場合は、返信メッセージはパラメータに解析される（ステップ９５０）。全ての解析された情報は、セッション・オブジェクト内に格納される（ステップ９６０）。セッション・オブジェクトは、それが新しいバスケットであるか否かが識別される（ステップ９７０）。セッション・オブジェクトが新しいものでなかった場合は、メッセージはクライアントに送信される（ステップ９８０）。セッション・オブジェクトが新しいものであった場合は、ヘッダが、セッションを識別する情報を有する返信メッセージに追加され（ステップ９９０）、次いでメッセージ全体がクライアントに送信される（ステップ９９５）。
【００７４】
Ｈｉｄｅ  ＆  Ｓｅｅｋが、アプリケーション・ビジネス・プロセスを改ざんするリモート・ユーザからアプリケーションを保護する。更にＨｉｄｅ  ＆  Ｓｅｅｋは、改ざん技術を伴うどのような要求からもアプリケーションを保護し、アプリケーション・オーナに即時の連続遮蔽を提供する。
【００７５】
４．Ｉｎｉｇｏ
本発明の一実施形態では、本明細書では「Ｉｎｉｇｏ」と呼ぶ第４のパイプが、１又は２以上のアプリケーション経路に適用される。Ｉｎｉｇｏとは、アプリケーション・オーナによって制限されたものとして指定されているアプリケーション経路を入力することからアプリケーション・オペレーション要求を制限する、アプリケーション−ノード阻止パイプである。ビジネス・アプリケーションが動作している環境においては、アプリケーション・オーナは、一般に、アプリケーション経路に関連したバグが発見された場合は、管理上の問題に直面することとなる。しかし、そのアプリケーション経路に関連付けられたアプリケーションの全ての実行を停止することは、アプリケーションが実施する１又は２以上のビジネス・プロセスに対して否定的な影響を及ぼす。従って、アプリケーション・オーナは、一般に、たとえアプリケーション内で脆弱性が知られても生産パッチが使用可能となるまで、アプリケーションを操作し続ける。Ｉｎｉｇｏパイプを実施することにより、アプリケーション・オーナは、ユーザが他のアプリケーションを使用できる状態にしたまま、脆弱なアプリケーション経路がアクセスされることを阻止できる。
【００７６】
図１０は、本発明の一実施形態に従って、Ｉｎｉｇｏパイプを実施するためのプロセス１０００を示す図である。アプリケーション経路がデータ・ソースからロードされる（ステップ１０１０）。着信要求メッセージが論理内にロードされる（ステップ１０２０）。次いで、メッセージの宛先が判断されて（ステップ１０３０）、阻止されるものとして指定されている特定のアプリケーション経路に対して比較される（ステップ１０４０）。一致が発見された場合は、メッセージは拒否される（ステップ１０６０）。一致が発見されなかった場合は、メッセージは通過できる（ステップ１０５０）。
【００７７】
たとえば、リンク、
ｈｔｔｐ：／／ｗｗｗ．ｙｏｕｒｓｉｔｅ．ｃｏｍ／ｍｙｓｉｔｅ／ｐｒｅｓｓ／ｎｅｗｓ．ａｓｐ？ｎｅｗｓｉｄ＝２３，
上で誤って公表された情報による、プレス・リリース・ディレクトリをブラウジングから阻止するために、Ｉｎｄｉｇｏが、このアプリケーション経路のための要求を識別し、完全に要求を拒否するか、又は要求の宛て先を変更して、
ｈｔｔｐ：／／ｗｗｗ．ｙｏｕｒｓｉｔｅ．ｃｏｍ／ｍｙｓｉｔｅ／ｄｅｆａｕｌｔ．ｈｔｍｌ，
などの異なるプレス・リリースが、クライアントに戻される。
【００７８】
Ｉｎｉｇｏパイプは、生産パイプが全てのサーバ上で実施されるのを待つことなく、アプリケーション・オーナに即時のトラフィック阻止ケイパリビティを提供し、それにより、脆弱性が発見された場合にも、単一の又は多量のアプリケーションを管理する複雑さが容易になる。
【００７９】
５．Ｏｇｉｎｉ
本発明の一実施形態では、本明細書ではＯｇｉｎｉと呼ぶ第５のパイプが、１又は２以上のアプリケーション経路に適用される。Ｏｇｉｎｉとは、信頼できないオペレーション要求が信頼できるネットワーク内の信頼できる環境又はゾーンに転送されることを阻止するパイプである。このパイプを実施することにより、アドミニストレータが、クライアントの特定のメッセージを、許可されたものとして指定されているアプリケーション経路のみに制限できる。具体的には、許可されたメッセージの定義済リストが実施される。クライアントの要求メッセージがリスト内のいずれかに一致した場合は、オペレーション要求は受け入れられる。そうでない場合は、オペレーション要求は拒否される。許可されたメッセージ・リストを更新するための容易な方法をアドミニストレータに提供するために、パイプは学習手法を任意にサポートし、受入れ可能であると判断された全ての着信要求メッセージが、後に着信要求と比較するためにメモリ内に格納される。
【００８０】
図１１は、Ｏｇｉｎｉパイプを実施するためのプロセス１１００を示す図である。具体的には、受入れ可能なオペレーション要求のリストが処理手段にロードされる（ステップ１１１０）。着信メッセージは、ロードされ（ステップ１１２０）、リストと比較して（ステップ１１３０）、一致が存在するかどうかを判断する（ステップ１１４０）。一致が発見された場合は、オペレーション要求は、通過することができる（ステップ１１５０）。そうでない場合は、オペレーション要求は拒否される（ステップ１１６０）。
【００８１】
６．Ｍｉｌｏｂａ
本発明の一実施形態では、本明細書では「Ｍｉｌｏｂａ」と呼ぶ第６のパイプが、１又は２以上のアプリケーション経路に適用される。Ｍｉｌｏｂａとは、定義済式規則に従って着信パラメータ値を確認するパイプである。たとえば、オンライン書店で、顧客がそれぞれの注文において１冊から５冊の本を注文できる場合がある。その書店は、注文された本の数を表すｏｒｄｅｒ＿ｑｔｙパラメータを使用する。Ｍｉｌｏｂａが、ユーザのｏｒｄｅｒ＿ｑｔｙパラメータ値が１から５の値を有する整数データ・タイプに一致することを確認する。本発明の一実施形態では、それぞれのパラメータについて定義済式規則を識別し組み立てるために、学習手法を連続するプロセスで実施して、以前に提出されたオペレーション要求に基づいて定義済規則を更新することによりオペレーション要求内の新しい受入れ可能なパラメータを識別する。
【００８２】
図１２は、本発明の一実施形態に従って、Ｍｉｌｏｂａパイプを実施するためのプロセス１２００を示す図である。定義済規則がデータ・ソースからロードされる（ステップ１２１０）。着信オペレーション要求が処理手段にロードされる（ステップ１２２０）。オペレーション要求内に含まれるパラメータ名及び値が判断される（ステップ１２３０）。それぞれのタイプのパラメータについては、そのパラメータに関連付けられた特定の規則が定義済規則から識別され（ステップ１２４０）、次いで着信パラメータ値に適用される（ステップ１２５０）。従って、規則が満足するものであるか否かが判断される（ステップ１２６０）。満足するものであった場合は、パラメータ値は認められる（ステップ１２７０）。そうでない場合は、オペレーション要求は拒否される（ステップ１２８０）。
【００８３】
７．Ｃｏｏｋｉｅ
本発明の一実施形態では、本明細書では「Ｃｏｏｋｉｅ」と呼ぶ第７のパイプが、１又は２以上のアプリケーション経路に適用される。このパイプは、クライアント側の（セッション・ベースの又は持続する）クッキーを、クライアントによって修正されるか又は改ざんされることから保護する。このパイプにより、クッキー内に格納されている情報がクライアントから使用可能でないことが確実となるが、アプリケーション自体にどのような変更も適用することなく、アプリケーションにはトランスペアレントにクリアである。具体的には、要求及びその場所に関連付けられたクッキーを識別するクッキー識別が、クライアント側で暗号化されて、クライアントがクッキーの識別を判断することを防ぐ。どのようなタイプの暗号化方法も用いることができ、またその実施については当業者には自明であろう。
【００８４】
図１３は、本発明の一実施形態に従って、着信オペレーション要求上でＣｏｏｋｉｅパイプを実施するためのプロセス１３００を示す図である。着信オペレーション要求がプロセッサにロードされる（ステップ１３１０）。パイプは、オペレーション要求内でプロトコル指定によって定義されたクッキー識別についてサーチする（ステップ１３２０）。次いで、パイプは、任意のクッキー識別が発見されたかどうかを判断する（ステップ１３３０）。発見された場合は、クッキー情報は解読され、オペレーション要求は、暗号化されたクッキー情報の代わりに解読されたクッキー情報を用いることにより修正される（ステップ１３４０）。次いで、クッキーは次のセキュリティ・パイプに転送される（ステップ１３５０）。クッキー情報が発見されなかった場合は、ステップ１３４０は実施されない。
【００８５】
図１４は、本発明の一実施形態に従って、返信メッセージ上でＣｏｏｋｉｅパイプを実施するためのプロセス１４００を示す図である。返信は、ロードされ（ステップ１４１０）、プロトコル指定によって定義されたクッキー識別についてスキャンされる（ステップ１４２０）。クッキー識別が発見された（ステップ１４３０）場合は、その情報が暗号化される（ステップ１４４０）。次いでその後、返信は暗号化された値を反映するよう修正される。次いで、メッセージは、次のセキュリティ・パイプ又はクライアントに転送される（ステップ１４５０）。
【００８６】
８．ＳＯＡＰ
本発明の別の実施形態では、ＳＯＡＰパイプは、有害なクライアント要求にサービスすること、あるいはリモート・クライアント又は特定のクライアントが呼び出すことを許可されていないサービス要求を防ぐことから、ウェブ・サービスを保護する。具体的には、このパイプにより、ウェブ・サービスが設計通りに動作し、アプリケーション・オーナによって実施されることが確実となる。このパイプにより、全てのクライアント要求がウェブ・サービスの定義及びデータ構造に一致し、リモート・クライアントが要求することを認証されているサービスにのみアクセスできることが確実となる。
【００８７】
図１５は、本発明の一実施形態に従って、着信オペレーション要求上でＳＯＡＰパイプを実施するためのプロセス１５００を示す図である。定義済規則がデータ・ソースからロードされる（ステップ１５１０）。着信オペレーション要求が処理手段にロードされる（ステップ１５２０）。オペレーション要求内に含まれるサービス名、パラメータ名、タイプ及び値が判断される（ステップ１５３０）。それぞれのサービス名については、ウェブ・サービス定義が取り込まれる（ステップ１５４０）。取り込む時に、サービス定義が発見されなかった場合は（ステップ１５５０）、オペレーション要求は拒否される（ステップ１５９０）。サービス定義が発見された場合は（ステップ１５５０）、そのサービスに関連付けられた特定の規則が識別され、次いで適用される（ステップ１５６０）。従って、規則は満足するものであるか否かが判断される（ステップ１５７０）。満足するものであった場合は、オペレーション要求は認められる（ステップ１５８０）。そうでない場合は、オペレーション要求は拒否される（ステップ１５９０）。
【００８８】
９．学習
本発明の一実施形態では、学習手法が、１又は２以上のアプリケーション経路上に適用される１又は２以上のパイプに用いられる。学習手法を適用することにより、要求内のパラメータが、統計モデルから判断されたクライアント、すなわちリクエスタによって入力される最も共通な値により良く一致するよう「微調整」できる。具体的には、それぞれのアプリケーション経路への全てのオペレーション要求が集められ、仮想記憶装置内に格納される。次いで、ダイナミックな範囲の入力された値が、クライアントが送信する要求内のそれぞれのパラメータについて構築される。実施された統計モードに基づき、確率の高い、すなわち最もしばしば入力された値か又は期待された値の範囲が計算される。更に、パラメータの値はアプリケーションからの返信に基づいて調整できる。
【００８９】
たとえば、格納されたフィールド「Ｆ」のコンテンツがリクエスタに報告し戻されることを要求しているデータベース・オペレーション要求を考える。特定の統計モデルが、９０パーセントの要求が９から１８までの範囲内で特定のＦを求めると判断した。更に、Ｆをこの範囲内に限定することが望まれる。この例においては、９から１８の間のどのようなＦ値も、アプリケーションに通過し実行できるが、２０のＦ値は、完全に拒否されるか、又は最も近い受入れ可能な値、たとえば１８などの別の値に調整される。
【００９０】
それまでに要求されたパラメータ値及び／又はアプリケーション経路から蓄積された情報を調整するか又はそれから「学習する」能力により、この技術を学習手法と呼ぶ。言い換えれば、統計モデルは変更できないが、最も共通する値の範囲は、数々の要求オペレーションから「学習された」値とともに動的に変更する。たとえば、最も共通する値の境界は、共通する値の元の範囲外の値がますます多く受信されるにつれて、変更できる。学習手法は、アプリケーション・レイヤ保護を強化するための別の方法を提供する。学習オペレーションは、それぞれのウェブ・アプリケーション上で別個に又は全ての使用可能なトンネル上で適用できる。
【００９１】
本発明の一実施形態では、ウェブ・アプリケーションが、２つのモードのオペレーション、たとえば学習モード又はイネーブル・モードを有する。学習モードにおいては、ウェブ・アプリケーションは、パイプによって判断される全てのセキュリティ・エラーを収集するための方法を用いる。それぞれのエラーについては、ウェブ・アプリケーション、トンネル、アプリケーション経路、要求されたアプリケーションなどのオペレーション要求のプロパティと、オペレーション・メッセージ・パラメータと、このセキュリティ事象を判断したパイプとが記録される。関連パイプのための改良推奨レコードが、関連パイプで作成される。改良推奨レコードが、それぞれのパイプに適用するために学習手法がシステム・アドミニストレータに提供する構成情報を有する。イネーブル・モードのオペレーションにおいては、それぞれの着信オペレーション要求について、ウェブ・アプリケーションは、オペレーション要求を１又は２以上のパイプに通過させることにより、オペレーション要求が承認されたメッセージであるか否かを判断する。承認された場合は、オペレーション要求は信頼できると思われる。承認されなかった場合は、オペレーション要求は更にパイプ検査をするために通過する。
【００９２】
それぞれのパラメータに関係する正規式を識別するために、学習手法は、それぞれのパラメータ値を蓄積する統計正規分布を使用する。現在の分散に基づいて、アルゴリズムは、現在のパラメータ正規式妥当性検査プロセスを改良する。たとえば、オペレーション要求が、
ステップ    パラメータ値        正規式
１      価格＝１２ドル      Ｌｏｎｇ［０−１ｅ６］，［ａ−ｚ］，［．／’＠＄］
２      価格＝１５          Ｉｎｔ［０−１００］，［／＠＄］
３      価格＝３４ドル      Ｉｎｔ［５−５０］，［＄］
４      価格＝２５．５ドル  Ｌｏｎｇ［５−５０］，［．＄］
Ｘ      価格＝２２．２ドル  Ｌｏｎｇ［１０−３０］，［．＄］
などの価格パラメータを有する。
【００９３】
ｘステップは、学習手法が有する最終正規式を表す。パラメータ正規式の分布分散が低かった場合に、最終段階に到達する。
【００９４】
本発明は、従来のセキュリティ技術を補完できる。たとえば、システムの一実施形態では、ファイアウォールが信頼できないネットワークとセキュリティ・システムの間に含まれ、それにより、ファイアウォールが、アプリケーション・レイヤで精査される前に、信頼できないオペレーション要求に対してデータ・リンク・レイヤでそのセキュリティ方法を実施できる。他の実施形態では、本発明のコンセプトは、ＳＳＬやＰＫＩなどのどのようなより低いレイヤ・セキュリティ技術とも組み合わせることができる。
【００９５】
本発明について、いくつかの好ましい実施形態を参照しながら具体的に示し記述してきたが、頭記の特許請求の範囲に定義されている本発明の趣旨及び範囲から逸脱することなく、形式及び詳細な点においてさまざまな変更形態を実施できることは、当業者なら理解されるであろう。
【図面の簡単な説明】
【００９６】
【図１】３つの従来のセキュリティ技術が動作するＯＳＩモデル及びプロトコル・レイヤを示す図である。
【図２Ａ】図２Ａは、本発明の一実施形態によるアプリケーション・レイヤ・セキュリティ・システムを示す図である。
【図２Ｂ】図２Ｂは、本発明の一実施形態によるアプリケーション・レイヤ・セキュリティ・システムを示す図である。
【図２Ｃ】図２Ｃは、本発明の一実施形態によるアプリケーション・レイヤ・セキュリティ・システムを示す図である。
【図２Ｄ】図２Ｄは、本発明の一実施形態によるアプリケーション・レイヤ・セキュリティ・システムを示す図である。
【図２Ｅ】図２Ｅは、本発明の一実施形態によるアプリケーション・レイヤ・セキュリティ・システムを示す図である。
【図３Ａ】図３Ａは、本発明の一実施形態によるアプリケーション・レイヤ・セキュリティ方法を示す図である。
【図３Ｂ】図３Ｂは、本発明の一実施形態によるアプリケーション・レイヤ・セキュリティ方法を示す図である。
【図４】本発明の一実施形態によるアプリケーション・レイヤ経路設定システムを示す図である。
【図５】本発明の一実施形態によるアプリケーション・レイヤ・セキュリティ・システムを示す図である。
【図６】本発明の一実施形態による第１のパイプを示す図である。
【図７】本発明の一実施形態による第２のパイプを示す図である。
【図８】本発明の一実施形態による第３のパイプを示す図である。
【図９】本発明の一実施形態による第３のパイプを示す図である。
【図１０】本発明の一実施形態による第４のパイプを示す図である。
【図１１】本発明の一実施形態による第５のパイプを示す図である。
【図１２】本発明の一実施形態による第６のパイプを示す図である。
【図１３】本発明の一実施形態による第７のパイプを示す図である。
【図１４】本発明の一実施形態による第７のパイプを示す図である。
【図１５】本発明の一実施形態による第８のパイプを示す図である。
【図１】
2004533676.tif 000006
【図２Ａ】
2004533676.tif 000007
【図２Ｂ】
2004533676.tif 000008
【図２Ｃ】
2004533676.tif 000009
【図２Ｄ】
2004533676.tif 000010
【図２Ｅ】
2004533676.tif 000011
【図３Ａ】
2004533676.tif 000012
【図３Ｂ】
2004533676.tif 000013
【図４】
2004533676.tif 000014
【図５】
2004533676.tif 000015
【図６】
2004533676.tif 000016
【図７】
2004533676.tif 000017
【図８】
2004533676.tif 000018
【図９】
2004533676.tif 000019
【図１０】
2004533676.tif 000020
【図１１】
2004533676.tif 000021
【図１２】
2004533676.tif 000022
【図１３】
2004533676.tif 000023
【図１４】
2004533676.tif 000024
【図１５】
2004533676.tif 000025
【国際公開パンフレット】
2004533676.tif 000026
2004533676.tif 000027
2004533676.tif 000028
2004533676.tif 000029
2004533676.tif 000030
2004533676.tif 000031
2004533676.tif 000032
2004533676.tif 000033
2004533676.tif 000034
2004533676.tif 000035
2004533676.tif 000036
2004533676.tif 000037
2004533676.tif 000038
2004533676.tif 000039
2004533676.tif 000040
2004533676.tif 000041
2004533676.tif 000042
2004533676.tif 000043
2004533676.tif 000044
2004533676.tif 000045
2004533676.tif 000046
2004533676.tif 000047
2004533676.tif 000048
2004533676.tif 000049
2004533676.tif 000050
2004533676.tif 000051
2004533676.tif 000052
2004533676.tif 000053
2004533676.tif 000054
2004533676.tif 000055
2004533676.tif 000056
2004533676.tif 000057
2004533676.tif 000058
2004533676.tif 000059
2004533676.tif 000060
2004533676.tif 000061
2004533676.tif 000062
2004533676.tif 000063
2004533676.tif 000064
2004533676.tif 000065
2004533676.tif 000066
2004533676.tif 000067
2004533676.tif 000068
2004533676.tif 000069
2004533676.tif 000070
2004533676.tif 000071
2004533676.tif 000072
2004533676.tif 000073
2004533676.tif 000074
2004533676.tif 000075
2004533676.tif 000076
2004533676.tif 000077
2004533676.tif 000078
2004533676.tif 000079
2004533676.tif 000080
2004533676.tif 000081
2004533676.tif 000082
2004533676.tif 000083
2004533676.tif 000084
2004533676.tif 000085
2004533676.tif 000086
2004533676.tif 000087
2004533676.tif 000088
2004533676.tif 000089
2004533676.tif 000090
2004533676.tif 000091
2004533676.tif 000092
2004533676.tif 000093
【国際調査報告】
2004533676.tif 000094