(57)【要約】      （修正有）【課題】ウェブアプリケーションの入力を特徴付けるための方法を提供する。【解決手段】一般に、ウェブアプリケーションの入力を識別し、次に、それらの入力にポピュレートできる情報のタイプを求めるのに、さまざまな技法が使用される。本発明の一態様は、ウェブアプリケーションの入力をプローブして、入力の特徴を求めることである。これらの特徴は、入力によって受け付けられる文字のタイプ、有効な入力データとみなすことができる最小の文字数及び最大の文字数、並びに、データが入力プロセッサによって検査又は処理される方法を含むことができる。本発明の別の態様は、入力のコンテキストを調べて、入力の特徴を求めることである。これは、入力を表示するウェブページのテキスト、グラフィックス、及び全体的なコンテキストを調べることに加えて、入力に関連付けられているマークアップ言語コードを調べることも伴う。【選択図】図２
2008171397.tif 000002
【特許請求の範囲】
【請求項１】
ウェブアプリケーションの入力を特徴付けるための方法であって、
ウェブアプリケーションの入力を識別するステップと、
前記入力の特徴をオペレーション上で求めるステップと、
前記入力の特徴をコンテキスト上で求めるステップと、
前記入力の特徴付け知識を適用するステップと
を含む方法。
【請求項２】
前記ウェブアプリケーションの前記入力の特徴をオペレーション上で求めるステップは、
どの文字が前記入力によって受け付けられるかを求めること
を含む
請求項１に記載の方法。
【請求項３】
前記ウェブアプリケーションの前記入力の特徴をオペレーション上で求めるステップは、
前記入力によって受け付けられる文字の個数を求めること
を含む
請求項１に記載の方法。
【請求項４】
前記ウェブアプリケーションの前記入力の特徴をオペレーション上で求めるステップは、
前記入力を扱う方法を求めること
を含む
請求項１に記載の方法。
【請求項５】
前記入力をオペレーション上で特徴付けるステップは、
前記ウェブアプリケーションへプローブを送信することであって、該プローブは、１つ又は２つ以上の文字を含む、前記ウェブアプリケーションへプローブを送信することと、
前記ウェブアプリケーションから応答を受信することと、
前記応答を解析することであって、それによって、前記１つ又は２つ以上の文字が受け付けられたか否かを判断する、前記応答を解析することと
をさらに含む
請求項１に記載の方法。
【請求項６】
前記ウェブアプリケーションの入力によって受け付けられた前記文字のすべてが識別されるまで、前記ステップを繰り返すステップ
をさらに含む
請求項５に記載の方法。
【請求項７】
前記ウェブアプリケーションの前記入力の特徴をコンテキスト上で求めるステップは、
前記入力の周辺の前記ウェブページのコンテキストを調べること
を含む
請求項１に記載の方法。
【請求項８】
前記入力の周辺の前記ウェブページの前記コンテキストを調べるステップは、前記入力に関連付けられた事項について前記ウェブページをスクレイプすること
を含む
請求項７に記載の方法。
【請求項９】
前記入力の周辺の前記ウェブページのコンテキストを調べるステップは、前記入力を記述するテキストコンテンツについて前記ウェブページをスクレイプすること
を含む
請求項７に記載の方法。
【請求項１０】
前記ウェブアプリケーションの前記入力の特徴をコンテキスト上で求めるステップは、前記入力に関係したマークアップ言語コードを調べること
を含む
請求項１に記載の方法。
【請求項１１】
前記入力に関係した前記マークアップ言語コードを調べるステップは、
前記入力を記述するテキストコンテンツについて前記コードをパースするステップ
を含む
請求項１０に記載の方法。
【請求項１２】
前記ウェブアプリケーションをクロールし、前記入力を識別するステップを
をさらに含む
請求項１に記載の方法。
【請求項１３】
前記ウェブアプリケーションの各入力について、前記ステップを繰り返すステップ
をさらに含む
請求項１２に記載の方法。
【請求項１４】
ウェブアプリケーションの入力を特徴付けるための方法であって、
前記ウェブアプリケーションをクロールし、前記入力を識別するステップと、
識別された各入力について、一連のプローブを前記入力へ送信することと、前記ウェブアプリケーションから前記プローブに対する応答を受信することと、前記応答を解析することとによって、その入力の特徴をオペレーション上で求めるステップと、
前記識別された各入力について、前記入力の周辺のコンテンツを調べること、及び、前記入力に関連付けられたマークアップ言語コードを調べることによって前記入力の特徴をコンテキスト上で求めるステップと
を含む方法。
【請求項１５】
前記一連のプローブを前記入力へ送信するステップは、プローブを送信し、該入力によって受け付けられた文字を識別すること
をさらに含む
請求項１４に記載の方法。
【請求項１６】
前記一連のプローブを前記入力へ送信するステップは、プローブを送信し、該入力によって受け付けられた文字の個数を識別すること
をさらに含む
請求項１４に記載の方法。
【請求項１７】
ウェブアプリケーションへの前記入力を特徴付けるための方法であって、
前記ウェブアプリケーションをクロールし、前記入力を識別するステップと、
識別された各入力について、さまざまな文字及び変化する個数の文字を有するプローブを前記入力へ送信すること、前記ウェブアプリケーションから前記プローブに対する応答を受信すること、前記応答を解析すること、前記入力に関係したテキスト情報について前記ウェブサイトのＨＴＭＬコードをパースすること、及び、前記ウェブページをスクレイプし、前記入力についての記述物を識別することによって、前記入力を特徴付けるステップと
を含む方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、ウェブサイトの解析、相互作用、監査、及びアクセスの自動化の分野に関し、より具体的には、ウェブアプリケーションの入力を解析して入力のドメインを識別し、次に、この知識を使用して解析器や監査器等の他のウェブサイトツールの性能を改善するツールに関する。
【０００２】
［関連出願の相互参照］
この出願は、出願番号第１１／５６０，９６９号を割り当てられ、代理人整理番号第１９００６．１０８０号によって識別される２００６年１１月１７日に出願された「WEB APPLICATION ASSESSMENT BASED ON INTELLIGENT GENERATION OF  ATTACK STRINGS」と題する米国特許出願、及び、出願番号１１／５６０，９２９号を割り当てられ、代理人整理番号第１９００６．１０７０号によって識別される２００６年１１月１７日に出願された「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）を開始し、すべてのエリアのカタログを動的に作成する。
これらのエージェントがそれらの評価を完了すると、結果を解析できるように、見つかったものは評価データベース１４０を通じてメインセキュリティエンジンへ報告される。
次に、ツールは、他のソフトウェアエージェントを起動することによって監査フェーズに入る。
これらの他のソフトウェアエージェントは、収集された情報を査定し、攻撃アルゴリズムを適用して、脆弱性の存在及び重大さを判断する。
次に、ツールは、結果を相関させ、それらの結果を、理解するのに容易なフォーマットで報告インターフェース１５０に提示する。
【００１７】
ウェブサイトに対するよく知られている攻撃の１つは、パラメータ操作及び強制パラメータである。
一般に、パラメータ操作攻撃は、ブラウザとウェブアプリケーションとの間で送信されるデータの操作を伴う。
パラメータ操作攻撃は、さまざまな形を取ることができる。
このさまざまな形には、ＨＴＭＬフォームフィールド操作、ＨＴＴＰヘッダ操作、クッキー操作、及びＵＲＬ操作が含まれるが、これらは限定されるものではない。
【００１８】
ＨＴＭＬフォームフィールド操作は、ＨＴＭＬページ上のデータ入力を表すフォームフィールドデータを変更することを伴う。
ユーザがＨＴＭＬページに提供する選択したもの及びデータエントリーのすべては、通常、フォームフィールド値として記憶され、その後、ＧＥＴ又はＰＯＳＴ等のＨＴＴＰ要求としてウェブアプリケーションへ送信される。
隠しフィールドも、この方法でウェブアプリケーションへ送信することができる。
隠しフィールドは、フォームフィールドの一部であるが、ブラウザによってスクリーンに表示もレンダリングもされない。
ユーザは、フォームフィールドのいずれも操作することができ、ユーザがサブミットしたいどの値もサブミットすることができる。
フォームフィールドを操作するために、ユーザは、ブラウザウィンドウから［view source（ソース閲覧）］を選択し、ソースを保存し、ソースを編集し、次に、ページをウェブブラウザに再ロードすることができる。たとえば、フォームフィールドは、そのフォームフィールドに関連付けられた許容される最大の文字数を有する場合がある。
このような制限は、フォームフィールド値「maxlength（最大長）」を、許容される文字の数を表す整数に設定することによってＨＴＭＬで課すことができる。
ユーザは、この値を簡単に編集することもできるし、この値を一斉に削除して、許容される文字の数の制限を取り除くこともできる。
【００１９】
ＨＴＴＰヘッダ操作は、ＨＴＴＰ要求中にクライアントからサーバへ渡されるＨＴＴＰヘッダ情報及びＨＴＴＰ応答中にサーバからクライアントへ渡されるＨＴＴＰヘッダ情報を変更することを伴う。
各ヘッダは、通常、名前及び値を含むＡＳＣＩＩテキストのラインを含む。
一般に、ウェブアプリケーションは、ヘッダを調べないが、いくつかのアプリケーションは、さまざまな目的でヘッダを使用し、したがって、これらのアプリケーションは、このタイプの攻撃に脆弱になる可能性がある。
通常のブラウザは、ヘッダの変更を許可していないが、単純なＰＥＲＬルーチン又はプロキシを、ブラウザから送信されたあらゆるデータのヘッダを変更するのに使用することができる。
ＨＴＴＰヘッダ操作の一例は、リファラヘッダ（Referer header）を使用することができる。
リファラヘッダは、通常、ブラウザによって送信され、要求の発信元のウェブページのＵＲＬを含む。
いくつかのウェブサイトは、このヘッダを利用して、受信された要求が、そのウェブサイトによってオリジナルに生成されたページを実際に起源とするものであることを保証する。
このステップは、当該ステップが、ユーザがページのソースを編集すること、ページのソースを再ロードすること、及びページのソースを要求として送信することを防止するという確信の下で行われる。
しかしながら、リファラヘッダを変更することによって、ユーザは、このようなページを、そのページがオリジナルのサイトから来る場合と同じに見せることができる。
【００２０】
クッキー操作は、クッキー内に存在するデータを変更することを伴う。
クッキーは、クライアント端において変更され、その後、ＵＲＬ要求と共にサーバへ送信される。
より具体的には、ウェブベースシステムは、通常、サーバにすでに記憶されたデータへの参照子としてクッキーを使用し、特定のユーザのみがそのクッキーの内容を知っているという前提の下で動作する。
このシステムは、悪意のあるユーザが別のユーザに割り当てられるクッキーを予測できる場合に攻撃に対して脆弱となる。
攻撃者は、その場合、偽造クッキーを使用することによって、適法なユーザのセッションをハイジャックすることができる。
このように、クッキー操作は、攻撃を行うクッキーの作成を含む。この技法は、クッキーがどのように作成されるかに応じて、多数の試みが必要とされる場合があるという点で、かなり負担となる場合がある。
【００２１】
ＵＲＬ操作は、おそらく、パラメータ操作の最も簡単な形であり、ブラウザのアドレスバーに示されるようなＵＲＬ文字列内のパラメータ又は値を変更することを単に伴う。
たとえば、ＧＥＴを通じてＨＴＭＬフォームをサブミットするとき、そのフォームの要素名及びそれらの値のすべては、ユーザに見える次のＵＲＬのクエリ文字列に現れる。
クエリをサブミットする前に、容易にＵＲＬを改ざんしてそれらの値を変更することができる。
【００２２】
たとえウェブアプリケーションの最も単純なものにおいても、パラメータ操作の脆弱性についてチェックを行うタスクが人の気力をかなり失わせる可能性があることを理解することは、大きな想像力を要しない。
並べ替えの個数及び攻撃の個数は、ウェブアプリケーションの複雑さと共に容易に増加し、したがって、多数の入力を有する大きなウェブアプリケーションは、評価タスクがほとんど不可能となる可能性がある。
しかしながら、ウェブアプリケーションの組み立て及び実施で使用されるコード及びルーチンの検査時に、ウェブアプリケーションの入力処理の多くが、共通の一組のバックエンドプロセスを使用して実行されることは明らかである。
ウェブアプリケーションの入力エリアのそれぞれにアクセスしなければならないのではなく、脆弱性についてバックエンドプロセスを単純に訓練することが好都合であろう。
しかしながら、外部の視点からは、ウェブアプリケーションを作成する構造及びコードに関する特定の知識を有することなく、このような情報を取得することは難しい。
【発明の開示】
【発明が解決しようとする課題】
【００２３】
したがって、当該技術分野では、ウェブアプリケーションのバックエンドプロセスについての構造的特徴を求めることができ、且つ、この知識で、対象とされる、的を絞った攻撃を開始することができる脆弱性評価を行うための方法システムが必要とされている。
このような解決策は、評価を行う際に実行しなければならないチェックの回数の削減を可能にすべきであり、性能を改善すべき、すなわち、評価を行うのに必要とされる時間を削減すべきであり、且つ、誤検出の発生を低減させるのを助けるべきである。
したがって、当該技術分野では、ウェブサイト及びウェブアプリケーションを解析する複雑さが増加の一途をたどっているが、この増加の一途をたどる複雑さに、正確ではあるが今日の技術よりも高速且つ効率的な方法で取り組むことができるウェブサイト及びウェブアプリケーションの評価ツールが必要とされている。
本明細書に記載する本発明は、このような解決策を提供する。
加えて、ウェブアプリケーションの入力を特徴付けることが可能になるという他の利益もある。
このような１つの利益は、「IMPROVED WEB APPLICATION AUDITING BASED ON SUB-APPLICATION IDENTIFICATION」と題し、出願番号第    ／    ，    号及び代理人整理番号第１９００６．１０７０号によって識別される参照出願に記載されているように、サブアプリケーションを識別し、この情報に基づいて、対象とされる攻撃を行うことにある。
他の利益には、アプリケーションを構成し、且つこの情報を使用してフォームの背後にあるページ（pages behinds a form）にアクセスし、且つエッジ攻撃（edge attack）を識別することの自動化に加えて、他の利益も含まれる。
したがって、当該技術分野では、ウェブアプリケーションの入力を評価して入力を特徴付ける技法が必要とされている。
【課題を解決するための手段】
【００２４】
本発明は、さまざまな特徴及び態様を含むが、一般に、ウェブアプリケーションの入力を特徴付ける技法を対象とする。
一般に、ウェブアプリケーションの入力を識別し、次に、それらの入力にポピュレートできる情報のタイプを求めるのに、さまざまな技法が使用される。
本発明の一態様は、ウェブアプリケーションの入力をプローブして、入力の特徴を求めることである。
これらの特徴は、入力によって受け付けられる文字のタイプ、有効な入力データとみなすことができる最小の文字数及び最大の文字数、並びに、データが入力プロセッサによって検査又は処理される方法を含むことができる。
本発明の別の態様は、入力のコンテキストを調べて、入力の特徴を求めることである。  
これは、入力を表示するウェブページのテキスト、グラフィックス、及び全体的なコンテキストを調べることに加えて、入力に関連付けられているマークアップ言語コードを調べることも伴う。
【００２５】
本発明の一実施の形態は、（ａ）ウェブアプリケーションの入力を識別すること、（ｂ）入力の特徴をオペレーション上で求めること、（ｃ）入力の特徴をコンテキスト上で求めることによって、ウェブアプリケーションの入力を特徴付けるための技法を含む。
この知識は、一旦取得されると、ウェブ評価ツール、クローラ、自動フォーム等のさまざまなアプリケーションで使用することができる。
ウェブアプリケーションの入力の特徴をオペレーション上で求めることは、どの文字が入力によって受け付けられるかを求めること、又は、入力によって受け付けられる文字の個数を求めることを含む。
加えて、これは、入力を扱う方法を求めることも含むことができる。
より具体的には、オペレーション上の特徴は、ウェブアプリケーションへプローブを送信し、ウェブアプリケーションから応答を受信し、次に、応答を解析して、１つ又は２つ以上の文字が受け付けられたか否かを判断することによって、求めることができる。
このプローブは、１つ又は２つ以上の文字を含む。
さらに、ウェブアプリケーションの入力の特徴をコンテキスト上で求めることは、ウェブアプリケーションの入力の特徴が入力の周辺のウェブページのコンテキストを調べることを含むものと判断することを含む。
これは、入力に関連付けられた事項（matter）についてウェブページをスクレイプすること、又は、入力を記述するテキストコンテンツについてウェブページをスクレイプすることを含むさまざまな技法を使用して達成することができる。
加えて、入力をコンテキスト上で特徴付けること求めることは、入力に関係したマークアップ言語コードを調べることを含むことができる。
たとえば、これは、入力を記述するテキストコンテンツのコードをパースすることを含むことができる。
【００２６】
図及び以下の説明は、本発明のさまざまな態様及び特徴を詳しく述べている。
【発明を実施するための最良の形態】
【００２７】
本発明は、知的エンジン技術の使用を用いることによって、ウェブベースの機能及びツールに大幅な改良をもたらす。
本発明は、顧客及び解析者がウェブアプリケーション評価製品を査定する方法を大幅に変更することになる技術を導入する。
本発明は、従来技術の技法を時代遅れのものとすることはないかもしれないが、それでも、本発明は、ウェブアプリケーション評価製品の性能、信頼性、及び効率を改善する解決策を提供する。
一般に、本発明は、知的エンジン及び静的チェックの組み合わせを利用して、徹底した効率の良いウェブアプリケーション評価製品を提供する。
【００２８】
好都合なことに、本発明は、セキュリティのプロが、はるかに高速に評価を完了することを可能にし、誤検出を実質的になくすことを可能にし、且つ、評価中に発見される真の脆弱性の個数を増加させることを可能にする。
現時点で最新の静的チェック技術を本発明の技術と比較する良い物差しには、評価を行うのに必要とされる時間、及び、識別される誤検出の個数が含まれる。
本発明は、これらのカテゴリーの双方において改善を提供する。
【００２９】
一般に、本発明は、外部のプローブを通じてウェブサイトの構造を解析し、ウェブアプリケーションのユーザインターフェース又は入力部を駆動するコアバックエンドプロセスを識別する。
評価ツールは、この知識を備えて、ありとあらゆる入力の脆弱性を探さなければならないのではなく、これらのバックエンドプロセスの脆弱性を識別する攻撃に的を絞ることができる。
好都合なことに、これによって、脆弱性評価プロセスは、はるかに高速に進むことが可能になり、バックエンドプロセスのより深くより徹底した検査が可能になる。
【００３０】
図２は、ウェブアプリケーションの入力を特徴付ける際の本発明のオペレーションの超高レベル図を示すフロー図である。
本発明は、評価ツール又は自動フォーム入力ツール等を駆動するエンジンを含むさまざまな実施形態に組み込むことができる。
評価ツールエンジンの実施形態におけるオペレーションを説明すると、最初に、エンジンは、ウェブアプリケーション上のどのロケーションがウェブページ受け付け入力を生成したかを判断する（２１０）。
この判断は、この入力が、フレーム構造内、フォーム内、選択ボックス内等にあるか否かを識別することを含むことができる。
次に、エンジンは、入力のそれぞれについてできるだけ多くの情報を識別し、したがって、入力を特徴付けるように動作する。
本発明の実施形態は、入力を特徴付けるために、いくつかの技法、オペレーション、及び機能を用いる。
これらのすべてが、任意の１つの実施形態に必要とされるとは限らず、さまざまな組み合わせ又は個々の技法が、それ自体単独で新規である場合がある。
入力を特徴付けるのに使用される技法の１つは、入力の特徴をオペレーション上で求めることである（２２０）。
この技法は、どのタイプの入力がそのページ上で又は特定のデータエントリーロケーションにおいて許可されているかを求める（etermining）ことを伴う（２２０）。
たとえば、このプロセスは、異なる文字、シンボル、文字列等をウェブページのデータ入力へシリアルに送信すること、及び、その応答を監視することを伴う。
たとえば、アルファベットの文字、数字、シンボル等を入力に送信して、受け付けられた入力のカテゴリー、さらには、受け付けられた具体的な入力を求めることができる。
加えて、入力が大文字対小文字に対して異なって反応するか否かについての判断、入力がデータエントリーの長さに対して異なって反応するか否かについての判断、入力が数字を整数、日付、値等として解釈するか否かについての判断、又は、それらの数字が標準文字とみなされるか否かについての判断を行うことができる。
また、この技法は、入力によって受け付けられる最小の文字数及び最大の文字数を求めるのに使用することもできる。
したがって、例示的な実施形態では、これは、さまざまな入力の特徴を識別するのに用いられる基本的な初歩ステップを含んだ非常に体系的で且つ的の絞られた手順とすることができる。
ウェブアプリケーションからの応答の監視は、Ｊａｖａ（登録商標）Ｓｃｒｉｐｔパーサの使用又は他の或る解析を行う等のさまざまな方法で行うことができる。
Ｊａｖａ（登録商標）Ｓｃｒｉｐｔパーサは、応答を解析（parse;パース）して、どのタイプの入力値が受け付けられるのか又は拒否されるのかを判断するものである。
たとえば、単純なブールタイプの解析を利用して、拒否されたエントリーと受け付けられたエントリーとを区別することができ、次に、この情報に基づいて入力を特徴付けることができる。
【００３１】
入力を特徴付けるためのもう１つの技法は、入力の特徴をコンテキスト上で求めることである（２３０）。
このプロセスは、入力を取り囲むウェブページ又は入力に関係したウェブページのコンテンツを調べて、入力に関する何らかの情報が発見されるか否かを判断することを伴う。
この情報は、ウェブアプリケーションのさまざまな入力をさらに特徴付けるのに使用される。
【００３２】
入力の特徴が一旦識別されると、この知識をさまざまな方法で適用して、ウェブアプリケーションの利用及び解析の改善を助けることができる（２３０）。
非限定的な例として、入力は、これらの特徴に基づいてグループ化することができ、参照の特許出願に記載されているようなサブアプリケーション監査ツールをサポートするのに使用することができる。
これらの特徴のグループは、基本的に、共通のバックエンドプロセスによって駆動されて制御される入力を識別する。
たとえば、ウェブアプリケーションが、www.bankofamerica.com等の複数のログインロケーションを有する場合、或る共通のバックエンドプロセスが、ユーザ名を受信してその有効性を確認するのに使用され、別の共通のバックエンドプロセスが、パスワードを受信してその有効性を確認するのに使用される場合がある。
又は、実際には、単一のバックエンドプロセスが双方を取り扱う場合もある。
図３Ａは、バンクオブアメリカのサインインウェブページのスクリーンショットである。
図示したスクリーンショットは、ユーザにより選択可能な１５個の異なるサインインリンクを含む。これらのリンクは、この図では丸で囲まれている。
各リンクをアクティブ化することによって、ユーザは別のウェブページに案内され、そのウェブページによって、ユーザはログインすることが可能になる。
これらのさまざまなログインスクリーンの提示は、ユーザの視点と異なる。
【００３３】
たとえば、図３Ｂ及び図３Ｃは、図３Ａのリンク３０２（Sign in）をアクティブ化した結果を示すスクリーンショットである。
図３Ｂでは、ユーザに、オンラインＩＤフィールド３０４（Enter Online ID）が提示され、オンラインＩＤの入力に成功した後、ユーザは、図３Ｃに示すウェブページに案内される。
図３Ｃでは、ユーザに、パスワードフィールド３０６（Password）が提示されている。
パスワードフィールド３０６の下のテキスト（4-20 Characters, case sensitive）は、パスワードフィールド３０６が４文字〜２０文字を受け付け、大文字と小文字を区別することを示している。
オンラインＩＤ及びパスワードを入力するために、ユーザは、最初の値を入力し、この情報をウェブアプリケーションへ送信し、その後、図３Ｃに示すスクリーンに誘導される必要がある。
この時点で、ユーザは、自身のパスワードを入力することができ、再び、これをウェブアプリケーションへサブミットすることができる。
このウェブページシーケンスを調べることから、バックエンドプロセスは、パスワード検証を行う前に、オンラインＩＤ検証を必要とすることは明らかである。
【００３４】
図３Ｄは、図３Ａのリンク３０８（Sign in）をアクティブ化した結果を示すスクリーンショットである。
図３Ｄでは、ユーザに、ユーザＩＤフィールド３１０（User ID）及びパスワードフィールド３１２（Password）がすべて同じウェブページ上で提示されている。
このスクリーンでは、ユーザは、自身のユーザＩＤ及びパスワードをウェブアプリケーションに送信する前に、これらの情報を入力する必要がある。
したがって、このスクリーンのユーザＩＤ及びパスワードを取り扱うためのバックエンドプロセスは、図３Ｂ及び図３ＣのオンラインＩＤ及びパスワードを処理するのに使用されるバックエンドプロセスとは異なる場合があるように見える。
【００３５】
図３Ｅは、図３Ａのリンク３１４（Sign in）をアクティブ化した結果を示す別のスクリーンショットである。
これは、軍用銀行のサインインである。図３Ｅでは、ユーザに、ユーザＩＤフィールド３１６（Username）及びパスワードフィールド３１８（Password）が提示されている。
図３Ｅに提示された構造は、図３Ｄに提示された構造と類似しており、したがって、ユーザＩＤ及びパスワードを受信して検証するのに使用されるバックエンドプロセスは、これらの２つのスクリーンについて共通である可能性が高い。
他方、図３Ａに示すウェブページに表示されたリンクからアクセス可能なサインインスクリーンのいくつかは、図３Ｂ及び図３Ｃの構造を忠実に表現し（adhere）、したがって、それらのサインインスクリーンは、共通のバックエンドプロセスを使用する可能性が最も高い。
したがって、この簡単な例示から、入力が２つのグループ化したものをどのように識別できるかが実証される。
【００３６】
したがって、この例では、入力が一旦カテゴリーに分類されると、脆弱性評価ツールは、次に、各カテゴリーにおける入力のサブセットの攻撃を開始することができる。
好都合なことに、本発明のこのアプリケーションは、評価の完全性を損なうことなく、評価を行う際のワークロードを大幅に削減することができる。
実際に、処理時間は節減され、ツールがありとあらゆる入力フィールドを試験しなければならない場合に可能にされる攻撃よりも深く徹底した攻撃をバックエンドプロセス上で行うことができる。
また、本発明のさまざまな実施形態で入力のグループ化を利用して、必要とされるワークロードを減少させることもできることが十分理解されるべきである。
たとえば、特徴付けられている入力のコンテキストが、特徴付けられていない入力と類似している場合、本実施形態は、その新たな入力を特徴付けるのに必要とされる時間を大幅に削減できるいくつかの仮定を立てることができる。
一例として、特徴付けられた入力が電話番号であり、その入力が、番号、括弧、スペース、及びハイフンしか受け付けないように示され、且つ、入力は、最小で１０文字、最大で１４文字に制限されているものと仮定する。
入力フィールドのコンテキストが、単語「phone（電話）」を含む場合、その近くに同様に「phone」を含んだ単語を含む、特徴付けられていない入力も、電話番号とすることができる。
この状況では、その入力に対して完全な試験シーケンスを行うのではなく、既知の許可された値及び拒否された値を使用して、入力を容易にプローブすることができ、また、入力が同じ方法で制限されることを検証することもできる。
【００３７】
したがって、本発明の一実施形態は、ウェブサイトのクロールを行って、そのウェブサイトの入力のすべてを識別するように動作する。次に、本実施形態は、攻撃の次のステップが何であるかを決定するために、ウェブアプリケーションに問い合わせ（interrogate;インターロゲート）し、ウェブアプリケーションからの回答又は応答をフィードバックとして使用することができる。
ウェブアプリケーションの入力の振る舞いを特徴付けることによって、バックエンド処理についての情報を取得することができる。
次に、攻撃は、ユーザインターフェースレベルではなく、バックエンドプロセスレベルにおいて脆弱性を探すことに的を絞ることができる。
このバックエンドプロセスレベルは、はるかに狭く、より的を絞った手法である。
【００３８】
前述したように、本発明の態様の１つは、ウェブアプリケーションのさまざまな入力を特徴付けることである。
このタスクを行う一方法は、さまざまなデータをウェブアプリケーションへ送信し、ウェブアプリケーションがどのように応答するかを観察することである。
たとえば、さまざまな文字列の長さを送信して、どの文字列の長さが受け付けられ、どの文字列の長さが拒否されるかを調べることによって、データ文字列の受け付けられた長さを識別することができる。
さらに、受け付け可能な文字セットも求めることができる。
プロセスは、さまざまな部類の文字からの代表的な文字である文字のグループを送信すること、又は、他の技法を使用して入力のこの態様を特徴付けることを伴うことができる。
【００３９】
入力フィールドのコンテキストを調べることによって、入力についての他の情報を求めることができる。
たとえば、図３Ａ〜図３Ｅに示すように、パスワードフィールドは、そのボックスの近傍にテキスト情報を含む。
すなわち、このテキスト情報は、パスワードフィールドが大文字と小文字を区別し、４〜２０文字を受け付けることを示している。
この情報は、スクリーンをスクレイプするか又はソースファイルを検索することによって取得することができる。
したがって、パスワード、パスコード、ＰＩＮ、アクセスコード等のラベルを含むフィールドは、最初に、共通のバックエンドプロセスを使用して、類似する可能性のある入力フィールドとしてタグ付けすることができる。
加えて、入力フィールドの他の特徴をグループ化するために、ＨＴＭＬコードを検索して、それらの他の特徴を識別することができる。
この情報のすべては、共に、さまざまな入力フィールドがどのデータを受け付けるかの特徴に基づいて、それらのさまざまな入力フィールドをグループ化するのを助けることができ、したがって、バックエンドプロセスの共通性についての良い表示を提供することができる。
【００４０】
また、これらの技法は、ウェブアプリケーションが入力データをどのように解釈するかを特徴付けるのに使用することもできる。
さまざまな入力フィールドを識別して分類することを助ける際に、経験則（heuristics;ヒューリスティックス）のライブラリを利用することができる。
たとえば、特定の入力フィールドが５文字しか受け付けず、その文字セットが、０から９の範囲の数字に限られることが求められている場合、そのフィールドは、郵便番号の入力用である確率が高い。
さらに、その入力フィールドの非常に近くにある郵便（zip）という用語又は郵便番号（zip code）のスクリーンをスクレイプすることによって、この推定をさらに立証することができる。
類似の特徴を有するウェブアプリケーションの他の入力フィールドを共にグループ化することができ、これらの入力フィールドのサブセットのみが脆弱性について評価される必要がある。
さまざまな他のフィールドについても、類似のヒューリスティックスを適用することができる。このさまざまな他のフィールドには、以下の例等があるが、これに限定されるものではない。
【００４１】
年齢：最大３文字であり、文字セットは、０〜９の数字を含み、３文字がサブミットされるときは、最上位ロケーションには空白、０、又は１のみを含む。
【００４２】
名前：最大２０文字であり、文字セットは、Ａ〜Ｚ及びａ〜ｚからの文字のみを含む。
【００４３】
電話番号：最大１４文字であり、文字セットは、０〜９の数字及び次の文字、すなわち「（」、「）」、スペース、及び「−」を含む。
【００４４】
加えて、これらの技法は、入力がデータをテキスト文字列として解釈すのか、それとも数字として解釈するのかを判断するのに使用することもできる。
【００４５】
図４は、ウェブアプリケーションの入力を特徴付ける、本発明の例示的な一実施形態に関連したステップを示すフロー図である。
最初に、クロールを行って入力を見つけることもできるし、別の方法で入力を識別することもできる。次に、各入力について、その入力によって受け付けられる文字又はシンボルが求められる（４１０）。
このプロセスは、１つ又は２つ以上の文字又はシンボルを一度に送信して、どの文字又はシンボルがエラーメッセージを引き起こすことになるかを判断することを単に伴うことができる。
また、このプロセスは、受け付けられた入力の長さを識別することも含むことができる（４１２）。この場合もまた、これは、１つの文字から開始して、文字列の長さが拒否されるまで徐々に増加させる等のさまざまな方法で行うこともできるし、より強固（robust;ローバスト）なアルゴリズムを用いて、最大長を識別するのに必要とされるステップ数を削減することもできる。
加えて、数値のみを受け付けるフィールドについては、受け付けられる数字の最大範囲や負の数に対する応答等を求めるアルゴリズムを用いることができる。
さらなる特徴が、入力フィールドのコンテキストを調べることによって求められる（４１４）。
上述したように、これは、テキストについてスクリーンをスクレイプすることを含むことができるが、入力フィールドの目的についてのヒントを提供する場合があるページのタイトル、カラー方式、グラフィックス等の他の属性を調べることも含むことができる。
また、ＨＴＭＬソースコードを検索して、入力フィールドに課せられた属性及び制限を識別することもできる（４１６）。
【００４６】
前述したように、ウェブアプリケーションの入力の特徴付けは、いくつかの用途に非常に有益となる可能性がある。
１つの用途は、前述したように、ウェブアプリケーションのサブアプリケーションベースの監査を行うことにある。
一方、入力の特徴付けは、ウェブのクロールを容易にすることを助けることもできる。
たとえば、入力を特徴付けることによって、クローラは、フォームの背後にあるウェブページにアクセスするためにフォームのさまざまなフィールドにどの値を入力するのかを知ることが可能になる。
一具体例として、本発明のスクリーンスクレイパの態様は、フィールドの近傍にアスタリスクを含むすべてのフィールドを識別することができる。このアスタリスクは、入力が必要であることを示すものである。
この知識により、クローラは、これらのフィールドが確実にポピュレートされるようにすることができ、且つ、他のフィールドを無視することができ、それでも、フォームの背後にあるページにアクセスすることができる。
【００４７】
さらに、本発明は、ウェブフォームを自動的に入力するか、又は、一定のフォーム情報を事前にポピュレートするのにも好都合に使用することができる。
たとえば、本発明が、ブラウザアプリケーションに組み込まれている場合、ウェブページ、特にウェブベースフォームがロードされると、本発明は、入力がレンダリングされると同時に入力を特徴付けることができる。
次に、アプリケーションは、ユーザの情報又はクッキーファイルを調べて、そのフォームの既知のフィールドをポピュレートするための情報を取得することができる。
本発明は、同様に、アプリケーションを構成するプロセスを自動化することにも使用することができる。
本発明の実施形態は、アプリケーションの入力及びプッシュされたテキストメッセージを調べて、次に行う必要があるものを論理的に解明することができる。
たとえば、簡単で非限定的な一例として、アプリケーションがロードされた後、本発明は、ユーザにＹＥＳボタンを選択させてコンピュータをリブートさせることを要求するウィンドウの提示を検出することができる。
本発明の実施形態は、この機能を自動的に検出して作動させることができる。
同様に、ウェブアプリケーションでは、フォームが一旦完了すると、本発明は、サブミットボタンを識別し、そのサブミットボタンを自動的に作動させることもできる。
【００４８】
この説明で提供された実施形態及び具体例は、非限定的な例として提供されたものであり、したがって、たとえそれらが個々に新規であると考えることができても、本発明の唯一の新規な実施態様又は構成とみなされるべきではないことが十分理解されるべきである。
説明した実施形態は、異なる特徴を含み、それらの特徴のすべてが、本発明のすべての実施形態で必要とされるとは限らない。
本発明のいくつかの実施形態は、これらの特徴又はこれらのの特徴の可能な組み合わせの一部しか利用しない。
当業者には、説明した本発明の実施形態の変形形態と説明した実施形態で言及された特徴の異なる組み合わせを含む本発明の実施形態とが思いつくであろう。
本発明の範囲は、添付の特許請求の範囲によってのみ限定される。
【図面の簡単な説明】
【００４９】
【図１】評価ツールの一般的構造のシステム図である。
【図２】評価するバックエンドプロセスを識別する際の本発明のオペレーションの超高レベル図を示すフロー図である。
【図３Ａ】バンクオブアメリカのサインインウェブサイトのスクリーンショットである。
【図３Ｂ】図３Ａのリンク３０２をアクティブ化した結果を示すスクリーンショットである。
【図３Ｃ】図３Ａのリンク３０２をアクティブ化した結果を示すスクリーンショットである。
【図３Ｄ】図３Ａのリンク３０８をアクティブ化した結果を示すスクリーンショットである。
【図３Ｅ】図３Ａのリンク３１４をアクティブ化した結果を示す別のスクリーンショットである。
【図４】ウェブアプリケーションの入力を特徴付ける、本発明の例示的な一実施形態に関連したステップを示すフロー図である。
【符号の説明】
【００５０】
１００・・・ウェブ評価インターフェース
１１０・・・ウェブサーバ又は宛先システム
１２０・・・インターネット
１３０・・・ソフトウェアエージェント
１４０・・・評価データ
１５０・・・報告インターフェース
【図１】
2008171397.tif 000003
【図２】
2008171397.tif 000004
【図３Ａ】
2008171397.tif 000005
【図３Ｂ】
2008171397.tif 000006
【図３Ｃ】
2008171397.tif 000007
【図３Ｄ】
2008171397.tif 000008
【図３Ｅ】
2008171397.tif 000009
【図４】
2008171397.tif 000010
【手続補正書】
【提出日】平成20年2月18日(2008.2.18)
【手続補正１】
【補正対象書類名】明細書
【補正対象項目名】００２３
【補正方法】変更
【補正の内容】
【００２３】
したがって、当該技術分野では、ウェブアプリケーションのバックエンドプロセスについての構造的特徴を求めることができ、且つ、この知識で、対象とされる、的を絞った攻撃を開始することができる脆弱性評価を行うための方法システムが必要とされている。
このような解決策は、評価を行う際に実行しなければならないチェックの回数の削減を可能にすべきであり、性能を改善すべき、すなわち、評価を行うのに必要とされる時間を削減すべきであり、且つ、誤検出の発生を低減させるのを助けるべきである。
したがって、当該技術分野では、ウェブサイト及びウェブアプリケーションを解析する複雑さが増加の一途をたどっているが、この増加の一途をたどる複雑さに、正確ではあるが今日の技術よりも高速且つ効率的な方法で取り組むことができるウェブサイト及びウェブアプリケーションの評価ツールが必要とされている。
本明細書に記載する本発明は、このような解決策を提供する。
加えて、ウェブアプリケーションの入力を特徴付けることが可能になるという他の利益もある。
このような１つの利益は、「IMPROVED WEB APPLICATION AUDITING BASED ON SUB-APPLICATION IDENTIFICATION」と題し、米国出願番号第１１／５６０，９２９号及び代理人整理番号第１９００６．１０７０号によって識別される参照出願に記載されているように、サブアプリケーションを識別し、この情報に基づいて、対象とされる攻撃を行うことにある。
他の利益には、アプリケーションを構成し、且つこの情報を使用してフォームの背後にあるページ（pages behinds a form）にアクセスし、且つエッジ攻撃（edge attack）を識別することの自動化に加えて、他の利益も含まれる。
したがって、当該技術分野では、ウェブアプリケーションの入力を評価して入力を特徴付ける技法が必要とされている。  
【外国語明細書】
CHARACTERIZATION OF WEB APPLICATION INPUTS
CROSS-REFERENCE TO RELATED APPLICATIONS
[0001] This application is related to and incorporates by reference, the United States Patent Application entitled WEB APPLICATION ASSESSMENT BASED ON INTELLIGENT GENERATION OF ATTACK STRINGS, filed on November 17, 2006, assigned serial number 11/560,969 and identified by attorney docket number 19006.1080 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, interaction, auditing, and access automation and, more specifically, to a tool that analyzes the inputs of a web application to identify domains of inputs and then using this knowledge to improve the performance of other web site tools such as analyzers, auditors, or the like.    
[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 parameter manipulation and forced parameters.  In general, parameter manipulation attacks involve the manipulation of data that is transmitted between a browser and a web application.  Parameter manipulation attacks can take on a variety of forms, including but not limited to, HTML form field manipulation, HTTP header manipulation, cookie manipulation, and URL manipulation.  
[0018] HTML form field manipulation involves changing the form field data representing the data input on an HTML page.  All of the selections and data entry that a user provides to an HTML page are typically stored as form field values and then sent to the web application as an HTTP request, such as a GET or POST.  Hidden fields may also be transmitted to the web application in this manner.  The hidden fields are part of the form field but are not displayed or rendered to the screen by the browser.  The user is able to manipulate any of the form fields and submit any value the user so desires.  To manipulate a form field, the user can select [view source] from the browser window, save the source, edit the source and then reload the page into the web browser.  For example, a form field may have a maximum number of characters allowed associated with it.  Such a restriction can be imposed in HTML by setting the form field value "maxlength" to an integer representing the number of allowed characters.  The user can simply edit this value or delete it all together to remove the restriction on the number of allowed characters.  
[0019] HTTP header manipulation involves modifying the HTTP header information that is passed from a client to the server during an HTTP request and from a server to a client during an HTTP response.  Each header typically includes a line of ASCII text that includes a name and a value.  Generally, web applications do not examine the header but, some applications use the header for various purposes and as such, these applications can be vulnerable to this type of attack.  Although the typical browser will not allow the header to be modified, a simple PERL routine or a proxy can be used to modify the header of any data send from the browser.  An example of an HTTP header manipulation can use the Referer header that is typically sent by a browser and contains the URL of the web page originating the request.  Some web sites utilize this header to ensure that the received request actually originated from a page that was originally generated by that web site.  This step is performed under the belief that it will prevent a user from editing the source of a page, reloading it and sending it as a request.  However, by modifying the Referer header, a user can make such a page look the same as if it came from the original site.  
[0020] Cookie manipulation involves changing the data residing within a cookie.  The cookie is modified at the client end and then sent to the server with a URL requests.  More specifically, a Web-based system typically uses a cookie as a reference to data already stored on the server, and operates under the assumption that only a specific user knows the contents of the cookie.  This system is vulnerable to attack if a malicious user can predict the cookie that will be assigned to another user.  The attacker can then hijack a legitimate user's session by using the counterfeit cookie.  Thus, cookie manipulation includes the forging of a cookie to perform the attack.  This technique may be quite burdensome in that a large number of attempts may be required depending on how the cookie is created.  
[0021] URL manipulation is probably the simplest form of parameter manipulation and simply involves changing the parameters or values within the URL string as shown in the address bar of the browser.  For example, when submitting HTML forms through a GET, all of the form element names and their values appear in the query string of the next URL the user sees.  The URL can easily be tampered with to change the values prior to submitting the query.  
[0022] It doesn't take a big imagination to realize that the task of checking for parameter manipulation vulnerabilities can be quite daunting, even on the simplest of web applications.  The number of permutations and attacks easily build with the complexity of the web application and as such, a large web application with numerous inputs can almost be an impossible assessment task.  However, upon examining the code and routines that are used in the building and implementation of a web application, it is apparent that much of the input processing of a web application is performed using a common set of backend processes.  It would be advantageous to simply exercise the backend processes for vulnerabilities rather than having to access each of the input areas of the web application.  However, from an external perspective, without having specific knowledge regarding the structure and code that makes up a web application, such information is difficult to obtain.    
[0023] Thus, there is a need in the art for a method and system for conducting vulnerability assessments that can determine structural characteristics about the backend processes of the web application and launch a directed and focused attack with this knowledge.  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 a 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.  In addition, there are other benefits of being able to characterize the inputs of a web application.  One such benefit is in identifying sub-applications and conducting a directed attack based on this information such as described in the referenced application entitled IMPROVED WEB APPLICATION AUDITING BASED ON SUB-APPLICATION IDENTIFICATION and identified by serial number ___/___,___ and attorney docket number 19006.1070.  Other benefits include the automation of configuring applications, using this information to access pages behinds a form, identifying edge attacks as well as other benefits.  Thus, there is a need in the art for a technique to assess and characterize the inputs of a web application.  
BRIEF SUMMARY OF THE INVENTION
[0024] The present invention, although comprising various features and aspects, in general is directed towards a technique to characterize the inputs of a web application.  In general, various techniques are used to identify the inputs of a web application and then to determine the types of information that can be populated into those inputs.  One aspect of the present invention is to probe the inputs of a web application to determine the characteristics of the inputs.  These characteristics may include the types of characters accepted by the input, the minimum and maximum number of characters that can be considered to be valid input data, and the manner in which the data is viewed or operated upon by the input processors.  Another aspect of the present invention is to examine the context of the input to determine characteristics of the input.  This involves examining the text, graphics, and overall context of the web page displaying the input as well as examining the markup language code that is associated with the input.  
[0025] One embodiment of the invention includes a technique for characterizing the inputs of a web application by (a) identifying an input of a web application; (b) operationally determining the characteristics of the input; and (c) contextually determining the characteristics of the input.  Once this knowledge is obtained, it can be used in a variety of applications such as web assessment tools, crawlers, automated forms, etc.   Operationally determining the characteristics of the input of the web application includes determining what characters are accepted by the input and or determining the number of characters that are accepted by the input.  In addition, this may also include determining the manner that the input is treated.  More specifically, the operational characteristics can be determined by sending a probe to the web application, the probe including one or more characters; receiving a response from the web application; and then analyzing the response to determine if the one or more characters were accepted.  Furthermore, contextually determining the characteristics of the input of the web application includes determining the characteristics of the input of the web application comprises examining the context of the web page in the vicinity of the input.  This can be accomplished using a variety of techniques including scraping the web page for matter associated with the input or scraping the web page for textual content describing the input.  In addition, contextually characterizing the inputs can include examining the markup language code related to the inputs.  For example, this may include parsing the code for textual content describing the input.  
[0026] 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
[0027] FIG. 1 is a system diagram of a typical structure for an assessment tool. 
[0028] FIG. 2 is a flow diagram depicting a very high-level view of the operation of the present invention in identifying backend processes to assess.   
[0029] FIG. 3A is a screen shot of the Bank of America sign-in website.    
[0030] Figs. 3B and 3C are screen shots showing the results of activating link 302 in Fig. 3A.  
[0031] Fig. 3D is a screen shot showing the results of activating link 308 in Fig. 3A.  
[0032] Fig. 3E is another screen shot showing the results of activating link 314 in Fig. 3A.  
[0033] Fig. 4 is a flow diagram illustrating the steps involved in an exemplary embodiment of the present invention to characterize the inputs of a web application.  
DETAILED DESCRIPTION OF THE INVENTION
[0034] The present invention brings a significant improvement to web based functionality and  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 may not render prior art techniques 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.  
[0035] 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 required to conduct an assessment and the number of false positives identified.  The present invention provides improvements in both of these categories.  
[0036] In general, the present invention analyzes the structure of a website, through external probing, to identify the core backend processes that drive the user interface or input portions of the web application.  Armed with this knowledge, the assessment tool can focus on attacks to identify vulnerabilities of these background processes rather than having to look for vulnerabilities for each and every input.  Advantageously, this allows the vulnerability assessment process to proceed much more quickly, and allows for a deeper more thorough examination of the backend process.  
[0037] FIG. 2 is a flow diagram depicting a very high-level view of the operation of the present invention in characterizing the inputs of a web application.  The present invention can be incorporated into a variety of embodiments, including  an engine that drives an assessment tool or an automated form filling tool, etc.  Describing the operation in an assessment tool engine embodiment, initially, the engine determines what locations on a web application generated web page accept inputs 210.  This determination may include identifying if the input is within a frame structure, a form, a selection box, etc.  The engine then operates to identify as much information about each of the inputs as possible and thus, characterize the inputs.  Embodiments of the present invention employ several techniques, operations and functionalities in an effort to characterize the inputs, not all of which are required in any one embodiment and which various combinations or individual techniques may in and of themselves be novel.  One of the techniques used to characterize the inputs is to operationally determine the characteristics of the inputs 220.   This technique involves etermining what types of inputs are allowed on that page, or at particular data entry locations 220.  For instance, this process involves serially sending different characters, symbols, strings, etc. to the data input of the web page and monitoring the responses.  For instance, letters of the alphabet, numbers, symbols, etc. can be sent to the input to determine categories of accepted inputs as well as specific accepted inputs.  .  In addition, determinations can be made as to whether the input responds differently to upper-case versus lower-case letters, the length of data entries, interprets digits as integer numbers, dates, values, etc. or if they are just viewed as standard characters.  This technique can also be employed to determine the minimum and maximum number of characters that are accepted by the input.  Thus, in exemplary embodiments, this may be a very systematic and focused procedure that includes basic rudimentary steps that are employed to identify the characteristics of the various inputs.  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 what types of input values are accepted or rejected or performing some other analysis.  For instance, a simple Boolean type analysis can be utilized to distinguish between rejected entries and accepted entries and then characterizing the inputs based on this information.  
[0038] Another technique for characterizing the input is contextually determining the characteristics of the inputs 230.  This process involves examining the content of the webpage surrounding or related to the input to determine if there is any information regarding the input to be discovered.  This information is used to further characterize the various inputs of the web application.   
[0039] Once the characteristics of the inputs are identified, this knowledge can be applied in a variety of manners to help improve web application utilization and analysis 230.  As a non-limiting example, the inputs can be grouped based on these characteristics and used to support a sub-application auditing tool as described in the referenced patent application.  These groups of characteristics basically identify inputs that are driven and controlled by common backend processes.  For instance, if a web application has multiple login locations, such as www.bankofamerica.com, a common backend process may be used for receiving and validating the user name and another common backend process for receiving and validating the password - or in fact a single backend process may handle both.  FIG. 3A is a screen shot of the Bank of America sign-in web page.  The illustrated screen shot includes 15 different sign-in links that can be selected by a user.  These links are circled in the figure.  Activating each link takes the user to another web page that allows the user to login.  The presentations of these various login screens are different from the user's perspective.  
[0040] For example, Figs. 3B and 3C are screen shots showing the results of activating link 302 in Fig. 3A.   In Fig. 3B, the user is presented with an Online ID field 304 and after successfully entering the Online ID, the user is taken to the web page illustrated in Fig. 3C, where the user is presented with a Password field 306.  Text below the password field 306 indicates that the password field 306 accepts 4-20 characters and is case sensitive.  To enter the Online ID and password, the user is required to enter the first value, send this information to the web application and then be directed to the screen shown in Fig. 3C.  At this point, the user can enter his or her password and again, submit this to the web application.  From examining this web page sequence, it is apparent that backend process requires Online ID verification prior to conducting password verification.  
[0041] Fig. 3D is a screen shot showing the results of activating link 308 in Fig. 3A.  In Fig. 3D, the user is presented with a user ID field 310 and a password field 312 all on the same web page.  In this screen, the user is required to enter his or her user ID and password prior to sending this information to the web application.  Thus, it appears that the backend process for handling the user ID and password for this screen may be different than the one used to process the online ID and password in Figs. 3B and 3C.  
[0042] Fig. 3E is another screen shot showing the results of activating link 314 in Fig. 3A.  This is the sign-in for military banking.  In Fig. 3E, the user is presented with a User ID field 316 and a password field 318.  The structure presented in Fig. 3E is similar to that presented in Fig. 3D and as such, the backend process used to receive and verify the user ID and the password has a high chance of being common for these two screens.  On the other hand, several of the sign-in screens accessible from links displayed in the web page shown in Fig. 3A adhere to the structure of Figs. 3B and 3C and as such, they most likely use a common backend process.  Thus, from this simple illustration, it is demonstrated how two groupings of inputs can be identified.  
[0043] Thus, in this example, once the inputs are categorized, the vulnerability assessment tool can then begin attacking a subset of the inputs in each category.  Advantageously, this application of the present invention can greatly reduce the workload in performing an assessment without compromising the integrity of the assessment.  In fact, with the processing time saved, deeper and more thorough attacks can be conducted on the backend processes than what would be allowed if the tool had to test each and every input field.  It should also be appreciated that the groupings of the inputs can also be utilized in various embodiments of the present invention to lessen the required workload.  For instance, if the context of a characterized input is similar to an uncharacterized input, the embodiment can make some assumptions that may greatly reduce the amount of time required to characterize the new input.  As an example, assume the characterized input is a telephone number and it has been shown to accept only numbers, parenthesis, spaces and hyphens and the input is limited to a minimum of ten characters and a maximum of 14 characters.  If the context of the input field includes the word "phone", then an uncharacterized input that also includes a word containing "phone" in its vicinity may also be a telephone number.  In this situation, rather than conducting a complete test sequence on the input, the known allowed and rejected values can easily be used to probe the input and verify that it is also limited in the same manner.  
[0044] Thus, one embodiment of the present invention operates to conduct a crawl of a web site to identify all of the inputs for the web site.  The embodiment may then interrogate the web application and use the answers or responses from the web application as feedback for deciding what the next steps in the attack will be.  By characterizing the behavior of the web application inputs, information about the backend processing can be obtained.  The attack can then focus on looking for vulnerabilities on a backend process level rather than at the user interface level - a much narrower and more focused approach. 
[0045] As previously mentioned, one of the aspects of the present invention is to characterize the various inputs of the web application.  One method to conduct this task is send various data to the web application and watch how the web application responds.  For instance, the accepted length of a data string can be identified by sending various string lengths and examining which string lengths are accepted and which are rejected.  Likewise, the set of acceptable characters can also be determined.  The process may involve sending groups of characters, representative characters from various classes of characters, or using other techniques to characterize this aspect of the inputs.    
[0046] Other information about the input can be determined by examining the context of the input field.  For instance, as illustrated in Figs. 3A-3E, the password field includes textual information in the proximity of the box.  Namely, this textual information indicates that the password field is case sensitive and accepts 4-20 characters.  This information can be obtained by scraping the screen or searching the source file.  As such, fields that include labels such as password, passcode, PIN, access code, etc. may initially be tagged as potentially similar input fields using common backend processes.  In addition, the HTML code can be searched to identify other characteristics of the input fields in an effort to group them.  All of this information together can help to group the various input fields based on the characteristics of what data they accept and as such, provide a good indication as to commonality of backend processes.  
[0047] These techniques may also be used to characterize how the web application interprets the input data.  A library of heuristics may be utilized in helping to identify or categorize the various input fields.  For instance, if it is determined that a particular input field accepts only 5 characters and the character set is limited to digits ranging from 0 to 9, then there is a high probability that the field is for entering zip codes.  Furthermore, by scraping the screen for the term zip or zip code in close proximity to the input field, this presumption can be further confirmed.  Other input fields for the web application that have similar characteristics can be grouped together and only a subset of these input fields will need to be assessed for vulnerabilities.  Similar heuristics can be applied for various other fields such as, but not limited to, the following examples:
[0048] age: maximum of three characters, character set includes numbers from 0 to 9 and only a blank, 0 or 1 in the most significant location when three characters are submitted.
[0049] name: maximum of 20 characters, character set includes only letters from A-Z and a-z.
[0050] phone number: maximum of 14 characters, character set includes numbers 0-9 and the following characters: "(", ")" space and "-"
[0051] In addition, these techniques can be used to determine if the input interprets the data as a text string or as number.    
[0052] Fig. 4 is a flow diagram illustrating the steps involved in an exemplary embodiment of the present invention to characterize the inputs of a web application.  Initially a crawl may be conducted to find the inputs or the inputs may otherwise be identified.  Then, for each input the characters or symbols that are accepted by that input are determined 410.  This process may simply involve sending one or more characters or symbols at a time to determine which ones result in invoking an error message.  The process may also include identifying the length of accepted inputs 412.  Again, this can be conducted in a variety of manners such as starting with one character and working up until a string length is rejected, or a more robust algorithm can be employed to reduce the number of steps required to identify the maximum length.  In addition, for fields that accept numeric values only, algorithms can be employed to determine the maximum range of accepted number, the response to negative numbers, etc.  Further characteristics are determined by examining the context of the input field 414.  As described above, this may include scraping the screen for text, but may also include looking at other attributes such as, titles of the page, color schemes, graphics, etc. that may provide hints as to the purpose of the input field.  Also, the HTML source code can be searched to identify attributes and limits imposed on the input field 416.
[0053] As previously mentioned, the characterization of the web application inputs can be greatly beneficial for several applications.  One application, as previously mentioned, is in conducting sub-application based audits of a web application.  However, the characterization of the inputs may also help facilitate web crawling.  For instance, characterizing the inputs allows a crawler to know what values to enter into the various fields of a form to gain access to the web pages behind the form.  As a specific example, the screen scraper aspect of the present invention can identify all the fields that include an asterisk in the proximity of the field - indicating that inputs are required.  With this knowledge, the crawler can ensure that these fields are populated and disregard the other fields and still gain access to the pages behind the form.  
[0054] Likewise, the present invention advantageously can be used for automatically filling in web forms or pre-populating certain form information.  For example, if the present invention is incorporated into a browser application, when a web page loads - especially a web based form - the present invention can characterize the inputs as they are rendered.  The application can then examine the user's information or cookie files to obtain information for populating known fields in the form.  The present invention can similarly be used in automating the process of configuring an application.  Embodiments of the present invention can examine the inputs and pushed text messages of an application and logically figure out what needs to be done next.  For instance, as a simple and non-limiting example, after an application loads, the present invention can detect the presentation of a window requesting the user to select a YES button to reboot the computer.  Embodiments of the present invention could automatically detect and actuate this function.  Similarly, in a web application, once a form is completed, the invention could identify a submit button and automatically actuate it.  
[0055] 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 characterizing the inputs of a web application, the method comprising the steps of:
identifying an input of a web application;
operationally determining the characteristics of the input; 
contextually determining the characteristics of the input; and
applying the input characterization knowledge.
2.    The method of claim 1, wherein the step of operationally determining the characteristics of the input of the web application comprises determining what characters are accepted by the input.
3.    The method of claim 1, wherein the step of operationally determining the characteristics of the input of the web application comprises determining the number of characters that are accepted by the input.
4.    The method of claim 1, wherein the step of operationally determining the characteristics of the input of the web application comprises determining the manner that the input is treated.  
5.    The method of claim 1, wherein the step of operationally characterizing the input further comprises:
sending a probe to the web application, the probe including one or more characters;
receiving a response from the web application; and
analyzing the response to determine if the one or more characters were accepted.
6.    The method of claim 5, further comprising the step of repeating the steps until all of the characters accepted by the web application input have been identified.  
7.    The method of claim 1, wherein the step of contextually determining the characteristics of the input of the web application comprises examining the context of the web page in the vicinity of the input.
8.    The method of claim 7, wherein the step of examining the context of the web page in the vicinity of the input comprises scraping the web page for matter associated with the input.  
9.    The method of claim 7, wherein the step of examining the context of the web page in the vicinity of the input comprises scraping the web page for textual content describing the input.
10.    The method of claim 1, wherein the step of contextually determining the characteristics of the input of the web application comprises examining the markup language code related to the inputs.  
11.    The method of claim 10, wherein the step of examining the markup language code related to the input comprises the step of parsing the code for textual content describing the input.  
12.    The method of claim 1, further comprising the step of crawling the web application to identify the input.
13.    The method of claim 12, further comprising the step of repeating the steps for each input of the web application.  
14.    A method for characterizing the inputs of a web application, the method comprising the steps of:
crawling the web application to identify the inputs;
for each identified input, operationally determining the characteristics of the input by:
sending a series of probes to the input;
receiving responses to the probes from the web application;
analyzing the response; and
for each identified input, contextually determining the characteristics of the input by:
examining content in the proximity of the input; and
examining the markup language code associated with the input.
15.    The method of claim 14, wherein the step of sending a series of probes to the input further comprises sending probes to identify the characters accepted by the input.
16.    The method of claim 14, wherein the step of sending a series of probes to the input further comprises sending probes to identify the number of characters accepted by the input. 
17.    A method for characterizing the inputs to a web application, the method comprising the steps of:
crawling the web application to identify the inputs;
for each identified input, characterizing the input by:
sending probes with various characters and varying numbers of characters to the input;
receiving responses to the probes from the web application;
analyzing the response;
parsing the HTML code of the web site for textual information related to the input; and
scraping the web page to identify descriptive material about the input.
ABSTRACT OF THE DISCLOSURE
The inputs of a web application are detected through a technique such as crawling, and then the characteristics of the inputs are determined.  The characteristics are determined by identifying how the inputs react to various probes containing varying characters and varying numbers of characters.  As such, the characters allowed by the input are identified, the maximum and minimum number of characters that are accepted and the manner in which the characters are treated by the web application.  Further characteristics of the inputs are determined by examining the context of the inputs, the markup language associated with the input, the size of the input, etc.  The knowledge regarding the input characterizations can be applied in a variety of settings.      
Fig. no. 2
2008171397.tif 000011
2008171397.tif 000012
2008171397.tif 000013
2008171397.tif 000014
2008171397.tif 000015
2008171397.tif 000016
2008171397.tif 000017
2008171397.tif 000018