JP5801953B2 - アプリケーションのセキュリティ検査 - Google Patents

Description

ソフトウェアセキュリティ検査は、ウェブアプリケーション等のアプリケーションの脆弱性を識別するために使用される。セキュリティ検査アプリケーションを使用することによるウェブベースソフトウェア開発のための従来のブラックボックス型セキュリティ検査は、スキャナと呼ばれることが多く、アタッカーを装うものである。ブラックボックス方式では、スキャナは、検査対象となるアプリケーション（AUT：Application Under Test）が入力を許容するURLの全てを見いだすために、HTTPリクエストを行い、そのHTTPレスポンスを評価することにより、該AUTを調査する。AUTが入力を許容するURLは、該AUTのアタックサーフェスと呼ばれる場合がある。スキャナは次いで、該アタックサーフェス及び存在し得る脆弱性のカテゴリに基づいてアタックを生成する。スキャナは、該アタックを加えて該プログラムのHTTPレスポンスを評価することにより脆弱性の存在又は不存在を診断する。ブラックボックス方式では、スキャナは、AUTの内部的な動作を洞察することはない。

ブラックボックス式脆弱性検査は、その概念は分かりやすいが、実際には多数の課題を呈するものである。例えば、AUTの調査は、全てのアタックサーフェスを露呈させることができない可能性があり、このため、スキャナは、AUTが脆弱となる場所の全てにアタックを加えない可能性がある。更に、脆弱性によっては、HTTPレスポンスで返される情報を介して精確に識別することができないものがある。該スキャナは、脆弱性を発見した場合に、AUTのコード内の該脆弱性が存在する場所に関する情報を提供することができない。更に、該スキャナは、AUTの同一の根本的な問題に全て関連する幾つかの脆弱性を報告する可能性があり、その結果として、プログラマは、それら脆弱性を修正しようとして多大な反復作業を行うことになる。

本書で説明する実施形態は、ウェブアプリケーションのグレーボックスセキュリティ検査を実行するための技術を提供する。グレーボックスセキュリティ検査では、AUTにより実行される内部動作を観察するために本書でオブザーバと称するソフトウェアプログラムが使用される。該オブザーバは、AUTの動作及び該AUTがアタックに応じて挙動する態様をスキャナが判定することを可能にする。該オブザーバはまた、通常のアプリケーションリクエストに応じたAUTの挙動をスキャナが判定することを可能にし、かかる挙動を利用して、スキャナは、送信すべきアタックの種類を判定することが可能となる。スキャナは、AUTにアタックを送り続けて、該AUTの内部動作に関する知識をオブザーバから受信する。このようにして、スキャナは、より多くの脆弱性を見いだしてより良い脆弱性レポートを生成することが可能となり、これにより、ウェブベースアプリケーションの一層総合的で詳細なソフトウェアセキュリティ検査が提供される。

一実施形態によれば、オブザーバとスキャナとの間に通信チャネルが配設される。スキャナは、この通信チャネルを使用してAUTの洞察をそのスキャニング中に得る。このスキャナとオブザーバとの間の通信チャネルは、AUTにより既に使用されている通信チャネルを用いて実施することが可能である。このようにして、テストを実施する者は、追加の設定又はセットアップ作業を行う必要がなく、該通信チャネルは、AUT又は該AUTを実行しているコンピュータシステムの通常動作を妨げないものとなる。本発明の更なる利点については、以下に示す説明を参照することにより一層良好に理解することが可能である。

一実施形態による、グレーボックスセキュリティ検査を行うために使用することが可能なシステムのブロック図である。 一実施形態による、グレーボックスセキュリティ検査を行うための検査システムの構成を示すブロック図である。 一実施形態による、グレーボックスセキュリティ検査方法のプロセスフローチャートである。 一実施形態による、グレーボックスセキュリティ検査を行うよう構成されたコードを格納する持続性コンピュータ読み取り可能媒体を示すブロック図である。

以下の詳細な説明では図面を参照して幾つかの実施形態について説明する。

図１は、本発明の一実施形態による、グレーボックスセキュリティ検査を行うために使用することが可能なシステムのブロック図である。該システムは全体的に符号100で示されている。図１に示す複数の機能ブロック及び装置は、回路を含むハードウェア要素、持続性マシン読み取り可能媒体に格納されたコンピュータコードを含むソフトウェア要素、又はハードウェア要素及びソフトウェア要素の組み合わせから構成することが可能である、ということが当業者には理解されよう。更に、該構成は、図１に示す構成に限定されるものではなく、本発明の実施形態において任意の数の機能ブロック及び装置を使用することが可能である。当業者であれば、特定の電子装置についての設計検討に基づいて特定の機能ブロックを容易に決定することが可能であろう。

図１に示すように、システム100はコンピューティング装置102を含み、該コンピューティング装置102は、バス106を介してディスプレイ108、キーボード110、及び１つ以上の入力装置112（マウス、タッチスクリーン、又はキーボード等）に接続されたプロセッサ104を一般に含むものとなる。一実施形態では、該コンピューティング装置102は、汎用コンピューティング装置（例えば、デスクトップコンピュータ、ラップトップコンピュータ、サーバ）である。コンピューティング装置102はまた、１種類又は２種類以上の持続性コンピュータ読み取り可能媒体（例えば、本発明の実施形態で使用されるオペレーティングプログラムを含む様々なオペレーティングプログラムの実行中に使用することができるメモリ114）を有することが可能である。該メモリ114は、リードオンリーメモリ（ROM）やランダムアクセスメモリ（RAM）等を含むことが可能である。コンピューティング装置102はまた、他の持続性コンピュータ読み取り可能媒体（例えば、本発明の実施形態で使用されるオペレーティングプログラム及びデータを含むオペレーティングプログラム及びデータの長期記憶のためのストレージシステム116）を含むことが可能である。

一実施形態では、コンピューティング装置102は、該コンピューティング装置102をサーバ120に接続するためのネットワークインタフェイスコントローラ（NIC）118を含む。該コンピューティング装置102は、ネットワーク122（例えば、インターネット、ローカルエリアネットワーク（LAN）、ワイドエリアネットワーク（WAN）、又はその他のネットワーク構成）を介してサーバ120に通信可能な状態で接続することが可能である。該サーバ120は、データを格納し、通信をバッファリングし、及びサーバ120のオペレーティングプログラムを格納するためのストレージデバイス等の持続性コンピュータ読み取り可能媒体を有することが可能である。コンピューティング装置102とサーバ120との間の通信は、HTTP（Hyper-Text Transfer Protocol）等のリクエスト／レスポンス型プロトコルを使用して行うことが可能である。

サーバ120は、AUT124をホストするアプリケーションサーバとすることが可能である。サーバ120はまた、実行中にAUT124を監視するオブザーバ126を含むことが可能である。コンピューティング装置102は、、AUT124に対してセキュリティ検査を実行するスキャナ128を含むことが可能である。例えば、スキャナ128は、ネットワーク122を介してAUT124へHTTPリクエストを送ることが可能であり、この場合、該HTTPリクエストはAUT124の脆弱性を露呈させるべく構成される。該HTTPリクエストは、暗号化通信とネットワークウェブサーバの安全な識別とを提供すべくHTTPにSSL（Secure Sockets Layer）及びTLS（Transport Layer Security）プロトコルを組み合わせたHTTPSリクエストを含むことが可能である。AUT124によるHTTPリクエストの処理中に、オブザーバ126は、該AUT124により実行される内部プロセスを監視する。例えば、オブザーバ126は、AUT124により実行されたコード、アクセスされたファイル、実行されたデータベースクエリ等を識別することが可能である。オブザーバ126及びAUT124は両方とも、同じHTTPチャネルを介してスキャナ128と通信するよう構成することが可能である。図２に関して後述するように、スキャナ128からサーバ120へ送信される幾つかのリクエストは、AUT124からそのプログラミングに従ってレスポンスを引き出すべく該AUT124をターゲットとすることが可能である。スキャナ128からサーバ120へ送信される他のリクエストは、AUT124により実行される動作に特定のリクエストが与えた影響に関する更なる情報、又は該AUT124、オブザーバ126、若しくは該AUT124をホストするサーバ120に関する他の情報を取得すべく、オブザーバ126をターゲットとすることが可能である。スキャナ128は、アプリケーションリクエスト及びサービスリクエストに応じて受信したデータを使用して脆弱性レポートを生成することが可能である。脆弱性レポートは、スキャナ128により提供されるユーザインタフェイスを介してユーザに対して表示することが可能である。

図２は、一実施形態による、グレーボックスセキュリティ検査を行うための検査システムの構成を示すブロック図である。システム200は、スキャナ128、AUT124、及びオブザーバ126を含むことが可能である。AUT124は、特に、JAVA又は.NETといった任意の適当なウェブベースコンピュータ言語でエンコードすることが可能である。AUT124は、特に、Struts、Struts 2、ASP.NET MVC、Oracle WebLogic、及びSpring MVCといった適当なソフトウェアフレームワーク内で動作することが可能である。該ソフトウェアフレームワークは、選択的にオーバーライドすること又は特定の機能を提供すべくユーザコードによって特殊化することが可能な汎用的な機能を提供する一組の共通コードモジュールを含む。AUT124は、スキャナ128からのリクエストを処理するために、Java仮想マシン（JVM）、共通言語ランタイム（CLR）、及びその他のランタイム環境の１つ以上のインスタンスを実行するよう構成することが可能である。ソフトウェアフレームワークの共通コードモジュール又はランタイム環境により提供されるプログラミング命令はコンテナコードと称することが可能である。AUT124に固有のカスタムプログラミング命令はユーザコードと称することが可能である
AUT124は、スキャナ128とAUT124との間のネットワーク122を介した通信を可能にするネットワークインタフェイス202を含む。該ネットワークインタフェイス202は、AUT124のアタックサーフェスを露呈させるものであり、該AUT124を一般的な用途に利用可能とする場合に該AUT124へのアクセスを提供するために最終的に使用されることになるものと同じインタフェイスである。スキャナ128とAUT124との間のネットワークインタフェイス202を介した通信は、スキャナ128からAUT124へ発行されるHTTPリクエスト及びAUT124からスキャナ128へ発行されるHTTPレスポンスを介して行われる。AUT124をターゲットとしたリクエストはアプリケーションリクエストと称することが可能であり、AUT124から受信するレスポンスはアプリケーションレスポンスと称することが可能である。スキャナ128により生成されるアプリケーションリクエストは、AUT124の潜在的な脆弱性を露呈させるべく構成することが可能である。

AUT124は、ファイルシステム204、データベース206、及びその他のAUT124により使用されるリソースに結合することが可能である。データベース206は、例えば、AUT124の様々なりソースへのアクセスを許可するために使用されるユーザ名及びパスワードといった、様々なユーザ情報を含むことが可能である。ファイルシステム204は、AUT124により使用されるデータ及びプログラム、並びに、HTTPページ、ソフトウェアプログラム、及びメディアファイルといったユーザにより要求されるデータを含むことが可能である。

オブザーバ126は、AUT124の実行環境内で動作し、AUT124により実行される内部動作にアクセスすることができる。例えば、オブザーバ126は、様々なプログラムポイントでJAVAクラス等の追加のコードをインジェクトすることにより、AUT124のバイトコードを変更することが可能である。該インジェクトされたコードは、AUT124を観察するモニタとして働く。該インジェクトされたモニタコードは、AUT124内のストラテジックプログラムポイント（例えば、URLパラメータの読み出し又はファイルシステム204への書き込みといった特定の動作を実行するアプリケーションプログラミングインタフェイス（API）コール）に配置することが可能である。かかるAUT124内のプログラムポイントが実行される場合には必ず、該モニタは、オブザーバ126により提供されるサービスをコールしてAUT124により実行された動作を記録する。オブザーバ126は、AUT124の内部動作に関して収集された情報を格納するためにバッファ210に接続することが可能である。該バッファ210は、収集されたがスキャナ128に未だ報告されていないデータを格納するために使用することが可能である。該バッファ210は、ハードディスクやSSD(Solid State Drive)等の不揮発性記憶媒体に格納することが可能である。

オブザーバ126はまた、該オブザーバ126とスキャナ128との間のネットワーク122を介した通信を可能にするための更なるネットワークインタフェイス208を含むことが可能である。上述のように、ネットワークインタフェイス202,208は何れも同一の通信チャネル（例えば、同一のHTTPチャネル）を使用することが可能である。スキャナ128とオブザーバ126との間の通信は、カスタムリクエストヘッダ及びカスタムレスポンスヘッダを使用して実施することが可能である。カスタムヘッダは、スキャナ128によるアプリケーションリクエストに追加することが可能であり、及び、カスタムヘッダは、オブザーバ126によるアプリケーションレスポンスに追加することが可能である。このようにして、スキャナ128とオブザーバ126との間の通信の少なくとも一部をAUT124との通常の通信に便乗させる（piggy-back）ことが可能である。単一チャネルの通信を使用することにより、専用の二次チャネルのオープンに関する問題が排除され、HTTPヘッダの追加は、一般にAUT124の通常動作を妨げるものではない。

スキャナ128は、各アプリケーションリクエストに１つ以上のカスタムヘッダを追加することが可能であり、この場合、該カスタムヘッダは、進行中のアタックに関する脆弱性を診断するためにオブザーバ126が使用することができる情報を含む。カスタムヘッダ内の情報は、スキャナ128のバージョン、又は該スキャナ128がアタックで使用しているペイロードを含むことが可能である。該ペイロード情報は、該アタックが成功したか否かを判定するためにオブザーバ126が使用することが可能なものである。

スキャナ128はまた、AUT124により実行される内部プロセスに関する追加情報、又はAUT124、サーバ120（図１）、若しくはオブザーバ126に関する情報を取得するために、オブザーバ126をターゲットとするリクエストを、カスタムリクエストヘッダを使用して生成することが可能である。オブザーバ126をターゲットとするリクエストはサービスリクエストと称することが可能であり、オブザーバ126から受信したレスポンスはサービスレスポンスと称することが可能である。オブザーバ126により発行されるサービスレスポンスは、以下で更に説明するように、サービスレスポンスのボディ内に補足情報を含むことが可能である。

一実施形態では、オブザーバ126は、スキャナ128からAUT124へ送信されるアプリケーションリクエスト及びサービスリクエストを受信するよう構成される。次いで該オブザーバ126は、ヘッダ情報を解析して、該リクエストがアプリケーションリクエストであるかサービスリクエストであるかを判定することが可能である。アプリケーションリクエストを受信した場合、オブザーバ126は、そのヘッダ情報を解析して、該特定のアプリケーションリクエストに関して該オブザーバ126が使用するデータを獲得することが可能である。アプリケーションリクエストは次いで、オブザーバ126によりAUT124へ供給され、AUT124のプログラミングに従って該AUT124により処理される。AUT124がアプリケーションレスポンスを生成すると、オブザーバ126は１つ以上のカスタムヘッダを該アプリケーションレスポンスに追加してスキャナ128へ追加情報を送ることが可能である。アプリケーションリクエスト及びアプリケーションレスポンスに追加されるカスタムヘッダは、リクエスト毎ヘッダと称することが可能であり、これについては「リクエスト毎ヘッダ」と題する章で更に説明する。

サービスリクエストを受信すると、オブザーバ126は、該サービスリクエストをAUT124へ供給することなくその処理を行うことが可能である。該サービスリクエストは、オブザーバ126の特定のサービスをリクエストするよう構成された情報（例えば、リクエストされているサービスの名称）を含む１つ以上のカスタムヘッダを含むことが可能である。オブザーバ126は、HTTPレスポンス（本書では「サービスレスポンス」と称す）のボディ内のリクエストされた情報に応答することが可能である。一実施形態では、サービスレスポンスのボディ内でオブザーバ126により提供される情報は、JSON（Java Script Object Notation）を使用して作成することが可能であり、自己識別型（self-identifying）JSONオブジェクトとすることが可能である。オブザーバ126は、送信すべき情報を有さず、レスポンスボディは空とすることが可能である。サービスリクエストについては、「サービスリクエスト」と題する章で更に説明する。
・リクエスト毎ヘッダ
リクエスト毎ヘッダは、カスタムHTTPヘッダであり、オブザーバ126及びスキャナ128によって理解されるカスタムフィールド名とそれに続く１つ以上のフィールド値とを含むことが可能である。該カスタムHTTPヘッダは、AUT124によって無視される。本書で説明するフィールド名は、特定の一実施形態で使用することができるフィールド名の単なる一例として使用したものであり、本発明の範囲を制限することを意図したものではない、ということが理解されよう。

リクエスト毎ヘッダは、スキャナ128とオブザーバ126との間の対話を調整するために使用されるバージョンヘッダを含むことが可能である。オブザーバ126は、あらゆるアプリケーションレスポンスにバージョンヘッダを追加することが可能である。スキャナ128は、該バージョンヘッダを使用してオブザーバ126がインストールされていることを検証することが可能である。一例として、バージョンヘッダは以下のように規定することが可能である。

X-WIPP-Version:<language>/<version>/<vm_id>
このバージョンヘッダの一例では、プレフィクス"X-WIPP"は、オブザーバ126により使用されるカスタムヘッダとしてのヘッダを識別するものである。フィールド名"X-WIPP-VERSION"は、バージョンヘッダとしてのカスタムヘッダを一意に識別する文字列である。フィールド値<language>は、アプリケーションリクエストを処理するためにAUT124により使用されるランタイム環境の名称（特にJava又は.NETなど）とすることが可能である。場合によっては、AUT124は、２つ以上のプロセスを実行することが可能であり、かかるプロセスを異なるランタイムインスタンスにより取り扱うことが可能である。例えば、AUT124は、アプリケーションリクエストを処理するためにロードバランサその他の作業分散構成を使用することが可能である。スキャナ128は、フィールド値<vm_id>を使用して、アプリケーションリクエストを取り扱うAUT124内のプロセスを識別することが可能である。例えば、フィールド値<vm_id>は、特定のJVMインスタンス（JAVAの場合）、CLRインスタンス（.NETの場合）、又はその他のタイプのランタイムインスタンスといった、アプリケーションリクエストを処理したランタイムインスタンスを一意に識別する名称とすることが可能である。フィールド値<version>は、オブザーバ126のバージョンを識別する数字又は文字列とすることが可能である。スキャナ128は、識別されたオブザーバ126のバージョンを使用して、オブザーバソフトウェアのバージョンによってオブザーバのインタフェイス208が変化する場合に該オブザーバ126との対話を適切に調整することが可能である。

リクエスト毎ヘッダはまた、ファイル不発見条件を識別するためにスキャナ128により使用されるFNF（File-Not-Found）ヘッダを含むことが可能である。HTTPでは、存在せず又は発見できないリソースをクライアントがリクエストした場合、ウェブアプリケーションは、HTTPコード404と称される標準的なエラーコードを生成することが可能である。単純なウェブアプリケーションは、HTTPレスポンスでHTTPコード404を返すことによりファイル不発見条件を示すことが多い。より複雑なウェブアプリケーションは、404コードを「吸収する（swallow）」。換言すれば、HTTPレスポンスでHTTPコード404エラーを単純に返すのではなく、該コード404が該ウェブアプリケーションをトリガしてクライアントをエラーページ、ランディングページ、又は該ウェブアプリケーションの任意の他の部分へとリダイレクトすることが可能である。従来のブラックボックス型検査では、単純にエラーを報告するのではなくスキャナ128をウェブアプリケーションの異なる部分へとリダイレクトした場合、該スキャナ128が誤判定を報告することになる。FNFヘッダは、かかる結果を回避するために使用され得るものである。オブザーバ126がアプリケーションの内部で動作しているため、該オブザーバ126は、ファイル不発見エラーを検出してFNFヘッダをアプリケーションレスポンスに追加することにより該ファイル不発見エラーを報告することが可能である。例えば、アプリケーションリクエストがAUT124からのファイル不発見レスポンスを生じさせた場合、オブザーバ126は、以下のヘッダをアプリケーションレスポンスに追加することが可能である。

X-WIPP-FNF:404
このようにして、AUT124により提供されるHTTPレスポンスにかかわらずスキャナ128にファイル不発見エラーを報告することができる。

リクエスト毎ヘッダはまた、リクエストIDヘッダを含むことが可能である。該リクエストIDヘッダは、以下のように規定することが可能である。

X-WIPP-RequestID:<request_id>
以下で更に説明するように、「サービスリクエスト」と題する章で、スキャナ128は、アプリケーションリクエストに応じてオブザーバ126により収集されたが未だアプリケーションレスポンスで報告されていない追加情報をリクエストすることが可能である。該追加情報は、本書で「トレース」と称するデータ構造内に含めることが可能である。該トレース内に含まれる情報は、特定のアプリケーションリクエストによりトリガされたAUT124の動作を記述するものである。該トレースリクエストサービスをサポートするために、オブザーバ126は、スキャナ128がリクエストされたトレースを該リクエストされたトレースに対応する特定のアプリケーションレスポンスに関連付けることを可能とすべく、各アプリケーションレスポンスにリクエストIDヘッダを追加することが可能である。一実施形態では、フィールド値<request_id>は、スキャナ128により割り当てられてアプリケーションリクエスト内に含められる。次いで、オブザーバ126が、対応するアプリケーションレスポンスに追加されるリクエストIDヘッダ内にそれと同一のrequest_id値を使用することが可能である。一実施形態では、スキャナ128はアプリケーションリクエストにリクエストIDヘッダを追加せず、この場合、オブザーバ126は、request_idのための一意の値を生成して、該request_idを、アプリケーションレスポンスに追加されるリクエストIDヘッダ内に含めることが可能である。何れの場合も、同一のrequest_id値をスキャナ128により使用して、それに対応するオブザーバ126からのトレースをリクエストすることが可能である。

リクエスト毎ヘッダはまた、AUT124に関する様々なタイプの変化をスキャナ128に通知するためにオブザーバ126により使用されるアップデートヘッダを含むことが可能である。該アップデートヘッダは、以下のように規定することが可能である。

X-WIPP-Update:<service_name_list>
該<service_name_list>値は、コンマで区切ったサービス名のリストとすることが可能であり、その各サービス名は、AUT124における変化の結果として新たな情報を提供し得るオブザーバ126により提供されるサービスを称するものである。AUT124に関する新たな情報が利用可能になると、オブザーバ126は、アプリケーションレスポンスにアップデートヘッダを追加することによりスキャナ128への通知を行うことが可能である。このようにして、アップデートヘッダは、AUT124に関する新たな情報が利用可能になったこと、及び該情報を取得するためにリクエストすべきサービスをスキャナ128に通知する。例えば、オブザーバ126が、AUT124のセキュリティ検査中に生成された追加のURLを検出した場合、該オブザーバ126は、スキャナ128にアップデートヘッダを送信することが可能であり、この場合、<service_name_list>は「アタックサーフェス」に等しくなる。該アップデートヘッダを受信した際に、スキャナ128は、識別された１つ以上のサービスをリクエストするサービスリクエストをオブザーバ126へ送信することが可能である。オブザーバ126は、指定した１つ以上のサービスのためのサービスリクエストをスキャナ128が発行するまで、あらゆるアプリケーションレスポンスでアップデートヘッダを送り続けることが可能である。
・サービスリクエスト−トレース
アプリケーションリクエストに応じて、オブザーバ126は、例えば、AUT124により実行された特定のコード、AUT124によりアクセスされたファイル、AUT124により実行されたデータベースクエリ、又はその他の情報を判定することにより、アプリケーションリクエストの結果を判定することが可能である。オブザーバ126により収集されたデータは、本書で「トレース」と称するデータ構造に格納することが可能である。一実施形態では、各トレースは、バッファ210に格納することが可能である。各トレースは、該トレースに対応するアプリケーションリクエスト及びアプリケーションレスポンスのリクエストIDを含むことが可能である。スキャナ128は、対応するトレースをオブザーバ126から読み出すことによって特定のアプリケーションリクエストによりトリガされたAUT124の内部動作について学習することが可能である。トレースを読み出すために、スキャナ128は、特定のアプリケーションリクエスト又はレスポンスに対応するトレースのリクエストを示すよう構成されたヘッダフィールド名／値の対を含むサービスリクエストをオブザーバ126に対して発行することが可能である。例えば、トレースをリクエストするための該フィールド名／値の対は、次のように規定することが可能である。

Trace=<request_id>
該値<request_id>は、「リクエスト毎ヘッダ」と題する章に関して上述したように、リクエストされたトレースに関連するアプリケーションリクエスト及び／又はアプリケーションレスポンスに対応するスキャナ128又はオブザーバ126により割り当てられた値である。トレースサービスリクエストを受信すると、オブザーバ126は、AUT124をバイパスして、該リクエストされたトレースを含むサービスレスポンスを生成することが可能である。一実施形態では、該リクエストされたトレースは、オブザーバ126によりバッファ210から読み出されてサービスレスポンスのボディに追加されることが可能であり、次いで該サービスレスポンスをスキャナ128へ送信することが可能である。該サービスレスポンスのヘッダは、リクエストされたトレースのrequest_id値を含み、該サービスレスポンスのボディは、JSONオブジェクトとして規定することが可能である。

スキャナ128が、発行されたあらゆるアプリケーションリクエストについてトレースをリクエストすることができるように、オブザーバ126は、バッファ210内に複数のトレースを維持することが可能である。バッファ210は、特定の実施形態に適した任意のサイズのものとすることが可能である。一実施形態では、バッファ210に格納されるトレースは、該バッファ210が一杯になった場合に、FIFO（first-in-first-out）態様で除去することが可能である。スキャナ128が未知のリクエストIDをリクエストした場合、オブザーバ126はエラーを返すことが可能である。リクエストIDは、それが無効であるか、過去に全く使用されたことがないか、又はオブザーバ126により維持されるトレースのバッファ210の中でも旧過ぎるかについて未知である可能性がある。

スキャナ128は、対応するアプリケーションリクエストが行われてAUT124からレスポンスが受信された後に別個のトレースサービスリクエストを送信するよう構成することが可能である。request_idは、オブザーバ126がトレースリクエストを順序に関係なく受信すると共に該受信したトレースを適当なアプリケーションリクエスト及びレスポンスに依然として関連付けできることを可能にする。スキャナ128がAUT124に対してアプリケーションリクエストを発行するマルチスレッドを実行し得ることに部分的に起因して、トレースリクエストを順序に関係なく受信することが可能となる。スキャナ128はまた、タイムアウトしたアプリケーションリクエストを中止するよう構成することが可能である（アプリケーションリクエストがタイムアウトした場合、スキャナ128は不完全なトレースをオブザーバ126から読み出す可能性がある）。完全なトレースと不完全なトレースとを区別するために、オブザーバ126は、トレースリクエストに対応するアプリケーションリクエストが成功裏に完了したことを示す特殊ノードを各々の完成したトレースに追加するよう構成することが可能である。例えば、オブザーバ126は、各々の完成したトレースの最後にタイプ"request_complete"の特殊ノードを追加することが可能である。該"request_complete"ノードの欠落は、対応するアプリケーションリクエストが失敗したことをスキャナ128に示すことが可能である。

オブザーバ126は、オブザーバ126によりインジェクトされた追加のモニタコードにより開始される複数のプロセスといった、アプリケーションリクエストとは無関係に発生するUT124により実行されるプロセスを監視することが可能である。許容不能なレベルのパフォーマンスオーバーヘッドを被ることを回避するために、オブザーバ126は、アプリケーションリクエストとは無関係のモニタリングプロセスのパフォーマンスオーバーヘッドを最小限にするよう構成することが可能である。例えば、パフォーマンスオーバーヘッドは、特定のAPIコール及びAUTのユーザコードの関連部分を選択的に監視するためのモニタコードをインジェクトすることにより最小限にすることが可能である。

スキャナ128に返されるトレースは、様々なタイプの１つ以上のトレースノードを含むことが可能である。各トレースノードは、AUT124により実行される内部プロセスに対応する複数ビットの情報を伝達する。一実施形態では、各トレースノードはタイププロパティを含み、該タイププロパティは、トレースノードのタイプを一意に識別する任意の適当な文字列とすることが可能である。幾つかのトレースノードのタイプは、AUT124により実行されたアクションのタイプに基づくものとすることが可能である。

一実施形態では、オブザーバ126は、AUT124及びコンテナコードにより使用されるコールスタックに関する情報を記録することが可能である。コールスタックとは、コンピュータプログラムのアクティブなサブルーチンに関する情報を格納するデータ構造である。例えば、コールスタックは、アクティブなサブルーチンがその実行を終了したときに制御を返すべきコード行を追跡することが可能である。コールスタックはまた、様々な機能の中でも特に、サブルーチンにパラメータを渡すため、及びサブルーチンに固有の変数のためにメモリを割り当てるために使用することが可能である。コールスタックは、AUT124又は該AUTのコンテナコードによりコールされた現在実行中のサブルーチンを表すトップスタックフレームを含むことが可能である。該トップスタックフレームは、特定の行のコードを識別するファイル名及び行番号を含むことが可能である。

各トレースは、１つ以上のトレースノードを含むことが可能であり、この場合、各トレースノードは、AUT124により生成される特定のコールスタックに関する詳細を記述するものである。トレースノードは、AUT124のコンテナコードにおけるオブザーバ126の外部のトップスタックフレームのファイル名及び行番号を識別するロケーションプロパティを含むことが可能である。トレースノードはまた、AUT124のユーザコードにおけるトップスタックフレームのためのファイル名及び行番号を与える"user_context"プロパティを含むことが可能である（かかるスタックフレームを識別し得る場合）。該コンテキストプロパティは、脆弱性の根本的原因の解析を含む脆弱性レポートをスキャナ128が生成することを可能にし、及びスキャナ128がコード内の同一の場所に関連する複数の脆弱性を１つにグループ化することを可能にする。

一実施形態では、オブザーバ126は脆弱性を検出するよう構成される。例えば、スキャナ128は、ファイルシステム204上に任意のファイルを生成するよう構成されたアプリケーションリクエストという形でAUT124にアタックを送ることが可能である。該アプリケーションリクエストは、該アタックの性質についてオブザーバ126に通知するカスタムヘッダ情報を含むことが可能である。AUT124が脆弱である場合には、オブザーバ126はファイル生成APIコールに遭遇することになり、それ故、ファイルアップロードアタックに成功し及び脆弱性が検出されたことがオブザーバ126に知らされる。

オブザーバ126は、脆弱性を検出した場合に、本書で「脆弱性トレースノード」と称するトレースノードを生成することが可能である。脆弱性トレースノードは、複数のシンクプログラムポイント及び（利用可能である場合には）１つ以上の潜在的なソースプログラムポイントといったコード場所情報をスキャナ128に提供する１つ以上のスタックトレースを含むことが可能である。ソースプログラムポイントは、AUT124により悪意のある入力が吸収されたコード場所であり、シンクプログラムポイントは、悪意のある入力がAUT124の挙動を変更させたコード場所である。例えば、クロスサイトスクリプティング脆弱性の場合、ソースプログラムポイントは、ユーザにより供給された値がURLパラメータから読み出された場所であり、シンクプログラムポイントは、汚染されたパラメータ値がHTMLページに書き込まれた場所である。スタックトレースは、それがオブザーバ126からのスタックフレームを含まないよう省略することが可能である。脆弱性トレースノードは、AUT124のコード及びコンテナコードの両方に関する複数のスタックフレームを含むことが可能であり、その各スタックフレームは、該スタックフレームがユーザコード又はコンテナコードに関係する場所の指示を含むことが可能である。オブザーバ126により提供されるコード場所情報によって、スキャナ128は、AUT124における脆弱性の場所を正確に示す脆弱性レポートを生成することが可能となり、及びAUT124における同一場所で生じる脆弱性をグループ化することが可能となり、このため、スキャナ128により生成される脆弱性レポートでの重複が削減される。コード場所情報はまた、脆弱性の性質に対するユーザの洞察を提供し、それ故、問題を修復するための修正努力の量を軽減させるものとなる。

脆弱性トレースノードはまた、「クロスサイトスクリプティング」又は「SQLインジェクション」といった脆弱性カテゴリ、及び各脆弱性カテゴリに対応するCWE（Common Weakness Enumeration）識別子といった標準的な脆弱性識別子を含むことが可能である。脆弱性トレースノードはまた、脆弱性の検出に関する詳細を含むことが可能である。例えば、脆弱性がSQLインジェクション脆弱性である場合、脆弱性トレースノードは、オブザーバ126による脆弱性の検出に伴うSQLクエリを含むことが可能である。このようにして、オブザーバ126は、スキャナ128に返されたアプリケーションレスポンスで脆弱性が顕わにならない場合であっても、SQLインジェクション脆弱性を検出してスキャナ128に報告することが可能となる。

オブザーバ126はまた、AUT124がデータベースに対してクエリ（SQLクエリなど）を実行する場合に、本書で「データベーストレースノード」と称するトレースノードを生成することが可能である。該データベーストレースノードは、データベースクエリでAUT124により使用されたバインドパラメータについてのデータベースクエリのテキスト及び値を含むことが可能である。他のタイプのトレースノードは、JAVAサーブレットやJSP（JAVA Server Pages）といったAUT124により呼び出されたソースコードファイルについての開始ノード及び終了ノードを含むことが可能である。開始ノード及び終了ノードは、AUT124を介した実行のフローを表す制御フロー構造におけるノードを称するものである。開始ノード及び終了ノードは、ソースコードファイルのファイル名及び該ソースコードファイルに渡されるパラメータを含むことが可能である。オブザーバ126はまた、例えば、とりわけ、AUT124により実行されるファイルシステム204の読み出し及び書き込み、AUT124により実行されるウェブサービスコール、及びAUT124により実行されるネットワークサービス操作を表すための、他のタイプのトレースノードを生成することが可能である。

上述のように、スキャナ128は、トレース情報を使用して重複する脆弱性をグループ化することが可能である。該重複する脆弱性のグループ化は、スキャナ128により実施される重複排除プロセスにより実行することが可能である。該重複排除において、スキャナ128は、脆弱性のための識別子を生成するために、脆弱性トレースノードの一部（user_contextプロパティ及び脆弱性カテゴリなど）にハッシュアルゴリズムを適用することが可能である。同一の識別子を有する２つの脆弱性は、AUT124の観点から重複するものとみなすことができる。脆弱性識別子は、複数の脆弱性のうちの１つを修正することによりそれと同一の脆弱性識別子を有する他の脆弱性もまた修正され得ることをユーザに知らせるために使用することが可能である。スキャナのユーザインタフェイスは、重複する脆弱性を１グループでユーザに提示するよう構成することが可能である。

一実施形態では、スキャナ128は、AUT124へ送信するアタックをトレース情報に基づいて最適化するよう構成される。例えば、特定のアプリケーションリクエストがファイルシステム204にアクセスしないことを所与のトレースが示す場合、スキャナは、該ファイルシステム204に関する脆弱性を対象としたアプリケーションリクエストに関連する同様のアタックを省略するよう構成することが可能である。同様に、特定のアプリケーションリクエストが所与のデータベースクエリを呼び出さないことを所与のトレースが示す場合、スキャナは、データベースの脆弱性（SQLインジェクションなど）を対象としたアプリケーションリクエストに関連する同様のアタックを省略するよう構成することが可能である。

一実施形態では、データベーストレースノードからのデータベースクエリ情報は、より持続性の高いクロスサイトスクリプティング脆弱性を識別するために使用することが可能である。例えば、データベース206をターゲットとするアプリケーションリクエストは、該アプリケーションリクエストに起因してAUT124によりアクセスされるデータベーステーブル及びカラムに関連するものとすることが可能である。スキャナ128は、この情報を使用して、該データベース206の特定の場所にデータを書き込むアプリケーションリクエストにより、該データベース206に対するデータの格納を試行するアタックを送信することが可能である。スキャナ128は、該データベース206の同じ場所から読み出しを行うアプリケーションリクエストを送信することにより該アタックの結果を判定することが可能である。
・サービスリクエスト−サーバ情報
オブザーバ126は、サーバ120に関する情報をスキャナ128に伝えるために使用されるサービス（本書では「サーバ情報サービス」と称す）を提供するよう構成することが可能である。サーバ情報を取り出すために、スキャナ128は、サーバ情報のリクエストを示すよう構成されたヘッダフィールド名（「サーバ」など）を含むサーバ情報サービスリクエストをオブザーバ126に対して発行することが可能である。該サーバ情報サービスリクエストを受信すると、オブザーバ126は、AUT124をバイパスして、リクエストされたサーバ情報をスキャナ128へ返すことが可能である。

リクエストされたサーバ情報は、オブザーバ126により生成されるサービスレスポンスのボディで返すことが可能であり、例えばJSONオブジェクトとして規定することが可能である。サービスレスポンスに含まれるサーバ情報の例として、とりわけ、ホストオペレーティングシステムの名称及びバージョン、アプリケーションサーバの名称及びバージョン、アプリケーションサーバが如何なるダウンタイムも伴うことなく実行した時間量、現在処理中のスレッドの数、及び現在使用中のメモリの量が挙げられる。スキャナ128は、該サーバ情報を使用して、AUT124をホストするサーバ120に適したアタックを生成することが可能である。例えば、スキャナ128は、AUT124をホストしているサーバ120がLinuxを実行している場合にMicrosoft（登録商標）WindowsベースのアタックをAUT124へ送信するのを回避するよう構成することが可能である。
・サービスリクエスト−アプリケーション情報
オブザーバ126は、AUT124に関する情報をスキャナ128に伝えるために使用されるサービス（本書では「アプリケーション情報サービス」と称す）を提供するよう構成することが可能である。アプリケーション情報を取り出すために、スキャナ128は、アプリケーション情報のリクエストを示すよう構成されたフィールド名（「アプリケーション」など）を含むアプリケーション情報サービスリクエストをオブザーバ126に対して発行することが可能である。該アプリケーション情報サービスリクエストを受信すると、オブザーバ126は、AUT124をバイパスして、リクエストされたアプリケーション情報をスキャナ128へ返すことが可能である。

リクエストされたアプリケーション情報は、オブザーバ126により生成されるサービスレスポンスのボディで返すことが可能であり、例えばJSONオブジェクトとして規定することが可能である。送信するために利用可能なアプリケーション情報が存在しない場合には、サービスレスポンスのボディを空にすることが可能である。サービスレスポンスにより返されるアプリケーション情報の例として、とりわけ、AUT124が対話するデータベースの全ての名称及びバージョン、AUT124により使用されるファイルライブラリ、AUT124が対話するウェブサービスサブシステム並びにその他のサブシステム及びソフトウェアフレームワークが挙げられる。スキャナ128は、該アプリケーション情報を使用して、一層効率的にアタックを生成することが可能である。例えば、AUT124により使用されているデータベースに関する情報は、スキャナ128が、識別されたデータベースに適したアタックを生成すること及び使用されていないデータベースに関するアタックの生成を回避することを可能にする。更に、スキャナ128は、Oracleデータベースのみを使用しているAUT124に対してMicrosoft（登録商標）SQL Serverをターゲットとするアタックを送信することを回避することが可能である。
・サービスリクエスト−アタックサーフェス
オブザーバ126は、単純なウェブクローラによって検出されない可能性のあるアタックサーフェスのコンポーネントを識別するために使用されるサービス（本書では「アタックサーフェスサービス」と称す）を提供するよう構成することが可能である。アタックサーフェス情報を取り出すために、スキャナ128は、アタックサーフェス情報のリクエストを示すよう構成されたヘッダフィールド名（「アタックサーフェス」など）を含むアタックサーフェスサービスリクエストを発行することが可能である。該アタックサーフェスサービスリクエストを受信すると、オブザーバ126は、AUT124をバイパスして、リクエストされたアタックサーフェス情報をスキャナ128へ返すことが可能である。該アタックサーフェス情報は、オブザーバ126により生成されるサービスレスポンスのボディで返すことが可能であり、例えばJSONオブジェクトとして規定することが可能である。送信するために利用可能なアタックサーフェス情報が存在しない場合には、サービスレスポンスのボディを空にすることが可能である。

AUT124のアタックサーフェスは、スキャナ128にアクセスすることが可能なリソース（例えばウェブページリンクなど）を含む。スキャナ128又はオブザーバ126は、AUT124を解析し又は「クロール」してかかるウェブページリンクを発見するよう構成することが可能である。スキャナ128にアクセスすることが可能なリソースの中にはウェブページリンクに関係しないものがあり、この意味で、かかるリソースは、AUT124のクロールにより発見することができない隠れたリソースである。隠れたリソースは、ファイルシステム204内のファイルとして存在する可能性があり、これは該ファイルシステム204にアクセスしたオブザーバ126により発見することが可能である。更に、リソースの中には、実行時にAUT124により動的に生成されるものがあり、換言すれば、受信したアプリケーションリクエストに応じてAUT124の実行中に生成されるものがある。動的なリソースは、リクエストされたURLを所定のルールに基づいてファイルシステム204上のリソースにマッピングするファイルであるコンフィギュレーションファイル及びマッピングファイル（Web.xmlファイルなど）に基づいて実行中に生成することが可能なものである。動的に生成されたリソースは、オブザーバ126により、マッピング及びコンフィギュレーションファイルを検査することにより及びAUT124の実行を観察して実行時に動的にバインドされたURL（Uniform Resource Locators）を識別することにより、発見することが可能である。

スキャナ128に対してアクセス可能な各リソースは、アタックサーフェスコンポーネントと称することが可能である。オブザーバ126により発見された各アタックサーフェスコンポーネントは、URLとして規定してアタックサーフェスサービスレスポンスのボディでスキャナ128にレポートすることが可能である。各アタックサーフェスコンポーネントは、該アタックサーフェスコンポーネントを静的なもの又は動的なものとして識別するようアタックサーフェスサービスレスポンスのボディ内でタグ付けすることが可能である。ファイルシステム204を探索することにより発見されたリソース（該ファイルシステム204のルートディレクトリ及びその下位に位置するファイルを含む）は、静的なものとしてタグ付けすることが可能である。マッピング及びコンフィギュレーションファイルを検査することにより発見されたリソースは、動的なものとしてタグ付けすることが可能である。アプリケーションの実行の一部としてWAR（Web application ARchive）ファイルを展開しないWebLogic等のコンテナの場合、オブザーバ126は、該WARファイルからリソースを抽出するタスクを該コンテナのコードに処理させ、次いで該抽出されたリソースのリストを使用してアタックサーフェスを規定することが可能である。
・エラー処理
場合によっては、スキャナ128は、オブザーバ126によって遂行できないサービスリクエストを発行することが可能である。例えば、スキャナ128は、オブザーバ126によって認識されないサービスリクエスト又はオブザーバ126によって認識されないヘッダフィールド値内のサービスリクエスト（未知のリクエストIDを有するトレースリクエストなど）を発行することが可能である。オブザーバ126は、遂行できないサービスリクエストに遭遇した場合に、サービスレスポンス又はアプリケーションレスポンスのヘッダでスキャナ128にエラーを返すことが可能である。例えば、オブザーバ126は、以下のように規定したサービスレスポンスを発行することが可能である。

X-WIPP-Error:<error_text_string>
ヘッダフィールド値<error_text_string>は、遭遇したエラーの概略的な記述を提供する適当なテキストストリングとすることが可能である。該エラーを記述するテキストストリングは、ユーザが見ることができるエラーログにスキャナ128によって格納することが可能である。更に、オブザーバ126がエラーログを維持することが可能であり、この場合、各エラーログエントリは、問題の一層詳細な説明を含む。オブザーバ126により維持される該エラーログは、オブザーバ126の動作中に遭遇したあらゆるエラーを記録することが可能である。

エラーは、サービスリクエスト又はオブザーバ126をターゲットとすることを意図した情報を含むアプリケーションリクエストヘッダの一部に応じて該オブザーバ126により生成される場合がある。サービスリクエストに応じてエラーが生成された場合には、そのエラーメッセージをサービスレスポンスで返すことが可能であり、該サービスレスポンスのボディを空にすることが可能である。アプリケーションリクエストに含まれる情報に応じてエラーが生成された場合には、そのエラーメッセージは、アプリケーションレスポンスで返すことが可能であり、該アプリケーションレスポンスのボディは、AUT124がそのプログラミングに従って提供する如何なるデータをも含むことが可能である。

図３は、一実施形態による、グレーボックスセキュリティ検査を実行する方法の概要を示すプロセスフローチャートである。該方法300は、図２に関して説明したAUT124及びオブザーバ126と連絡してスキャナ128により実行することが可能である。該方法300は、ブロック302で開始して、AUT124へアプリケーションリクエストを送ることが可能である。該アプリケーションリクエストは、AUT124の潜在的な脆弱性を露呈させるよう構成することが可能である。上述のように、該アプリケーションリクエストは、オブザーバ126と情報をやりとりするために使用されるカスタムヘッダを含むことが可能である。例えば、スキャナ128は、オブザーバ126に対するアプリケーションリクエストを一意に識別するリクエストID値を該アプリケーションリクエストのヘッダに追加することが可能である。

ブロック304で、スキャナ128は、AUT124のプログラミングに従って該AUT124からアプリケーションレスポンスを受信することが可能である。スキャナ128が各アプリケーションリクエストにリクエストIDを追加するよう構成されている場合には、オブザーバ126は、それと同じリクエストIDをアプリケーションレスポンスのヘッダに追加することが可能である。別の態様では、スキャナ128は、一意のリクエストIDを生成して該リクエストIDをアプリケーションレスポンスのヘッダに追加することが可能である。上述のように、オブザーバ126はまた、更なる情報（ファイル不発見ヘッダ、オブザーババージョンヘッダ、アップデートヘッダなど）をアプリケーションレスポンスのヘッダに追加することが可能である。

ブロック306で、スキャナ128はオブザーバ126へサービスリクエストを送ることが可能である。一実施形態では、該サービスリクエストは、ブロック302のアプリケーションリクエストに更なるヘッダ情報を追加することにより該アプリケーションリクエストに含ませることが可能である。一実施形態では、サービスリクエストは、別個の（換言すれば、アプリケーションリクエストと結合されていない）リクエストとすることが可能である。サービスリクエストは、オブザーバ126により処理され、AUT124には渡されない。サービスリクエストは、とりわけ、アタックサーフェス情報、サーバ又はアプリケーション情報、及びAUT124の内部プロセスに関連するトレース情報といった情報をリクエストするよう構成することが可能である。スキャナ128は、特定のアプリケーションレスポンスに対応するトレース情報を取得するために、サービスリクエストのヘッダにリクエストIDを追加することが可能である。

ブロック308で、スキャナ128は、オブザーバ126からサービスレスポンスを受信することが可能である。該サービスレスポンスは、アプリケーションリクエストに起因してAUT124により実行されたプロセスに関する情報を含むことが可能である。例えば、サービスレスポンスは、アプリケーションリクエストの結果としてAUT124により実行されたプロセスを識別するスタックトレース情報を含むことが可能である。サービスレスポンスは、オブザーバ126により検出された脆弱性に対応するコード場所を含む脆弱性トレースノードを含むことが可能である。サービスレスポンスはまた、アプリケーションリクエストの結果としてAUT124により実行されたデータベースクエリに対応する情報を含むことが可能である。一実施形態では、サービスレスポンスは、とりわけ、AUT124のプログラミング言語、AUT124の名称及びバージョン、並びに静的URL及び動的URLを含むAUT124のアタックサーフェスといったAUT124に関する情報を含むことが可能である。サービスレスポンスはまた、とりわけ、オペレーティングシステム名及びバージョン、アプリケーションサーバ名及びバージョン、スレッドの数、メモリ使用量、及びサーバ120がダウンタイムを全く伴わずに実行してきた量といったオブザーバ126に関する情報を含むことが可能である。

該方法300は、本技術の実施形態を説明するために使用した例示的なプロセスフローに過ぎないものであり、実際のプロセスフローは特定の実施形態に応じて変動し得るものである、ということが理解されよう。例えば、スキャナ128は、全てのアプリケーションリクエストについてサービスリクエストを発行しないことが可能である。更に、スキャナ128は、複数のアプリケーションリクエスト及びレスポンスを送受信した後に、該複数のアプリケーションレスポンスのうちの特定の１つに関してサービスリクエストを送ることが可能である。

ブロック310で、スキャナ128は、AUT124及びオブザーバ126から受信した情報に基づいて脆弱性レポートを生成することが可能である。該脆弱性レポートは、検出された脆弱性を、ブロック308で受信したトレースノードに含まれるコード場所情報に基づいてグループ化することが可能である。該脆弱性レポートは、スキャナ128により提供されるユーザインタフェイスを介してユーザに提示することが可能である。該脆弱性レポートはまた、記憶装置に格納し又はプリントすることが可能である。

図４は、一実施形態による、グレーボックスセキュリティ検査を実行するよう構成されたコードを格納する持続性コンピュータ読み取り可能媒体を示すブロック図である。該持続性マシン読み取り可能媒体は符号400で示されている。該持続性マシン読み取り可能媒体400は、RAM、ハードディスクドライブ、ハードディスクドライブアレイ、光学ドライブ、光学ドライブアレイ、不揮発性メモリ、USBドライブ、DVD（Digital Versatile Disk）、CD（Compact Disk）などを含み得るものである。該持続性マシン読み取り可能媒体400は、通信経路404を介してプロセッサ402によりアクセスすることが可能である。

図４に示すように、本書で説明する様々な構成要素を該持続性マシン読み取り可能媒体400に格納することが可能である。該持続性マシン読み取り可能媒体400の領域406は、AUT124へアプリケーションリクエストを送るよう構成されたアプリケーションインタフェイスを含むことが可能であり、この場合、該アプリケーションリクエストは、該AUT124の潜在的な脆弱性を露呈させるよう構成される。該アプリケーションインタフェイスはまた、AUT124からアプリケーションレスポンスを受信することが可能であり、この場合、該アプリケーションレスポンスは、AUT124のプログラミングに従って該AUT124により生成される。領域408は、オブザーバ126へサービスリクエストを送るよう構成されたオブザーバインタフェイスを含むことが可能である。該オブザーバインタフェイスはまた、サービスレスポンスを受信し、該サービスレスポンスは、例えば、アプリケーションリクエストに起因してAUT124により実行されたプロセスに対応する情報、AUT124に関する情報、又はAUT124をホストするサーバ120に関する情報を含む。領域410は、AUT124及びオブザーバ126から受信したデータを解析し及び該解析に基づいて脆弱性レポートを生成するよう構成された脆弱性レポート生成手段を含むことが可能である。

以下においては、本発明の種々の構成要件の組み合わせからなる例示的な実施態様を示す。
１．検査対象となるアプリケーション（AUT）をホストするサーバと、
該AUTにより実行された命令を監視するよう構成されたオブザーバと、
該AUT及び該オブザーバに共通の通信チャネルを介して通信可能な状態で接続されたコンピューティング装置であって、プロセッサとコンピュータ読み取り可能命令を格納するための記憶装置とを備えている、コンピューティング装置と
を備えたシステムであって、前記コンピュータ読み取り可能命令が、
前記AUTの潜在的な脆弱性を露呈させるよう構成されたアプリケーションリクエストを該AUTへ送信し、
該AUTのプログラミングに従って該AUTからアプリケーションレスポンスを受信し、
前記オブザーバへサービスリクエストを送信し、
前記アプリケーションリクエストに起因して前記AUTにより実行された命令に対応する情報、該AUTに関する情報、又は該AUTをホストするサーバに関する情報を含むサービスレスポンスを前記オブザーバから受信する、
という各ステップを前記プロセッサに実行させるよう構成されている、システム。
２．前記オブザーバが、前記アプリケーションリクエストの結果として前記AUTにより実行された命令を識別するトレースを生成し、該トレースを前記サービスレスポンスのボディで前記コンピューティング装置へ送信するよう構成されている、前項１に記載のシステム。
３．前記オブザーバが、前記アプリケーションレスポンスにカスタムヘッダを追加することにより少なくとも部分的に前記コンピューティング装置と通信するよう構成されている、前項１に記載のシステム。
４．前記記憶装置が、前記オブザーバからトレース情報を受信するよう前記プロセッサに指示するよう構成されたコンピュータ読み取り可能命令を含み、該トレース情報が、複数の脆弱性トレースノードを含み、その各脆弱性トレースノードが、前記オブザーバにより検出された脆弱性に対応するコード場所を含む、前項１に記載のシステム。
５．前記記憶装置が、同一のコード場所を含む脆弱性トレースノードに基づく複数の脆弱性トレースノードのグループ化の実行を前記プロセッサに指示するよう構成されたコンピュータ読み取り可能命令を含む、前項４に記載のシステム。
６．前記オブザーバが、AUTを監視して該AUTの実行時に動的に生成される新しいURL(Uniform Resource Locator)を識別し及びアプリケーションレスポンスのヘッダでアップデートフィールドを返すよう構成されており、該アップデートフィールドが、該AUTのアタックサーフェスが変化したことを前記コンピューティング装置に通知するよう構成されている、前項１に記載のシステム。
７．前記オブザーバが、
前記コンピューティング装置からリクエストを受信して該リクエストのヘッダを解析し、
該ヘッダの解析に基づいて該リクエストをアプリケーションリクエスト又はサービスリクエストとして識別し、
該アプリケーションリクエストを前記AUTへ渡し、
該サービスリクエストを該AUTへ渡すことなく該サービスリクエストを処理する、
という各ステップを実行するよう構成されている、前項１に記載のシステム。
８．検査対象となるアプリケーション（AUT）の潜在的な脆弱性を露呈させるよう構成されたアプリケーションリクエストを該AUTへ送信し、
該AUTのプログラミングに従って該AUTからアプリケーションレスポンスを受信し、
該AUTにより実行される命令を監視するオブザーバへサービスリクエストを送信し、
前記アプリケーションリクエストに起因して該AUTにより実行された命令に対応する情報、該AUTに関する情報、又は該AUTをホストするサーバに関する情報を含むサービスレスポンスを前記オブザーバから受信する、
という各ステップからなり、前記アプリケーションリクエスト、前記アプリケーションレスポンス、前記サービスリクエスト、及び前記サービスレスポンスが、同一のネットワークチャネルを介して通信される、方法。
９．前記AUTにより生成されたファイル不発見エラーを示すために前記オブザーバにより前記アプリケーションレスポンスに追加されたファイル不発見ヘッダを該アプリケーションレスポンスで受信するステップを含む、前項８に記載の方法。
１０．前記サービスリクエストがトレースサービスリクエストであり、前記オブザーバから受信したサービスレスポンスのボディでスタックトレースを受信するステップを含む、前項８に記載の方法。
１１．前記オブザーバにより検出された脆弱性を識別する脆弱性トレースノードを前記サービスレスポンスのボディで受信するステップを含む、前項８に記載の方法。
１２．前記サービスリクエストがアタックサーフェスサービスリクエストであり、前記AUTのアタックサーフェスに関する情報を前記サービスレスポンスのボディで受信し、該アタックサーフェスが、該AUTにより実行時に生成される静的URL及び動的URLからなる、前項８に記載の方法。
１３．検査対象となるアプリケーション（AUT）の潜在的な脆弱性を露呈させるよう構成されたアプリケーションリクエストを該AUTへ送信し、
該AUTのプログラミングに従って該AUTからアプリケーションレスポンスを受信し、
該AUTにより実行される命令を監視するオブザーバへサービスリクエストを送信し、
前記アプリケーションリクエストに起因して該AUTにより実行された命令に対応する情報、該AUTに関する情報、又は該AUTをホストするサーバに関する情報を含むサービスレスポンスを前記オブザーバから受信する、
という各ステップの実行をプロセッサに指示するよう構成されたコードを含む、持続性コンピュータ読み取り可能媒体であって、
前記アプリケーションリクエスト、前記アプリケーションレスポンス、前記サービスリクエスト、及び前記サービスレスポンスが同一のネットワークチャネルを介して通信される、持続性コンピュータ読み取り可能媒体。
１４．前記アプリケーションリクエストを一意に識別するリクエストIDを該アプリケーションリクエストのヘッダに追加するステップの実行を前記プロセッサに指示するよう構成されたコードを含み、前記オブザーバから受信した前記サービスレスポンスが該リクエストIDを含む、前項１３に記載の持続性コンピュータ読み取り可能媒体。
１５．前記サービスレスポンスが、前記アプリケーションリクエストの結果として前記AUTにより実行されたデータベースクエリに対応する情報を含むデータベーストレースノードを含む、前項１３に記載の持続性コンピュータ読み取り可能媒体。

Claims (15)

1. 検査対象となるアプリケーション（AUT）をホストするサーバと、
   該AUTにより実行された命令を監視するよう構成されたオブザーバと、
   該AUT及び該オブザーバに共通の通信チャネルを介して通信可能な状態で接続されたコンピューティング装置であって、プロセッサとコンピュータ読み取り可能命令を格納するための記憶装置とを備えている、コンピューティング装置と
   を備えたシステムであって、
   前記コンピュータ読み取り可能命令が、
   前記AUTの潜在的な脆弱性を露呈させるよう構成されたアプリケーションリクエストを該AUTへ送信し、
   該AUTのプログラミングに従って該AUTからアプリケーションレスポンスを受信し、
   前記オブザーバへサービスリクエストを送信し、
   前記アプリケーションリクエストに起因して前記AUTにより実行された命令に対応する情報、該AUTに関する情報、又は該AUTをホストするサーバに関する情報を含むサービスレスポンスを前記オブザーバから受信する、
   という各ステップを前記プロセッサに実行させるよう構成されており、
   前記オブザーバが、
   前記コンピューティング装置からリクエストを受信して該リクエストのヘッダを解析し、
   該ヘッダの解析に基づいて該リクエストをアプリケーションリクエスト又はサービスリクエストとして識別し、
   該アプリケーションリクエストを前記AUTへ渡し、
   該サービスリクエストを該AUTへ渡すことなく該サービスリクエストを処理する、
   という各ステップを実行するよう構成されている、システム。
2. 前記オブザーバが、前記アプリケーションリクエストの結果として前記AUTにより実行された命令を識別するトレースを生成し、該トレースを前記サービスレスポンスのボディで前記コンピューティング装置へ送信するよう構成されている、請求項１に記載のシステム。
3. 前記オブザーバが、前記アプリケーションレスポンスにカスタムヘッダを追加することにより少なくとも部分的に前記コンピューティング装置と通信するよう構成されている、請求項１又は請求項２に記載のシステム。
4. 前記記憶装置が、前記オブザーバからトレース情報を受信するよう前記プロセッサに指示するよう構成されたコンピュータ読み取り可能命令を含み、該トレース情報が、複数のスタックトレースを含み、その各スタックトレースが、前記オブザーバにより検出された脆弱性に対応するコード場所を含む、請求項１ないし請求項３の何れか一項に記載のシステム。
5. 前記記憶装置が、同一のコード場所を含むスタックトレースに基づく複数のスタックトレースのグループ化の実行を前記プロセッサに指示するよう構成されたコンピュータ読み取り可能命令を含む、請求項４に記載のシステム。
6. 前記オブザーバが、AUTを監視して該AUTの実行時に動的に生成される新しいURL(Uniform Resource Locator)を識別し及びアプリケーションレスポンスのヘッダでアップデートフィールドを返すよう構成されており、該アップデートフィールドが、該AUTのアタックサーフェスが変化したことを前記コンピューティング装置に通知するよう構成されている、請求項１ないし請求項５の何れか一項に記載のシステム。
7. コンピューティング装置により、検査対象となるアプリケーション（AUT）の潜在的な脆弱性を露呈させるよう構成されたアプリケーションリクエストを該AUTへ送信し、
   該コンピューティング装置により、該AUTのプログラミングに従って該AUTからアプリケーションレスポンスを受信し、
   該コンピューティング装置により、該AUTにより実行される命令を監視するオブザーバへサービスリクエストを送信し、
   該コンピューティング装置により、前記アプリケーションリクエストに起因して該AUTにより実行された命令に対応する情報、該AUTに関する情報、又は該AUTをホストするサーバに関する情報を含むサービスレスポンスを前記オブザーバから受信する、
   という各ステップからなり、
   前記アプリケーションリクエスト、前記アプリケーションレスポンス、前記サービスリクエスト、及び前記サービスレスポンスが、同一のネットワークチャネルを介して通信され、
   前記オブザーバが、
   前記コンピューティング装置からリクエストを受信して該リクエストのヘッダを解析し、
   該ヘッダの解析に基づいて該リクエストをアプリケーションリクエスト又はサービスリクエストとして識別し、
   該アプリケーションリクエストを前記AUTへ渡し、
   該サービスリクエストを該AUTへ渡すことなく該サービスリクエストを処理する、
   という各ステップを実行するよう構成されている、方法。
8. 前記AUTにより生成されたファイル不発見エラーを示すために前記オブザーバにより前記アプリケーションレスポンスに追加されたファイル不発見ヘッダを該アプリケーションレスポンスで受信するステップを含む、請求項７に記載の方法。
9. 前記サービスリクエストがトレースサービスリクエストであり、前記オブザーバから受信したサービスレスポンスのボディでスタックトレースを受信するステップを含む、請求項７又は請求項８に記載の方法。
10. 前記オブザーバにより検出された脆弱性を識別するスタックトレースを前記サービスレスポンスのボディで受信するステップを含む、請求項７又は請求項８に記載の方法。
11. 前記サービスリクエストがアタックサーフェスサービスリクエストであり、前記AUTのアタックサーフェスに関する情報を前記サービスレスポンスのボディで受信し、該アタックサーフェスが、該AUTにより実行時に生成される静的URL及び動的URLからなる、請求項７又は請求項８に記載の方法。
12. 検査対象となるアプリケーション（AUT）の潜在的な脆弱性を露呈させるよう構成されたアプリケーションリクエストを該AUTへ送信し、
    該AUTのプログラミングに従って該AUTからアプリケーションレスポンスを受信し、
    該AUTにより実行される命令を監視するオブザーバへサービスリクエストを送信し、
    前記アプリケーションリクエストに起因して該AUTにより実行された命令に対応する情報、該AUTに関する情報、又は該AUTをホストするサーバに関する情報を含むサービスレスポンスを前記オブザーバから受信する、
    という各ステップの実行をコンピューティング装置のプロセッサに指示するよう構成されたコードを含む、持続性コンピュータ読み取り可能媒体であって、
    前記アプリケーションリクエスト、前記アプリケーションレスポンス、前記サービスリクエスト、及び前記サービスレスポンスが同一のネットワークチャネルを介して通信され、
    前記オブザーバが、
    前記コンピューティング装置からリクエストを受信して該リクエストのヘッダを解析し、
    該ヘッダの解析に基づいて該リクエストをアプリケーションリクエスト又はサービスリクエストとして識別し、
    該アプリケーションリクエストを前記AUTへ渡し、
    該サービスリクエストを該AUTへ渡すことなく該サービスリクエストを処理する、
    という各ステップを実行するよう構成されている、持続性コンピュータ読み取り可能媒体。
13. 前記アプリケーションリクエストを一意に識別するリクエストIDを該アプリケーションリクエストのヘッダに追加するステップの実行を前記プロセッサに指示するよう構成されたコードを含み、前記オブザーバから受信した前記サービスレスポンスが該リクエストIDを含む、請求項１２に記載の持続性コンピュータ読み取り可能媒体。
14. 前記サービスレスポンスが、前記アプリケーションリクエストの結果として前記AUTにより実行されたデータベースクエリに対応する情報を含む、請求項１２又は請求項１３に記載の持続性コンピュータ読み取り可能媒体。
15. 前記サービスリクエストがアタックサーフェスサービスリクエストであり、前記AUTのアタックサーフェスに関する情報が前記サービスレスポンスのボディに含まれ、該アタックサーフェスが、該AUTにより実行時に生成される静的URL及び動的URLからなる、請求項１２ないし請求項１４の何れか一項に記載の持続性コンピュータ読み取り可能媒体。

Images