本発明は、ウェブサイトの解析、相互作用、監査、及びアクセスの自動化の分野に関し、より具体的には、ウェブアプリケーションの入力を解析して入力のドメインを識別し、次に、この知識を使用して解析器や監査器等の他のウェブサイトツールの性能を改善するツールに関する。

［関連出願の相互参照］
この出願は、出願番号第１１／５６０，９６９号を割り当てられ、代理人整理番号第１９００６．１０８０号によって識別される２００６年１１月１７日に出願された「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;ローバスト）なアルゴリズムを用いて、最大長を識別するのに必要とされるステップ数を削減することもできる。
加えて、数値のみを受け付けるフィールドについては、受け付けられる数字の最大範囲や負の数に対する応答等を求めるアルゴリズムを用いることができる。
さらなる特徴が、入力フィールドのコンテキストを調べることによって求められる（４１４）。
上述したように、これは、テキストについてスクリーンをスクレイプすることを含むことができるが、入力フィールドの目的についてのヒントを提供する場合があるページのタイトル、カラー方式、グラフィックス等の他の属性を調べることも含むことができる。
また、ＨＴＭＬソースコードを検索して、入力フィールドに課せられた属性及び制限を識別することもできる（４１６）。

前述したように、ウェブアプリケーションの入力の特徴付けは、いくつかの用途に非常に有益となる可能性がある。
１つの用途は、前述したように、ウェブアプリケーションのサブアプリケーションベースの監査を行うことにある。
一方、入力の特徴付けは、ウェブのクロールを容易にすることを助けることもできる。
たとえば、入力を特徴付けることによって、クローラは、フォームの背後にあるウェブページにアクセスするためにフォームのさまざまなフィールドにどの値を入力するのかを知ることが可能になる。
一具体例として、本発明のスクリーンスクレイパの態様は、フィールドの近傍にアスタリスクを含むすべてのフィールドを識別することができる。 このアスタリスクは、入力が必要であることを示すものである。
この知識により、クローラは、これらのフィールドが確実にポピュレートされるようにすることができ、且つ、他のフィールドを無視することができ、それでも、フォームの背後にあるページにアクセスすることができる。

さらに、本発明は、ウェブフォームを自動的に入力するか、又は、一定のフォーム情報を事前にポピュレートするのにも好都合に使用することができる。
たとえば、本発明が、ブラウザアプリケーションに組み込まれている場合、ウェブページ、特にウェブベースフォームがロードされると、本発明は、入力がレンダリングされると同時に入力を特徴付けることができる。
次に、アプリケーションは、ユーザの情報又はクッキーファイルを調べて、そのフォームの既知のフィールドをポピュレートするための情報を取得することができる。
本発明は、同様に、アプリケーションを構成するプロセスを自動化することにも使用することができる。
本発明の実施形態は、アプリケーションの入力及びプッシュされたテキストメッセージを調べて、次に行う必要があるものを論理的に解明することができる。
たとえば、簡単で非限定的な一例として、アプリケーションがロードされた後、本発明は、ユーザにＹＥＳボタンを選択させてコンピュータをリブートさせることを要求するウィンドウの提示を検出することができる。
本発明の実施形態は、この機能を自動的に検出して作動させることができる。
同様に、ウェブアプリケーションでは、フォームが一旦完了すると、本発明は、サブミットボタンを識別し、そのサブミットボタンを自動的に作動させることもできる。

この説明で提供された実施形態及び具体例は、非限定的な例として提供されたものであり、したがって、たとえそれらが個々に新規であると考えることができても、本発明の唯一の新規な実施態様又は構成とみなされるべきではないことが十分理解されるべきである。
説明した実施形態は、異なる特徴を含み、それらの特徴のすべてが、本発明のすべての実施形態で必要とされるとは限らない。
本発明のいくつかの実施形態は、これらの特徴又はこれらのの特徴の可能な組み合わせの一部しか利用しない。
当業者には、説明した本発明の実施形態の変形形態と説明した実施形態で言及された特徴の異なる組み合わせを含む本発明の実施形態とが思いつくであろう。
本発明の範囲は、添付の特許請求の範囲によってのみ限定される。

評価ツールの一般的構造のシステム図である。

評価するバックエンドプロセスを識別する際の本発明のオペレーションの超高レベル図を示すフロー図である。

バンクオブアメリカのサインインウェブサイトのスクリーンショットである。

図３Ａのリンク３０２をアクティブ化した結果を示すスクリーンショットである。

図３Ａのリンク３０２をアクティブ化した結果を示すスクリーンショットである。

図３Ａのリンク３０８をアクティブ化した結果を示すスクリーンショットである。

図３Ａのリンク３１４をアクティブ化した結果を示す別のスクリーンショットである。

ウェブアプリケーションの入力を特徴付ける、本発明の例示的な一実施形態に関連したステップを示すフロー図である。

符号の説明

１００・・・ウェブ評価インターフェース１１０・・・ウェブサーバ又は宛先システム１２０・・・インターネット１３０・・・ソフトウェアエージェント１４０・・・評価データ１５０・・・報告インターフェース