JP2005538620A

JP2005538620A - コンピュータアプリケーションへの不正なリクエストのスクリーニング

Info

Publication number: JP2005538620A
Application number: JP2004534897A
Authority: JP
Inventors: ライナー、リチャード
Original assignee: ライナー、リチャード
Priority date: 2002-09-13
Filing date: 2003-09-12
Publication date: 2005-12-15
Also published as: AU2003269619A8; CA2498649A1; US20050246545A1; AU2003269619A1; WO2004025460A2; WO2004025460A3; EP1540917A2

Abstract

コンピュータアプリケーションへの不正なリクエストが、存在に関する条件、統計的条件、及び複合の普遍条件のうちの少なくとも１つを持つルールを用いてスクリーニングされうる。コンピュータアプリケーションへの不正なハイパーテキスト転送プロトコル（ＨＴＴＰ）リクエストが、リクエストの要素（例えば、ヘッダ）に適用されるルールを用いてスクリーニングされうる。

Description

発明の背景

本発明は、コンピュータアプリケーションへの不正なリクエストのスクリーニングに関する。

コンピュータネットワークでは、情報はパケット形式で通常伝送される。情報の流れは、通常、コンピュータアプリケーションに対して為されるリクエストとアプリケーションによる該リクエストへの応答の形式である。パケットが信頼されていないソース（例えば、公衆インターネット）から来た場合、それらがコンピュータアプリケーションへの不正なリクエストを含んでいる（ｃｏｍｐｒｉｓｅ又はｃｏｎｔａｉｎ）危険性がある。そのような不正なリクエストは、所有者の情報へアクセスしようとする未許可の試み、情報を改竄しようとする未許可の試み、又はアプリケーションの通常の動作に干渉しようとする試み（所謂、「ＤｏＳ攻撃」）を構成しうる。

コンピュータ上のアプリケーションは、アプリケーションに向けられたパケットをフィルタリングするコンピュータファイアウォールによって、不正なリクエストから保護されうる。より詳細には、ファイアウォールはパケットを検証し、予め定義されたアクセスルールのセットに一致するかどうかによって、それらをアプリケーションへと受け渡すかまたはそれらを破棄する。インターネットプロトコル（ＩＰ）に従うパケットの場合、パケットフィルタリングファイアウォールは、インターネットプロトコル（ＩＰ）ナンバー、トランスポートコントロールプロトコル（ＴＣＰ）ポート番号、ユーザデータグラムプロトコル（ＵＤＰ）ポート番号、インターネット制御通知プロトコル（ＩＣＭＰ）タイプコード、及びパケットの他の関連する特徴、のうちの１つ以上に基づき、このスクリーニングを行う。パケットフィルタリングファイアウォールは、ステートレスなものであってもステートフルなものであってもよい。ステートレスファイアウォールフィルタは、各ＩＰデータグラムを独立してフィルタリングする。ステートフルファイアウォールは、コネクションに属するデータグラムをトラッキングし、これにより、より効果的なフィルタリングが可能となる。

パケットフィルタリングファイアウォールは、多くの不正なリクエストをスクリーニング除去するのに効果的であるが、そのようなファイアウォールを破るうまい「攻撃」が未だ発生している。

不正なリクエストからアプリケーションを保護するための別のアプローチには、プロキシファイアウォールの採用がある。プロキシファイアウォールは、公衆ネットワークを介して到達するパケットの宛先として機能し、各パケットから公衆ネットワークを介するパケットの方向付けに使用されたオーバーヘッドを取り除く。このアプローチにより、パケットのネットワークオーバーヘッドを使用するいずれの攻撃も回避される。プロキシファイアウォールは非常に効果的なものでありうるが、既存のプロキシファイアウォールは未だ突破を可能としえ、さらに、プロキシファイアウォールはパケットトラフィックを（しばしばかなり）遅くする。

従って、理想的にはパケットトラフィックの流れに顕著な影響を与えることなく、不正なリクエストを効果的にスクリーニングするためのアプローチの必要性が存在している。

発明の要旨

コンピュータアプリケーションへの不正なリクエストは、存在に関する条件（ｅｘｉｓｔｅｎｔｉａｌｃｏｎｄｉｔｉｏｎ）、統計的条件（ｓｔａｔｉｓｔｉｃａｌｃｏｎｄｉｔｉｏｎ）、及び複合の普遍条件（ｃｏｍｐｌｅｘｕｎｉｖｅｒｓａｌｃｏｎｄｉｔｉｏｎ）のうちの少なくとも１つ以上を持つルールを用いてスクリーニングされうる。コンピュータアプリケーションへの不正なハイパーテキスト転送プロトコル（ＨＴＴＰ）リクエストは、ＨＴＴＰリクエストの要素に適用されるルールを用いてスクリーニングされうる。

本発明によれば、コンピュータアプリケーションへの不正なリクエストをスクリーニングする方法が提供され、該方法は、存在に関する条件、統計的条件、及び複合の普遍条件のうちの少なくとも１つを有するルールを用いてリクエストをスクリーニングすることを含んでいる。該方法を達成するためのコンピュータ読取可能媒体及びスクリーナ（ｓｃｒｅｅｎｅｒ）も提供される。

本発明の別の態様によれば、コンピュータアプリケーションへの不正なハイパーテキスト転送プロトコル（ＨＴＴＰ）リクエストをスクリーニングする方法が提供され、該方法は、ルールを用いてＨＴＴＰリクエストをスクリーニングすることを含んでおり、該ルールは、リクエストの以下のパート：ヘッダ、クッキー、ＨＴＴＰバージョンインジケータ、普遍資源識別子（ＵＲＩ）パラメータ、ＵＲＩエンコードフィールド、マルチパートエンコードフィールド、シンプルオブジェクトアクセスプロトコル（ＳＯＡＰ）要素、ＵＲＩフォーマット、のうちの少なくとも１つについての条件を含んでいる。該方法を達成するためのコンピュータ読取可能媒体及びスクリーナも提供される。

他の特徴及び利点は、図面とともに以下の説明を検討後、明らかとなるだろう。

詳細な説明

インターネットを介して伝送されるパケットは、上位のリンク層、中位のネットワーク層、より下位のトランスポート層、下位のアプリケーション層を含む。より上位の層のそれぞれが、本質的には、パケットである。従って、リンク層は、ヘッダとネットワーク層パケットを含むデータとを有するパケットであり、ネットワーク層パケットは、ヘッダとトランスポート層パケットを含むデータとを有する。リンク層のヘッダは、ほぼ必ず、パケットが従うプロトコルがインターネットプロトコル（ＩＰ）（より旧式のプロトコルは、現在はほとんど廃れているかつ／又はインターネットでは使用されていない）であることを示している。パケットがＩＰパケットである場合、ネットワーク層は、ＩＰデータグラムとして知られている。トランスポート層のヘッダは伝送プロトコルを示す。ＩＰの伝送制御プロトコル（ＴＣＰ）は、それがウェブブラウジング、電子メール、およびウェブサービスに使用されているので、とりわけ最も一般的な伝送プロトコルである。（当業者に理解されるように、ウェブサービスは、あるアプリケーションが別のアプリケーションのリクエストをそれにより作成しうるマシン間の対話である）。

トランスポート層パケットのデータは、アプリケーション層を含む（これは通常、多数のトランスポート層パケットにわたって分散されている）。トランスポート層におけるポート番号、及び／又はコンテキストは、アプリケーション層プロトコルを示している。伝送プロトコルがＴＣＰである場合、アプリケーション層プロトコルは様々なアプリケーション層プロトコルのいずれであってもよいが、最も重要なのは、ハイパーテキスト転送プロトコル（ＨＴＴＰ）、セキュアＨＴＴＰ（ＨＴＴＰＳ）、ファイル転送プロトコル（ＦＴＰ）、及び簡易メール転送プロトコル（ＳＭＴＰ）である。

公知のパケットフィルタリングファイアウォールは、使用されているプロトコルを検証するために、リンク層、ネットワーク層、及びトランスポート層のうちの１つ以上のパケットヘッダにルールを適用しうる。公知のプロキシファイアウォールは、アプリケーションプロトコルを検証しうる。公知のパケットフィルタリングファイアウォール及びプロキシファイアウォールにより適用される各ルールは、「汎用（ｓｉｍｐｌｅｕｎｉｖｅｒｓａｌ）」と呼ばれうる形式である。説明として、ルールは、それが適用される要素のタイプを特定する。ルールは、ルールにより特定されるタイプの全ての要素にそれが適用される場合、汎用ルールである。一例として、ルール「全てのパケットは、送信先ポート番号８０宛でなくてはならない」において、このルールが適用される要素はパケットである。そして、このルールが全てのパケットに適用されるので、それは汎用ルールである。

現在、ＨＴＴＰ（又はＨＴＴＰＳ）は、ウェブブラウジング及びウェブサービスに使用されている。ＨＴＴＰリクエストは、以下の一般的な形式を有する。
＜メソッド＞＜ＵＲＩ＞＜ＨＴＴＰバージョン＞
＜埋め込みクッキーを持つＨＴＴＰヘッダ＞
＜リクエスト本体＞
ここで、「ＵＲＩ」は、普遍資源識別子を示す。ＵＲＩは、ウェブ上のエンティティへのリンクであり、一般には統一資源位置指定子（ＵＲＬ）である。ＵＲＩはまた、任意のＵＲＩパラメータ（これもＧＥＴフィールドとして知られている）を含む。ＨＴＴＰリクエスト中には、０以上のヘッダと０以上のクッキーが存在しうる。本体はオプションであり、もしある場合には、ＵＲＩエンコードフォーマット、フォームマルチパートエンコードフォーマット、シンプルオブジェクトアクセスプロトコル（ＳＯＡＰ）フォーマットを有していてもよいし、本体が体系化されていない内容を有していてもよい。ＵＲＩエンコードフォーマット又はフォームマルチパートエンコードフォーマットを有する本体は、ハイパーテキストマークアップ言語（ＨＴＭＬ）又は拡張可能ＨＴＭＬ（ＸＨＴＭＬ）で記述される。ＳＯＡＰフォーマットを有する本体は、拡張可能マークアップ言語（ＸＭＬ）で記述される。

例として、図１Ａを参照して、ＨＴＴＰリクエスト１０は、ＧＥＴメソッド１２、ＵＲＩ１４、ＨＴＴＰバージョンインジケータ１６、及び埋め込みクッキー２０を持つヘッダ１８、並びに本体２２を有する。この特殊なＨＴＴＰリクエストは本体を持たない。ＵＲＩは、ＵＲＬ２４とＵＲＩパラメータ２６から構成される。

図１Ａから明らかなように、ＵＲＩパラメータ２６は、フォーマット“名”＝“値”を持つ（実施例ＨＴＴＰリクエスト１０は２つのＵＲＩパラメータを持つ）。典型的であるように、ＵＲＩパラメータは、ユーザのカレントセッションを識別する。ヘッダ１８は、フォーマット“名”：“値”を持つ。各クッキーは埋め込まれた名と値とのペアを持ち、各ペアはコロンにより分けられている。従って、クッキー２０はフォーマット：“クッキー”：”名１＝“値１”；“名２”＝“値２”；“名３”＝“値３”・・・を持つ。

図１Ｂは、ＰＯＳＴメソッド１２’、ＵＲＩパラメータを持たないＵＲＩ１４’、ＨＴＴＰバージョンインジケータ１６、埋め込みクッキー２０’を持つヘッダ１８’を有する第２の実施例ＨＴＴＰリクエスト１０’を示している。ＨＴＴＰリクエスト１０’は、本体２２’も有している。本体は、フィールド２５’（各々が、名２４’と値２６’とのペアを持つ）から構成される。リクエスト１０’のヘッダ１８ａ’は、本体２２’が、ＵＲＬエンコードフォーマットを有し、結果として、名−値ペアが形式“名”＝“値”（各ペアは＆によって分けられている）を有することを示している。

図１Ｃの実施例ＨＴＴＰリクエスト１０”は、メソッド１２”、ＵＲＩ１４”、ＨＴＴＰバージョンインジケータ１６”、ヘッダ１８”、及び本体２２”を有している。ヘッダに埋め込まれたクッキーはないことが分かる。ヘッダ１８ａ”は、本体２２”がマルチパートフォームエンコードフォーマットを有することを示している。マルチパートフォームフォーマットの場合、本体のフィールドはパートとして知られている。ヘッダ１８ａ”は、各パートを線引きするパートバウンダリ２８”を指定する。パートバウンダリの後には、データフィールドの名２４”、それに続くフィールド値２６”を含む１つ以上のヘッダ３０”が続く。

図１Ｄの実施例ＨＴＴＰリクエスト１０’’’は、本体の要素２５’’’がＸＭＬ要素、それらの属性、及びＳＯＡＰメッセージフォーマットの仕様に従うデータオブジェクトを含むように、本体２２’’’がＳＯＡＰフォーマットを有することを示すヘッダ１８ａ’’’を持つ。

アプリケーションへの攻撃を始める際にパケットの実際のペイロードデータパート（アプリケーション層）を用いる不正なリクエスト生成元（これは人のハッカーであるかもしれないし機械であるかもしれない）の可能性が存在する。従って、攻撃は、ＨＴＴＰリクエストのパートを使用しうる。そのような攻撃を失敗させるためには、不正なリクエストをスクリーニングするため、各ＨＴＴＰリクエストのパートにスクリーニングルールを適用することが考えられる。

各ルールは、トリガー文（ｔｒｉｇｇｅｒｃｌａｕｓｅ）及び１つ以上の条件を持ちうる。トリガー文は、ルールが適用される全ての可能なリクエストのサブセットを示している。条件は、そのようなリクエストがルールを満たすものであるかどうかを決定するために、トリガー文を満たすリクエストに適用される制限である。

トリガー文は、最も有用には、リクエスト中に現れうるＵＲＩのいくつかのサブセットの仕様として策定される。例えば、トリガー文は、「全てのＵＲＬは拡張子‘．ｇｉｆ’で終わる」、「全てのＵＲＬは文字‘／ｓｃｒｉｐｔｓ’で始まる」、又は「全てのＵＲＬは、小文字、続いて１つの強調文字、続いて１つの小文字の、１つ以上の存在の列を含む」でありうる。

条件は、リクエストのいずれかの又はすべての残りの要素に（すなわち、トリガー文が満たされるかどうかを決定するために使用されるもの以外のリクエストの要素に）適用される制限である。条件は、最も有用には、リクエスト中の要素のたった１つのタイプ（例えば、リクエストのヘッダ）に対する制限を記載するように策定される。この制限は、任意の所望の複雑さの条件を策定するために、他のそのような制限（例えば、ブール、ｉｆ−ｔｈｅｎ、又はファジー理論を使用することによってなど）と組み合わせてもよい。

従って、ルールは、以下のＨＴＴＰ要素（任意の埋め込みクッキー、リクエスト本体のフィールド、ＵＲＩフォーマット、ＵＲＩパラメータ、ＨＴＴＰバージョン、及びヘッダ）のうちの１つ以上に適用可能な１つ以上の条件を持って記述されうる。ルールはまた、メソッドに１つ以上の条件を持ちうる。

リクエストの以下のタイプの要素（ヘッダ、クッキー、ＵＲＩパラメータ、（リクエスト本体の）ＵＲＩエンコードフィールド、（リクエスト本体の）マルチパートエンコードフィールド、及び（リクエスト本体の）ＳＯＡＰ要素）のそれぞれが、リクエスト中に複数例存在しうる。これらのタイプの要素のいずれかについての条件（この条件はそのようなタイプの全ての要素に適用される）が、単純な普遍条件（ｓｉｍｐｌｅｕｎｉｖｅｒｓａｌｃｏｎｄｉｔｉｏｎ）である。従って、例えば、条件「クッキーの全てがアルファベット値を持たなくてはならない」は単純な普遍条件である。アプリケーション層の要素に適用される単純な普遍条件は、不正なリクエストのスクリーニングに有用である。しかしながら、本発明者は、単純な普遍条件ではない条件を用いてリクエストをスクリーニングすることが有用であることに気付いた。より詳細には、本発明者は、存在に関する条件、統計的条件、及び複合の普遍条件が、リクエストをスクリーニングするためのルールに有用であることを見出した。以下は、これらのタイプの条件のそれぞれを説明する。

特定数の所定タイプの要素、或いは、特定のプロパティ（例えば、特定の“名”又は“値”）を持つ特定数の所定タイプの要素の存在を必要とする条件が存在に関するものである。条件が、所定タイプの要素、又は特定のプロパティを持つ所定タイプの要素の存在を単に必要とするときは、条件は単純な存在に関する条件である。例えば、条件「‘セッションＩＤ’と呼ばれるクッキーが存在しなくてはならない」は、クッキー要素の名プロパティに対する単純な存在に関する条件である。必要とされる数に対するより複雑な制限を条件が持つときは、条件は複合の存在に関する条件である。従って、例えば、条件「５個のヘッダが存在しなければならない」及び「数値を有するＰＯＳＴフィールドが３〜５個存在しなくてはならない」は、複合の存在に関する条件である。

条件がリクエスト中の特定タイプの要素のプロパティの統計的尺度に基づく場合、それは統計的条件であると考えられる。例えば、以下は統計的条件である。「ＵＲＩパラメータ値の平均長は３よりも大きくなくてはならない」、「ＰＯＳＴメソッドの場合、リクエスト本体におけるフィールド長の標準偏差は、３〜７でなくてはならない」。（第１の実施例では、要素タイプはＵＲＩパラメータであり、プロパティはそれらの値である。第２の実施例では、“長さ”は特定のプロパティであり、“フィールド”は要素タイプである。）

複合の普遍条件は、所定タイプの全ての要素を考慮に入れるが、その際、そのような要素のうちの全て未満に制限を加える。そのような条件の例は以下のとおりである。「ＰＯＳＴメソッドの場合、１つを除き全てのフィールドが、数値である値を持たなければならない」、「ヘッダの５０％が１００文字長未満でなくてはならない」、「ＰＯＳＴメソッドの場合、フィールドの３０％〜７０％は、ブランクではない値を持たなければならない」。

単純な普遍条件ではない条件を持つルールでのスクリーニングは、単純な普遍条件のみを持つルールで可能なものよりも、ユーザとアプリケーションとの間の許容される対話の形式をより正確に反映することを可能とする。例えば、存在に関する条件を用いた場合、“セッションＩＤ”クッキーの存在を必要とすることが可能である。そして、複合の普遍条件を用いた場合、フォームがそのフィールドブランクの大部分とともに提出されないかもしれないことを保証することが可能である。単純な普遍条件ではない条件の採用は、リクエストが人によって作られたか機械によって作られたかの決定を容易にしうる。正当なリクエストが人により作られる場合には、これは、不正なリクエストを隔離しうる。例えば、ウェブサイトへのＰＯＳＴメソッドの場合（記入したフォームをユーザが提出することから通常生じる）、条件は、リクエストのフィールド中の文字使用の相対頻度と、人の言語に特有な相対頻度とを比較しうる。もし、フィールド中の文字使用の相対頻度が、人の言語に特有なものから閾値を超えて逸脱していたら、条件は満たされないだろう。ＰＯＳＴメソッドに対するさらなる条件は、ブランクフィールドとブランクではないフィールドとの割合を判断しうる。そして、リクエストがこれらの条件のいずれかを満たさない場合、それはスクリーニング除去されうる。

図２は、人が読み取り可能な形式で表現されている実施例ルールセットを示している。（実際には、リクエスト用のルールは、通常はテーブルに記憶され、そして、人が読み取り可能な形式で簡便に表現されうるよりも細かい区別を可能とする様式で、記号を用いて表現されうる。）図２を参照して、トリガー５０は、それと関連付けられた多数の条件５２を有する。各条件は、トリガー条件を満たすリクエスト中に現れうる要素タイプ５６に又は要素タイプ５６のプロパティ５８に、制限５４を確立する。

ルールはリクエストを以下のようにしてスクリーニングするために使用される。
・リクエストは、それが任意のルールのトリガー条件を満たさない場合、ルールに違反している。（すなわち、全てのリクエストがルールによってスクリーニングされるように各リクエストに適用される少なくとも１つのルールが存在する場合であるはずである。）
・リクエストは、それがルールのトリガー文を満たしかつそのルールの各条件を満たさない場合、ルールに違反している。
・リクエストは、それがルールのトリガー文を満たす各々の場合に、それがそのルールの条件の全てを満たしている場合、ルールに適合していると考えられうる。あるいは、ルールがより具体的なものからより一般的なものへと順序付けられている場合、リクエストは、それがトリガー文を満たすリスト中の第１のルールについて、それがそのルールの条件の全てを満たしている場合、ルールに適合していると考えられうる。

リクエストがルールに違反している場合、以下の動作のうちの任意の１つ以上が行われうる：リクエストはスクリーニング除去されうる（すなわち、ブロックされ、従って、それが方向付けられたアプリケーションへは受け渡されない）、違反のログが記録されうる、かつ／又は違反が（システム管理者への）通知又は警告を生じうる。

図３は、本発明の実施形態を採用した実施例ネットワークを示している。図３を見ると、ネットワーク１００は公衆インターネット１１０を含み、公衆インターネット１１０にウェブサーバ１１２がスクリーナ１１４を介して接続されている。ローカルエリアネットワーク（ＬＡＮ）１１６は、ファイアウォール１１８を介して、インターネット１１０に接続されている。多数のワークステーション１２０及びウェブサーバ１２２、１２３が、ＬＡＮ１１６に接続されている。ウェブサーバ１３０は、ファイアウォール１３２を介して、インターネット１１０に接続されている。スクリーナ１３４も、入／出力１３６を介して、ファイアウォール１３２に接続されている。

いくつかのアプリケーションがサーバ１１２上で実行されうる。アプリケーションのそれぞれが、ウェブサービスを提供またはウェブサイトを支援しうる。これらのアプリケーションのそれぞれが、そのホスト名部分又はそのパス部分のプレフィックスセグメントが異なるＵＲＩを持つ。スクリーナ１１４は、ウェブサーバ１１２上のいずれかのアプリケーション宛のリクエストを受信し、それらが内部に記憶されたルールセット（このルールセットは本発明に従う）と一致する場合のみ、それらをウェブサーバへと通過させるように適合された特殊用途の装置（例えば、専用チップまたはＡＳＩＣ）である。

スクリーナ１１４と同様に、スクリーナ１３４は、本発明に従い作製された内部に記憶されたルールセットに違反するリクエストを廃棄するように適合された特殊用途の装置である。スクリーナ１３４は、そのルールセットに一致するリクエストを戻すように適合されている。ファイアウォール１３２は、それがブロックしない全ての入ってきたリクエストをスクリーナ１３４へと受け渡すように改変された任意の公知のファイアウォールでありうる。ファイアウォール１３２はまた、それがスクリーナ１３４から戻ってきたリクエストをウェブサーバ１３０へと方向付けるように改変されている。従って、ウェブサーバ１３０上のアプリケーション宛のリクエストがファイアウォール１３２に達した場合に、ファイアウォールは、その通常様式でリクエストに作用する。ファイアウォールがリクエストをブロックしない場合、それはそれを（場合により改変された形式で）スクリーナ１３４へと受け渡す。スクリーナは、その内部ルールセットをリクエストのアプリケーション層に適用し、リクエストを廃棄するか又はそれをファイアウォールへと戻す。リクエストがファイアウォールへと戻された場合、それはウェブサーバ１３０へと回される。本発明に従うスクリーニングが、さらにセキュリティを高めるために、任意の以前から存在するファイアウォール技術とともに採用されうることは、この実施例構成から明らかである。

ファイアウォール１１８は、メモリを持つプロセッサ上で実行されるアプリケーションである。ファイアウォールアプリケーションは、コンピュータ読取可能媒体１２６から読み込まれたスクリーニングソフトウェアによって改変される。コンピュータ読取可能媒体１２６は、例えば、ディスク、読み出し専用メモリチップ、又はリモートソースからダウンロードされたファイルでありうる。スクリーニングソフトウェアは、その通常様式での動作に加えて、それがスクリーナとして動作する（入ってくるリクエストを本発明に従うルールセットを用いてスクリーニングする）ようにファイアウォール１１８を適合させる。

リクエストがルールセットに違反している場合、法廷で用いられる記録を保存することを可能とするために、そのログが記録されうる。ログは、スクリーナ、関連するファイアウォール、又はログを記録することが可能な別のサーバによって、保存されうる。ログは、リクエストが方向付けられたアプリケーションと関連付けられうる。さらに、スクリーナが１つを超えるアプリケーションを保護する場合、アプリケーション群（例えば、一企業のアプリケーション）についてのログが共に関連付けられうる。

現在、ウェブ検索はキーワードベースである。セマンティックウェブ検索（ｓｅｍａｎｔｉｃｗｅｂｓｅａｒｃｈｉｎｇ）を開発するための試みがなされている。これを支援するために、ウェブページはＨＴＭＬ又はＸＨＴＭＬよりもＸＭＬでコーディングされうる（ＸＭＬはユーザがページ上に任意のデータ要素をマークアップ（タグ）することを可能とするので）。ウェブページがＸＭＬベースとなった場合、リクエストは、ＨＴＭＬよりもＸＭＬでコーディングされる。ＸＭＬベースのリクエストに、そして実際には、任意の他の適切な言語に基づくリクエストに、本発明は適用可能であることが理解される。さらに、ＨＴＴＰ又は任意の他の適切なプロトコルに従うリクエストへの適用を本発明は有する。

記載されたルールはトリガー及び１つ以上の条件を含んでいるが、トリガーは必ずしも必要ではない。トリガーがない場合、ルールは全てのリクエストに適用される。

他の特徴及び利点が当業者には明らかであり、従って、本発明は特許請求の範囲に定義される。

本発明の実施例態様を記載する図において、図１Ａ、１Ｂ、１Ｃ、及び１Ｄは、実施例ＨＴＴＰリクエストの内容を示している。本発明の実施例態様を記載する図において、図１Ａ、１Ｂ、１Ｃ、及び１Ｄは、実施例ＨＴＴＰリクエストの内容を示している。本発明の実施例態様を記載する図において、図１Ａ、１Ｂ、１Ｃ、及び１Ｄは、実施例ＨＴＴＰリクエストの内容を示している。本発明の実施例態様を記載する図において、図１Ａ、１Ｂ、１Ｃ、及び１Ｄは、実施例ＨＴＴＰリクエストの内容を示している。図２は、人が読み取り可能な形式の本発明に従うルールセットの一部の例である。そして、図３は、本発明の実施形態を採用するネットワークの概要図である。

Claims

存在に関する条件、統計的条件、及び複合の普遍条件のうちの少なくとも１つを持つルールを用いてリクエストをスクリーニングすることを含む、コンピュータアプリケーションへの不正なリクエストをスクリーニングする方法。
前記ルールを用いてのスクリーニングが、前記リクエストが特定タイプであることにより引き起こされる、請求項１に記載の方法。
前記ルールが複数の条件を持ち、該複数の条件が、前記リクエストが前記特定タイプであることにより引き起こされる、請求項２に記載の方法。
前記特定タイプが、特定タイプの普遍資源識別子（ＵＲＩ）である、請求項３に記載の方法。
前記存在に関する条件が、所定タイプの特定数の要素が前記リクエスト中に存在することを必要とする、請求項１に記載の方法。
所定タイプの前記要素が、ヘッダ、クッキー、普遍資源識別子（ＵＲＩ）パラメータ、ＵＲＩエンコードフィールド、マルチパートエンコードフィールド、シンプルオブジェクトアクセスプロトコル（ＳＯＡＰ）エンコード要素のうちの１つである、請求項５に記載の方法。
前記存在に関する条件が、所定のプロパティを持つ所定タイプの特定数の要素が前記リクエスト中に存在することを必要とする、請求項１に記載の方法。
前記複合の普遍条件が、所定タイプの特定の割合の要素が前記リクエスト中に存在することを必要とする、請求項１に記載の方法。
前記統計的条件が、リクエスト中の特定タイプの要素のプロパティの統計的尺度に基づくものである、請求項１に記載の方法。
特定タイプの要素の前記プロパティが、特定タイプの前記要素の名又は値のうちの１つである、請求項９に記載の方法。
前記リクエストがハイパーテキスト転送プロトコル（ＨＴＴＰ）リクエストである、請求項１に記載の方法。
前記ルールが、リクエストの以下のパート：ヘッダ、クッキー、メソッド、ＨＴＴＰバージョン、普遍資源識別子（ＵＲＩ）パラメータ、ＵＲＩエンコードフィールド、マルチパートエンコードフィールド、シンプルオブジェクトアクセスプロトコル（ＳＯＡＰ）要素、の１つ以上についての条件を含む、請求項１１に記載の方法。
前記リクエストの前記本体がシンプルオブジェクトアクセスプロトコル（ＳＯＡＰ）に従う、請求項３に記載の方法。
存在に関する条件を持つルールを用いてリクエストをスクリーニングすることを含む、コンピュータアプリケーションへの不正なリクエストをスクリーニングする方法。
コンピュータアプリケーションへの不正なハイパーテキスト転送プロトコル（ＨＴＴＰ）リクエストをスクリーニングする方法であって、該方法は、ルールを用いてＨＴＴＰリクエストをスクリーニングすることを含み、該ルールは、リクエストの以下のパート：ヘッダ、クッキー、ＨＴＴＰバージョンインジケータ、普遍資源識別子（ＵＲＩ）パラメータ、ＵＲＩエンコードフィールド、マルチパートエンコードフィールド、シンプルオブジェクトアクセスプロトコル（ＳＯＡＰ）要素、ＵＲＩフォーマット、のうちの少なくとも１つについての条件を含む、方法。
前記ルールを用いたスクリーニングが、前記リクエストのＵＲＩが特定タイプであることにより引き起こされる、請求項１５に記載の方法。
リクエストが条件を満たさないと判明した時、該リクエストをブロックすることをさらに含む、請求項１５に記載の方法。
リクエストが条件を満たさないと判明した時、イベントログにエントリを追加することをさらに含む、請求項１５に記載の方法。
リクエストが条件を満たさないと判明した時、警告することをさらに含む、請求項１５に記載の方法。
コンピュータアプリケーションへの不正なハイパーテキスト転送プロトコル（ＨＴＴＰ）リクエストをスクリーニングする方法であって、該方法は、ルールを用いてＨＴＴＰリクエストをスクリーニングすることを含み、該ルールは、該リクエストの本体中のフィールド又は要素についての条件と、該リクエストのクッキーに対する別の条件とを含む、方法。
前記ルールが、前記リクエストの普遍資源識別子（ＵＲＩ）パラメータについての条件も含む、請求項２０に記載の方法。
前記ルールが、前記リクエストのメソッドについての条件も含む、請求項２１に記載の方法。
前記ルールのセットが、前記リクエストのハイパーテキスト転送プロトコル（ＨＴＴＰ）バージョンインジケータについての条件も含む、請求項２２に記載の方法。
前記ルールが、前記リクエストのＵＲＩフォーマットについての条件も含む、請求項２３に記載の方法。
前記ルールが、前記リクエストのヘッダについての条件も含む、請求項２４に記載の方法。
プロセッサ上にロードされたときに、存在に関する条件、統計的条件、及び複合の普遍条件のうちの１つを持つルールを用いてリクエストを該プロセッサにスクリーニングさせるコンピュータ実行可能な命令を含むコンピュータ読取可能媒体。
プロセッサ上にロードされたときに、ルールを用いてＨＴＴＰリクエストを該プロセッサにスクリーニングさせるコンピュータ実行可能な命令を含むコンピュータ読取可能媒体であって、該ルールが、リクエストの以下のパート：ヘッダ、クッキー、ＨＴＴＰバージョンインジケータ、普遍資源識別子（ＵＲＩ）パラメータ、ＵＲＩエンコードフィールド、マルチパートエンコードフィールド、シンプルオブジェクトアクセスプロトコル（ＳＯＡＰ）要素、ＵＲＩフォーマット、のうちの少なくとも１つについての条件を含む、コンピュータ読取可能媒体。
リクエストを受信するための入力と、
存在に関する条件、統計的条件、及び複合の普遍条件のうちの１つを持つルールを用いて、受信したリクエストをスクリーニングするための手段と
を備えるスクリーナ。
ＨＴＴＰリクエスト受信するための入力と、
ルールを用いてＨＴＴＰリクエストをスクリーニングするための手段と
を備えるスクリーナであって、
該ルールが、リクエストの以下のパート：ヘッダ、クッキー、ＨＴＴＰバージョンインジケータ、普遍資源識別子（ＵＲＩ）パラメータ、ＵＲＩエンコードフィールド、マルチパートエンコードフィールド、シンプルオブジェクトアクセスプロトコル（ＳＯＡＰ）要素、ＵＲＩフォーマット、のうちの少なくとも１つについての条件を含む、スクリーナ。
コンピュータアプリケーションへの不正なハイパーテキスト転送プロトコル（ＨＴＴＰ）リクエストをスクリーニングする方法であって、該方法は、ルールを用いてＨＴＴＰリクエストをスクリーニングすることを含み、該ルールは、リクエストの以下のパート：ヘッダ、クッキー、メソッド、ＨＴＴＰバージョン、普遍資源識別子（ＵＲＩ）パラメータ、ＵＲＩエンコードフィールド、マルチパートエンコードフィールド、シンプルオブジェクトアクセスプロトコル（ＳＯＡＰ）要素、ＵＲＩフォーマット、のうちの少なくとも２つについての条件を含む、方法。