(57)【要約】侵入検知システム（ＩＤＳ）用のハイパーテキストトランスポートプロトコル（ＨＴＴＰ）検査エンジンは、ＨＴＴＰポリシー選択コンポーネント、リクエスト統一資源識別子（ＵＲＩ）発見コンポーネントおよびＵＲＩ正規化モジュールを備える。ＨＴＴＰポリシー選択コンポーネントはパケットを用いてＨＴＴＰ侵入検知ポリシーを識別する。リクエストＵＲＩ発見コンポーネントはパケット内のＵＲＩを特定する。ＵＲＩ正規化モジュールはＵＲＩの内の難読化をデコードする。別の実施形態では、ネットワーク上で送信されたパケットが傍受される。パケットがパースされる。パケットのインターネットプロトコル（ＩＰ）アドレスが識別される。ネットワークデバイスに対するＨＴＴＰ侵入検知ポリシーが決定される。パケットにおいてＵＲＩが特定される。侵入検知システムのルールによるパターンと特定されたＵＲＩとが比較される。別の実施形態では、ＩＤＳはパケット捕捉システム、ネットワークおよびトランスポート再アセンブリモジュール、ＨＴＴＰ検査エンジン、検知エンジンおよびロギングシステムを備える。
2008509458.tif 000002
【特許請求の範囲】
【請求項１】
ハイパーテキストトランスポートプロトコルポリシー選択コンポーネントと、
リクエスト統一資源識別子発見コンポーネントと、
統一資源識別子正規化モジュールと、からなる侵入検知システム用ハイパーテキストトランスポートプロトコル検査エンジン。
【請求項２】
ハイパーテキストトランスポートプロトコルポリシー選択コンポーネントは、侵入検知システムによってパースされたパケットから取得されるインターネットプロトコルアドレスをインターネットプロトコルアドレスとウェブサーバハイパーテキストトランスポートプロトコル侵入検知ポリシーとを関連付けるキーワードトライに対するキーとして用いることによって、ウェブサーバハイパーテキストトランスポートプロトコル侵入検知ポリシーを識別する、請求項１に記載のハイパーテキストトランスポートプロトコル検査エンジン。
【請求項３】
ウェブサーバハイパーテキストトランスポートプロトコル侵入検知ポリシーは統一資源識別子をパースする命令および統一資源識別子をデコードする命令のうちの１つ以上を含む請求項２に記載のハイパーテキストトランスポートプロトコル検査エンジン。
【請求項４】
リクエスト統一資源識別子発見コンポーネントは、ハイパーテキストトランスポートプロトコルポリシー選択コンポーネントによって識別されるウェブサーバハイパーテキストトランスポートプロトコル侵入検知ポリシーに基づき、侵入検知システムによってパースされたパケット内の１つ以上の統一資源識別子を特定する請求項１に記載のハイパーテキストトランスポートプロトコル検査エンジン。
【請求項５】
リクエスト統一資源識別子発見コンポーネントは、ハイパーテキストトランスポートプロトコルアプリケーションデータを一度に読み取ることによって、侵入検知システムによってパースされたパケット内の１つ以上の統一資源識別子を特定する請求項４に記載のハイパーテキストトランスポートプロトコル検査エンジン。
【請求項６】
ハイパーテキストトランスポートプロトコルアプリケーションデータを一度に読み取ることは状態機械を用いることを含む請求項５に記載のハイパーテキストトランスポートプロトコル検査エンジン。
【請求項７】
統一資源識別子正規化モジュールはリクエスト統一資源識別子発見コンポーネントによって特定される１つ以上の統一資源識別子内の難読化をデコードする請求項１に記載のハイパーテキストトランスポートプロトコル検査エンジン。
【請求項８】
難読化はハイパーテキストトランスポートプロトコルポリシー選択コンポーネントによって識別されるウェブサーバによって認識される統一資源位置指定子フィールドをエンコードすることを含む請求項７に記載のハイパーテキストトランスポートプロトコル検査エンジン。
【請求項９】
統一資源識別子正規化モジュールはリクエスト統一資源識別子発見コンポーネントによって特定される１つ以上の統一資源識別子内の難読化を、１６進デコード、二重パーセント１６進デコード、二重ニブル１６進デコード、第１ニブル１６進デコード、第２ニブル１６進デコード、８ビットユニコード変換形式デコード、８ビットユニコード変換形式空白バイトデコード、マイクロソフト％Ｕデコードおよびミスマッチデコードのうちの１つ以上によってデコードする請求項７に記載のハイパーテキストトランスポートプロトコル検査エンジン。
【請求項１０】
統一資源識別子正規化モジュールは、ハイパーテキストトランスポートプロトコルアプリケーションデータを一度に読み取ることによって、リクエスト統一資源識別子発見コンポーネントによって特定される１つ以上の統一資源識別子内の難読化をデコードする請求項７に記載のハイパーテキストトランスポートプロトコル検査エンジン。
【請求項１１】
ハイパーテキストトランスポートプロトコルアプリケーションデータを一度に読み取ることは状態機械を用いることを含む請求項１０に記載のハイパーテキストトランスポートプロトコル検査エンジン。
【請求項１２】
侵入検知システムを用いてネットワーク上のハイパーテキストトランスポートプロトコル回避を検知する方法であって、
ネットワーク上に送信されるパケットを傍受するパケット傍受工程と、
同パケットをパースするパケットパース工程と、
同パケットのインターネットプロトコルアドレスを識別するアドレス識別工程と、
同インターネットプロトコルアドレスに位置するネットワークデバイスに対するウェブサーバハイパーテキストトランスポートプロトコル侵入検知ポリシーを決定するポリシー決定工程と、
同ウェブサーバハイパーテキストトランスポートプロトコル侵入検知ポリシーに基づき同パケット内の１つ以上の統一資源識別子を特定する識別子特定工程と、
侵入検知システムのルールによる１つ以上のパターンを同１つ以上の統一資源識別子と比較する識別子比較工程と、
侵入検知システムのルールによる同１つ以上のパターンと同１つ以上の統一資源識別子との間のマッチをハイパーテキストトランスポートプロトコル回避として識別する識別子回避識別工程と、からなる方法。
【請求項１３】
パケットは未アセンブルパケットおよび再アセンブルパケットのうちの１つを含む請求項１２に記載の方法。
【請求項１４】
ポリシー決定工程はインターネットプロトコルアドレスとウェブサーバハイパーテキストトランスポートプロトコル侵入検知ポリシーとを関連付けるキーワードトライに対するキーとして前記インターネットプロトコルアドレスを用いる工程を含む請求項１２に記載の方法。
【請求項１５】
ネットワークデバイスはウェブクライアントおよびウェブサーバのうちの１つを含む請求項１２に記載の方法。
【請求項１６】
ウェブサーバハイパーテキストトランスポートプロトコル侵入検知ポリシーは統一資源識別子をパースする命令および統一資源識別子をデコードする命令のうちの１つ以上を含む請求項１２に記載の方法。
【請求項１７】
ハイパーテキストトランスポートプロトコルアプリケーションデータを一度に読み取ることによってパケットから１つ以上の統一資源識別子をデコードする工程を含む請求項１２に記載の方法。
【請求項１８】
ハイパーテキストトランスポートプロトコルアプリケーションデータを一度に読み取ることは状態機械を用いることを含む請求項１７に記載の方法。
【請求項１９】
ウェブサーバハイパーテキストトランスポートプロトコル侵入検知ポリシーに基づき前記１つ以上の統一資源識別子内の難読化をデコードする難読化デコード工程と、
侵入検知システムのルールによる１つ以上のパターンを同難読化と比較する難読化比較工程と、
侵入検知システムのルールによる同１つ以上のパターンと同難読化との間のマッチをハイパーテキストトランスポートプロトコル回避として識別する難読化回避識別工程と、を含む請求項１２に記載の方法。
【請求項２０】
難読化はネットワークデバイスのウェブサーバによって認識される統一資源位置指定子フィールドをエンコードすることを含む請求項１９に記載の方法。
【請求項２１】
難読化デコード工程は、１６進デコード、二重パーセント１６進デコード、二重ニブル１６進デコード、第１ニブル１６進デコード、第２ニブル１６進デコード、８ビットユニコード変換形式デコード、８ビットユニコード変換形式空白バイトデコード、マイクロソフト％Ｕデコードおよびミスマッチデコードのうちの１つ以上を含む請求項１９に記載の方法。
【請求項２２】
難読化デコード工程はハイパーテキストトランスポートプロトコルアプリケーションデータを一度に読み取る工程を含む請求項１９に記載の方法。
【請求項２３】
ハイパーテキストトランスポートプロトコルアプリケーションデータを一度に読み取る工程は状態機械を用いる工程を含む請求項２２に記載の方法。
【請求項２４】
パケットに埋め込まれている１つ以上の追加の統一資源識別子を識別する工程と、
侵入検知システムのルールによる１つ以上のパターンを同１つ以上の追加の統一資源識別子と比較する工程と、
侵入検知システムのルールによる同１つ以上のパターンと同１つ以上の追加の統一資源識別子との間の１つ以上のマッチを１つ以上のハイパーテキストトランスポートプロトコル回避として識別する工程と、を含む請求項１２に記載の方法。
【請求項２５】
マッチを記録する工程を含む請求項１２に記載の方法。
【請求項２６】
ネットワークを通じて送信されるパケットを傍受し、同パケットをパースするパケット捕捉システムと、
同パケットからネットワークプロトコルをパースするネットワークプロトコル再アセンブリモジュールと、
同パケットからトランスポートプロトコルをパースするトランスポートプロトコル再アセンブリモジュールと、
同パケットからハイパーテキストトランスポートプロトコルをパースし、同パケットに対するウェブサーバハイパーテキストトランスポートプロトコル侵入検知ポリシーを決定し、同ウェブサーバハイパーテキストトランスポートプロトコル侵入検知ポリシーに基づき同パケットから１つ以上の統一資源識別子を特定し、かつ、同ウェブサーバハイパーテキストトランスポートプロトコル侵入検知ポリシーに基づき同１つ以上の統一資源識別子内の難読化をデコードするハイパーテキストトランスポートプロトコル検査エンジンと、
ハイパーテキストトランスポートプロトコル検査エンジンからハイパーテキストトランスポートプロトコル検査済みパケット情報を受信し、侵入について同ハイパーテキストトランスポートプロトコル検査済みパケット情報を検査する検知エンジンと、
検知エンジンから侵入に関する情報を受信して記憶するロギングシステムと、からなる侵入検知システム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、ネットワーク上で観察されるパケットからハイパーテキストトランスポートプロトコル攻撃およびハイパーテキストトランスポートプロトコル侵入検知回避を検知するための方法およびシステムに関する。より詳細には、本発明は、ウェブサーバハイパーテキストトランスポートプロトコル侵入検知ポリシーとネットワークデバイスとを関連付け、ウェブサーバハイパーテキストトランスポートプロトコル侵入検知ポリシーに基づきネットワークパケットから統一資源識別子をデコードし、ウェブサーバハイパーテキストトランスポートプロトコル侵入検知ポリシーに基づき統一資源識別子内の難読化をデコードするためのシステムおよび方法に関する。
【背景技術】
【０００２】
典型的な侵入検知システム（ＩＤＳ）はネットワークパケットを読み取り、そのパケットを１つ以上のアプリケーションプロトコルへ分解し、その１つ以上のアプリケーションプロトコルに含まれるデータを、ネットワーク攻撃またはコンピュータ攻撃を構成するものとして既知である記憶されているパターンと比較する。通常、この記憶されているパターンは文字列であり、プロトコルデータの文字と直接比較される。
【０００３】
ハイパーテキストトランスポートプロトコル（ＨＴＴＰ）はアプリケーションプロトコルであり、ＩＤＳはＨＴＴＰを検査する必要がある。ＨＴＴＰは主としてウェブクライアントとウェブサーバとの間で通信を行うために用いられる。ＨＴＴＰにおいては、広汎にエンコード方式が用いられる。これらのエンコード方式は文字表現をある形式から別の形式へ変換する。これらのエンコード方式が用いられる理由は様々である。幾つかのエンコード方式はＨＴＴＰにおいて特別の意味を有する一定の文字を区別するために用いられる。他のエンコード方式はウェブクライアントとウェブサーバとの間に送信されるトラフィック量を低減するために用いられる。また、ＨＴＴＰ通信において用いられるエンコード方式の全てが標準化されている訳ではない。例えば、特定のベンダーの開発した特定のウェブサーバに対しユニークなエンコード方式が存在し得る。
【０００４】
その結果として、ＨＴＴＰで用いられるエンコード方式は、ＩＤＳにおいて深刻な問題を提示する。ＩＤＳがそのパターンをＨＴＴＰデータと単純に直接比較することは不可能である。ＩＤＳが単純に直接比較する場合、攻撃者はＨＴＴＰエンコード方式を用いて悪意のあるパターンの全部または一部を隠蔽することによって、検知を回避することが可能である。ＨＴＴＰエンコード方式を用いて悪意のあるパターンを隠蔽することは、ＨＴＴＰ  ＩＤＳ回避と呼ばれている。
【０００５】
ウィスカ（ｗｈｉｓｋｅｒ）と呼ばれるウェブスキャナが最初に一般にリリースされて以来、ＨＴＴＰ  ＩＤＳ回避は一般的なものとなった。ＨＴＴＰ  ＩＤＳ回避の原型には、このウィスカの最初のリリースに含まれていたものが多い。これらの回避に含まれていたのは、複数のスラッシュを用いてディレクトリを難読化することや、パケット中のＵＲＬを検出するためにＩＤＳの用い得るアルゴリズムを回避するように統一資源位置指定子（ＵＲＬ）に‘ＨＴＴＰ／１．０’を挿入することである。
【０００６】
ウィスカの提示した回避に加えて、他のタイプのＨＴＴＰ難読化も普及した。１つの回避はＵＲＬを難読化することであった。この回避は相対ＵＲＬの代わりに絶対ＵＲＬを用いることによって行われた。これら他のタイプの回避は重要であったが、基本的なウィスカスキャンほどの回避性を有さず、一般的でもなかった。
【０００７】
別の一般的な回避は、マイクロソフト（登録商標）インターネットインフォメーションサービス（ＩＩＳ）ウェブサーバ用に開発された８ビットユニコード変換形式（ＵＴＦ−８）エンコードの一般リリースによって生じた。ＩＩＳが脆弱性を有することに加えて、このエンコードの開発によって、ＩＤＳに実装されていなかった手法によるＵＲＬのエンコード方法が提示された。この開発までは、ほとんどのＩＤＳはＡＳＣＩＩエンコードおよびディレクトリトラバーサルによる従来のウィスカ回避に対し安全機能を確立していたが、ユニコードコードポイントのＵＴＦ−８エンコードについては保護していなかった。
【０００８】
他のタイプのＨＴＴＰ  ＩＤＳ回避ではＨＴＴＰプロトコルのプロパティが利用される。これらの回避のうちの１つでは、リクエストパイプライニングのプロパティが用いられた。別の回避では、コンテンツ−エンコード（ｃｏｎｔｅｎｔ−ｅｎｃｏｄｉｎｇ）ヘッダを用いてリクエストペイロードのＨＴＴＰリクエストパラメータがエンコードされた。
【発明の開示】
【発明が解決しようとする課題】
【０００９】
以上より、ＨＴＴＰエンコード方式またはＨＴＴＰプロトコルパラメータを利用するＨＴＴＰ  ＩＤＳ回避をＩＤＳが識別することを可能とするシステムおよび方法の充分な必要が存在することが認識される。
【課題を解決するための手段】
【００１０】
本発明の一実施形態は、ＩＤＳ用ＨＴＴＰ検査エンジンである。このＨＴＴＰ検査エンジンは、ＨＴＴＰポリシー選択コンポーネントと、リクエスト統一資源識別子（ＵＲＩ）発見コンポーネントと、ＵＲＩ正規化モジュールとを備える。
【００１１】
ＨＴＴＰポリシー選択コンポーネントは、ＩＤＳによってパースされたパケットを用いてウェブサーバＨＴＴＰ侵入検知ポリシーを識別する。ウェブサーバＨＴＴＰ侵入検知ポリシーは、ＩＤＳによってパースされたパケットから取得されるインターネットプロトコルアドレスをインターネットプロトコルアドレスとウェブサーバＨＴＴＰ侵入検知ポリシーとを関連付けるキーワードトライに対するキーとして用いることによって、識別される。ウェブサーバＨＴＴＰ侵入検知ポリシーはパケット検査のために用いられる。ウェブサーバＨＴＴＰ侵入検知ポリシーは、以下に限定されないが、統一資源識別子をパースする命令および統一資源識別子をデコードする命令を含む。
【００１２】
リクエストＵＲＩ発見コンポーネントは、ＩＤＳによってパースされたパケットにおいてＵＲＩを特定する。ＵＲＩを特定するために用いられる方法は、ＨＴＴＰポリシー選択コンポーネントによって識別されるウェブサーバＨＴＴＰ侵入検知ポリシーに基づく。また、リクエストＵＲＩ発見コンポーネントは、ＵＲＩにデコードが必要であるか否かを判定する。ＵＲＩは、パケットＨＴＴＰアプリケーションデータを一度に読み取るワンパス（ｏｎｅ  ｐａｓｓ）検査技術を用いて特定される。パケットＨＴＴＰアプリケーションデータを一度に読み取ることによってＵＲＩを特定し、ＵＲＩにデコードが必要であるか否かを判定することは、例えば、状態機械を用いることによって行われる。
【００１３】
ＵＲＩ正規化モジュールはリクエストＵＲＩ発見コンポーネントによって特定されるＵＲＩ内の難読化をデコードする。難読化は、例えば、ＨＴＴＰポリシー選択コンポーネントによって識別されるウェブサーバによってユニークに認識される統一資源位置指定子フィールドをエンコードすることである。難読化は、以下に限定されないが、１６進デコード、二重パーセント１６進デコード、二重ニブル１６進デコード、第１ニブル１６進デコード、第２ニブル１６進デコード、８ビットユニコード変換形式デコード、８ビットユニコード変換形式空白バイトデコード、マイクロソフト％Ｕデコードおよびミスマッチデコードを含むデコード手法を用いてデコードされる。また、難読化は、ＨＴＴＰアプリケー
ションデータを一度に読み取るワンパス検査技術を用いてデコードされる。ＨＴＴＰアプリケーションデータを一度に読み取ることによって難読化をデコードすることは、例えば、状態機械を用いることによって行われる。
【００１４】
本発明の別の実施形態は、ＩＤＳを用いてネットワーク上のＨＴＴＰ回避を検知するための方法である。ネットワーク上で送信されたパケットが傍受される。パケットは、未アセンブルパケット（例えば、通信線からのパケット）またはアセンブル済みのパケット（例えば、通信線からのパケットからアセンブルされたパケット）を含む。このパケットはパースされる。パケットのインターネットプロトコルアドレスが識別される。そのインターネットプロトコルアドレスに位置するネットワークデバイスに対するウェブサーバＨＴＴＰ侵入検知ポリシーが決定される。ウェブサーバＨＴＴＰ侵入検知ポリシーは、以下に限定されないが、ＵＲＩをパースする命令およびＵＲＩをデコードする命令を含む。ネットワークデバイスは、以下に限定されないが、ウェブクライアントおよびウェブサーバを含む。ウェブサーバＨＴＴＰ侵入検知ポリシーに基づき、パケットからＵＲＩが特定される。ＵＲＩは、パケットＨＴＴＰアプリケーションデータを一度に読み取るワンパス検査技術を用いて特定される。ＨＴＴＰアプリケーションデータを一度に読み取ることによってＵＲＩを特定することは、例えば、状態機械を用いることによって行われる。ＩＤＳのルールによるパターンと特定されたＵＲＩとが比較される。最後に、ＩＤＳのルールによるパターンと特定されたＵＲＩとの間のマッチがＨＴＴＰ回避として識別される。
【００１５】
この方法の別の実施形態では、パケットのインターネットプロトコルアドレスをインターネットプロトコルアドレスとウェブサーバＨＴＴＰ侵入検知ポリシーとを関連付けるキーワードトライに対するキーとして用いることによって、ネットワークデバイスに対するウェブサーバＨＴＴＰ侵入検知ポリシーが決定される。ネットワークデバイスに関するウェブサーバＨＴＴＰ侵入検知ポリシーは、パケットから検出されるＩＰアドレスに関するＨＴＴＰ侵入検知ポリシーである。
【００１６】
この方法の別の実施形態では、パケットに関連付けられたウェブサーバＨＴＴＰ侵入検知ポリシーに基づき、ＵＲＩ内で難読化がデコードされる。難読化は、以下に限定されないが、１６進デコード、二重パーセント１６進デコード、二重ニブル１６進デコード、第１ニブル１６進デコード手法、第２ニブル１６進デコード、８ビットユニコード変換形式デコード、８ビットユニコード変換形式空白バイトデコード、マイクロソフト％Ｕデコードおよびミスマッチデコードを含むデコード手法を用いてデコードされる。難読化は、ＨＴＴＰアプリケーションデータを一度に読み取るワンパス検査技術を用いてデコードされる。ＨＴＴＰアプリケーションデータを一度に読み取ることによって難読化をデコードすることは、例えば、状態機械を用いることによって行われる。例えば、難読化は、ネットワークデバイスのウェブサーバによってユニークに認識されるＵＲＬフィールドをエンコードすることである。ＩＤＳのルールによる１つ以上のパターンが難読化と比較される。最後に、ＩＤＳのルールによる１つ以上のパターンと難読化との間のマッチがＨＴＴＰ回避として識別される。
【００１７】
この方法の別の実施形態では、パケットに埋め込まれた１つ以上の追加のＵＲＩが識別される。ＩＤＳのルールによる１つ以上のパターンが１つ以上の追加のＵＲＩと比較される。ＩＤＳのルールによる１つ以上のパターンと１つ以上の追加のＵＲＩとの間の１つ以上のマッチが、１つ以上のＨＴＴＰ回避として識別される。
【００１８】
この方法の別の実施形態では、ＩＤＳのルールによるパターンとＵＲＩとの間のマッチが記録される。
本発明の別の実施形態はＩＤＳである。このＩＤＳは、パケット捕捉システム、ネットワークプロトコル再アセンブリモジュール、トランスポートプロトコル再アセンブリモジ
ュール、ＨＴＴＰ検査エンジン、検知エンジンおよびロギングシステムを備える。パケット捕捉システムはネットワークを通じて送信されるパケットを傍受し、パケットをパースする。ネットワークプロトコル再アセンブリモジュールはパケットからネットワークプロトコルをパースする。トランスポートプロトコル再アセンブリモジュールはパケットからトランスポートプロトコルをパースする。ＨＴＴＰ検査エンジンはパケットからＨＴＴＰをパースし、パケットに対するウェブサーバＨＴＴＰ侵入検知ポリシーを決定し、ウェブサーバＨＴＴＰ侵入検知ポリシーに基づき、パースしたパケット内のＵＲＩを特定し、かつ、ウェブサーバＨＴＴＰ侵入検知ポリシーに基づきＵＲＩ内の難読化をデコードする。検知エンジンはＨＴＴＰ検査エンジンからＨＴＴＰ検査済みパケット情報を受信し、侵入についてＨＴＴＰ検査済みパケット情報を検査する。ロギングシステムは検知エンジンから侵入検知情報を受信して記憶する。
【発明を実施するための最良の形態】
【００１９】
Ｉ．ＩＤＳ  ＨＴＴＰプロトコル解析
ＩＤＳがＵＲＬ攻撃を取り扱うためには、ＩＤＳは悪意のある攻撃についてＨＴＴＰ  ＵＲＬフィールドを検査する必要がある。２つの最も一般的なＩＤＳ検査方法はパターンマッチングおよびプロトコル解析である。現在、いずれの方法も悪意のあるＵＲＬをサーチする必要があり、このサーチには何らかの形式のパターンマッチングおよび何らかの形式のＨＴＴＰプロトコル解析が伴うので、これらの２つの方法は同様に作用する。
【００２０】
元来、パターンマッチング法とプロトコル解析法との間には差異が存在した。プロトコル解析法では、悪意のあるＵＲＬについてＨＴＴＰストリームのＵＲＬフィールドのみがサーチされたが、パターンマッチング法では、悪意のあるＵＲＬについて全パケットがサーチされた。
【００２１】
悪意のあるＵＲＬのエンコードおよび難読化が開始されるまでは、２つの方法は同様に行われていた。開始時点で、プロトコル解析法ではＵＲＬフィールドへ適切なデコードアルゴリズムを付加することが必要となった。パターンマッチングエンジンには、既にＨＴＴＰプロトコルデコードが組み込まれていた。しかし、パターンマッチング法には、パケットのどの部分をデコードまたは正規化するかを決定する手段が存在しなかった。パターンマッチング法では、適切なデコードアルゴリズムを適用し得るように、ＵＲＬフィールドを検出する何らかの形式のプロトコル解析を組み込む必要があった。パターンマッチング法にＨＴＴＰプロトコル解析の一形式が追加され、２つの方法は再び同様に作用し始めた。
【００２２】
これらのＩＤＳ方法における現在の類似性のため、本明細書に記載のＨＴＴＰ  ＩＤＳ回避は両方のＩＤＳ検査方法に適用される。第１の一般的なＩＤＳ回避は無効なプロトコルパーシングである。例えば、ＨＴＴＰ  ＵＲＬが正確に検出されない場合、悪意のあるＵＲＬはエンコードされても検知されない。換言すると、ＩＤＳがＵＲＬを検出しない場合、ＩＤＳがＵＲＬをデコードすることは不可能である。
【００２３】
第２の一般的なＩＤＳ回避は無効なプロトコルフィールドデコードである。ＵＲＬが正確に検出される場合、ＩＤＳはＵＲＬのフィールドをデコードするために適切なデコードアルゴリズムを認識している必要がある。さもなければ、ＵＲＬはやはり不正確にデコードされる。
【００２４】
Ａ．無効なプロトコルパーシング
ＨＴＴＰプロトコルパーシングを用いて、パケット内でＵＲＩまたはＵＲＬが特定される。無効なプロトコルパーシングを用いるＩＤＳ回避は、スキャナウィスカによって、またサイドステップ（Ｓｉｄｅｓｔｅｐ）と呼ばれるプログラムによって実際に行われる。
これらの２つのプログラム間の差異は、ウィスカが欠陥のあるＩＤＳプロトコルパーシングを用いて検知を回避し、サイドステップは有効な外見のアプリケーション層プロトコルを用いて偽装に弱いプロトコルパーサを実装したＩＤＳを回避することである。ウィスカおよびサイドステップによって明らかとなるように、無効なプロトコルパーシングの回避は、２つのＨＴＴＰプロトコルフィールド、即ち、ＵＲＬおよびＵＲＬパラメータに対して特に有効である。
【００２５】
例えば、ＨＴＴＰリクエストパケット毎に１つのＵＲＬしか存在しないとＩＤＳ  ＨＴＴＰパーサが仮定する場合、１つのパケットで２つのＵＲＬが送信されるときには、ＩＤＳは第２のＵＲＬを正確にパースしない。これはリクエストパイプライニング回避と呼ばれる。
【００２６】
Ｂ．無効なプロトコルフィールドデコード
無効なプロトコルフィールドデコードは、特定のプロトコルフィールドにおいて利用可能な複数のエンコード方式をＩＤＳがデコードまたは正規化する性能をテストする。ＨＴＴＰの場合、これはＵＲＬフィールドにおいて最も明確に見られる。ＨＴＴＰコメント要求（ＲＦＣ）エンコード標準規格への準拠について、またＩＩＳなど、異なるウェブサーバ用のユニークなエンコードタイプに対して、ＩＤＳをテストすることが可能である。ＩＤＳが一定のタイプのＵＲＬエンコードをデコードすることが不可能な場合、攻撃者はこれらのエンコードを用いて悪意のあるＵＲＬの検知を迂回する。
【００２７】
ＨＴＴＰの無効なプロトコルフィールドデコードの別の方法は、ディレクトリ難読化によるものである。ディレクトリ難読化はディレクトリプロパティを操作することによって行われる。例えば、１つのスラッシュの代わりに複数のスラッシュを用いて、‘／ｃｇｉ−ｂｉｎ／ｐｈｆ’を操作し得る、即ち、ディレクトリトラバーサルを用いて正確なディレクトリパスを難読化し得る。
【００２８】
アクセスするファイルの他に１つ以上のディレクトリを含むＵＲＬをＩＤＳが捜す場合のみ、ディレクトリ難読化は悪意のあるＵＲＬを不明瞭化することが可能である。‘／ｃｇｉ−ｂｉｎ／ｐｈｆ’ディレクトリの例では、ＩＤＳが‘ｃｇｉ−ｂｉｎ’ディレクトリの‘ｐｈｆ’ファイルを捜している場合、難読化は機能する。しかしながら、ＩＤＳが単なる‘ｐｈｆ’ファイルを捜している場合、そのコンテンツにはディレクトリパスが存在しないので、ディレクトリ難読化は機能しない。
【００２９】
上述の２つの一般的なＩＤＳ回避については、以下の対応する項目において、より詳細に説明する。
ＩＩ．無効なプロトコルパーシング
Ａ．リクエストパイプラインを用いるＵＲＬ回避
リクエストパイプライン回避は無効なプロトコルパーシング回避の１つのタイプである。リクエストパイプライン回避では、ＨＴＴＰプロトコルのバージョン１．１におけるリクエストパイプラインのプロトコル特性を用いることによって、ＵＲＩを不明瞭化する。
【００３０】
リクエストパイプライン標準規格では、ウェブクライアントが単一のパケット内で幾つかのリクエストを送信することが可能である。これはＨＴＴＰキープ・アライブ（ｋｅｅｐ  ａｌｉｖｅ）ヘッダとは異なるので、混同されない。リクエストパイプラインが幾つかのリクエスト全てを１つのパケットにより送信する場合、ＨＴＴＰキープ・アライブヘッダは、さらなるリクエストに対しＴＣＰストリームを開いておく。
【００３１】
リクエストパイプライン機構を用いて、１つのパケットに幾つかのＵＲＬが埋め込まれる。ほとんどのＩＤＳは第１のＵＲＬを正確にパースするが、他のＵＲＬのパースには失
敗する。他のＵＲＬがエンコード可能となるため、回避の手段が残される。ＩＤＳが追加のＵＲＬをデコードしないため、悪意のあるＵＲＬを捜すコンテンツマッチは失敗する。
【００３２】
例えば、次のペイロードはリクエストパイプライニングを用いてＵＲＬ検知を回避する：
【００３３】
【表１】
2008509458.tif 000003
【００３４】
Ｂ．ＰＯＳＴおよびコンテンツ−エンコードを用いるパラメータ回避
悪意のあるデータまたは攻撃を含む別の共通ＨＴＴＰプロトコルフィールドはＵＲＬパラメータフィールドである。ほとんどのデータベースおよびコモンゲートウェイインタフェース（ＣＧＩ）の攻撃は、ＵＲＬパラメータフィールドにおいて発生する。ほとんどのＩＤＳは悪意のあるパラメータのキーおよび値を検知するためのシグネチャを含む。
【００３５】
ＩＤＳを回避する一方法は、ＵＲＬがエンコードされるようにＵＲＬフィールドパラメータをエンコードすることである。しかしながら、ほとんどのＩＤＳは既にＵＲＬデコード手法をパラメータフィールドにも適用している。
【００３６】
回避の別の方法は、ＰＯＳＴリクエストを用いてパラメータフィールドをＨＴＴＰリクエストヘッダ部分の終わりへ移動させることである。この部分では、パラメータフィールドは平文であり、ＩＤＳは悪意のあるコンテンツを容易に取り除くことが可能である。代わりに、コンテンツ−エンコードのヘッダオプションを用いると、パラメータフィールドはｂａｓｅ６４エンコードを用いてエンコードされる。パラメータフィールドはエンコードされた形式でネットワークを通じて送信される。ＩＤＳはＰＯＳＴリクエストを正確にパースする必要があるだけでなく、パラメータフィールドを検査する前にｂａｓｅ６４を用いて、パラメータフィールドをデコードする必要もある。
【００３７】
実際にＩＤＳがｂａｓｅ６４を用いてＰＯＳＴリクエストのパラメータフィールドをデコードする場合、デコードは非常に時間を消費するものとなるであろう。また、デコードの必要な大きなパラメータフィールドと共に多数のＰＯＳＴリクエストを送信することによるＤＯＳ攻撃にも弱いであろう。
【００３８】
ＩＩＩ．無効なプロトコルフィールドデコード
ＵＲＬ難読化は、ＨＴＴＰサーバが受容する様々なタイプのエンコード方法によって開始される。ほとんどのエンコードタイプはＩＩＳウェブサーバのものであるが、各ＨＴＴＰサーバに対してエンコードのタイプ毎にテストが行われる。
【００３９】
ＩＤＳがウェブサーバ用のエンコードされたタイプをデコードすることが不可能である場合、ＵＲＬが悪意のあるものであるか否かをＩＤＳが判定することは不可能である。パターンマッチング法およびプロトコル解析法のいずれにも、この問題は存在する。
【００４０】
リクエストＵＲＩのエンコードには、２つのＲＦＣ標準規格しか存在しない。それらは１６進エンコードおよびＵＴＦ−８エンコードについての標準規格である。これらの２つの標準規格はエンコードされる各バイトをエスケープするために‘％’文字を用いてエンコードされる。なお、アパッチ（Ａｐａｃｈｅ）ウェブサーバは、これらの２つのＵＲＬエンコードタイプしか受容しない。ＵＲＬ難読化を可能とする他のエンコードタイプは、
サーバに固有であり、非ＲＦＣ準拠である。ＩＩＳウェブサーバでは非ＲＦＣ準拠のエンコードタイプが可能である。
【００４１】
Ａ．１６進エンコード
１６進エンコード法はＵＲＬをエンコードするためのＲＦＣ準拠の手法のうちの１つである。また、１６進エンコード法はＵＲＬをエンコードする最も一般的な方法でもある。このエンコード法は、エンコードされた文字に対する１６進バイト値を‘％’文字によってエスケープすることからなる。大文字の‘Ａ’（ＡＳＣＩＩマップの十六進値で‘０ｘ４１’）がエンコードされる場合、そのエンコードは
％４１＝‘Ａ’
のように示される。
【００４２】
Ｂ．二重パーセント１６進エンコード
二重パーセント１６進エンコードは１６進エンコードの標準的な方法に基づく。‘％’は１６進エンコードを用いてエンコードされ、エンコードされる１６進バイト値が後に続く。大文字の‘Ａ’をエンコードするためのエンコードは、次のように示される：
％２５４１＝‘Ａ’
‘％’は‘％２５’とエンコードされる。次いで、この値は再び、この例では‘％４１’である値（これは‘Ａ’と等しい）にデコードされる。このエンコードはＩＩＳウェブサーバによってサポートされる。
【００４３】
Ｃ．二重ニブル１６進エンコード
二重ニブル１６進エンコードは標準規格の１６進エンコード法に基づく。各１６進ニブル値は標準規格の１６進エンコードを用いてエンコードされる。例えば、大文字の‘Ａ’をエンコードするためのエンコードは、次のように示される：
％％３４％３１＝‘Ａ’
‘Ａ’の標準的な１６進エンコードは‘％４１’である。各１６進ニブル値は標準的な１６進エンコード形式によりエンコードされる。したがって、第１のニブル‘４’は‘％３４’（数字‘４’のＡＳＣＩＩ値）としてエンコードされ、第２のニブル‘１’は‘％３１’（数字‘１’のＡＳＣＩＩ値）としてエンコードされる。
【００４４】
ＵＲＬデコードの第１のパスでは、ニブル値は数字‘４’および‘１’へと変換される。‘％’が‘４’および‘１’に先行するので、第２のパスは‘％４１’を認識し、‘％４１’を大文字のＡとしてデコードする。このエンコードはＩＩＳウェブサーバによってサポートされる。
【００４５】
Ｄ．第１ニブル１６進エンコード
第１ニブル１６進エンコードは二重ニブル１６進エンコードと非常に類似している。差異は、第１ニブルしかエンコードされないことである。大文字の‘Ａ’は、二重ニブル１６進エンコードにおいて‘％％３４％３１’としてエンコードされる代わりに、第１ニブル１６進エンコードを用いて次のようにエンコードされる：
％％３４１＝‘Ａ’
先のように、ＵＲＬデコードの第１のパスでは‘％３４’が数字‘４’としてデコードされ、第２のパスに‘％４１’を与える。第２のパスでは、‘％４１’が大文字の‘Ａ’としてデコードされる。このエンコードはＩＩＳウェブサーバによってサポートされる。
【００４６】
Ｅ．第２ニブル１６進エンコード
第２ニブル１６進エンコードは、第２の１６進ニブル値が標準的な１６進エンコードによってエンコードされることを除いて、第１ニブル１６進エンコードと同じである。大文字の‘Ａ’は次のようにエンコードされる：
％４％３１＝‘Ａ’
デコードの第１パスにおいて‘％３１’が数字‘１’へデコードされ、次いで、第２のパスにおいて‘％４１’が大文字の‘Ａ’としてデコードされる。このエンコードはＩＩＳウェブサーバによってサポートされる。
【００４７】
Ｆ．ＵＴＦ−８エンコード
ＵＴＦ−８エンコードはバイトストリーム中で１バイト（０〜２５５）より大きな値が表現されることを可能とする。ＨＴＴＰウェブサーバはＵＴＦ−８エンコードを用いて、ＡＳＣＩＩコードポイントの範囲（１〜１２７）の外にあるユニコードコードポイントを表現する。
【００４８】
ＵＴＦ−８はバイト中の高位ビットに特別な意味を与えることによって機能する。以下に２バイト、３バイトのＵＴＦ−８シーケンスを示す：
【００４９】
【表２】
2008509458.tif 000004
【００５０】
ＵＴＦ−８シーケンス全体に存在するバイト数を示すため、ＵＴＦ−８シーケンスの第１のバイトが最も重要である。シーケンス全体のバイト数は最初の０までの高位ビットを数えることによって決定される。２バイトシーケンスの例では、第１のバイトは２つの高位ビットのセットを含み、その後に０が続く。これは２バイトのＵＴＦ−８シーケンスを示す。第１のＵＴＦ−８バイトの０の後の残りのビットは、計算される最終的な値のビットである。
【００５１】
最初のバイトに続くＵＴＦ−８バイトは全て、高位ビットに０が続く同じ形式を有する。ＵＴＦ−８バイトを識別するために２ビットが用いられるので、値を計算するためには６ビットが用いられる。
【００５２】
ＵＲＬにおいてＵＴＦ−８をエンコードするために、ＵＴＦ−８シーケンスは各バイト毎に‘％’によってエスケープされる。ＵＴＦ−８エンコードされた文字は、次のように示される：
％ＣＯ％ＡＦ＝‘／’
ＵＴＦ−８エンコードはユニコードコードポイントの値をエンコードするために用いられる。コードポイントの値は、通常、０〜６５５３５の範囲に含まれる。１２７より大きな任意のコードポイントの値は、ＨＴＴＰ  ＵＲＬにおいてＵＴＦ−８エンコードを用いる。
【００５３】
０〜１２７のユニコードコードポイントの値は、１対１でＡＳＣＩＩ値とマッピングされる。このため、ハンガリー語や日本語などの言語では、他の文字を表現するためにほぼ６５４０８の値が残されている。
【００５４】
通常、これらの言語は、それらの言語が必要とする文字を表現するそれらの言語自体のユニコードコードページを有する。ユニコードコードポイントの値はユニコードコードページから導かれる。各ユニコードコードページはユニークな値のセットを有することが可能である。したがって、ユニコードコードページが変化するにしたがって、ユニコードコードポイントの表現する文字も変化する。誤ったコードページを用いてユニコードコード
ポイントが解釈される場合、結果は無効である。ＵＲＬエンコードでは、この概念は重要である。
【００５５】
ＵＴＦ−８エンコードを用いて、ＩＤＳにおける混乱に弱いユニコードコードポイントを表現することには、３つの特徴が存在する。第１の特徴は、ＵＴＦ−８が単一のコードポイントまたはＡＳＣＩＩ値を１つ以上の手法によってエンコード可能であるということである。これは現在のユニコード標準規格では修復されているが、（アパッチ以外の）幾つかのウェブサーバでは依然として普及している。例えば、２バイトのＵＴＦ−８シーケンスでは、大文字の‘Ａ’は次のようにエンコードされる：
【００５６】
【表３】
2008509458.tif 000005
【００５７】
また、３バイトのＵＴＦ−８シーケンスでは、大文字の‘Ａ’は次のようにエンコードされる：
【００５８】
【表４】
2008509458.tif 000006
【００５９】
このように、ＵＴＦ−８を用いてＡＳＣＩＩ文字をエンコードすることによって、１つ以上の表現が生じる。
第２の特徴は、幾つかの非ＡＳＣＩＩユニコードコードポイントがＡＳＣＩＩ文字に対してもマッピングされていることである。例えば、ユニコードコードポイント‘１２００１’は大文字の‘Ａ’に対しマッピングされ得る。いずれのコードポイントがＡＳＣＩＩ文字に対しマッピングされているかを決定する唯一の方法は、ユニコード符号マップを読むこと、または異なるユニコードコードポイントの全てについてサーバに対しテストを行うことである。現在、このマッピングを行うことが知られている唯一のウェブサーバはＩＩＳウェブサーバである。
【００６０】
第３の特徴は第２の特徴に関連している。ユニコードコードマップが変更されているか、または認識されていない場合、解釈されるユニコードコードポイントは無効である。例えば中国、日本およびポーランドのＩＩＳウェブサーバは異なるコードページを用いるので、このことは重要である。ウェブサーバがいずれのコードページを使用しているかをＩＤＳが認識していない場合、ＵＴＦ−８のＵＲＬデコードを行うことは無効である。特定のサーバに対していずれのユニコードコードページを使用するかについてＩＤＳを設定可能でない場合、ＩＤＳが知識を有するコードページを使用しない任意のウェブサーバを回避することが可能である。
【００６１】
Ｇ．ＵＴＦ−８空白バイト（ｂａｒｅ  ｂｙｔｅ）エンコード
ＵＴＦ−８バイトシーケンスが‘％’によってエスケープされないということ以外、ＵＴＦ−８空白バイトエンコードはＵＴＦ−８エンコードと同じである。バイトシーケンスは実際のバイトによって送信される。大文字の‘Ａ’がネットワークを通じて送信される場合、次に示すように表現される：
０ｘＣ１  ０ｘ８１＝‘Ａ’
この種のエンコードは、ＩＩＳウェブサーバ上でのみ実行されることが知られている。
【００６２】
Ｈ．マイクロソフト％Ｕエンコード
マイクロソフト％Ｕエンコードは、６５５３５（即ち、２バイト）までのユニコードコードポイントの値をエンコードするための異なる一手法を提示する。この形式では、ユニコードコードポイントの値を表現する４つの１６進ニブル値に‘％Ｕ’が先行する。その形式は次のように示される：
％ＵＸＸＸＸ
例えば、大文字の‘Ａ’は次のようにエンコードされ得る：
％Ｕ００４１＝‘Ａ’
このエンコードはＩＩＳウェブサーバによってサポートされる。
【００６３】
Ｉ．ミスマッチエンコード
ミスマッチエンコードは異なるエンコードタイプを用いてＡＳＣＩＩ文字を表現し、それ自体はユニークなエンコードではない。ミスマッチエンコードは様々なタイプのエンコードを組み合わせて単一の文字をエンコードする。
【００６４】
例えば、大文字の‘Ａ’はマイクロソフト％Ｕエンコード法を用いてエンコードされる。しかしながら、ＩＩＳウェブサーバはＵＲＬに対し二重デコードを実行するので、別の手法を用いて‘％Ｕ’がエンコードされ得る。例えば、‘Ｕ’は標準的な１６進エンコードによってエンコードされ得る。したがって、‘％Ｕ００４１’は‘％％５５００４１になる。さらに、‘００４１’は標準的な１６進エンコードまたは別のタイプのエンコードによってエンコードされ得る。
【００６５】
ＩＩＳウェブサーバにおいて機能する、より複雑なエンコードミスマッチは
％Ｕ００２５％５５０％３０３％３７＝‘７’
のように示される。
【００６６】
ＩＶ．ＨＴＴＰ検査エンジン
図１は、本発明の一実施形態によるＩＤＳ  １００用の代表的なＨＴＴＰ検査エンジン１２０のコンポーネントを示す概略図である。システム１００では、ＨＴＴＰ検査エンジン１２０はＨＴＴＰポリシー選択コンポーネント１３０、リクエストＵＲＩ発見コンポーネント１４０およびＵＲＩ正規化モジュール１５０を備える。未検査のパケット１１０が、ＨＴＴＰ検査エンジン１２０によってＩＤＳから取得される。ＨＴＴＰアプリケーションデータ用にＩＤＳによって受信されるパケット全てを検査することは非効率的であろう。その結果として、ＨＴＴＰ検査エンジン１２０は、ウェブサーバとの間を移動するパケットを最初に識別するように設計されている。この識別は、未検査のパケット１１０に関連付けられたウェブサーバＨＴＴＰ侵入検知ポリシーが存在するか否かを判定することによって行われる。
【００６７】
ＨＴＴＰポリシー選択コンポーネント１３０は、未検査のパケット１１０からウェブサーバＨＴＴＰ侵入検知ポリシーを識別することを試みる。ＨＴＴＰポリシー選択コンポーネント１３０は、ウェブサーバＨＴＴＰ侵入検知ポリシーによりインターネットプロトコルアドレスを識別するキーワードトライに対するキーとして用いることによって、ウェブサーバＨＴＴＰ侵入検知ポリシーをサーチする。ウェブサーバＨＴＴＰ侵入検知ポリシーは未検査のパケット１１０の検査に用いられる。ウェブサーバＨＴＴＰ侵入検知ポリシーは、以下に限定されないが、ＵＲＩをパースする命令およびＵＲＩをデコードする命令を含む。
【００６８】
未検査のパケット１１０がウェブサーバＨＴＴＰ侵入検知ポリシーと関連付けられると
、リクエストＵＲＩ発見コンポーネント１４０は未検査のパケット１１０内のＵＲＩを特定することを試みる。ＵＲＩは、未検査のパケット１１０に対し識別されるウェブサーバＨＴＴＰ侵入検知ポリシーに基づき特定される。典型的には、パケット中のＵＲＩの形態は次の通りである：
【００６９】
【表５】
2008509458.tif 000007
【００７０】
ＵＲＩを特定する代表的な一方法は状態機械アプローチである。この状態機械アプローチには、最初に第１の空白デリミタ（‘＜ｓｐａｃｅ＞’）をサーチすることが含まれる。空白デリミタが検出されない場合、状態は‘ＵＲＩ内’である。次いで、ＵＲＩが読み取られる。第１の空白が検出される場合、ＵＲＩも‘ＵＲＩ内’状態へ移される。次いで、ＵＲＩは第２の空白デリミタ（‘＜ｓｐａｃｅ＞’）またはＨＴＴＰデリミタ（‘ＨＴＴＰ／ｘ．ｘ＜ＣＲ＞＜ＬＦ＞’）のいずれのデリミタが最初に現われても、それらのデリミタまで処理される。第２のデリミタが存在しない場合、パケットの残り部分はＵＲＩの一部であると仮定される。全ての他の状態は‘ＵＲＩ外’である。
【００７１】
全てのウェブサーバが空白デリミタを必要とする訳ではない。幾つかのウェブサーバはタブもデリミタとして認識する。また、全てのウェブサーバが、キャリッジリターン（‘＜ＣＲ＞’）およびラインフィード（‘＜ＬＦ＞’）で終わるＨＴＴＰデリミタを認識する訳ではない。幾つかのウェブサーバは単に‘＜ＬＦ＞’で終わるＨＴＴＰデリミタを認識する。ＵＲＩ発見コンポーネント１４０は、ＨＴＴＰポリシー選択コンポーネント１３０によって識別されるウェブサーバＨＴＴＰ侵入検知ポリシーに基づき、適切なパーシング法を選択する。
【００７２】
状態機械法を用いてパケットをパースするため、パケット中のＨＴＴＰアプリケーションデータを一度に読み取ることによってＵＲＩが特定される。ＨＴＴＰアプリケーションデータが読み取られると同時に、ＵＲＩ発見コンポーネント１４０はＵＲＩをデコードする必要があるか否かを判定する。ＵＲＩ発見コンポーネント１４０は、‘％’などＵＲＩ中のエンコードされた文字をサーチすることによって、ＵＲＩをデコードする必要があるか否かを判定する。
【００７３】
ＵＲＩがＵＲＩ発見コンポーネント１４０によって特定されており、ＨＴＴＰ侵入検知ポリシーによってデコード難読化に対する命令が提供される場合、ＵＲＩ正規化モジュール１５０はリクエストＵＲＩ発見コンポーネント１４０によって特定されたＵＲＩ内の難読化をデコードすることを試みる。例えば、難読化は、ＨＴＴＰポリシー選択コンポーネント１３０により識別されたウェブサーバによって認識されるＵＲＬフィールドをエンコードすることである。ＵＲＩ正規化モジュール１５０は、エンコードされた文字およびディレクトリトラバーサルを含めて、ＵＲＩ発見コンポーネント１４０によって検知される難読化をデコードする。
【００７４】
難読化は、例えば、状態機械を用いてデコードされる。この結果、難読化はＨＴＴＰアプリケーションデータを一度に読み取ることによって検出される。状態機械アプローチは、バックスラッシュ（‘＼’）、右上がりスラッシュ（‘／’）、パーセント（‘％’）および非ＡＳＣＩＩ文字（０ｘ８０〜０ｘＦＦ）を捜すことからなる。これらの文字のうちの１つが検出される場合、ＵＲＩ正規化モジュール１５０は状態機械に入り、検出されない場合、次の文字が処理される。バックスラッシュまたは右上がりスラッシュが検出さ
れる場合、ＵＲＩ正規化モジュール１５０は‘ＤＩＲＥＣＴＯＲＹ’状態に入り、ディレクトリの位置をバッファにトラッキングする。‘ＤＩＲＥＣＴＯＲＹ’状態遷移の直後にドット（‘．’）に遭遇する場合、ＵＲＩ正規化モジュール１５０は‘ＤＩＲＥＣＴＯＲＹ＿ＴＲＡＶＥＲＳＡＬ１’状態に入る。‘ＤＩＲＥＣＴＯＲＹ’状態（複数のスラッシュを１つのスラッシュへ正規化する）においてバックスラッシュまたは右上がりスラッシュに遭遇する場合、ＵＲＩ正規化モジュール１５０は、その状態のままである。‘ＤＩＲＥＣＴＯＲＹ’状態においてバックスラッシュにも右上がりスラッシュにも遭遇しない場合、状態は通常状態へ戻る。
【００７５】
‘ＤＩＲＥＣＴＯＲＹ＿ＴＲＡＶＥＲＳＡＬ１’状態の直後にドットが検出される場合、ＵＲＩ正規化モジュール１５０は‘ＤＩＲＥＣＴＯＲＹ＿ＴＲＡＶＥＲＳＡＬ２’状態へ遷移する。‘ＤＩＲＥＣＴＯＲＹ＿ＴＲＡＶＥＲＳＡＬ１’状態において右上がりスラッシュまたはバックスラッシュが検出される場合、自己ディレクトリトラバーサルが検出され、ＵＲＩ正規化モジュール１５０はディレクトリを最後の右上がりスラッシュへ戻して正規化する。‘ＤＩＲＥＣＴＯＲＹ＿ＴＲＡＶＥＲＳＡＬ１’状態において右上がりスラッシュもバックスラッシュも検出されない場合、状態は通常状態へ戻る。
【００７６】
‘ＤＩＲＥＣＴＯＲＹ＿ＴＲＡＶＥＲＳＡＬ２’状態の直後に右上がりスラッシュまたはバックスラッシュが検出される場合、ディレクトリトラバーサルが検出され、ＵＲＩ正規化モジュール１５０はディレクトリを２つのディレクトリ位置へ戻して正規化する。‘ＤＩＲＥＣＴＯＲＹ＿ＴＲＡＶＥＲＳＡＬ２’状態の直後に右上がりスラッシュもバックスラッシュも検出されない場合、状態は通常状態へ戻る。
【００７７】
パーセント文字が検出される場合、ＵＲＩ正規化モジュール１５０は‘ＤＥＣＯＤＥ’状態に入る。追加のパーセント文字に遭遇する場合、ＵＲＩ正規化モジュール１５０は‘ＤＯＵＢＬＥ  ＤＥＣＯＤＥ’状態へ遷移する。ＵＲＩ正規化モジュール１５０が‘ＤＥＣＯＤＥ’状態において非１６進文字に遭遇する場合、ＵＲＩ正規化モジュール１５０は‘ＩＮＶＡＬＩＤ＿ＤＥＣＯＤＥ’状態に入る。ＵＲＩ正規化モジュール１５０が上下の‘ｕ’の場合に遭遇する場合、ＵＲＩ正規化モジュール１５０は‘Ｕ＿ＥＮＣＯＤＩＮＧ’状態に入る。それ以外の場合、ＵＲＩ正規化モジュール１５０は‘ＤＥＣＯＤＥ’状態のまま、続いて次の文字へ進む。ＵＲＩ正規化モジュール１５０が‘ＤＥＣＯＤＥ’状態の２つの標準的な文字を処理した場合、ＵＲＩ正規化モジュール１５０はデコードされた１６進文字の値を計算する。
【００７８】
‘ＤＥＣＯＤＥ’状態において、デコードした１６進文字の値がパーセントである場合、ＵＲＩ正規化モジュール１５０は‘ＤＯＵＢＬＥ＿ＤＥＣＯＤＥ’状態へ遷移する。デコードされた１６進文字の値が非ＡＳＣＩＩである場合、ＵＲＩ正規化モジュール１５０は‘ＵＴＦ＿８’状態へ遷移する。ＵＲＩ正規化モジュール１５０が‘ＤＯＵＢＬＥ＿ＤＥＣＯＤＥ’状態にある場合、ＵＲＩ正規化モジュール１５０は‘ＤＥＣＯＤＥ’状態を継続しているかのようであるが、‘ＵＴＦ＿８’状態または‘ＤＯＵＢＬＥ＿ＤＥＣＯＤＥ’状態に遷移することは不可能である。代わりに、パーセント文字または非ＡＳＣＩＩ文字により、ＵＲＩ正規化モジュール１５０は‘ＩＮＶＡＬＩＤ＿ＤＥＣＯＤＥ’状態となる。
【００７９】
ＵＲＩ正規化モジュール１５０が‘Ｕ＿ＥＮＣＯＤＩＮＧ’状態にある場合、ＵＲＩ正規化モジュール１５０は次の４文字を読み取る。これらの文字のうちのいずれも１６進文字（０〜９、ａ〜ｚ、Ａ〜Ｚ）でない場合、ＵＲＩ正規化モジュール１５０は‘ＩＮＶＡＬＩＤ＿ＤＥＣＯＤＥ’状態に入る。これらの文字のうちのいずれかが１６進文字である場合、ＵＲＩ正規化モジュール１５０は、１６進文字の値を計算し、その値を初期化されたユニコード値と比較する。マッチが存在する場合、ＵＲＩ正規化モジュール１５０はそ
の文字をマッピングされたバイト値へデコードする。マッチが存在しない場合、ＵＲＩ正規化モジュール１５０は‘ＩＮＶＡＬＩＤ＿ＤＥＣＯＤＥ’状態に入る。マッピングされたバイト値がパーセントと等しい場合、ＵＲＩ正規化モジュール１５０は‘ＤＯＵＢＬＥ＿ＤＥＣＯＤＥ’状態に入る。
【００８０】
ＵＲＩ正規化モジュール１５０が‘ＵＴＦ＿８’状態にある場合、またはＵＲＩ正規化モジュール１５０が通常状態（開始状態）にあるときにＵＲＩ正規化モジュール１５０が非ＡＳＣＩＩ文字を検出する場合、ＵＲＩ正規化モジュール１５０は、計算値がＵＴＦ−８エンコード形式を順守していることを検査する。この値が有効なＵＴＦ−８エンコードである場合、ＵＲＩ正規化モジュール１５０は‘ＤＯＵＢＬＥ＿ＤＥＣＯＤＥ’ルーチンを用いて次のバイトのデコードを続ける。ＵＲＩ正規化モジュール１５０が‘ＤＯＵＢＬＥ＿ＤＥＣＯＤＥ’ルーチンから‘ＩＮＶＡＬＩＤ＿ＤＥＣＯＤＥ’状態に遭遇する場合、またはデコードされた文字がＵＴＦ−８エンコード形式を順守していない場合、ＵＲＩ正規化モジュール１５０は‘ＩＮＶＡＬＩＤ＿ＤＥＣＯＤＥ’状態へ遷移する。それ以外の場合、ＵＲＩ正規化モジュール１５０は、この値を初期化されたユニコード値と比較する。マッチが存在する場合、ＵＲＩ正規化モジュール１５０はその文字をマッピングされたバイト値へデコードする。マッチが存在しない場合、ＵＲＩ正規化モジュール１５０は‘ＩＮＶＡＬＩＤ＿ＤＥＣＯＤＥ’状態に入る。ＵＲＩ正規化モジュール１５０が‘ＩＮＶＡＬＩＤ＿ＤＥＣＯＤＥ’状態へ遷移する場合、ＵＲＩ正規化モジュール１５０は無効なデコードがデータバッファに存在することを示す既知の値へと、デコードされた文字を正規化する。
【００８１】
難読化をデコードするために用いられる方法には、以下に限定されないが、１６進デコード、二重パーセント１６進デコード、二重ニブル１６進デコード、第１ニブル１６進デコード、第２ニブル１６進デコード、ＵＴＦ−８デコード、ＵＴＦ−８空白バイトデコード、マイクロソフト％Ｕデコードおよびミスマッチデコードが含まれる。これらの例は上述において説明した。
【００８２】
難読化をデコードすることによって、検査済みのパケット１６０はＵＲＩ正規化モジュール１５０を退出し、さらなる処理のためにＩＤＳへ戻る。
図２は、本発明の一実施形態による、ＩＤＳを用いてネットワーク上のＨＴＴＰ回避を検知するための代表的な一方法２００を示すフローチャートである。
【００８３】
方法２００の工程２１０では、ネットワーク上で送信されたパケットが傍受される。パケットは、未アセンブルパケットまたはアセンブル済みのパケットを含む。
工程２２０では、パケットがパースされる。例えば、ＩＤＳはパケットをネットワーク、トランスポートおよびアプリケーションのデータへパースする。
【００８４】
工程２３０では、パケットのインターネットプロトコルアドレスが識別される。
工程２４０では、そのインターネットプロトコルアドレスに位置するネットワークデバイスに対するウェブサーバＨＴＴＰ侵入検知ポリシーが決定される。ウェブサーバＨＴＴＰ侵入検知ポリシーは、以下に限定されないが、ＵＲＩをパースする命令およびＵＲＩをデコードする命令を含む。ネットワークデバイスは、以下に限定されないが、ウェブクライアントおよびウェブサーバを含む。
【００８５】
工程２５０では、ウェブサーバＨＴＴＰ侵入検知ポリシーに基づき、パケット内でＵＲＩが特定される。ＵＲＩは、パケットＨＴＴＰアプリケーションデータを一度に読み取るワンパス検査技術を用いて特定される。パケットＨＴＴＰアプリケーションデータを一度に読み取ることによってＵＲＩを特定することは、例えば、状態機械を用いることによって行われる。
【００８６】
工程２６０では、ＩＤＳのルールによる１つ以上のパターンと特定されたＵＲＩとが比較される。ルールベースのＩＤＳはマッチされるパターンを含む侵入検知ルールを含むことが、当業者には認識される。
【００８７】
工程２７０では、ＩＤＳのルールによるパターンと特定されたＵＲＩとの間のマッチがＨＴＴＰ回避として識別される。
この方法の別の実施形態では、パケットのインターネットプロトコルアドレスをインターネットプロトコルアドレスとウェブサーバＨＴＴＰ侵入検知ポリシーとを関連付けるキーワードトライに対するキーとして用いることによって、ネットワークデバイスに対するウェブサーバＨＴＴＰ侵入検知ポリシーが決定される。ネットワークデバイスに関するウェブサーバＨＴＴＰ侵入検知ポリシーは、パケットから検出されるＩＰアドレスに関するＨＴＴＰ侵入検知ポリシーである。
【００８８】
この方法の別の実施形態では、パケットに関連付けられたウェブサーバＨＴＴＰ侵入検知ポリシーに基づき、ＵＲＩ内で難読化がデコードされる。難読化は、以下に限定されないが、１６進デコード、二重パーセント１６進デコード、二重ニブル１６進デコード、第１ニブル１６進デコード手法、第２ニブル１６進デコード、８ビットユニコード変換形式デコード、８ビットユニコード変換形式空白バイトデコード、マイクロソフト％Ｕデコードおよびミスマッチデコードを含むデコード手法を用いてデコードされる。難読化は、ＨＴＴＰアプリケーションデータを一度に読み取るワンパス検査技術を用いてデコードされる。ＨＴＴＰアプリケーションデータを一度に読み取ることによって難読化をデコードすることは、例えば、状態機械を用いることによって行われる。例えば、難読化は、ネットワークデバイスのウェブサーバによってユニークに認識されるＵＲＬフィールドをエンコードすることである。ＩＤＳのルールによる１つ以上のパターンが難読化と比較される。最後に、ＩＤＳのルールによる１つ以上のパターンと難読化との間のマッチがＨＴＴＰ回避として識別される。
【００８９】
この方法の別の実施形態では、パケットに埋め込まれた１つ以上の追加のＵＲＩが識別される。ＩＤＳのルールによる１つ以上のパターンが１つ以上の追加のＵＲＩと比較される。ＩＤＳのルールによる１つ以上のパターンと１つ以上の追加のＵＲＩとの間の１つ以上のマッチが、１つ以上のＨＴＴＰ回避として識別される。
【００９０】
この方法の別の実施形態では、ＩＤＳのルールによるパターンとＵＲＩとの間のマッチが記録される。
図３は、本発明の一実施形態による、ＨＴＴＰ検査エンジン３７５を含む代表的なＩＤＳ  ３１０のコンポーネントを示す概略図である。システム３００では、ＩＤＳ  ３１０はパケット捕捉システム３６０、ネットワークプロトコル再アセンブリモジュール３６５、トランスポートプロトコル再アセンブリモジュール３７０、ＨＴＴＰ検査エンジン３７５、検知エンジン３８０およびロギングシステム３９０を備える。パケット捕捉システム３６０は、ネットワークデバイス３３０とネットワークデバイス３４０との間のネットワーク３５０を通じて送信されるパケット３２０を傍受し、パケット３２０をパースする。ネットワークプロトコル再アセンブリモジュール３６５は、パケットからネットワークプロトコルをパースする。トランスポートプロトコル再アセンブリモジュール３７０は、パケットからトランスポートプロトコルをパースする。ＨＴＴＰ検査エンジン３７５はパケットからＨＴＴＰをパースし、パケットに対するウェブサーバＨＴＴＰ侵入検知ポリシーを決定し、ウェブサーバＨＴＴＰ侵入検知ポリシーに基づきパケットからＵＲＩをパースし、かつ、ウェブサーバＨＴＴＰ侵入検知ポリシーに基づきＵＲＩ内の難読化をデコードする。検知エンジン３８０はＨＴＴＰ検査エンジン３７５からＨＴＴＰ検査済みパケット情報を受信し、侵入についてＨＴＴＰ検査済みパケット情報を検査する。ロギングシステ
ム３９０は検知エンジン３８０から侵入検知情報を受信して記憶する。
【００９１】
本発明の実施形態は１つ以上のネットワークを介するデータ通信に関する。このデータ通信は、１つ以上のネットワークの１つ以上の通信チャネルによって搬送され得る。ネットワークは有線通信リンク（例えば、同軸ケーブル、銅線、光ファイバ、それらの組合せなど）、無線通信リンク（例えば、衛星通信リンク、地上無線通信リンク、衛星−地上通信リンク、それらの組合せなど）またはそれらの組合せを含むことが可能である。通信リンクは、通信を搬送する１つ以上の通信チャネルを含むことが可能である。例えば、通信リンクは、時分割多重（‘ＴＤＭ’）チャネル、周波数分割多重（‘ＦＤＭ’）チャネル、符号分割多重（‘ＣＤＭ’）チャネル、波長分割多重（‘ＷＤＭ’）チャネル、それらの組合せなど、多重通信チャネルを含むことが可能である。
【００９２】
本発明の一実施形態では、方法を実行するためにプロセッサによって実行されるように構成された命令はコンピュータ可読媒体上に記憶される。コンピュータ可読媒体はデジタル情報を記憶するデバイスであり得る。ソフトウェアを記憶するための技術分野において知られているように、コンピュータ可読媒体は、例えば、コンパクト・ディスクを用いる読み出し専用メモリ（ＣＤ−ＲＯＭ）を含む。コンピュータ可読媒体は、実行されるように構成された命令を実行するのに適切なプロセッサによってアクセスされる。用語「実行されるように構成された命令」および「実行される命令」の意味するところには、その現在の形態（例えば、機械コード）においてプロセッサによって実行可能であるか、またはプロセッサによって実行可能とするためにさらなる操作（例えば、コンパイル、解読、またはアクセスコードの提供など）を必要とする任意の命令が含まれる。
【００９３】
本明細書に開示の本発明の一実施形態によるシステムおよび方法は、ＩＤＳがＨＴＴＰ回避および攻撃を検知する性能を有利に改良することが可能である。ＨＴＴＰポリシー選択コンポーネントはＨＴＴＰ侵入検知ポリシーをパケットと関連付けることによって、検査の必要のあるパケットの数を制限する。リクエストＵＲＩ発見コンポーネントはパケットに関連付けられたウェブサーバＨＴＴＰ侵入検知ポリシーを用いて、パケット内のＵＲＩを特定する。ＵＲＩ正規化モジュールはパケットに関連付けられたウェブサーバＨＴＴＰ侵入検知ポリシーに従ってＵＲＬフィールドをデコードすることによって、ＵＲＩの内の難読化を識別する。
【図面の簡単な説明】
【００９４】
【図１】本発明の一実施形態による代表的なＩＤＳ用ＨＴＴＰ検査エンジンのコンポーネントを示す概略図。
【図２】本発明の一実施形態による、ＩＤＳを用いてネットワーク上のＨＴＴＰ回避を検知するための代表的な方法を示すフローチャート。
【図３】本発明の一実施形態によるＨＴＴＰ検査エンジンを含む代表的なＩＤＳのコンポーネントを示す概略図。
【図１】
2008509458.tif 000008
【図２】
2008509458.tif 000009
【図３】
2008509458.tif 000010