Ｗｅｂサービス提供システム検査装置及びＷｅｂサービス提供システム検査プログラム
【課題】 脆弱性検出の確実性向上に寄与することができるＷｅｂサービス提供システム検査装置を提供する。
【解決手段】 パラメータ変形部１１は、ポジティブリクエスト生成部１３とネガティブリクエスト生成部１４に、正当なリクエスト中のパラメータを変形したポジティブリクエストとネガティブリクエストを生成させる。ステータス抽出部２２〜特殊文字列抽出部２５は、リクエスト送信部１５がＷｅｂサービス提供システム６０に送信し、レスポンス受信部２１が受信したポジティブリクエストとネガティブリクエストに対する各々のレスポンス中の特徴的な情報のパターンを抽出する。レスポンス情報比較部２７は、ネガティブレスポンスに対する全てのレスポンスのパターンが、ポジティブレスポンスに対するどのレスポンスのパターンにも一致しない場合には脆弱性ありと判定する。
【解決手段】 パラメータ変形部１１は、ポジティブリクエスト生成部１３とネガティブリクエスト生成部１４に、正当なリクエスト中のパラメータを変形したポジティブリクエストとネガティブリクエストを生成させる。ステータス抽出部２２〜特殊文字列抽出部２５は、リクエスト送信部１５がＷｅｂサービス提供システム６０に送信し、レスポンス受信部２１が受信したポジティブリクエストとネガティブリクエストに対する各々のレスポンス中の特徴的な情報のパターンを抽出する。レスポンス情報比較部２７は、ネガティブレスポンスに対する全てのレスポンスのパターンが、ポジティブレスポンスに対するどのレスポンスのパターンにも一致しない場合には脆弱性ありと判定する。
【発明の詳細な説明】
【技術分野】
【０００１】
この発明は、Ｗｅｂアプリケーションの脆弱性を検出するＷｅｂサービス提供システム検査装置に関する。
【背景技術】
【０００２】
Ｗｅｂサーバをフロントエンドとして用い、ＤＢサーバが提供するＤＢサービス等を用いたアプリケーションサービスを提供する、いわゆるＷｅｂアプリケーションが知られている。例えば会員向けの情報提供サービスを行うＷｅｂアプリケーションは、例えば図３３に示すように、ログイン処理部とセッション管理部等を有する構成となっている。このようなＷｅｂアプリケーションには、例えばＳＱＬ発行部６２ａ等にバックエンドのＤＢサーバ６３で不正なＳＱＬ文が実行されるＳＱＬインジェクション脆弱性等を有する場合がある。この図３３に示すＷｅｂアプリケーションでは、ログイン画面６２１ａに対してユーザが入力したログイン情報（ユーザ名とパスワード）が供給されると、ＳＱＬ発行部６２ａは、ＤＢサーバ６３を介してＤＢ６４に問い合わせを行う。情報画面構成部６２３は、この問い合わせ結果に基づいた応答を生成してユーザ側の装置に供給する。
【０００３】
ＳＱＬ発行部６２ａがＤＢ６４に問い合わせを行う際には、ユーザがログイン画面６２１ａで入力したログイン情報に基づいてＳＱＬ文を生成し、生成したＳＱＬ文をＤＢサーバ６３に供給することによって行う。このＳＱＬ文の生成において、ユーザが入力したログイン情報に、ＳＱＬ文を生成するために使用される特殊記号が含まれていると、開発者が意図したＳＱＬ文とは異なるＳＱＬが生成されてしまうことがある。このため、Ｗｅｂアプリケーションでは、ユーザからのログイン情報等の入力値にＳＱＬ文の生成に使用する特殊記号が含まれないようにする必要がある。このように、ＷｅｂアプリケーションのＳＱＬ発行部６２ａ（例えば同図中の斜線部の「パラメータチェック及びＳＱＬコマンド生成」処理等）等における入力値チェックの不備等により、本来意図していないＳＱＬ文が生成され、ＤＢ６４内の情報が漏洩したり改ざんされたりするのがＳＱＬインジェクション脆弱性である。
【０００４】
例えばＷｅｂアプリケーションが通常は使用しない文字種が含まれている入力値を適切に処理しなかった場合、アプリケーションの利用者からの入力値によっては想定外の処理が実行されてしまう可能性がある。このことを利用すると、入力値を巧みに操作することによりＤＢに格納されている情報が漏洩したり、改ざんされたりする可能性がある。このような脆弱性にはバックエンドで処理を行うサーバの違いによりＳＱＬインジェクション脆弱性やＬＤＡＰインジェクション脆弱性やＸＰａｔｈインジェクション脆弱性などがあり、これらをインジェクション系脆弱性と呼ぶ。
【０００５】
このような脆弱性を検出するための手法として、脆弱性によるエラーが生じた際に表示される文字列を予めＤＢに格納しておき、Ｗｅｂサーバからの応答中の文字列とＤＢに格納しておいた文字列を照合する方法が知られている（例えば特許文献１）。この方法では、例えば図５３に示すように、まず、脆弱性に起因するエラーが生じると思われる検査文字列をＷｅｂサーバに送信し、これに対するＷｅｂサーバからの応答（レスポンス）中の文字列を、ＤＢに格納されている脆弱性情報（文字列）と照合し、一致する文字列があれば該当する脆弱性が存在すると判断する。
【特許文献１】米国特許６５８４５６９号公報（図１、図３）
【発明の開示】
【発明が解決しようとする課題】
【０００６】
しかしながら、フロントエンドのＷｅｂサーバの構成やアプリケーションの作りこみによっては、単純にＷｅｂサーバからの応答中の文字列とＤＢに格納されている文字列を照合するだけでは脆弱性を検出できない場合もある。例えば図５４は、アプリケーションが入力値を適切に処理していない脆弱性に起因するＳＱＬエラー表示の例であるが、アプリケーションの作りこみ次第で図５５に示すようなエラー表示となる場合も考えられる。
【０００７】
従って、上述のように、予め脆弱性によるエラーが生じた際に表示される文字列をＤＢに格納しておき、Ｗｅｂアプリケーションの応答中の文字列とＤＢに格納しておいた文字列を照合する方法では、Ｗｅｂサーバの構成やアプリケーションの作り込みによっては脆弱性を検出できない場合がある。
【０００８】
本発明は、上述のような課題に鑑みてなされたものであり、Ｗｅｂアプリケーションのインジェクション系脆弱性検出の確実性向上に寄与することができるＷｅｂサービス提供システム検査装置及びＷｅｂサービス提供システム検査プログラムを提供することを目的とする。
【課題を解決するための手段】
【０００９】
この課題を解決するために、本発明に係るＷｅｂサービス提供システム検査装置は、Ｗｅｂサーバを介してアプリケーションサービスを提供するＷｅｂサービス提供システムの検査を行うＷｅｂサービス提供システム検査装置であって、正当なリクエスト中のパラメータを予め設定されたポジティブリクエスト文字列に基づいて変形して複数のポジティブリクエストを生成するポジティブリクエスト生成手段と、正当なリクエスト中のパラメータを予め設定されたネガティブリクエスト文字列に基づいて変形して複数のネガティブリクエストを生成するネガティブリクエスト生成手段と、各ポジティブリクエストと各ネガティブリクエストをＷｅｂサービス提供システムに供給する供給手段と、各ポジティブリクエストと各ネガティブリクエストに対するＷｅｂサービス提供システムの応答を取得する取得手段と、取得した各ポジティブリクエストと各ネガティブリクエストに対するＷｅｂサービス提供システムの応答中の特徴的な情報（応答パターン）を抽出する特徴抽出手段と、ネガティブリクエストに対する応答パターンのいずれかが、ポジティブリクエストに対するどの応答パターンとも一致しないときに脆弱性が存在すると判定する判定手段とを備えることを特徴とする。
【００１０】
ポジティブリクエスト文字列及びネガティブリクエスト文字列は、例えばアプリケーションサービスに対する正当なリクエスト中のパラメータに対して、変更する文字列として予め設定されている。ポジティブリクエスト文字列は、正当なリクエスト中では用いられない文字種を含む文字列であってＷｅｂサービス提供システム脆弱性に起因する問題が生じる可能性のない文字種から選択されている。また、ネガティブリクエスト文字列は、正当なリクエスト中では用いられない文字種を含む文字列であってＷｅｂサービス提供システム脆弱性に起因する問題が生じる可能性のある文字種から選択されている。
【発明の効果】
【００１１】
本発明では、正当なリクエスト中のパラメータを予め設定されたポジティブリクエスト文字列に基づいて変形して複数のポジティブリクエストを生成し、正当なリクエスト中のパラメータを予め設定されたネガティブリクエスト文字列に基づいて変形して複数のネガティブリクエストを生成し、これらをＷｅｂサービス提供システムに供給し、各ポジティブリクエストと各ネガティブリクエストに対するＷｅｂサービス提供システムの応答を取得し、取得した各ポジティブリクエストと各ネガティブリクエストに対するＷｅｂサービス提供システムの複数の応答中の特徴的な情報（応答パターン）を抽出し、ネガティブリクエストに対する応答パターンのいずれかが、ポジティブリクエストに対するどの応答パターンとも一致しないときに脆弱性が存在すると判定することにより、脆弱性検出の確実性向上に寄与することができる。
【発明を実施するための最良の形態】
【００１２】
本発明は、例えばＷｅｂサーバを介してアプリケーションサービスを提供するＷｅｂサービス提供システムにおける脆弱性の検査を行う検査装置等に適用することができる。
【実施例１】
【００１３】
（全体構成）
図１は、本発明を適用した一実施形態に係る検査装置の構成を概念的に示すブロック図である。この検査装置は、例えばネットワーク経由でＷｅｂサーバをフロントエンドとしたアプリケーションサービスを提供するＷｅｂサービス提供システム６０の脆弱性の検査を行うもので、Ｗｅｂサービス提供システム６０に対するリクエストを生成するリクエスト生成部１０と、Ｗｅｂサービス提供システム６０の応答を解析するレスポンス解析部２０と、検査者からの指示を入力する装置操作部３０と、リクエスト生成部１０，レスポンス解析部２０等の制御を行う検査制御部４０と、脆弱性の判定結果を出力する表示部等の判定結果出力部５０とを備えている。なお、リクエスト生成部１０，レスポンス解析部２０等はプログラムで構成されている。
【００１４】
リクエスト生成部１０は、Ｗｅｂアプリケーションにおいて情報を入力する入力ページ中のパラメータ入力値を変形するパラメータ変形部１１と、予め設定されている挿入文字列データ１２に基づいてＷｅｂアプリケーションにおいて脆弱性に起因するエラーを引き起こす可能性がないポジティブリクエストを生成するポジティブリクエスト生成部１３と、Ｗｅｂアプリケーションにおいて脆弱性に起因するエラーを引き起こす可能性があるネガティブリクエストを生成するネガティブリクエスト生成部１４と、ポジティブリクエスト生成部１３及びネガティブリクエスト生成部１４が生成したＨＴＴＰリクエスト（ポジティブリクエスト，ネガティブリクエスト）をＷｅｂサービス提供システム６０に送信するリクエスト送信部１５を備えている。
【００１５】
また、レスポンス解析部２０は、Ｗｅｂサービス提供システム６０からの応答（ＨＴＴＰレスポンス）を受信するレスポンス受信部２１と、ＨＴＴＰレスポンス中のステータス情報を抽出するステータス抽出部２２と、ＨＴＴＰレスポンス中のボディ部分のバイト長を抽出するレスポンス長抽出部２３と、ＨＴＴＰレスポンス中のヘッダ情報を抽出するヘッダ情報抽出部２４と、ＨＴＴＰレスポンス中の特殊文字列を抽出する特殊文字列抽出部２５と、ステータス抽出部２２〜特殊文字列抽出部２５が抽出したポジティブリクエストに対する各情報とネガティブリクエストに対する各情報を保持するレスポンス情報保存部２６と、レスポンス情報保存部２６に保持されているポジティブリクエストに対する各情報とネガティブリクエストに対する各情報とを比較するレスポンス情報比較部２７を備えている。
【００１６】
この検査装置の検査対象となるＷｅｂサービス提供システム６０は、例えば図２に示すように、ネットワーク８０経由で接続されるクライアント７０に対してアプリケーションサービスを提供するもので、Ｗｅｂアプリケーション６２が提供するアプリケーションサービスのフロントエンドとなるＷｅｂサーバ６１と、Ｗｅｂアプリケーション６２のバックエンドで動作するＤＢサーバ６３（データ保存部としてＤＢ６４を持つ），ＬＤＡＰサーバ６５等のサービス提供部を備えている。Ｗｅｂアプリケーション６２は、例えばＰＨＰ言語，Ｐｅｒｌ言語等のスクリプト言語の処理系（プログラム言語処理系）６６で実行されるプログラムから構成することができる。
【００１７】
このＷｅｂアプリケーション６２には、Ｗｅｂサービス提供システム６０が提供するサービスの種類に応じた処理を行う機能が実装されており、この機能に応じて、例えばＤＢサーバ６３に対するＳＱＬ文を発行するＳＱＬ発行部６２ａ、ＬＤＡＰサーバ６５に対するＬＤＡＰ問い合わせを発行するＬＤＡＰ発行部６２ｂ、当該Ｗｅｂアプリケーション６２が実行されているＷｅｂサービス提供システム６０のＯＳに対するコマンドを発行するコマンド発行部６２ｃ等の外部のプログラム等に対するアクセス等を行う処理部を備えている。また、プログラム言語処理系６６は、ＤＢサーバ６３に対する接続を行うライブラリ（ＤＢサーバ接続ＡＰＩ）６６ａと、ＬＤＡＰサーバ６５に対する接続を行うライブラリ（ＬＤＡＰサーバ接続ＡＰＩ）６６ｂと、サービス提供システム６０のＯＳに対するコマンドの発行等を行うライブラリ（ＯＳコマンド接続ＡＰＩ）６６ｃ等を備えている。
【００１８】
Ｗｅｂアプリケーション６２は、ユーザからのリクエストがある毎にプログラム言語処理系６６で実行される。ユーザからのリクエストがパラメータ入力値を持つ場合、入力に応じた処理が実行される。例えばバックエンドのＤＢサーバ６３と接続を行うアプリケーションでは、ユーザからの入力に応じて、ＳＱＬ発行部６２ａがＳＱＬ文を生成し、ＤＢサーバ接続ＡＰＩ６６ａを介してＤＢサーバ６３に供給される。ＤＢサーバ６３は、供給されたＳＱＬ文に応じた処理を実行し、実行結果をＤＢサーバ接続ＡＰＩ６６ａを介してＳＱＬ発行部６２ａに返す。
【００１９】
ところで、Ｗｅｂアプリケーション６２のＳＱＬ発行部６２ａが、ユーザからの入力に応じたＳＱＬ文を生成する際に、ユーザからのリクエスト中のパラメータ入力値にＳＱＬ文の特殊文字が含まれていると、本来意図したＳＱＬ文とは異なるＳＱＬ文が生成される可能性がある。このため、Ｗｅｂアプリケーション６２では、パラメータ入力値に含まれるＳＱＬ文の特殊文字を適切に処理する必要があるが、このような処理が適切に行われていないＷｅｂアプリケーションにはＳＱＬインジェクション脆弱性があることになる。
【００２０】
クライアント７０は、例えばＷｅｂサーバ６１を介してアプリケーションサービスを利用するＷｅｂブラウザ７１と、Ｗｅｂブラウザ７１の制御に応じて表示部７３に表示する表示画像（画面）を生成する表示制御部７２と、ユーザの指示を入力する入力部７４等を備えた、パーソナルコンピュータ・ＰＤＡあるいは携帯電話端末装置等の情報処理装置から構成されている。
【００２１】
図３は、このように構成されたＷｅｂサービス提供システム６０が提供するアプリケーションサービスにおいて、ユーザ名とパスワードを入力してログインを行うページの例である。このページには、例えばユーザ名を入力する入力欄と、パスワードを入力する入力欄と、ログインを指示するボタンが定義されている。図４は、このようなページを表示するためのＨＴＭＬの例である。
【００２２】
通常のＷｅｂアプリケーションとしての動作では、例えば図５に示すように、クライアント７０のユーザは、上述のような画面に対してユーザ名とパスワードを入力してログインボタンを押下する（Ｓ１０１）。これに応じて、Ｗｅｂブラウザ７１は、例えば図６に示すように、入力されたユーザ名とパスワードをパラメータとしてＨＴＴＰリクエストをＷｅｂサーバ６１に送信する（Ｓ１０２）。このようなＨＴＴＰリクエストを受信すると、Ｗｅｂサーバ６１は当該リクエストをＷｅｂアプリケーション６２に供給する（Ｓ１０３，Ｓ１０４）。Ｗｅｂアプリケーション６２は、供給されたＨＴＴＰリクエスト中のパラメータ（ユーザ名，パスワード）を用いてＤＢサーバ６３にＳＱＬ問い合わせを行う（Ｓ１０５，Ｓ１０６）。ＤＢ６４には、例えば図７に示すように、ユーザ毎にユーザ名（ｕｓｅｒｎａｍｅ）とパスワード（ｐａｓｓｗｏｒｄ）が対応付けられてＤＢ内に格納されている。Ｗｅｂアプリケーション６２からＳＱＬ問い合わせがあると、ＤＢサーバ６３は、これに応じて、ＤＢを照会し（Ｓ１０７）、問い合わせ結果をＷｅｂアプリケーション６２に供給する（Ｓ１０８）。なお、ユーザ名（ｕｓｅｒｎａｍｅ）とパスワード（ｐａｓｓｗｏｒｄ）に用いることができる文字の種類は、例えば英数字と特定の記号のみ等といったように予め決められている。
【００２３】
Ｗｅｂアプリケーション６２は、問い合わせ結果に応じたＨＴＭＬを生成し（Ｓ１０９）、Ｗｅｂサーバ６１に供給する（Ｓ１１０）。Ｗｅｂサーバ６１は、供給されたＨＴＭＬをＨＴＴＰレスポンスとしてＷｅｂブラウザ７１に送信する（Ｓ１１１，Ｓ１１２）。このようなＨＴＴＰレスポンスを受信すると、Ｗｅｂブラウザ７１は当該ＨＴＭＬに応じて、例えば図８あるいは図９に示すような応答画面を表示させる。なお、図８は、正しいユーザ名とパスワードの組み合わせを入力し、ログインが成功した場合の応答画面を示しており、図９は、ユーザ名とパスワードの組み合わせが正しくない場合の応答画面を示している。
【００２４】
（動作概要）
ところで、Ｗｅｂアプリケーション６２には、パラメータ入力値に特定の文字列が含まれていると、想定外の処理が実行されるインジェクション系脆弱性が存在する場合があるが、フロントエンドのＷｅｂサーバ６１の構成やＷｅｂアプリケーション６２の構成等によっては、単純にＷｅｂサーバ６１からの応答（ＨＴＴＰレスポンス）中の文字列とエラーが生じた場合の文字列のパターンを比較するだけでは脆弱性を検出できない場合もある。
【００２５】
Ｗｅｂサービス提供システム検査装置はクライアント７０と同様の環境に配置される。この検査装置では、脆弱性毎にパラメータの入力値を変形し、Ｗｅｂアプリケーションにおいて脆弱性に起因するエラーを引き起こす可能性がないポジティブリクエストとＷｅｂアプリケーションにおいて脆弱性に起因するエラーを引き起こす可能性があるネガティブリクエストを生成し、各々のリクエストに対する応答を比較して脆弱性の有無を判定するようにしている。
【００２６】
具体的には、例えば図１０に示すように、検査者が装置操作部３０を操作して入力したＷｅｂアプリケーション６２に対する正当なリクエストのデータ，対象となる脆弱性等を検査制御部４０が取得し（Ｓ１）、パラメータ変形部１１が、各々の脆弱性毎に、パラメータ入力値を変形してリクエストを生成する（Ｓ２〜Ｓ３）。このパラメータの変形では、ポジティブリクエスト生成部１３とネガティブリクエスト生成部１４によってリクエスト（ポジティブリクエストとネガティブリクエスト）を生成する。リクエストが生成されると、リクエスト送信部１５は、これをＷｅｂサービス提供システム６０に送信する（Ｓ４）。
【００２７】
このようなリクエストに応じたＷｅｂサービス提供システム６０の応答を取得すると（Ｓ５）、レスポンス解析部２０は、脆弱性の種類毎に、ポジティブリクエストに対する応答（ＨＴＴＰレスポンス）とネガティブリクエストに対する応答（ＨＴＴＰレスポンス）の特徴的な情報（後述のレスポンス長，ヘッダ情報，ステータス，特徴的な文字列等）を抽出する（Ｓ６）。さらに、レスポンス情報比較部２７はポジティブリクエストに対する応答の特徴的な情報とネガティブリクエストに対する応答の特徴的な情報のいずれか若しくはすべてを利用して比較し、この比較結果に応じて検査制御部４０が脆弱性の有無の判定を行う（Ｓ７）。
【００２８】
上述の図１０中のＳ１において、検査者は、まず、脆弱性検査を実施するＷｅｂアプリケーション６２に対する正当なリクエストのデータと正当なリクエストの送信先のＵＲＬ一覧と正当なリクエストに関連付けられたパラメータ一覧を、検査対象となる脆弱性毎に入力する。検査制御部４０は検査者が入力した各々の正当なリクエストのデータと各々の正当なリクエストの送信先のＵＲＬ一覧と各リクエストに関連付けられたパラメータ一覧を保持する。図１１に示すように、ＵＲＬ一覧は、例えば入力された正当なリクエストのパラメータに応じて、ＨＴＴＰリクエストを送信する先のＵＲＬ（ｕｒｌ １，ｕｒｌ ２）の一覧であり、例えば同図中に示す例ではｕｒｌ １に対するパラメータ一覧としてはパラメータ１−１，１−２が対応付けられており、ｕｒｌ ２に対するパラメータ一覧としてはパラメータ２−１，２−２が対応付けられている。
【００２９】
また、挿入文字列データ１２には、脆弱性の種類毎に、パラメータ入力値の変形文字列（ポジティブリクエストとネガティブリクエストに用いる文字列）が格納されており、これらの文字列を用いて、図１１中のパラメータ１−１に対して示すように、脆弱性の種類毎に脆弱性の検査を行う。
【００３０】
（動作詳細：ＳＱＬインジェクション脆弱性）
以下、ＳＱＬインジェクション脆弱性の場合を例に検査の詳細を説明する。
ＳＱＬインジェクション脆弱性を検査する場合には、例えば図１２に処理の概要を示すように、
（１）検査対象となるＵＲＬ（例えば“ｕｒｌ １”）に対してパラメータ入力値（例えば“パラメータ１−１”，“パラメータ１−２”）を変形したリクエスト（ポジティブリクエストとネガティブリクエスト）を複数生成し、
（２）各々のリクエストをサービス提供システム６０側に送信し、
（３）各々のリクエストに対するＷｅｂサービス提供システム６０のＨＴＴＰレスポンスを取得し、
（４）ポジティブリクエストに対するＨＴＴＰレスポンスとネガティブリクエストに対するＨＴＴＰレスポンスを比較し、ネガティブレスポンスだけから得られたＨＴＴＰレスポンスの有無を確認することによって行う。このＨＴＴＰレスポンスの比較は、各々のＨＴＴＰレスポンスから抽出した特徴的な情報のパターンを比較することによって行う。
【００３１】
図１２に示す手順をさらに具体的に示したのが図１３に示すフローチャートである。まず、検査制御部４０が、検査対象のリクエストを選択し（Ｓ１１）、検査対象の脆弱性（この場合ではＳＱＬインジェクション脆弱性）を選択すると（Ｓ１２）、リクエスト生成部１０は指定されたリクエストのパラメータを変形したリクエストを生成して指定されたＵＲＬ宛に送信する（Ｓ１３）。
【００３２】
このようなリクエストに対して、Ｗｅｂサービス提供システム６０からの応答（ＨＴＴＰレスポンス）を受信すると、レスポンス解析部２０は、このＨＴＴＰレスポンス中の特徴的な情報を抽出し、ポジティブリクエストに対するＨＴＴＰレスポンス（ポジティブレスポンス）のパターンのグループとネガティブリクエストに対するＨＴＴＰレスポンス（ネガティブレスポンス）のパターンのグループを作成する（Ｓ１４）。この後、レスポンス解析部２０は、各々のパターンのグループを比較し（Ｓ１５）、ネガティブレスポンスグループ内に、ポジティブレスポンスグループ中のパターンのいずれにも一致しないパターンがあれば脆弱性ありと判定し（Ｓ１６）、すべてのネガティブレスポンスグループのパターンがポジティブレスポンスグループ中のいずれかのパターンに一致すれば脆弱性なしと判定する（Ｓ１７）。
【００３３】
Ｓ１３では、リクエスト生成部１０のポジティブリクエスト生成部１３とネガティブリクエスト生成部１４において、各々挿入文字列データ１２を参照してポジティブリクエストとネガティブリクエストを生成し（Ｓ２１，Ｓ３１）、リクエスト送信部１５が、例えば図１４に示すように、レスポンス解析部２０側でどのリクエストに対する応答か区別できるようにＷｅｂサービス提供システム６０に送信する（Ｓ２２，Ｓ３２）。具体的には、例えばリクエスト送信部１５は、送信したリクエスト及び検査対象の脆弱性及びポジティブリクエストかネガティブリクエストかの種別を示す情報をレスポンス受信部２１に供給し、レスポンス受信部２１は、これらの情報に応じて各々のリクエストとこれらに対するレスポンスを対応付けておく。
【００３４】
また、Ｓ１４では、レスポンス解析部２０のレスポンス受信部２１は、Ｗｅｂサービス提供システム６０からの応答（ＨＴＴＰレスポンス）を受信し（Ｓ２３，Ｓ３３）、ステータス抽出部２２〜特殊文字列抽出部２５は、各々のＨＴＴＰレスポンスの特徴的な情報（応答パターン）を抽出し（Ｓ２４，Ｓ３４）、レスポンス情報保存部２６は各々のレスポンスパターンを作成する（Ｓ２５，Ｓ３５）。このように作成された各々のレスポンスパターンは、Ｓ１５において、レスポンス情報比較部２７による比較に用いられる。
【００３５】
（動作詳細：リクエスト生成）
Ｗｅｂアプリケーション６２に、ＳＱＬインジェクション脆弱性がある場合には、入力パラメータの値に、正当なリクエスト中では使用されない。例えば「’」，「−−」，「％」等の文字列が含まれている場合にエラーを生じる可能性があることが知られている。このため、ＳＱＬインジェクション脆弱性の検査用には、ネガティブリクエストを生成する文字列として例えば「’ ａｎｄ ． ａｎｄ ’１’＝’１」，「−−」，「％」等が選択されており、ポジティブリクエストを生成する文字列としてこれら以外の文字列であって正当なリクエスト中では使用されない文字種を含む文字列、例えば「＜」，「＞」，「／」，「！」等が選択されている。同様に、他の脆弱性に対してもネガティブリクエストを生成する文字列とポジティブリクエストを生成する文字列とが選択されている。これらの文字列は、正当なパラメータ入力値（例えば正当なユーザ名“ｊｏｈｎ”）の「前」，「途中」，「後」にこれらの文字列を挿入される。また、正当なパラメータ入力値を持つリクエスト及びパラメータの値を削除したリクエストもポジティブリクエストに含まれる。ただし、正当なパラメータ入力値のどこにこれらの文字列を挿入するかは、検査時間の短縮等の目的によって「前」のみにする等適宜変更するようにしてもよい。
【００３６】
テストデータを生成するためには、正当なリクエストが必要となる。具体的には、例えば図１５に示すように、上述の図３及び図４に示すような画面に対して正しい「ユーザ名」及び「パスワード」の組み合わせを入力した際のリクエストのデータを、検査者が予め生成して検査制御部４０に入力しておく。
【００３７】
また、テストデータの生成は、上述の正当なリクエストを、例えば図１６に示す処理によって加工することで生成される。このテストデータ生成処理では、例えば予め登録された挿入文字列データ１２を利用して正当なリクエストのデータからテストデータを生成する（Ｓ５２〜Ｓ５５）。
【００３８】
上述のように、検出する脆弱性毎に、ポジティブリクエストを生成するための文字列とネガティブリクエストを生成するための文字列が選択されている。検査者は予め、これらの文字列を用い、例えば図１７に示すように、正当なリクエスト中のパラメータ名及びその入力値を示す文字列（置換対象文字列“ｕｓｅｒｎａｍｅ＝ｊｏｈｎ”）と、この置換対象文字列中のパラメータ入力値を上述の文字列で置き換えた文字列（置換文字列）の組み合わせとして、挿入文字列データ１２を作成し、当該検査装置に入力しておく。なお、このような挿入文字列データ１２は、検査対象となるパラメータ毎、検査対象となる脆弱性毎に作成し、当該検査装置に入力しておく。なお、置換文字列がパラメータ名のみ、あるいは空白であるものは、パラメータ入力値がない状態、あるいはパラメータ名もない状態を示している。すなわち、置換対象文字列を置換文字列“ｕｓｅｒｎａｍｅ＝”で置換するとパラメータ入力値がない状態、置換対象文字列を置換文字列“”で置換するとパラメータ自体がない状態となる。
【００３９】
ポジティブリクエスト生成部１３及びネガティブリクエスト生成部１４は、これらの挿入文字列データ１２に従って、正当なリクエスト中の置換対象文字列を、各置換文字列で置換した複数のポジティブリクエストとネガティブリクエストのデータ（テストデータ）を生成する（Ｓ５３，Ｓ５４）。このようなテストデータは、対象となるパラメータ毎（例えばパスワード（ｐａｓｓｗｏｒｄ）等）に対して、対象となる脆弱性毎に生成する。
【００４０】
なお、図１７に示すように、挿入文字列データ１２として置換前後の文字列を定義しておく代わりに、図１８に示すように、変形の対象となるパラメータと当該パラメータの入力値の置換後の文字列のみを定義しておくようにしてもよい。この場合、パラメータ変形部１１は、正当なリクエストから置換対象のパラメータの入力値を置換文字列で置換してテストデータを生成する。さらに、パラメータ自体がない状態のテストデータは、パラメータ名とその入力値を削除することによって行う。
【００４１】
このように生成されたポジティブリクエストとネガティブリクエストのデータは、Ｗｅｂサーバ６１に送信される。このＨＴＴＰリクエストは、例えばステータス部，ヘッダ部、送信データ本体であるボディ部等から構成されている。
【００４２】
また、このようなＨＴＴＰリクエストに対するＷｅｂサービス提供システム６０からの応答（ＨＴＴＰレスポンス）は、例えば図１９（ＨＴＴＰレスポンス）に示すような構成になっている。これらのＨＴＴＰレスポンスは、例えばステータス部，ヘッダ部、ＨＴＭＬデータ本体であるボディ部等から構成されている。
【００４３】
上述のような構成のＨＴＴＰレスポンスは、Ｗｅｂサーバ６１からレスポンス受信部２１に供給される。供給されたＨＴＴＰレスポンスはレスポンス受信部２１からステータス抽出部２２〜特殊文字列抽出部２５に供給され、ステータス抽出部２２〜特殊文字列抽出部２５においてＨＴＴＰレスポンス中の特徴的な情報が抽出される。
【００４４】
（レスポンス長の抽出）
レスポンス長抽出部２３は、ＨＴＴＰレスポンスのボディ部分の長さを検出する。ＨＴＴＰレスポンスは、例えば上述の図１９に示すように、ヘッダ部分とボディ部分から構成されており、これらの部分は空白行により分割されている。レスポンス長抽出部２３では、空白行以降のＨＴＴＰレスポンスのボディ部分のバイト数をカウントし、レスポンス長とする。
【００４５】
ＨＴＴＰレスポンスのヘッダ部分にはボディ部分に含まれるバイト数を示すためのＣｏｎｔｅｎｔ−Ｌｅｎｇｔｈヘッダが含まれていることがあるが、まれにボディ部分の実際のバイト数と異なるバイト数が指定されていることがある。レスポンス長抽出部２３では、Ｃｏｎｔｅｎｔ−Ｌｅｎｇｔｈヘッダに示された値ではなく、実際に取得したＨＴＴＰレスポンスのボディ部分のバイト数をレスポンス長とする。なお、上述の図１９に示すレスポンスのボディ部分は、別途ＣＳＳファイルで指定されたデザインでボディ部分を表示するように構成されているが、レスポンス解析部２０では、レスポンスのボディ部分のみから特徴的な情報を抽出する。
【００４６】
例えば図２０及び図２１に示すＨＴＴＰレスポンスのレスポンス長を抽出すると、図２２に示すように、図２０のレスポンス１の場合では２６９バイト、図２１のレスポンス２の場合では、１６４バイトとなる。なお、動的に生成されるＨＴＭＬデータで構成される画面では、同一のＵＲＬに同一のパラメータ入力値でアクセスした場合でも、若干レスポンス長が異なる場合がある。このような場合には、レスポンス長による特徴的な差異があるかどうか判断する際の閾値として、例えばレスポンス長が５０％以上増減することとする。この閾値はＷｅｂアプリケーションによって変化させてもよい。
【００４７】
ところで、図２０と図２１は、いずれもポジティブリクエストに対してログインが失敗した際のＨＴＴＰレスポンス（ポジティブレスポンス）の例であるが、アプリケーションの作り込みの違いによって、レスポンス長が異なる例を示している。図２０に示す場合では、ログインが失敗した際に再度入力欄を有するログイン画面に戻るようにアプリケーションが構成されているが、図２１に示す場合では、ログインが失敗した際にその旨を表示する画面に戻り、ボタンが押下された後にログイン画面に戻るようにアプリケーションが構成されている。
【００４８】
（ヘッダ情報の抽出）
また、ヘッダ情報抽出部２４は、例えばＨＴＴＰレスポンス中のＬｏｃａｔｉｏｎヘッダとＳｅｔ−Ｃｏｏｋｉｅヘッダを抽出し、各々のヘッダの有無をヘッダ情報とする。Ｌｏｃａｔｉｏｎヘッダは、クライアントのリクエストを他のＵＲＬに転送したい場合に、次に取得するべきＵＲＬを指定する。また、Ｓｅｔ−Ｃｏｏｋｉｅヘッダは、新たなＣｏｏｋｉｅを設定するために付加される。Ｃｏｏｋｉｅはセッション管理に利用されるため、Ｓｅｔ−Ｃｏｏｋｉｅヘッダが含まれるということは、既存のセッションを破棄することを意味している。
【００４９】
これにより、例えば図２３及び図２４に示すようなＨＴＴＰレスポンスのヘッダ情報を抽出した結果は、図２５に示すようになる。なお、アプリケーションの作りこみによっては、遷移毎にＳｅｔ−Ｃｏｏｋｉｅヘッダが付加される（遷移毎にＣｏｏｋｉｅを変える）場合があるが、このような場合には、Ｓｅｔ−Ｃｏｏｋｉｅヘッダを抽出しないようにしてもよい。
【００５０】
（ＨＴＴＰステータスコードの抽出）
また、ステータス抽出部２２は、ＨＴＴＰレスポンス中のステータス部からステータスコードを抽出する。ＨＴＴＰのステータスコードは、以下のように、Ｗｅｂサービス提供システム６０内部でリクエストがどのように処理されたかを示している。
１ＸＸ：情報。サーバはリクエストを受信したが、最終結果はまだ利用可能でない。
２ＸＸ：成功。サーバはリクエストを正常に処理した。
３ＸＸ：リダイレクト。リクエストは別のＵＲＬにリダイレクトされる。
４ＸＸ：クライアントエラー。リクエストにエラーがあり正常に処理できなかった。
５ＸＸ：サーバエラー。サーバはリクエストを正常に処理できなかった。
なお、これらの処理結果は、脆弱性が原因とは限らないが、ステータスコードが異なれば、Ｗｅｂサービス提供システム６０内部の処理が異なることがわかる。
これにより、例えば図２６及び図２７に示すようなＨＴＴＰレスポンスのステータスコードを抽出した結果は、図２８に示すようになる。
【００５１】
（特定文字列の抽出）
特殊文字列抽出部２５は、例えば図２９に示すように、予め設定された特定の文字列がＨＴＴＰレスポンス内に存在するか否かを検出し、検出した文字列を抽出する。Ｗｅｂサービス提供システム６０側で脆弱性が原因のエラーが発生した場合、ＨＴＴＰレスポンスに「エラー」や「不正」「Ｅｒｒｏｒ」といった特徴的なメッセージが含まれることがあるため、このような特定の文字列を予め設定しておき、ＨＴＴＰレスポンス内にこれらの文字列が含まれる場合には抽出する。これにより、例えば図３０及び図３１に示すようなＨＴＴＰレスポンス中の特定文字列を抽出した結果は、図３２に示すようになる。
【００５２】
（脆弱性有無の判定）
ステータス抽出部２２〜特殊文字列抽出部２５は、上述のように、各々のポジティブレスポンス及び各々のネガティブレスポンス毎に、特徴的な情報を抽出し、レスポンス情報保存部２６に供給する。例えば図３３に示すように、登録ユーザ毎に、情報提供を行うＷｅｂアプリケーション６２では、例えば図３４（Ａ）に示すようなログイン画面に対してユーザが入力したユーザ名とパスワードを、ＤＢ６４に格納されている認証情報と照合し、ユーザ名とパスワードが正しい組み合わせであれば同図（Ｂ）に示すような情報提供サービスを提供し、ユーザ名とパスワードが正しくない場合には同図（Ｃ）に示すような再入力画面を表示させるＷｅｂアプリケーション６２を想定し、具体的なポジティブレスポンスとネガティブレスポンスについて説明する。
【００５３】
例えば図３４（Ａ）に示すログイン画面中で指定されたアドレス（ＵＲＬ）に対して、例えば上述の図１５に示すようなユーザ名とパスワードの組み合わせを含むリクエスト（ポジティブリクエスト１）が供給されると、Ｗｅｂアプリケーション６２のＳＱＬ発行部６２ａ（さらに具体的には、例えば同図中の斜線部の「パラメータチェック及びＳＱＬコマンド生成」処理等）は、ＤＢサーバ接続ＡＰＩ６６ａを介して、ユーザ名「ｊｏｈｎ」に対応するパスワードが「ｊｔｒ」であることを確認するＳＱＬ文を作成し、ＤＢサーバ６３に送信する。ＤＢサーバ６３は、供給されたＳＱＬ文に従って指定されたユーザ名「ｊｏｈｎ」に対応するパスワードが「ｊｔｒ」であるかを検索し、その結果をＷｅｂアプリケーション６２のＳＱＬ発行部６２ａに供給する。Ｗｅｂアプリケーション６２は検索結果が１件あればユーザ名とパスワードの組み合わせが正しいと判断する。クライアント７０側から供給されたユーザ名とパスワードの組み合わせが正しい場合には、Ｗｅｂアプリケーション６２は、上述の図１９に示すように、図３４（Ｂ）に示すページに対応するレスポンスデータを生成し、これをレスポンス解析部２０側に供給する。また、クライアント７０側から供給されたユーザ名とパスワードの組み合わせが誤っている場合、供給されたＳＱＬ文による検索結果は０件となる。このとき、Ｗｅｂアプリケーション６２は図３４（Ｃ）に示すページに対応するレスポンスデータを生成し、これをレスポンスレスポンス解析部２０側に供給する。
【００５４】
上述の図１５に示すリクエスト中のユーザ名「ｊｏｈｎ」をポジティブテスト文字列「＜ｊｏｈｎ」で置き換えたリクエスト（ポジティブリクエスト２）に対するレスポンスは、例えば図３５に示すようになる。同様に、図１５に示すリクエスト中のユーザ名「ｊｏｈｎ」をポジティブテスト文字列「／ｊｏｈｎ」で置き換えたリクエスト（ポジティブリクエスト４）に対するレスポンスは、例えば図３６に示すようになり、ポジティブテスト文字列「！ｊｏｈｎ」で置き換えたリクエスト（ポジティブリクエスト５）に対するレスポンスは、例えば図３７に示すようになる。
【００５５】
また、Ｗｅｂアプリケーション６２に脆弱性がある場合、図１５に示すリクエスト中のユーザ名「ｊｏｈｎ」をネガティブテスト文字列「’ ａｎｄ ． ａｎｄ ‘１’＝’１ｊｏｈｎ」で置き換えたリクエスト（ネガティブリクエスト１）に対するレスポンスは、例えば図３８に示すようになり、ネガティブテスト文字列「−−ｊｏｈｎ」で置き換えたリクエスト（ネガティブリクエスト２）に対するレスポンスは、例えば図３９に示すようになる。一方、Ｗｅｂアプリケーション６２に脆弱性がない場合、図１５に示すリクエスト中のユーザ名「ｊｏｈｎ」をネガティブテスト文字列「’ ａｎｄ ． ａｎｄ ‘１’＝’１ｊｏｈｎ」で置き換えたリクエスト（ネガティブリクエスト１）に対するレスポンスは、例えば図４０に示すようになり、ネガティブテスト文字列「−−ｊｏｈｎ」で置き換えたリクエスト（ネガティブリクエスト２）に対するレスポンスは、例えば図４１に示すようになる。
【００５６】
図４２及び図４３は、上述の図１９及び図３５〜図４１に示すような複雑なＨＴＴＰレスポンスを返すＷｅｂアプリケーション６２におけるポジティブレスポンスのグループの例とネガティブレスポンスのグループの例について、特徴的な情報の中のレスポンス長をまとめたものである。なお、図４２は脆弱性がある場合、図４３は脆弱性がない場合についてまとめたものである。
【００５７】
例えば特徴的な情報のいずれかのみ（例えばレスポンス長）を用い、ネガティブレスポンスグループ内の全てのパターン（この場合ではレスポンス長）が、ポジティブレスポンスグループ中のパターンのいずれかに一致しなければ「脆弱性あり」と判定することにしても、脆弱性の有無に応じた応答パターンの違いがあれば、ある程度の脆弱性の検出は可能である。このような判定方法では、例えば図４２に示す場合では、「ネガティブレスポンス２」と「ネガティブレスポンス３」のパターン「２６５７」は、ポジティブレスポンスグループ内に存在するが、「ネガティブレスポンス１」のパターン「５１１」はポジティブレスポンスグループ内には存在しないため、「脆弱性あり」と判定する。また、図４３に示す場合では、「ネガティブレスポンス１」〜「ネガティブレスポンス３」のいずれのパターンもポジティブレスポンスグループ内に存在するため、「脆弱性なし」と判定する。
【００５８】
このように、個々の特徴的な情報（例えば「レスポンス長」）を独立に比較することによっても、ある程度は、脆弱性の有無を検出することができるが、Ｗｅｂアプリケーション６２における応答画面の作りこみ次第では、例えば図４２中の「ネガティブレスポンス１」の応答のレスポンス長が、ポジティブレスポンスグループのいずれかの応答のレスポンス長と同一になってしまう場合も考えられる。
【００５９】
例えばＷｅｂアプリケーション６２の作りこみ次第では、上述の図３８（図３４（Ｄ）に示す画面に相当）に示すレスポンスの代わりに、例えば図４４に示すようなレスポンスを返す（図４５に示す画面に相当）ように構成することも充分考えられる。さらに、例えば図４６に示すように，「ネガティブレスポンス１」の応答のレスポンス長が、ポジティブレスポンスグループ内の応答のレスポンス長と同一になってしまう場合も考えられる。この場合、「ネガティブレスポンス１」〜「ネガティブレスポンス３」のパターンがいずれもポジティブレスポンスグループ内に存在するため、「脆弱性なし」と判定してしまう。
【００６０】
このような場合には、ポジティブレスポンスグループとネガティブレスポンスグループの特徴的な情報を複数用いて判定を行うことにより、脆弱性の検出の精度を向上させることができる。図４７及び図４８は、上述の図１９，図３５〜図３７及び図４４に示すポジティブレスポンスのグループの例とネガティブレスポンスのグループの例について、特徴的な情報のパターンをまとめたものである。なお、図４７は脆弱性がある場合、図４８は脆弱性がない場合についてまとめたものである。図４７に示す場合では、上述のようにレスポンス長のみで脆弱性を判断しようとすると「脆弱性なし」と判定してしまうが、このような場合にも、図４７のポジティブレスポンスグループ内には、ネガティブレスポンス１のように、レスポンス長が「２６６」であっても「Ｃｏｏｋｉｅ書き換えなし」で応答中に「エラー」という文字が含まれる組み合わせがないため、当該応答中の個々の特徴的な情報を総合的に比較して判定するようにすれば、Ｗｅｂアプリケーション６２の脆弱性を確実に検出することができる。
【００６１】
レスポンス情報比較部２７は、この特徴的な情報のパターンについて比較を行い、例えば図４７に示すように、ネガティブレスポンスグループ内に、ポジティブレスポンスグループ中のパターンのいずれにも一致しないパターンがあれば「脆弱性あり」と判定する。また、レスポンス情報比較部２７は、例えば図４８に示すように、すべてのネガティブレスポンスグループのパターンがポジティブレスポンスグループ中のいずれかのパターンに一致すれば「脆弱性なし」と判定する。これにより、この検査装置では、Ｗｅｂサービス提供システム６０において、Ｗｅｂアプリケーション６２のＳＱＬインジェクション脆弱性の検出の確実性を向上させることができる。
【００６２】
なお、ポジティブリクエストとネガティブリクエストを複数生成し、Ｗｅｂアプリケーション６２に供給しているのは、Ｗｅｂアプリケーション６２（例えば上述の図３３中のログイン処理部６２１等）の作りこみの違い（必要な機能の実装上の違い等）、プログラム言語処理系６６やＤＢサーバ６３の種類あるいはバージョンの違い等によって、同様な処理を行うＷｅｂアプリケーション６２であっても挙動が異なるためである。複数のポジティブリクエストと複数のネガティブリクエストに対する複数の応答の特徴的な情報を抽出して比較することにより、Ｗｅｂアプリケーション６２の挙動の違いがあっても、脆弱性の検出の確実性を向上させることができる。
【００６３】
（他の脆弱性の検査）
以上、ＳＱＬインジェクション脆弱性の検出の場合について説明したが、この検査装置では、Ｗｅｂアプリケーション６２の他のインジェクション系脆弱性の検出も行う。ＬＤＡＰインジェクション脆弱性は、Ｗｅｂアプリケーションのプログラム内部においてＬＤＡＰ文を生成する際に、ユーザからの入力がそのままＬＤＡＰ文に含まれることが問題となって発生する。例えば、各々のユーザ毎に住所録を提供するＷｅｂアプリケーション６２を想定する。このようなＷｅｂアプリケーションにおいて、例えば上述の図１５のようなリクエストに応じてＬＤＡＰ文を生成し、各々のユーザが登録した住所録を表示させるような場合には、ＬＤＡＰ発行部６２ｂが、リクエスト中のパラメータ「ｕｓｅｒｎａｍｅ」のユーザからの入力「ｊｏｈｎ」を取り出し、予め設定しておいたＬＤＡＰ文の一部に埋め込み、ＬＤＡＰサーバに処理を要求して、”ｊｏｈｎ”というｕｉｄで登録されている情報を取得するＬＤＡＰ文が生成される。
（ｕｉｄ＝ｊｏｈｎ）
このとき、Ｗｅｂアプリケーション６２にＬＤＡＰインジェクション脆弱性があると、ユーザからの入力に「ｊｏｈｎ）（｜（ｏｂｊｅｃｔｃｌａｓｓ＝＊）」が指定された場合に、以下のようＬＤＡＰ文が生成されてしまう。
（ｕｉｄ＝ｊｏｈｎ）（｜（ｏｂｊｅｃｔｃｌａｓｓ＝＊））
このように、ＬＤＡＰ文の生成に利用される特殊文字をユーザが指定し、これがそのままＬＤＡＰ文の生成に使用される場合にはＬＤＡＰインジェクション脆弱性が存在する。このような場合には、予め想定されたものとは異なるＬＤＡＰ文が生成され得るため、ユーザは任意のＬＤＡＰ文を実行可能である。
【００６４】
ＬＤＡＰサーバ６５にＬＤＡＰインジェクション脆弱性がある場合にエラーを生じる可能性がある文字は、例えば「（」、「）」として知られている。これらの文字列は、正当なリクエスト中では使用されない。このため、ＬＤＡＰインジェクション脆弱性の検査用には、ネガティブリクエストを生成する文字列として「（」、「）」が選択されており、ポジティブリクエストを生成する文字列としてこれら以外の正当なリクエスト中では使用されない文字種を含む文字列、例えば「＜」，「＞」，「／」，「！」が選択されている。これらの文字列は、正当な入力パラメータの「前」，「途中」，「後」に挿入される。また、正当なパラメータ入力値を持つリクエスト及びパラメータの値を削除したリクエストもポジティブリクエストに含まれる。ただし、正当な入力パラメータのどこにこれらの文字列を挿入するかは、検査時間の短縮等の目的によって「前」のみにするなどしてよい。これらの選択に従って、例えば図４９に示すように、上述の図１７と同様な形式でＬＤＡＰインジェクション脆弱性の検査用の挿入文字データが生成され、予め当該検査装置に入力されている。
【００６５】
また、ＸＰａｔｈインジェクション脆弱性は、Ｗｅｂアプリケーション６２のプログラム内部においてＸＰａｔｈ式を組み立てる際に、ユーザからの入力がそのままＸＰａｔｈ式に含まれることが問題となって発生する。例えば、各々のユーザ毎に住所録を提供するＷｅｂアプリケーション６２を想定する。このようなＷｅｂアプリケーションにおいて、例えば上述の図１５のようなリクエストに応じ応じてＸＰａｔｈ式を生成し、各々のユーザが登録した住所録を取り出すような場合には、Ｗｅｂアプリケーション６２のＸＰａｔｈ式発行部（図示せず）が、リクエスト中のパラメータ「ｕｓｅｒｎａｍｅ」のユーザからの入力「ｊｏｈｎ」を取り出し、予め設定しておいたＸＰａｔｈ式の一部に埋め込み、”ｊｏｈｎ”という属性値を持つ”ｎａｍｅ”ノードを取得するＸＰａｔｈ式を生成する。
ｓｔｒｉｎｇ（／／ｕｓｅｒ［ｎａｍｅ／ｔｅｘｔ（）＝’ｊｏｈｎ’］／ａｃｃｏｕｎｔ／ｔｅｘｔ（））
このとき、Ｗｅｂアプリケーション６２にＸＰａｔｈインジェクション脆弱性があると、ユーザからの入力に「’ ｏｒ ’１ ’＝’１」が指定された場合、以下のようなＸＰａｔｈ式が生成されてしまう。
ｓｔｒｉｎｇ（／／ｕｓｅｒ［ｎａｍｅ／ｔｅｘｔ（）＝’’ ｏｒ ’ １ ’＝’１’］／ａｃｃｏｕｎｔ／ｔｅｘｔ（））
このように、ＸＰａｔｈ式の生成に利用される特殊文字をユーザが指定し、これがそのままＸＰａｔｈ式の生成に使用される場合には、ＸＰａｔｈインジェクション脆弱性が発生する可能性がある。このような場合には、予め想定されたものとは異なるＸＰａｔｈ式が生成され得るため、ユーザは任意のＸＰａｔｈ式を実行可能である。
【００６６】
Ｘｐａｔｈインジェクション脆弱性がある場合にエラーを生じる可能性がある文字は、例えば「’」，「”」として知られている。これらの文字列は、正当なリクエスト中では使用されない。このため、Ｘｐａｔｈインジェクション脆弱性の検査用には、ネガティブリクエストを生成する文字列として「’ ＡＮＤ １＜＞２ ＡＮＤ ’１ ’＝’１」，「” ＡＮＤ １＜＞２ ＡＮＤ ”１”＝”１」が選択されており、ポジティブリクエストを生成する文字列としてこれら以外の正当なリクエスト中では使用されない文字種を含む文字列、例えば「＃」，「！」，「＊」が選択されている。これらの文字列は、正当な入力パラメータの「前」，「途中」，「後」にこれらの文字列を挿入される。また、正当なパラメータ入力値を持つリクエスト及びパラメータの値を削除したリクエストもポジティブリクエストに含まれる。ただし、正当な入力パラメータのどこにこれらの文字列を挿入するかは、検査時間の短縮等の目的によって「前」のみにするなどしてよい。これらの選択に従って、例えば図５０に示すように、上述の図１７と同様な形式でＸｐａｔｈインジェクション脆弱性の検査用の挿入文字データが生成され、予め当該検査装置に入力されている。
【００６７】
また、コマンドインジェクション脆弱性は、Ｗｅｂアプリケーション６２のプログラム内部においてＯＳのコマンドを組み立てる際に、ユーザからの入力がそのままＯＳコマンドに含まれることが問題となって発生する。例えば各々のユーザ毎にディレクトリを割り当てファイル共有サービスを提供するＷｅｂアプリケーション６２を想定する。このようなＷｅｂアプリケーション６２において、例えば上述の図１５のようなリクエストに応じ応じてＯＳのコマンドを生成し、各々のユーザのディレクトリ内のファイルのリストを表示させるような場合には、コマンド発行部６２ｃが、リクエスト中のパラメータ「ｕｓｅｒｎａｍｅ」のユーザからの入力「ｊｏｈｎ」を取り出し、予め設定しておいたＯＳコマンドの一部に埋め込み、ディレクトリ“ｊｏｈｎ”に格納されているファイルの一覧を取得するＯＳコマンドが生成される。
ｓｙｓｔｅｍ（“ｌｓ −ｌ ｊｏｈｎ”）
このとき、Ｗｅｂアプリケーション６２にコマンドインジェクション脆弱性があると、ユーザからの入力に「； ｃａｔ ／ｅｔｃ／ｐａｓｓｗｄ」が指定された場合に、以下のようなＯＳコマンドが生成されてしまう。
ｓｙｓｔｅｍ（“ｌｓ −ｌ ； ｃａｔ ／ｅｔｃ／ｐａｓｓｗｄ”）
このように、ＯＳコマンドの組み立てに利用される特殊文字をユーザが指定し、これがそのままＯＳコマンドの生成に使用される場合には、ＯＳコマンドインジェクション脆弱性が存在する。このような場合には、予め想定されたものとは異なるＯＳコマンドが生成され得るため、ユーザは任意のＯＳコマンドを実行可能である。
【００６８】
コマンドインジェクション脆弱性がある場合にエラーを生じる可能性がある文字は、例えば「＆」，「＆＆」，「；」，「｜」，「｜｜」として知られている。これらの文字列は、正当なリクエスト中では使用されない。このため、コマンドインジェクション脆弱性の検査用には、ネガティブリクエストを生成する文字列として「＆」，「＆＆」，「；」，「｜」，「｜｜」が選択されており、ポジティブリクエストを生成する文字列としてこれら以外の正当なリクエスト中では使用されない文字種を含む文字列、例えば「％」，「＃」が選択されている。これらの文字列は、正当な入力パラメータの「前」，「途中」，「後」にこれらの文字列を挿入される。また、正当なパラメータ入力値を持つリクエスト及びパラメータの値を削除したリクエストもポジティブリクエストに含まれる。ただし、正当な入力パラメータのどこにこれらの文字列を挿入するかは、検査時間の短縮等の目的によって「前」のみにするなどしてよい。これらの選択に従って、例えば図５１に示すように、上述の図１７と同様な形式でコマンドインジェクション脆弱性の検査用の挿入文字データが生成され、予め当該検査装置に入力されている。
【００６９】
また、ＳＳＩインジェクション脆弱性は、Ｗｅｂアプリケーション６２のプログラム内部においてＨＴＭＬデータを生成する際に、ユーザからの入力がそのまま含まれることが問題となって発生する。例えば、各々のユーザ毎にディレクトリを割り当て保存されているファイル共有サービスを提供するＷｅｂアプリケーション６２を想定する。このようなＷｅｂアプリケーション６２において、例えば上述の図１５のようなリクエストに応じてＳＳＩコマンドを生成し、各々のユーザのディレクトリ内のファイルのリストを表示させるような場合には、Ｗｅｂアプリケーション６２のＳＳＩ発行部（図示なし）は、リクエスト中のパラメータ「ｕｓｅｒｎａｍｅ」のユーザからの入力「ｊｏｈｎ」を取り出し、予め設定しておいたＳＳＩコマンドの一部に埋め込み、ディレクトリ“ｊｏｈｎ”に格納されているファイルの一覧を取得するＳＳＩコマンドを生成する。
＜！――＃ｅｘｅｃ ｃｍｄ＝“／ｂｉｎ／ｌｓ ｊｏｈｎ”――＞
このとき、Ｗｅｂアプリケーション６２にＳＳＩインジェクション脆弱性があると、例えばユーザからの入力が「ｊｏｈｎ” ――＞ ＜！――＃ｅｘｅｃ ｃｍｄ＝“／ｂｉｎ／ｃａｔ ／ｅｔｃ／ｐａｓｓｗｄ」である場合には、以下のようなＳＳＩコマンドが生成されてしまう。
＜！――＃ｅｘｅｃ ｃｍｄ＝“／ｂｉｎ／ｌｓ ｊｏｈｎ” ――＞ ＜！――＃ｅｘｅｃ ｃｍｄ＝“／ｂｉｎ／ｃａｔ ／ｅｔｃ／ｐａｓｓｗｄ”――＞
このように、ＳＳＩコマンドに利用される特殊文字をユーザが指定し、これがそのままＳＳＩコマンドの生成に使用される場合には、ＳＳＩインジェクション脆弱性が存在する。このような場合には、予め想定されたものとは異なるＳＳＩコマンドが生成され得るため、ユーザは任意のＳＳＩコマンドを実行可能である。
【００７０】
ＳＳＩインジェクション脆弱性がある場合にエラーを生じる可能性がある文字は、例えば「＜！――＃」として知られている。これらの文字列は、正当なリクエスト中では使用されない。このため、ＳＳＩインジェクション脆弱性の検査用には、ネガティブテスト文字列として文字列「＜！――＃」が選択されており、ポジティブテスト文字列としてこれら以外の正当なリクエスト中では使用されない文字種を含む文字列、例えば「／」，「！」，「−」，「＜！−−＃ｅｃｈｏ ｖａｒ＝“”――＞」が選択されている。これらの文字列は、正当な入力パラメータの「前」，「途中」，「後」にこれらの文字列を挿入される。ただし、正当な入力パラメータのどこにこれらの文字列を挿入するかは、検査時間の短縮等の目的によって「前」のみにするなどしてよい。これらの選択に従って、例えば図５２に示すように、上述の図１７と同様な形式でＳＳＩインジェクション脆弱性の検査用の挿入文字データが生成され、予め当該検査装置に入力されている。
【００７１】
ＬＤＡＰ脆弱性以下の他の脆弱性もＳＱＬインジェクションの場合と同様のフローにより脆弱性の検出を行うことができる。ポジティブリクエスト生成部１３及びネガティブリクエスト生成部１４は、挿入文字列データ１２内の上述の各脆弱性についての定義に従って、パラメータ変形部１１から指定されたパラメータ入力値を変形して、ポジティブリクエストとネガティブリクエストを生成し、リクエスト送信部１５がＷｅｂサーバ６１に送信する。これらのリクエストに対するＨＴＴＰレスポンスが供給されると、上述のＳＱＬインジェクションの場合と同様に、ステータス抽出部２２〜特殊文字列抽出部２５が各々の特徴的な情報を抽出し、レスポンス情報比較部２７が各応答パターンの比較を行う。これにより、ＳＱＬインジェクション脆弱性の検出の場合と同様に、Ｗｅｂアプリケーション６２自体に存在する脆弱性の検出の確実性を向上させることができる。
【００７２】
（効果）
上述のように、このＷｅｂサービス提供システム検査装置では、脆弱性毎に検査文字列を定義しておき、これに応じてパラメータ入力値を変化させたリクエストを生成し、これらのリクエストに対するＷｅｂサービス提供システム６０側のＨＴＴＰレスポンス中の特徴的な情報を抽出し、これらを総合的に判断して脆弱性の有無を判断しているため、Ｗｅｂアプリケーション６２等によって構成されるＷｅｂサービス提供システムに存在する脆弱性の検出の確実性を向上させることができる。
【００７３】
Ｗｅｂアプリケーション６２の作りこみ次第で、脆弱性が存在するにもかかわらず、脆弱性に起因する特徴的な文字列がＨＴＴＰレスポンスに含まれない場合がある。このような場合には、単なる特定の文字列との比較では脆弱性の有無を判定することができない。
【００７４】
これに対し、この検査装置では、ポジティブリクエストに対するＨＴＴＰレスポンスとネガティブリクエストに対するＨＴＴＰレスポンスから各々抽出した特徴的な情報（レスポンス長，ヘッダ情報，ステータス，特徴的な文字列等）のいずれか若しくはすべてを利用して複数のレスポンスを比較して脆弱性の有無を判定するため、脆弱性検出の確実性向上に寄与することができる。
【図面の簡単な説明】
【００７５】
【図１】本発明の一実施例に係る検査装置の構成例を示すブロック図である。
【図２】検査対象となるＷｅｂサービス提供システムの使用例を示す図である。
【図３】ログイン画面の例を示す図である。
【図４】ログイン画面を表示するためのＨＴＭＬソースの例を示す図である。
【図５】Ｗｅｂサービス提供システムによるサービス提供動作の例を示すシーケンス図である。
【図６】Ｗｅｂサーバに対するＨＴＴＰリクエストの例を示す図である。
【図７】正当なパラメータの例を示す図である。
【図８】正常応答の画面の例を示す図である。
【図９】エラー画面の例を示す図である。
【図１０】脆弱性検査全体の概要を示す図である。
【図１１】検査対象のアプリケーションにおけるＵＲＬ及びパラメータの例を示す図である。
【図１２】検査処理の概要を示す図である。
【図１３】検査処理の例を示すフローチャートである。
【図１４】リクエスト送信部による各リクエストの送信タイミングを示す図である。
【図１５】ＨＴＴＰリクエストの例を示す図である。
【図１６】パラメータ変形部１１による処理の例を示すフローチャートである。
【図１７】ポジティブリクエスト及びネガティブリクエストの生成に用いる挿入文字列データの例を示す図である。
【図１８】挿入文字列データの他の例を示す図である。
【図１９】ポジティブレスポンスの例を示す図である。
【図２０】ＨＴＴＰレスポンスの例を示す図である。
【図２１】ＨＴＴＰレスポンスの例を示す図である。
【図２２】ＨＴＴＰレスポンスのボディ部分のレスポンス長の例を示す図である。
【図２３】ＨＴＴＰレスポンスの例を示す図である。
【図２４】ＨＴＴＰレスポンスの例を示す図である。
【図２５】ＨＴＴＰレスポンスから抽出したヘッダ情報の例を示す図である。
【図２６】ＨＴＴＰレスポンスの例を示す図である。
【図２７】ＨＴＴＰレスポンスの例を示す図である。
【図２８】ＨＴＴＰレスポンスから抽出したステータスコードの例を示す図である。
【図２９】特定文字列のリストの例を示す図である。
【図３０】ＨＴＴＰレスポンスの例を示す図である。
【図３１】ＨＴＴＰレスポンスの例を示す図である。
【図３２】ＨＴＴＰレスポンスから抽出した特定文字列の例を示す図である。
【図３３】Ｗｅｂアプリケーション６２の構成例を示すブロック図である。
【図３４】Ｗｅｂアプリケーション６２の画面遷移の例を示す図である。
【図３５】ポジティブリクエストに対するＨＴＴＰレスポンスの例を示す図である。
【図３６】ポジティブリクエストに対するＨＴＴＰレスポンスの例を示す図である。
【図３７】ポジティブリクエストに対するＨＴＴＰレスポンスの例を示す図である。
【図３８】ネガティブリクエストに対するＨＴＴＰレスポンスの例を示す図である。
【図３９】ネガティブリクエストに対するＨＴＴＰレスポンスの例を示す図である。
【図４０】ネガティブリクエストに対するＨＴＴＰレスポンスの例を示す図である。
【図４１】ネガティブリクエストに対するＨＴＴＰレスポンスの例を示す図である。
【図４２】レスポンス情報保存部に保持される特徴的な情報のパターンの例を示す図である。
【図４３】レスポンス情報保存部に保持される特徴的な情報のパターンの例を示す図である。
【図４４】ネガティブリクエストに対するＨＴＴＰレスポンスの他の例を示す図である。
【図４５】前記ＨＴＴＰレスポンスに応じて表示される画面の例を示す図である。
【図４６】レスポンス情報保存部に保持される特徴的な情報のパターンの例を示す図である。
【図４７】レスポンス情報保存部に保持される特徴的な情報のパターンの例を示す図である。
【図４８】レスポンス情報保存部に保持される特徴的な情報のパターンの例を示す図である。
【図４９】ポジティブリクエスト及びネガティブリクエストの生成に用いる挿入文字列データの他の例を示す図である。
【図５０】ポジティブリクエスト及びネガティブリクエストの生成に用いる挿入文字列データの他の例を示す図である。
【図５１】ポジティブリクエスト及びネガティブリクエストの生成に用いる挿入文字列データの他の例を示す図である。
【図５２】ポジティブリクエスト及びネガティブリクエストの生成に用いる挿入文字列データの他の例を示す図である。
【図５３】従来の脆弱性検出方法の例を示す図である。
【図５４】ＨＴＴＰレスポンスに応じて表示される画面の例を示す図である。
【図５５】ＨＴＴＰレスポンスに応じて表示される画面の例を示す図である。
【符号の説明】
【００７６】
１０…リクエスト生成部、１１…パラメータ変形部、１２…リクエスト生成パターンデータ、１３…ポジティブリクエスト生成部、１４…ネガティブリクエスト生成部、１５…リクエスト送信部、２０…レスポンス解析部、２１…レスポンス受信部、２２…ステータス抽出部、２３…レスポンス長抽出部、２４…ヘッダ情報抽出部、２５…特殊文字列抽出部、２６…レスポンス情報保存部、２７…レスポンス情報比較部、６０…Ｗｅｂサービス提供システム、６１…Ｗｅｂサーバ、６２…Ｗｅｂアプリケーション、６３…ＤＢサーバ
【技術分野】
【０００１】
この発明は、Ｗｅｂアプリケーションの脆弱性を検出するＷｅｂサービス提供システム検査装置に関する。
【背景技術】
【０００２】
Ｗｅｂサーバをフロントエンドとして用い、ＤＢサーバが提供するＤＢサービス等を用いたアプリケーションサービスを提供する、いわゆるＷｅｂアプリケーションが知られている。例えば会員向けの情報提供サービスを行うＷｅｂアプリケーションは、例えば図３３に示すように、ログイン処理部とセッション管理部等を有する構成となっている。このようなＷｅｂアプリケーションには、例えばＳＱＬ発行部６２ａ等にバックエンドのＤＢサーバ６３で不正なＳＱＬ文が実行されるＳＱＬインジェクション脆弱性等を有する場合がある。この図３３に示すＷｅｂアプリケーションでは、ログイン画面６２１ａに対してユーザが入力したログイン情報（ユーザ名とパスワード）が供給されると、ＳＱＬ発行部６２ａは、ＤＢサーバ６３を介してＤＢ６４に問い合わせを行う。情報画面構成部６２３は、この問い合わせ結果に基づいた応答を生成してユーザ側の装置に供給する。
【０００３】
ＳＱＬ発行部６２ａがＤＢ６４に問い合わせを行う際には、ユーザがログイン画面６２１ａで入力したログイン情報に基づいてＳＱＬ文を生成し、生成したＳＱＬ文をＤＢサーバ６３に供給することによって行う。このＳＱＬ文の生成において、ユーザが入力したログイン情報に、ＳＱＬ文を生成するために使用される特殊記号が含まれていると、開発者が意図したＳＱＬ文とは異なるＳＱＬが生成されてしまうことがある。このため、Ｗｅｂアプリケーションでは、ユーザからのログイン情報等の入力値にＳＱＬ文の生成に使用する特殊記号が含まれないようにする必要がある。このように、ＷｅｂアプリケーションのＳＱＬ発行部６２ａ（例えば同図中の斜線部の「パラメータチェック及びＳＱＬコマンド生成」処理等）等における入力値チェックの不備等により、本来意図していないＳＱＬ文が生成され、ＤＢ６４内の情報が漏洩したり改ざんされたりするのがＳＱＬインジェクション脆弱性である。
【０００４】
例えばＷｅｂアプリケーションが通常は使用しない文字種が含まれている入力値を適切に処理しなかった場合、アプリケーションの利用者からの入力値によっては想定外の処理が実行されてしまう可能性がある。このことを利用すると、入力値を巧みに操作することによりＤＢに格納されている情報が漏洩したり、改ざんされたりする可能性がある。このような脆弱性にはバックエンドで処理を行うサーバの違いによりＳＱＬインジェクション脆弱性やＬＤＡＰインジェクション脆弱性やＸＰａｔｈインジェクション脆弱性などがあり、これらをインジェクション系脆弱性と呼ぶ。
【０００５】
このような脆弱性を検出するための手法として、脆弱性によるエラーが生じた際に表示される文字列を予めＤＢに格納しておき、Ｗｅｂサーバからの応答中の文字列とＤＢに格納しておいた文字列を照合する方法が知られている（例えば特許文献１）。この方法では、例えば図５３に示すように、まず、脆弱性に起因するエラーが生じると思われる検査文字列をＷｅｂサーバに送信し、これに対するＷｅｂサーバからの応答（レスポンス）中の文字列を、ＤＢに格納されている脆弱性情報（文字列）と照合し、一致する文字列があれば該当する脆弱性が存在すると判断する。
【特許文献１】米国特許６５８４５６９号公報（図１、図３）
【発明の開示】
【発明が解決しようとする課題】
【０００６】
しかしながら、フロントエンドのＷｅｂサーバの構成やアプリケーションの作りこみによっては、単純にＷｅｂサーバからの応答中の文字列とＤＢに格納されている文字列を照合するだけでは脆弱性を検出できない場合もある。例えば図５４は、アプリケーションが入力値を適切に処理していない脆弱性に起因するＳＱＬエラー表示の例であるが、アプリケーションの作りこみ次第で図５５に示すようなエラー表示となる場合も考えられる。
【０００７】
従って、上述のように、予め脆弱性によるエラーが生じた際に表示される文字列をＤＢに格納しておき、Ｗｅｂアプリケーションの応答中の文字列とＤＢに格納しておいた文字列を照合する方法では、Ｗｅｂサーバの構成やアプリケーションの作り込みによっては脆弱性を検出できない場合がある。
【０００８】
本発明は、上述のような課題に鑑みてなされたものであり、Ｗｅｂアプリケーションのインジェクション系脆弱性検出の確実性向上に寄与することができるＷｅｂサービス提供システム検査装置及びＷｅｂサービス提供システム検査プログラムを提供することを目的とする。
【課題を解決するための手段】
【０００９】
この課題を解決するために、本発明に係るＷｅｂサービス提供システム検査装置は、Ｗｅｂサーバを介してアプリケーションサービスを提供するＷｅｂサービス提供システムの検査を行うＷｅｂサービス提供システム検査装置であって、正当なリクエスト中のパラメータを予め設定されたポジティブリクエスト文字列に基づいて変形して複数のポジティブリクエストを生成するポジティブリクエスト生成手段と、正当なリクエスト中のパラメータを予め設定されたネガティブリクエスト文字列に基づいて変形して複数のネガティブリクエストを生成するネガティブリクエスト生成手段と、各ポジティブリクエストと各ネガティブリクエストをＷｅｂサービス提供システムに供給する供給手段と、各ポジティブリクエストと各ネガティブリクエストに対するＷｅｂサービス提供システムの応答を取得する取得手段と、取得した各ポジティブリクエストと各ネガティブリクエストに対するＷｅｂサービス提供システムの応答中の特徴的な情報（応答パターン）を抽出する特徴抽出手段と、ネガティブリクエストに対する応答パターンのいずれかが、ポジティブリクエストに対するどの応答パターンとも一致しないときに脆弱性が存在すると判定する判定手段とを備えることを特徴とする。
【００１０】
ポジティブリクエスト文字列及びネガティブリクエスト文字列は、例えばアプリケーションサービスに対する正当なリクエスト中のパラメータに対して、変更する文字列として予め設定されている。ポジティブリクエスト文字列は、正当なリクエスト中では用いられない文字種を含む文字列であってＷｅｂサービス提供システム脆弱性に起因する問題が生じる可能性のない文字種から選択されている。また、ネガティブリクエスト文字列は、正当なリクエスト中では用いられない文字種を含む文字列であってＷｅｂサービス提供システム脆弱性に起因する問題が生じる可能性のある文字種から選択されている。
【発明の効果】
【００１１】
本発明では、正当なリクエスト中のパラメータを予め設定されたポジティブリクエスト文字列に基づいて変形して複数のポジティブリクエストを生成し、正当なリクエスト中のパラメータを予め設定されたネガティブリクエスト文字列に基づいて変形して複数のネガティブリクエストを生成し、これらをＷｅｂサービス提供システムに供給し、各ポジティブリクエストと各ネガティブリクエストに対するＷｅｂサービス提供システムの応答を取得し、取得した各ポジティブリクエストと各ネガティブリクエストに対するＷｅｂサービス提供システムの複数の応答中の特徴的な情報（応答パターン）を抽出し、ネガティブリクエストに対する応答パターンのいずれかが、ポジティブリクエストに対するどの応答パターンとも一致しないときに脆弱性が存在すると判定することにより、脆弱性検出の確実性向上に寄与することができる。
【発明を実施するための最良の形態】
【００１２】
本発明は、例えばＷｅｂサーバを介してアプリケーションサービスを提供するＷｅｂサービス提供システムにおける脆弱性の検査を行う検査装置等に適用することができる。
【実施例１】
【００１３】
（全体構成）
図１は、本発明を適用した一実施形態に係る検査装置の構成を概念的に示すブロック図である。この検査装置は、例えばネットワーク経由でＷｅｂサーバをフロントエンドとしたアプリケーションサービスを提供するＷｅｂサービス提供システム６０の脆弱性の検査を行うもので、Ｗｅｂサービス提供システム６０に対するリクエストを生成するリクエスト生成部１０と、Ｗｅｂサービス提供システム６０の応答を解析するレスポンス解析部２０と、検査者からの指示を入力する装置操作部３０と、リクエスト生成部１０，レスポンス解析部２０等の制御を行う検査制御部４０と、脆弱性の判定結果を出力する表示部等の判定結果出力部５０とを備えている。なお、リクエスト生成部１０，レスポンス解析部２０等はプログラムで構成されている。
【００１４】
リクエスト生成部１０は、Ｗｅｂアプリケーションにおいて情報を入力する入力ページ中のパラメータ入力値を変形するパラメータ変形部１１と、予め設定されている挿入文字列データ１２に基づいてＷｅｂアプリケーションにおいて脆弱性に起因するエラーを引き起こす可能性がないポジティブリクエストを生成するポジティブリクエスト生成部１３と、Ｗｅｂアプリケーションにおいて脆弱性に起因するエラーを引き起こす可能性があるネガティブリクエストを生成するネガティブリクエスト生成部１４と、ポジティブリクエスト生成部１３及びネガティブリクエスト生成部１４が生成したＨＴＴＰリクエスト（ポジティブリクエスト，ネガティブリクエスト）をＷｅｂサービス提供システム６０に送信するリクエスト送信部１５を備えている。
【００１５】
また、レスポンス解析部２０は、Ｗｅｂサービス提供システム６０からの応答（ＨＴＴＰレスポンス）を受信するレスポンス受信部２１と、ＨＴＴＰレスポンス中のステータス情報を抽出するステータス抽出部２２と、ＨＴＴＰレスポンス中のボディ部分のバイト長を抽出するレスポンス長抽出部２３と、ＨＴＴＰレスポンス中のヘッダ情報を抽出するヘッダ情報抽出部２４と、ＨＴＴＰレスポンス中の特殊文字列を抽出する特殊文字列抽出部２５と、ステータス抽出部２２〜特殊文字列抽出部２５が抽出したポジティブリクエストに対する各情報とネガティブリクエストに対する各情報を保持するレスポンス情報保存部２６と、レスポンス情報保存部２６に保持されているポジティブリクエストに対する各情報とネガティブリクエストに対する各情報とを比較するレスポンス情報比較部２７を備えている。
【００１６】
この検査装置の検査対象となるＷｅｂサービス提供システム６０は、例えば図２に示すように、ネットワーク８０経由で接続されるクライアント７０に対してアプリケーションサービスを提供するもので、Ｗｅｂアプリケーション６２が提供するアプリケーションサービスのフロントエンドとなるＷｅｂサーバ６１と、Ｗｅｂアプリケーション６２のバックエンドで動作するＤＢサーバ６３（データ保存部としてＤＢ６４を持つ），ＬＤＡＰサーバ６５等のサービス提供部を備えている。Ｗｅｂアプリケーション６２は、例えばＰＨＰ言語，Ｐｅｒｌ言語等のスクリプト言語の処理系（プログラム言語処理系）６６で実行されるプログラムから構成することができる。
【００１７】
このＷｅｂアプリケーション６２には、Ｗｅｂサービス提供システム６０が提供するサービスの種類に応じた処理を行う機能が実装されており、この機能に応じて、例えばＤＢサーバ６３に対するＳＱＬ文を発行するＳＱＬ発行部６２ａ、ＬＤＡＰサーバ６５に対するＬＤＡＰ問い合わせを発行するＬＤＡＰ発行部６２ｂ、当該Ｗｅｂアプリケーション６２が実行されているＷｅｂサービス提供システム６０のＯＳに対するコマンドを発行するコマンド発行部６２ｃ等の外部のプログラム等に対するアクセス等を行う処理部を備えている。また、プログラム言語処理系６６は、ＤＢサーバ６３に対する接続を行うライブラリ（ＤＢサーバ接続ＡＰＩ）６６ａと、ＬＤＡＰサーバ６５に対する接続を行うライブラリ（ＬＤＡＰサーバ接続ＡＰＩ）６６ｂと、サービス提供システム６０のＯＳに対するコマンドの発行等を行うライブラリ（ＯＳコマンド接続ＡＰＩ）６６ｃ等を備えている。
【００１８】
Ｗｅｂアプリケーション６２は、ユーザからのリクエストがある毎にプログラム言語処理系６６で実行される。ユーザからのリクエストがパラメータ入力値を持つ場合、入力に応じた処理が実行される。例えばバックエンドのＤＢサーバ６３と接続を行うアプリケーションでは、ユーザからの入力に応じて、ＳＱＬ発行部６２ａがＳＱＬ文を生成し、ＤＢサーバ接続ＡＰＩ６６ａを介してＤＢサーバ６３に供給される。ＤＢサーバ６３は、供給されたＳＱＬ文に応じた処理を実行し、実行結果をＤＢサーバ接続ＡＰＩ６６ａを介してＳＱＬ発行部６２ａに返す。
【００１９】
ところで、Ｗｅｂアプリケーション６２のＳＱＬ発行部６２ａが、ユーザからの入力に応じたＳＱＬ文を生成する際に、ユーザからのリクエスト中のパラメータ入力値にＳＱＬ文の特殊文字が含まれていると、本来意図したＳＱＬ文とは異なるＳＱＬ文が生成される可能性がある。このため、Ｗｅｂアプリケーション６２では、パラメータ入力値に含まれるＳＱＬ文の特殊文字を適切に処理する必要があるが、このような処理が適切に行われていないＷｅｂアプリケーションにはＳＱＬインジェクション脆弱性があることになる。
【００２０】
クライアント７０は、例えばＷｅｂサーバ６１を介してアプリケーションサービスを利用するＷｅｂブラウザ７１と、Ｗｅｂブラウザ７１の制御に応じて表示部７３に表示する表示画像（画面）を生成する表示制御部７２と、ユーザの指示を入力する入力部７４等を備えた、パーソナルコンピュータ・ＰＤＡあるいは携帯電話端末装置等の情報処理装置から構成されている。
【００２１】
図３は、このように構成されたＷｅｂサービス提供システム６０が提供するアプリケーションサービスにおいて、ユーザ名とパスワードを入力してログインを行うページの例である。このページには、例えばユーザ名を入力する入力欄と、パスワードを入力する入力欄と、ログインを指示するボタンが定義されている。図４は、このようなページを表示するためのＨＴＭＬの例である。
【００２２】
通常のＷｅｂアプリケーションとしての動作では、例えば図５に示すように、クライアント７０のユーザは、上述のような画面に対してユーザ名とパスワードを入力してログインボタンを押下する（Ｓ１０１）。これに応じて、Ｗｅｂブラウザ７１は、例えば図６に示すように、入力されたユーザ名とパスワードをパラメータとしてＨＴＴＰリクエストをＷｅｂサーバ６１に送信する（Ｓ１０２）。このようなＨＴＴＰリクエストを受信すると、Ｗｅｂサーバ６１は当該リクエストをＷｅｂアプリケーション６２に供給する（Ｓ１０３，Ｓ１０４）。Ｗｅｂアプリケーション６２は、供給されたＨＴＴＰリクエスト中のパラメータ（ユーザ名，パスワード）を用いてＤＢサーバ６３にＳＱＬ問い合わせを行う（Ｓ１０５，Ｓ１０６）。ＤＢ６４には、例えば図７に示すように、ユーザ毎にユーザ名（ｕｓｅｒｎａｍｅ）とパスワード（ｐａｓｓｗｏｒｄ）が対応付けられてＤＢ内に格納されている。Ｗｅｂアプリケーション６２からＳＱＬ問い合わせがあると、ＤＢサーバ６３は、これに応じて、ＤＢを照会し（Ｓ１０７）、問い合わせ結果をＷｅｂアプリケーション６２に供給する（Ｓ１０８）。なお、ユーザ名（ｕｓｅｒｎａｍｅ）とパスワード（ｐａｓｓｗｏｒｄ）に用いることができる文字の種類は、例えば英数字と特定の記号のみ等といったように予め決められている。
【００２３】
Ｗｅｂアプリケーション６２は、問い合わせ結果に応じたＨＴＭＬを生成し（Ｓ１０９）、Ｗｅｂサーバ６１に供給する（Ｓ１１０）。Ｗｅｂサーバ６１は、供給されたＨＴＭＬをＨＴＴＰレスポンスとしてＷｅｂブラウザ７１に送信する（Ｓ１１１，Ｓ１１２）。このようなＨＴＴＰレスポンスを受信すると、Ｗｅｂブラウザ７１は当該ＨＴＭＬに応じて、例えば図８あるいは図９に示すような応答画面を表示させる。なお、図８は、正しいユーザ名とパスワードの組み合わせを入力し、ログインが成功した場合の応答画面を示しており、図９は、ユーザ名とパスワードの組み合わせが正しくない場合の応答画面を示している。
【００２４】
（動作概要）
ところで、Ｗｅｂアプリケーション６２には、パラメータ入力値に特定の文字列が含まれていると、想定外の処理が実行されるインジェクション系脆弱性が存在する場合があるが、フロントエンドのＷｅｂサーバ６１の構成やＷｅｂアプリケーション６２の構成等によっては、単純にＷｅｂサーバ６１からの応答（ＨＴＴＰレスポンス）中の文字列とエラーが生じた場合の文字列のパターンを比較するだけでは脆弱性を検出できない場合もある。
【００２５】
Ｗｅｂサービス提供システム検査装置はクライアント７０と同様の環境に配置される。この検査装置では、脆弱性毎にパラメータの入力値を変形し、Ｗｅｂアプリケーションにおいて脆弱性に起因するエラーを引き起こす可能性がないポジティブリクエストとＷｅｂアプリケーションにおいて脆弱性に起因するエラーを引き起こす可能性があるネガティブリクエストを生成し、各々のリクエストに対する応答を比較して脆弱性の有無を判定するようにしている。
【００２６】
具体的には、例えば図１０に示すように、検査者が装置操作部３０を操作して入力したＷｅｂアプリケーション６２に対する正当なリクエストのデータ，対象となる脆弱性等を検査制御部４０が取得し（Ｓ１）、パラメータ変形部１１が、各々の脆弱性毎に、パラメータ入力値を変形してリクエストを生成する（Ｓ２〜Ｓ３）。このパラメータの変形では、ポジティブリクエスト生成部１３とネガティブリクエスト生成部１４によってリクエスト（ポジティブリクエストとネガティブリクエスト）を生成する。リクエストが生成されると、リクエスト送信部１５は、これをＷｅｂサービス提供システム６０に送信する（Ｓ４）。
【００２７】
このようなリクエストに応じたＷｅｂサービス提供システム６０の応答を取得すると（Ｓ５）、レスポンス解析部２０は、脆弱性の種類毎に、ポジティブリクエストに対する応答（ＨＴＴＰレスポンス）とネガティブリクエストに対する応答（ＨＴＴＰレスポンス）の特徴的な情報（後述のレスポンス長，ヘッダ情報，ステータス，特徴的な文字列等）を抽出する（Ｓ６）。さらに、レスポンス情報比較部２７はポジティブリクエストに対する応答の特徴的な情報とネガティブリクエストに対する応答の特徴的な情報のいずれか若しくはすべてを利用して比較し、この比較結果に応じて検査制御部４０が脆弱性の有無の判定を行う（Ｓ７）。
【００２８】
上述の図１０中のＳ１において、検査者は、まず、脆弱性検査を実施するＷｅｂアプリケーション６２に対する正当なリクエストのデータと正当なリクエストの送信先のＵＲＬ一覧と正当なリクエストに関連付けられたパラメータ一覧を、検査対象となる脆弱性毎に入力する。検査制御部４０は検査者が入力した各々の正当なリクエストのデータと各々の正当なリクエストの送信先のＵＲＬ一覧と各リクエストに関連付けられたパラメータ一覧を保持する。図１１に示すように、ＵＲＬ一覧は、例えば入力された正当なリクエストのパラメータに応じて、ＨＴＴＰリクエストを送信する先のＵＲＬ（ｕｒｌ １，ｕｒｌ ２）の一覧であり、例えば同図中に示す例ではｕｒｌ １に対するパラメータ一覧としてはパラメータ１−１，１−２が対応付けられており、ｕｒｌ ２に対するパラメータ一覧としてはパラメータ２−１，２−２が対応付けられている。
【００２９】
また、挿入文字列データ１２には、脆弱性の種類毎に、パラメータ入力値の変形文字列（ポジティブリクエストとネガティブリクエストに用いる文字列）が格納されており、これらの文字列を用いて、図１１中のパラメータ１−１に対して示すように、脆弱性の種類毎に脆弱性の検査を行う。
【００３０】
（動作詳細：ＳＱＬインジェクション脆弱性）
以下、ＳＱＬインジェクション脆弱性の場合を例に検査の詳細を説明する。
ＳＱＬインジェクション脆弱性を検査する場合には、例えば図１２に処理の概要を示すように、
（１）検査対象となるＵＲＬ（例えば“ｕｒｌ １”）に対してパラメータ入力値（例えば“パラメータ１−１”，“パラメータ１−２”）を変形したリクエスト（ポジティブリクエストとネガティブリクエスト）を複数生成し、
（２）各々のリクエストをサービス提供システム６０側に送信し、
（３）各々のリクエストに対するＷｅｂサービス提供システム６０のＨＴＴＰレスポンスを取得し、
（４）ポジティブリクエストに対するＨＴＴＰレスポンスとネガティブリクエストに対するＨＴＴＰレスポンスを比較し、ネガティブレスポンスだけから得られたＨＴＴＰレスポンスの有無を確認することによって行う。このＨＴＴＰレスポンスの比較は、各々のＨＴＴＰレスポンスから抽出した特徴的な情報のパターンを比較することによって行う。
【００３１】
図１２に示す手順をさらに具体的に示したのが図１３に示すフローチャートである。まず、検査制御部４０が、検査対象のリクエストを選択し（Ｓ１１）、検査対象の脆弱性（この場合ではＳＱＬインジェクション脆弱性）を選択すると（Ｓ１２）、リクエスト生成部１０は指定されたリクエストのパラメータを変形したリクエストを生成して指定されたＵＲＬ宛に送信する（Ｓ１３）。
【００３２】
このようなリクエストに対して、Ｗｅｂサービス提供システム６０からの応答（ＨＴＴＰレスポンス）を受信すると、レスポンス解析部２０は、このＨＴＴＰレスポンス中の特徴的な情報を抽出し、ポジティブリクエストに対するＨＴＴＰレスポンス（ポジティブレスポンス）のパターンのグループとネガティブリクエストに対するＨＴＴＰレスポンス（ネガティブレスポンス）のパターンのグループを作成する（Ｓ１４）。この後、レスポンス解析部２０は、各々のパターンのグループを比較し（Ｓ１５）、ネガティブレスポンスグループ内に、ポジティブレスポンスグループ中のパターンのいずれにも一致しないパターンがあれば脆弱性ありと判定し（Ｓ１６）、すべてのネガティブレスポンスグループのパターンがポジティブレスポンスグループ中のいずれかのパターンに一致すれば脆弱性なしと判定する（Ｓ１７）。
【００３３】
Ｓ１３では、リクエスト生成部１０のポジティブリクエスト生成部１３とネガティブリクエスト生成部１４において、各々挿入文字列データ１２を参照してポジティブリクエストとネガティブリクエストを生成し（Ｓ２１，Ｓ３１）、リクエスト送信部１５が、例えば図１４に示すように、レスポンス解析部２０側でどのリクエストに対する応答か区別できるようにＷｅｂサービス提供システム６０に送信する（Ｓ２２，Ｓ３２）。具体的には、例えばリクエスト送信部１５は、送信したリクエスト及び検査対象の脆弱性及びポジティブリクエストかネガティブリクエストかの種別を示す情報をレスポンス受信部２１に供給し、レスポンス受信部２１は、これらの情報に応じて各々のリクエストとこれらに対するレスポンスを対応付けておく。
【００３４】
また、Ｓ１４では、レスポンス解析部２０のレスポンス受信部２１は、Ｗｅｂサービス提供システム６０からの応答（ＨＴＴＰレスポンス）を受信し（Ｓ２３，Ｓ３３）、ステータス抽出部２２〜特殊文字列抽出部２５は、各々のＨＴＴＰレスポンスの特徴的な情報（応答パターン）を抽出し（Ｓ２４，Ｓ３４）、レスポンス情報保存部２６は各々のレスポンスパターンを作成する（Ｓ２５，Ｓ３５）。このように作成された各々のレスポンスパターンは、Ｓ１５において、レスポンス情報比較部２７による比較に用いられる。
【００３５】
（動作詳細：リクエスト生成）
Ｗｅｂアプリケーション６２に、ＳＱＬインジェクション脆弱性がある場合には、入力パラメータの値に、正当なリクエスト中では使用されない。例えば「’」，「−−」，「％」等の文字列が含まれている場合にエラーを生じる可能性があることが知られている。このため、ＳＱＬインジェクション脆弱性の検査用には、ネガティブリクエストを生成する文字列として例えば「’ ａｎｄ ． ａｎｄ ’１’＝’１」，「−−」，「％」等が選択されており、ポジティブリクエストを生成する文字列としてこれら以外の文字列であって正当なリクエスト中では使用されない文字種を含む文字列、例えば「＜」，「＞」，「／」，「！」等が選択されている。同様に、他の脆弱性に対してもネガティブリクエストを生成する文字列とポジティブリクエストを生成する文字列とが選択されている。これらの文字列は、正当なパラメータ入力値（例えば正当なユーザ名“ｊｏｈｎ”）の「前」，「途中」，「後」にこれらの文字列を挿入される。また、正当なパラメータ入力値を持つリクエスト及びパラメータの値を削除したリクエストもポジティブリクエストに含まれる。ただし、正当なパラメータ入力値のどこにこれらの文字列を挿入するかは、検査時間の短縮等の目的によって「前」のみにする等適宜変更するようにしてもよい。
【００３６】
テストデータを生成するためには、正当なリクエストが必要となる。具体的には、例えば図１５に示すように、上述の図３及び図４に示すような画面に対して正しい「ユーザ名」及び「パスワード」の組み合わせを入力した際のリクエストのデータを、検査者が予め生成して検査制御部４０に入力しておく。
【００３７】
また、テストデータの生成は、上述の正当なリクエストを、例えば図１６に示す処理によって加工することで生成される。このテストデータ生成処理では、例えば予め登録された挿入文字列データ１２を利用して正当なリクエストのデータからテストデータを生成する（Ｓ５２〜Ｓ５５）。
【００３８】
上述のように、検出する脆弱性毎に、ポジティブリクエストを生成するための文字列とネガティブリクエストを生成するための文字列が選択されている。検査者は予め、これらの文字列を用い、例えば図１７に示すように、正当なリクエスト中のパラメータ名及びその入力値を示す文字列（置換対象文字列“ｕｓｅｒｎａｍｅ＝ｊｏｈｎ”）と、この置換対象文字列中のパラメータ入力値を上述の文字列で置き換えた文字列（置換文字列）の組み合わせとして、挿入文字列データ１２を作成し、当該検査装置に入力しておく。なお、このような挿入文字列データ１２は、検査対象となるパラメータ毎、検査対象となる脆弱性毎に作成し、当該検査装置に入力しておく。なお、置換文字列がパラメータ名のみ、あるいは空白であるものは、パラメータ入力値がない状態、あるいはパラメータ名もない状態を示している。すなわち、置換対象文字列を置換文字列“ｕｓｅｒｎａｍｅ＝”で置換するとパラメータ入力値がない状態、置換対象文字列を置換文字列“”で置換するとパラメータ自体がない状態となる。
【００３９】
ポジティブリクエスト生成部１３及びネガティブリクエスト生成部１４は、これらの挿入文字列データ１２に従って、正当なリクエスト中の置換対象文字列を、各置換文字列で置換した複数のポジティブリクエストとネガティブリクエストのデータ（テストデータ）を生成する（Ｓ５３，Ｓ５４）。このようなテストデータは、対象となるパラメータ毎（例えばパスワード（ｐａｓｓｗｏｒｄ）等）に対して、対象となる脆弱性毎に生成する。
【００４０】
なお、図１７に示すように、挿入文字列データ１２として置換前後の文字列を定義しておく代わりに、図１８に示すように、変形の対象となるパラメータと当該パラメータの入力値の置換後の文字列のみを定義しておくようにしてもよい。この場合、パラメータ変形部１１は、正当なリクエストから置換対象のパラメータの入力値を置換文字列で置換してテストデータを生成する。さらに、パラメータ自体がない状態のテストデータは、パラメータ名とその入力値を削除することによって行う。
【００４１】
このように生成されたポジティブリクエストとネガティブリクエストのデータは、Ｗｅｂサーバ６１に送信される。このＨＴＴＰリクエストは、例えばステータス部，ヘッダ部、送信データ本体であるボディ部等から構成されている。
【００４２】
また、このようなＨＴＴＰリクエストに対するＷｅｂサービス提供システム６０からの応答（ＨＴＴＰレスポンス）は、例えば図１９（ＨＴＴＰレスポンス）に示すような構成になっている。これらのＨＴＴＰレスポンスは、例えばステータス部，ヘッダ部、ＨＴＭＬデータ本体であるボディ部等から構成されている。
【００４３】
上述のような構成のＨＴＴＰレスポンスは、Ｗｅｂサーバ６１からレスポンス受信部２１に供給される。供給されたＨＴＴＰレスポンスはレスポンス受信部２１からステータス抽出部２２〜特殊文字列抽出部２５に供給され、ステータス抽出部２２〜特殊文字列抽出部２５においてＨＴＴＰレスポンス中の特徴的な情報が抽出される。
【００４４】
（レスポンス長の抽出）
レスポンス長抽出部２３は、ＨＴＴＰレスポンスのボディ部分の長さを検出する。ＨＴＴＰレスポンスは、例えば上述の図１９に示すように、ヘッダ部分とボディ部分から構成されており、これらの部分は空白行により分割されている。レスポンス長抽出部２３では、空白行以降のＨＴＴＰレスポンスのボディ部分のバイト数をカウントし、レスポンス長とする。
【００４５】
ＨＴＴＰレスポンスのヘッダ部分にはボディ部分に含まれるバイト数を示すためのＣｏｎｔｅｎｔ−Ｌｅｎｇｔｈヘッダが含まれていることがあるが、まれにボディ部分の実際のバイト数と異なるバイト数が指定されていることがある。レスポンス長抽出部２３では、Ｃｏｎｔｅｎｔ−Ｌｅｎｇｔｈヘッダに示された値ではなく、実際に取得したＨＴＴＰレスポンスのボディ部分のバイト数をレスポンス長とする。なお、上述の図１９に示すレスポンスのボディ部分は、別途ＣＳＳファイルで指定されたデザインでボディ部分を表示するように構成されているが、レスポンス解析部２０では、レスポンスのボディ部分のみから特徴的な情報を抽出する。
【００４６】
例えば図２０及び図２１に示すＨＴＴＰレスポンスのレスポンス長を抽出すると、図２２に示すように、図２０のレスポンス１の場合では２６９バイト、図２１のレスポンス２の場合では、１６４バイトとなる。なお、動的に生成されるＨＴＭＬデータで構成される画面では、同一のＵＲＬに同一のパラメータ入力値でアクセスした場合でも、若干レスポンス長が異なる場合がある。このような場合には、レスポンス長による特徴的な差異があるかどうか判断する際の閾値として、例えばレスポンス長が５０％以上増減することとする。この閾値はＷｅｂアプリケーションによって変化させてもよい。
【００４７】
ところで、図２０と図２１は、いずれもポジティブリクエストに対してログインが失敗した際のＨＴＴＰレスポンス（ポジティブレスポンス）の例であるが、アプリケーションの作り込みの違いによって、レスポンス長が異なる例を示している。図２０に示す場合では、ログインが失敗した際に再度入力欄を有するログイン画面に戻るようにアプリケーションが構成されているが、図２１に示す場合では、ログインが失敗した際にその旨を表示する画面に戻り、ボタンが押下された後にログイン画面に戻るようにアプリケーションが構成されている。
【００４８】
（ヘッダ情報の抽出）
また、ヘッダ情報抽出部２４は、例えばＨＴＴＰレスポンス中のＬｏｃａｔｉｏｎヘッダとＳｅｔ−Ｃｏｏｋｉｅヘッダを抽出し、各々のヘッダの有無をヘッダ情報とする。Ｌｏｃａｔｉｏｎヘッダは、クライアントのリクエストを他のＵＲＬに転送したい場合に、次に取得するべきＵＲＬを指定する。また、Ｓｅｔ−Ｃｏｏｋｉｅヘッダは、新たなＣｏｏｋｉｅを設定するために付加される。Ｃｏｏｋｉｅはセッション管理に利用されるため、Ｓｅｔ−Ｃｏｏｋｉｅヘッダが含まれるということは、既存のセッションを破棄することを意味している。
【００４９】
これにより、例えば図２３及び図２４に示すようなＨＴＴＰレスポンスのヘッダ情報を抽出した結果は、図２５に示すようになる。なお、アプリケーションの作りこみによっては、遷移毎にＳｅｔ−Ｃｏｏｋｉｅヘッダが付加される（遷移毎にＣｏｏｋｉｅを変える）場合があるが、このような場合には、Ｓｅｔ−Ｃｏｏｋｉｅヘッダを抽出しないようにしてもよい。
【００５０】
（ＨＴＴＰステータスコードの抽出）
また、ステータス抽出部２２は、ＨＴＴＰレスポンス中のステータス部からステータスコードを抽出する。ＨＴＴＰのステータスコードは、以下のように、Ｗｅｂサービス提供システム６０内部でリクエストがどのように処理されたかを示している。
１ＸＸ：情報。サーバはリクエストを受信したが、最終結果はまだ利用可能でない。
２ＸＸ：成功。サーバはリクエストを正常に処理した。
３ＸＸ：リダイレクト。リクエストは別のＵＲＬにリダイレクトされる。
４ＸＸ：クライアントエラー。リクエストにエラーがあり正常に処理できなかった。
５ＸＸ：サーバエラー。サーバはリクエストを正常に処理できなかった。
なお、これらの処理結果は、脆弱性が原因とは限らないが、ステータスコードが異なれば、Ｗｅｂサービス提供システム６０内部の処理が異なることがわかる。
これにより、例えば図２６及び図２７に示すようなＨＴＴＰレスポンスのステータスコードを抽出した結果は、図２８に示すようになる。
【００５１】
（特定文字列の抽出）
特殊文字列抽出部２５は、例えば図２９に示すように、予め設定された特定の文字列がＨＴＴＰレスポンス内に存在するか否かを検出し、検出した文字列を抽出する。Ｗｅｂサービス提供システム６０側で脆弱性が原因のエラーが発生した場合、ＨＴＴＰレスポンスに「エラー」や「不正」「Ｅｒｒｏｒ」といった特徴的なメッセージが含まれることがあるため、このような特定の文字列を予め設定しておき、ＨＴＴＰレスポンス内にこれらの文字列が含まれる場合には抽出する。これにより、例えば図３０及び図３１に示すようなＨＴＴＰレスポンス中の特定文字列を抽出した結果は、図３２に示すようになる。
【００５２】
（脆弱性有無の判定）
ステータス抽出部２２〜特殊文字列抽出部２５は、上述のように、各々のポジティブレスポンス及び各々のネガティブレスポンス毎に、特徴的な情報を抽出し、レスポンス情報保存部２６に供給する。例えば図３３に示すように、登録ユーザ毎に、情報提供を行うＷｅｂアプリケーション６２では、例えば図３４（Ａ）に示すようなログイン画面に対してユーザが入力したユーザ名とパスワードを、ＤＢ６４に格納されている認証情報と照合し、ユーザ名とパスワードが正しい組み合わせであれば同図（Ｂ）に示すような情報提供サービスを提供し、ユーザ名とパスワードが正しくない場合には同図（Ｃ）に示すような再入力画面を表示させるＷｅｂアプリケーション６２を想定し、具体的なポジティブレスポンスとネガティブレスポンスについて説明する。
【００５３】
例えば図３４（Ａ）に示すログイン画面中で指定されたアドレス（ＵＲＬ）に対して、例えば上述の図１５に示すようなユーザ名とパスワードの組み合わせを含むリクエスト（ポジティブリクエスト１）が供給されると、Ｗｅｂアプリケーション６２のＳＱＬ発行部６２ａ（さらに具体的には、例えば同図中の斜線部の「パラメータチェック及びＳＱＬコマンド生成」処理等）は、ＤＢサーバ接続ＡＰＩ６６ａを介して、ユーザ名「ｊｏｈｎ」に対応するパスワードが「ｊｔｒ」であることを確認するＳＱＬ文を作成し、ＤＢサーバ６３に送信する。ＤＢサーバ６３は、供給されたＳＱＬ文に従って指定されたユーザ名「ｊｏｈｎ」に対応するパスワードが「ｊｔｒ」であるかを検索し、その結果をＷｅｂアプリケーション６２のＳＱＬ発行部６２ａに供給する。Ｗｅｂアプリケーション６２は検索結果が１件あればユーザ名とパスワードの組み合わせが正しいと判断する。クライアント７０側から供給されたユーザ名とパスワードの組み合わせが正しい場合には、Ｗｅｂアプリケーション６２は、上述の図１９に示すように、図３４（Ｂ）に示すページに対応するレスポンスデータを生成し、これをレスポンス解析部２０側に供給する。また、クライアント７０側から供給されたユーザ名とパスワードの組み合わせが誤っている場合、供給されたＳＱＬ文による検索結果は０件となる。このとき、Ｗｅｂアプリケーション６２は図３４（Ｃ）に示すページに対応するレスポンスデータを生成し、これをレスポンスレスポンス解析部２０側に供給する。
【００５４】
上述の図１５に示すリクエスト中のユーザ名「ｊｏｈｎ」をポジティブテスト文字列「＜ｊｏｈｎ」で置き換えたリクエスト（ポジティブリクエスト２）に対するレスポンスは、例えば図３５に示すようになる。同様に、図１５に示すリクエスト中のユーザ名「ｊｏｈｎ」をポジティブテスト文字列「／ｊｏｈｎ」で置き換えたリクエスト（ポジティブリクエスト４）に対するレスポンスは、例えば図３６に示すようになり、ポジティブテスト文字列「！ｊｏｈｎ」で置き換えたリクエスト（ポジティブリクエスト５）に対するレスポンスは、例えば図３７に示すようになる。
【００５５】
また、Ｗｅｂアプリケーション６２に脆弱性がある場合、図１５に示すリクエスト中のユーザ名「ｊｏｈｎ」をネガティブテスト文字列「’ ａｎｄ ． ａｎｄ ‘１’＝’１ｊｏｈｎ」で置き換えたリクエスト（ネガティブリクエスト１）に対するレスポンスは、例えば図３８に示すようになり、ネガティブテスト文字列「−−ｊｏｈｎ」で置き換えたリクエスト（ネガティブリクエスト２）に対するレスポンスは、例えば図３９に示すようになる。一方、Ｗｅｂアプリケーション６２に脆弱性がない場合、図１５に示すリクエスト中のユーザ名「ｊｏｈｎ」をネガティブテスト文字列「’ ａｎｄ ． ａｎｄ ‘１’＝’１ｊｏｈｎ」で置き換えたリクエスト（ネガティブリクエスト１）に対するレスポンスは、例えば図４０に示すようになり、ネガティブテスト文字列「−−ｊｏｈｎ」で置き換えたリクエスト（ネガティブリクエスト２）に対するレスポンスは、例えば図４１に示すようになる。
【００５６】
図４２及び図４３は、上述の図１９及び図３５〜図４１に示すような複雑なＨＴＴＰレスポンスを返すＷｅｂアプリケーション６２におけるポジティブレスポンスのグループの例とネガティブレスポンスのグループの例について、特徴的な情報の中のレスポンス長をまとめたものである。なお、図４２は脆弱性がある場合、図４３は脆弱性がない場合についてまとめたものである。
【００５７】
例えば特徴的な情報のいずれかのみ（例えばレスポンス長）を用い、ネガティブレスポンスグループ内の全てのパターン（この場合ではレスポンス長）が、ポジティブレスポンスグループ中のパターンのいずれかに一致しなければ「脆弱性あり」と判定することにしても、脆弱性の有無に応じた応答パターンの違いがあれば、ある程度の脆弱性の検出は可能である。このような判定方法では、例えば図４２に示す場合では、「ネガティブレスポンス２」と「ネガティブレスポンス３」のパターン「２６５７」は、ポジティブレスポンスグループ内に存在するが、「ネガティブレスポンス１」のパターン「５１１」はポジティブレスポンスグループ内には存在しないため、「脆弱性あり」と判定する。また、図４３に示す場合では、「ネガティブレスポンス１」〜「ネガティブレスポンス３」のいずれのパターンもポジティブレスポンスグループ内に存在するため、「脆弱性なし」と判定する。
【００５８】
このように、個々の特徴的な情報（例えば「レスポンス長」）を独立に比較することによっても、ある程度は、脆弱性の有無を検出することができるが、Ｗｅｂアプリケーション６２における応答画面の作りこみ次第では、例えば図４２中の「ネガティブレスポンス１」の応答のレスポンス長が、ポジティブレスポンスグループのいずれかの応答のレスポンス長と同一になってしまう場合も考えられる。
【００５９】
例えばＷｅｂアプリケーション６２の作りこみ次第では、上述の図３８（図３４（Ｄ）に示す画面に相当）に示すレスポンスの代わりに、例えば図４４に示すようなレスポンスを返す（図４５に示す画面に相当）ように構成することも充分考えられる。さらに、例えば図４６に示すように，「ネガティブレスポンス１」の応答のレスポンス長が、ポジティブレスポンスグループ内の応答のレスポンス長と同一になってしまう場合も考えられる。この場合、「ネガティブレスポンス１」〜「ネガティブレスポンス３」のパターンがいずれもポジティブレスポンスグループ内に存在するため、「脆弱性なし」と判定してしまう。
【００６０】
このような場合には、ポジティブレスポンスグループとネガティブレスポンスグループの特徴的な情報を複数用いて判定を行うことにより、脆弱性の検出の精度を向上させることができる。図４７及び図４８は、上述の図１９，図３５〜図３７及び図４４に示すポジティブレスポンスのグループの例とネガティブレスポンスのグループの例について、特徴的な情報のパターンをまとめたものである。なお、図４７は脆弱性がある場合、図４８は脆弱性がない場合についてまとめたものである。図４７に示す場合では、上述のようにレスポンス長のみで脆弱性を判断しようとすると「脆弱性なし」と判定してしまうが、このような場合にも、図４７のポジティブレスポンスグループ内には、ネガティブレスポンス１のように、レスポンス長が「２６６」であっても「Ｃｏｏｋｉｅ書き換えなし」で応答中に「エラー」という文字が含まれる組み合わせがないため、当該応答中の個々の特徴的な情報を総合的に比較して判定するようにすれば、Ｗｅｂアプリケーション６２の脆弱性を確実に検出することができる。
【００６１】
レスポンス情報比較部２７は、この特徴的な情報のパターンについて比較を行い、例えば図４７に示すように、ネガティブレスポンスグループ内に、ポジティブレスポンスグループ中のパターンのいずれにも一致しないパターンがあれば「脆弱性あり」と判定する。また、レスポンス情報比較部２７は、例えば図４８に示すように、すべてのネガティブレスポンスグループのパターンがポジティブレスポンスグループ中のいずれかのパターンに一致すれば「脆弱性なし」と判定する。これにより、この検査装置では、Ｗｅｂサービス提供システム６０において、Ｗｅｂアプリケーション６２のＳＱＬインジェクション脆弱性の検出の確実性を向上させることができる。
【００６２】
なお、ポジティブリクエストとネガティブリクエストを複数生成し、Ｗｅｂアプリケーション６２に供給しているのは、Ｗｅｂアプリケーション６２（例えば上述の図３３中のログイン処理部６２１等）の作りこみの違い（必要な機能の実装上の違い等）、プログラム言語処理系６６やＤＢサーバ６３の種類あるいはバージョンの違い等によって、同様な処理を行うＷｅｂアプリケーション６２であっても挙動が異なるためである。複数のポジティブリクエストと複数のネガティブリクエストに対する複数の応答の特徴的な情報を抽出して比較することにより、Ｗｅｂアプリケーション６２の挙動の違いがあっても、脆弱性の検出の確実性を向上させることができる。
【００６３】
（他の脆弱性の検査）
以上、ＳＱＬインジェクション脆弱性の検出の場合について説明したが、この検査装置では、Ｗｅｂアプリケーション６２の他のインジェクション系脆弱性の検出も行う。ＬＤＡＰインジェクション脆弱性は、Ｗｅｂアプリケーションのプログラム内部においてＬＤＡＰ文を生成する際に、ユーザからの入力がそのままＬＤＡＰ文に含まれることが問題となって発生する。例えば、各々のユーザ毎に住所録を提供するＷｅｂアプリケーション６２を想定する。このようなＷｅｂアプリケーションにおいて、例えば上述の図１５のようなリクエストに応じてＬＤＡＰ文を生成し、各々のユーザが登録した住所録を表示させるような場合には、ＬＤＡＰ発行部６２ｂが、リクエスト中のパラメータ「ｕｓｅｒｎａｍｅ」のユーザからの入力「ｊｏｈｎ」を取り出し、予め設定しておいたＬＤＡＰ文の一部に埋め込み、ＬＤＡＰサーバに処理を要求して、”ｊｏｈｎ”というｕｉｄで登録されている情報を取得するＬＤＡＰ文が生成される。
（ｕｉｄ＝ｊｏｈｎ）
このとき、Ｗｅｂアプリケーション６２にＬＤＡＰインジェクション脆弱性があると、ユーザからの入力に「ｊｏｈｎ）（｜（ｏｂｊｅｃｔｃｌａｓｓ＝＊）」が指定された場合に、以下のようＬＤＡＰ文が生成されてしまう。
（ｕｉｄ＝ｊｏｈｎ）（｜（ｏｂｊｅｃｔｃｌａｓｓ＝＊））
このように、ＬＤＡＰ文の生成に利用される特殊文字をユーザが指定し、これがそのままＬＤＡＰ文の生成に使用される場合にはＬＤＡＰインジェクション脆弱性が存在する。このような場合には、予め想定されたものとは異なるＬＤＡＰ文が生成され得るため、ユーザは任意のＬＤＡＰ文を実行可能である。
【００６４】
ＬＤＡＰサーバ６５にＬＤＡＰインジェクション脆弱性がある場合にエラーを生じる可能性がある文字は、例えば「（」、「）」として知られている。これらの文字列は、正当なリクエスト中では使用されない。このため、ＬＤＡＰインジェクション脆弱性の検査用には、ネガティブリクエストを生成する文字列として「（」、「）」が選択されており、ポジティブリクエストを生成する文字列としてこれら以外の正当なリクエスト中では使用されない文字種を含む文字列、例えば「＜」，「＞」，「／」，「！」が選択されている。これらの文字列は、正当な入力パラメータの「前」，「途中」，「後」に挿入される。また、正当なパラメータ入力値を持つリクエスト及びパラメータの値を削除したリクエストもポジティブリクエストに含まれる。ただし、正当な入力パラメータのどこにこれらの文字列を挿入するかは、検査時間の短縮等の目的によって「前」のみにするなどしてよい。これらの選択に従って、例えば図４９に示すように、上述の図１７と同様な形式でＬＤＡＰインジェクション脆弱性の検査用の挿入文字データが生成され、予め当該検査装置に入力されている。
【００６５】
また、ＸＰａｔｈインジェクション脆弱性は、Ｗｅｂアプリケーション６２のプログラム内部においてＸＰａｔｈ式を組み立てる際に、ユーザからの入力がそのままＸＰａｔｈ式に含まれることが問題となって発生する。例えば、各々のユーザ毎に住所録を提供するＷｅｂアプリケーション６２を想定する。このようなＷｅｂアプリケーションにおいて、例えば上述の図１５のようなリクエストに応じ応じてＸＰａｔｈ式を生成し、各々のユーザが登録した住所録を取り出すような場合には、Ｗｅｂアプリケーション６２のＸＰａｔｈ式発行部（図示せず）が、リクエスト中のパラメータ「ｕｓｅｒｎａｍｅ」のユーザからの入力「ｊｏｈｎ」を取り出し、予め設定しておいたＸＰａｔｈ式の一部に埋め込み、”ｊｏｈｎ”という属性値を持つ”ｎａｍｅ”ノードを取得するＸＰａｔｈ式を生成する。
ｓｔｒｉｎｇ（／／ｕｓｅｒ［ｎａｍｅ／ｔｅｘｔ（）＝’ｊｏｈｎ’］／ａｃｃｏｕｎｔ／ｔｅｘｔ（））
このとき、Ｗｅｂアプリケーション６２にＸＰａｔｈインジェクション脆弱性があると、ユーザからの入力に「’ ｏｒ ’１ ’＝’１」が指定された場合、以下のようなＸＰａｔｈ式が生成されてしまう。
ｓｔｒｉｎｇ（／／ｕｓｅｒ［ｎａｍｅ／ｔｅｘｔ（）＝’’ ｏｒ ’ １ ’＝’１’］／ａｃｃｏｕｎｔ／ｔｅｘｔ（））
このように、ＸＰａｔｈ式の生成に利用される特殊文字をユーザが指定し、これがそのままＸＰａｔｈ式の生成に使用される場合には、ＸＰａｔｈインジェクション脆弱性が発生する可能性がある。このような場合には、予め想定されたものとは異なるＸＰａｔｈ式が生成され得るため、ユーザは任意のＸＰａｔｈ式を実行可能である。
【００６６】
Ｘｐａｔｈインジェクション脆弱性がある場合にエラーを生じる可能性がある文字は、例えば「’」，「”」として知られている。これらの文字列は、正当なリクエスト中では使用されない。このため、Ｘｐａｔｈインジェクション脆弱性の検査用には、ネガティブリクエストを生成する文字列として「’ ＡＮＤ １＜＞２ ＡＮＤ ’１ ’＝’１」，「” ＡＮＤ １＜＞２ ＡＮＤ ”１”＝”１」が選択されており、ポジティブリクエストを生成する文字列としてこれら以外の正当なリクエスト中では使用されない文字種を含む文字列、例えば「＃」，「！」，「＊」が選択されている。これらの文字列は、正当な入力パラメータの「前」，「途中」，「後」にこれらの文字列を挿入される。また、正当なパラメータ入力値を持つリクエスト及びパラメータの値を削除したリクエストもポジティブリクエストに含まれる。ただし、正当な入力パラメータのどこにこれらの文字列を挿入するかは、検査時間の短縮等の目的によって「前」のみにするなどしてよい。これらの選択に従って、例えば図５０に示すように、上述の図１７と同様な形式でＸｐａｔｈインジェクション脆弱性の検査用の挿入文字データが生成され、予め当該検査装置に入力されている。
【００６７】
また、コマンドインジェクション脆弱性は、Ｗｅｂアプリケーション６２のプログラム内部においてＯＳのコマンドを組み立てる際に、ユーザからの入力がそのままＯＳコマンドに含まれることが問題となって発生する。例えば各々のユーザ毎にディレクトリを割り当てファイル共有サービスを提供するＷｅｂアプリケーション６２を想定する。このようなＷｅｂアプリケーション６２において、例えば上述の図１５のようなリクエストに応じ応じてＯＳのコマンドを生成し、各々のユーザのディレクトリ内のファイルのリストを表示させるような場合には、コマンド発行部６２ｃが、リクエスト中のパラメータ「ｕｓｅｒｎａｍｅ」のユーザからの入力「ｊｏｈｎ」を取り出し、予め設定しておいたＯＳコマンドの一部に埋め込み、ディレクトリ“ｊｏｈｎ”に格納されているファイルの一覧を取得するＯＳコマンドが生成される。
ｓｙｓｔｅｍ（“ｌｓ −ｌ ｊｏｈｎ”）
このとき、Ｗｅｂアプリケーション６２にコマンドインジェクション脆弱性があると、ユーザからの入力に「； ｃａｔ ／ｅｔｃ／ｐａｓｓｗｄ」が指定された場合に、以下のようなＯＳコマンドが生成されてしまう。
ｓｙｓｔｅｍ（“ｌｓ −ｌ ； ｃａｔ ／ｅｔｃ／ｐａｓｓｗｄ”）
このように、ＯＳコマンドの組み立てに利用される特殊文字をユーザが指定し、これがそのままＯＳコマンドの生成に使用される場合には、ＯＳコマンドインジェクション脆弱性が存在する。このような場合には、予め想定されたものとは異なるＯＳコマンドが生成され得るため、ユーザは任意のＯＳコマンドを実行可能である。
【００６８】
コマンドインジェクション脆弱性がある場合にエラーを生じる可能性がある文字は、例えば「＆」，「＆＆」，「；」，「｜」，「｜｜」として知られている。これらの文字列は、正当なリクエスト中では使用されない。このため、コマンドインジェクション脆弱性の検査用には、ネガティブリクエストを生成する文字列として「＆」，「＆＆」，「；」，「｜」，「｜｜」が選択されており、ポジティブリクエストを生成する文字列としてこれら以外の正当なリクエスト中では使用されない文字種を含む文字列、例えば「％」，「＃」が選択されている。これらの文字列は、正当な入力パラメータの「前」，「途中」，「後」にこれらの文字列を挿入される。また、正当なパラメータ入力値を持つリクエスト及びパラメータの値を削除したリクエストもポジティブリクエストに含まれる。ただし、正当な入力パラメータのどこにこれらの文字列を挿入するかは、検査時間の短縮等の目的によって「前」のみにするなどしてよい。これらの選択に従って、例えば図５１に示すように、上述の図１７と同様な形式でコマンドインジェクション脆弱性の検査用の挿入文字データが生成され、予め当該検査装置に入力されている。
【００６９】
また、ＳＳＩインジェクション脆弱性は、Ｗｅｂアプリケーション６２のプログラム内部においてＨＴＭＬデータを生成する際に、ユーザからの入力がそのまま含まれることが問題となって発生する。例えば、各々のユーザ毎にディレクトリを割り当て保存されているファイル共有サービスを提供するＷｅｂアプリケーション６２を想定する。このようなＷｅｂアプリケーション６２において、例えば上述の図１５のようなリクエストに応じてＳＳＩコマンドを生成し、各々のユーザのディレクトリ内のファイルのリストを表示させるような場合には、Ｗｅｂアプリケーション６２のＳＳＩ発行部（図示なし）は、リクエスト中のパラメータ「ｕｓｅｒｎａｍｅ」のユーザからの入力「ｊｏｈｎ」を取り出し、予め設定しておいたＳＳＩコマンドの一部に埋め込み、ディレクトリ“ｊｏｈｎ”に格納されているファイルの一覧を取得するＳＳＩコマンドを生成する。
＜！――＃ｅｘｅｃ ｃｍｄ＝“／ｂｉｎ／ｌｓ ｊｏｈｎ”――＞
このとき、Ｗｅｂアプリケーション６２にＳＳＩインジェクション脆弱性があると、例えばユーザからの入力が「ｊｏｈｎ” ――＞ ＜！――＃ｅｘｅｃ ｃｍｄ＝“／ｂｉｎ／ｃａｔ ／ｅｔｃ／ｐａｓｓｗｄ」である場合には、以下のようなＳＳＩコマンドが生成されてしまう。
＜！――＃ｅｘｅｃ ｃｍｄ＝“／ｂｉｎ／ｌｓ ｊｏｈｎ” ――＞ ＜！――＃ｅｘｅｃ ｃｍｄ＝“／ｂｉｎ／ｃａｔ ／ｅｔｃ／ｐａｓｓｗｄ”――＞
このように、ＳＳＩコマンドに利用される特殊文字をユーザが指定し、これがそのままＳＳＩコマンドの生成に使用される場合には、ＳＳＩインジェクション脆弱性が存在する。このような場合には、予め想定されたものとは異なるＳＳＩコマンドが生成され得るため、ユーザは任意のＳＳＩコマンドを実行可能である。
【００７０】
ＳＳＩインジェクション脆弱性がある場合にエラーを生じる可能性がある文字は、例えば「＜！――＃」として知られている。これらの文字列は、正当なリクエスト中では使用されない。このため、ＳＳＩインジェクション脆弱性の検査用には、ネガティブテスト文字列として文字列「＜！――＃」が選択されており、ポジティブテスト文字列としてこれら以外の正当なリクエスト中では使用されない文字種を含む文字列、例えば「／」，「！」，「−」，「＜！−−＃ｅｃｈｏ ｖａｒ＝“”――＞」が選択されている。これらの文字列は、正当な入力パラメータの「前」，「途中」，「後」にこれらの文字列を挿入される。ただし、正当な入力パラメータのどこにこれらの文字列を挿入するかは、検査時間の短縮等の目的によって「前」のみにするなどしてよい。これらの選択に従って、例えば図５２に示すように、上述の図１７と同様な形式でＳＳＩインジェクション脆弱性の検査用の挿入文字データが生成され、予め当該検査装置に入力されている。
【００７１】
ＬＤＡＰ脆弱性以下の他の脆弱性もＳＱＬインジェクションの場合と同様のフローにより脆弱性の検出を行うことができる。ポジティブリクエスト生成部１３及びネガティブリクエスト生成部１４は、挿入文字列データ１２内の上述の各脆弱性についての定義に従って、パラメータ変形部１１から指定されたパラメータ入力値を変形して、ポジティブリクエストとネガティブリクエストを生成し、リクエスト送信部１５がＷｅｂサーバ６１に送信する。これらのリクエストに対するＨＴＴＰレスポンスが供給されると、上述のＳＱＬインジェクションの場合と同様に、ステータス抽出部２２〜特殊文字列抽出部２５が各々の特徴的な情報を抽出し、レスポンス情報比較部２７が各応答パターンの比較を行う。これにより、ＳＱＬインジェクション脆弱性の検出の場合と同様に、Ｗｅｂアプリケーション６２自体に存在する脆弱性の検出の確実性を向上させることができる。
【００７２】
（効果）
上述のように、このＷｅｂサービス提供システム検査装置では、脆弱性毎に検査文字列を定義しておき、これに応じてパラメータ入力値を変化させたリクエストを生成し、これらのリクエストに対するＷｅｂサービス提供システム６０側のＨＴＴＰレスポンス中の特徴的な情報を抽出し、これらを総合的に判断して脆弱性の有無を判断しているため、Ｗｅｂアプリケーション６２等によって構成されるＷｅｂサービス提供システムに存在する脆弱性の検出の確実性を向上させることができる。
【００７３】
Ｗｅｂアプリケーション６２の作りこみ次第で、脆弱性が存在するにもかかわらず、脆弱性に起因する特徴的な文字列がＨＴＴＰレスポンスに含まれない場合がある。このような場合には、単なる特定の文字列との比較では脆弱性の有無を判定することができない。
【００７４】
これに対し、この検査装置では、ポジティブリクエストに対するＨＴＴＰレスポンスとネガティブリクエストに対するＨＴＴＰレスポンスから各々抽出した特徴的な情報（レスポンス長，ヘッダ情報，ステータス，特徴的な文字列等）のいずれか若しくはすべてを利用して複数のレスポンスを比較して脆弱性の有無を判定するため、脆弱性検出の確実性向上に寄与することができる。
【図面の簡単な説明】
【００７５】
【図１】本発明の一実施例に係る検査装置の構成例を示すブロック図である。
【図２】検査対象となるＷｅｂサービス提供システムの使用例を示す図である。
【図３】ログイン画面の例を示す図である。
【図４】ログイン画面を表示するためのＨＴＭＬソースの例を示す図である。
【図５】Ｗｅｂサービス提供システムによるサービス提供動作の例を示すシーケンス図である。
【図６】Ｗｅｂサーバに対するＨＴＴＰリクエストの例を示す図である。
【図７】正当なパラメータの例を示す図である。
【図８】正常応答の画面の例を示す図である。
【図９】エラー画面の例を示す図である。
【図１０】脆弱性検査全体の概要を示す図である。
【図１１】検査対象のアプリケーションにおけるＵＲＬ及びパラメータの例を示す図である。
【図１２】検査処理の概要を示す図である。
【図１３】検査処理の例を示すフローチャートである。
【図１４】リクエスト送信部による各リクエストの送信タイミングを示す図である。
【図１５】ＨＴＴＰリクエストの例を示す図である。
【図１６】パラメータ変形部１１による処理の例を示すフローチャートである。
【図１７】ポジティブリクエスト及びネガティブリクエストの生成に用いる挿入文字列データの例を示す図である。
【図１８】挿入文字列データの他の例を示す図である。
【図１９】ポジティブレスポンスの例を示す図である。
【図２０】ＨＴＴＰレスポンスの例を示す図である。
【図２１】ＨＴＴＰレスポンスの例を示す図である。
【図２２】ＨＴＴＰレスポンスのボディ部分のレスポンス長の例を示す図である。
【図２３】ＨＴＴＰレスポンスの例を示す図である。
【図２４】ＨＴＴＰレスポンスの例を示す図である。
【図２５】ＨＴＴＰレスポンスから抽出したヘッダ情報の例を示す図である。
【図２６】ＨＴＴＰレスポンスの例を示す図である。
【図２７】ＨＴＴＰレスポンスの例を示す図である。
【図２８】ＨＴＴＰレスポンスから抽出したステータスコードの例を示す図である。
【図２９】特定文字列のリストの例を示す図である。
【図３０】ＨＴＴＰレスポンスの例を示す図である。
【図３１】ＨＴＴＰレスポンスの例を示す図である。
【図３２】ＨＴＴＰレスポンスから抽出した特定文字列の例を示す図である。
【図３３】Ｗｅｂアプリケーション６２の構成例を示すブロック図である。
【図３４】Ｗｅｂアプリケーション６２の画面遷移の例を示す図である。
【図３５】ポジティブリクエストに対するＨＴＴＰレスポンスの例を示す図である。
【図３６】ポジティブリクエストに対するＨＴＴＰレスポンスの例を示す図である。
【図３７】ポジティブリクエストに対するＨＴＴＰレスポンスの例を示す図である。
【図３８】ネガティブリクエストに対するＨＴＴＰレスポンスの例を示す図である。
【図３９】ネガティブリクエストに対するＨＴＴＰレスポンスの例を示す図である。
【図４０】ネガティブリクエストに対するＨＴＴＰレスポンスの例を示す図である。
【図４１】ネガティブリクエストに対するＨＴＴＰレスポンスの例を示す図である。
【図４２】レスポンス情報保存部に保持される特徴的な情報のパターンの例を示す図である。
【図４３】レスポンス情報保存部に保持される特徴的な情報のパターンの例を示す図である。
【図４４】ネガティブリクエストに対するＨＴＴＰレスポンスの他の例を示す図である。
【図４５】前記ＨＴＴＰレスポンスに応じて表示される画面の例を示す図である。
【図４６】レスポンス情報保存部に保持される特徴的な情報のパターンの例を示す図である。
【図４７】レスポンス情報保存部に保持される特徴的な情報のパターンの例を示す図である。
【図４８】レスポンス情報保存部に保持される特徴的な情報のパターンの例を示す図である。
【図４９】ポジティブリクエスト及びネガティブリクエストの生成に用いる挿入文字列データの他の例を示す図である。
【図５０】ポジティブリクエスト及びネガティブリクエストの生成に用いる挿入文字列データの他の例を示す図である。
【図５１】ポジティブリクエスト及びネガティブリクエストの生成に用いる挿入文字列データの他の例を示す図である。
【図５２】ポジティブリクエスト及びネガティブリクエストの生成に用いる挿入文字列データの他の例を示す図である。
【図５３】従来の脆弱性検出方法の例を示す図である。
【図５４】ＨＴＴＰレスポンスに応じて表示される画面の例を示す図である。
【図５５】ＨＴＴＰレスポンスに応じて表示される画面の例を示す図である。
【符号の説明】
【００７６】
１０…リクエスト生成部、１１…パラメータ変形部、１２…リクエスト生成パターンデータ、１３…ポジティブリクエスト生成部、１４…ネガティブリクエスト生成部、１５…リクエスト送信部、２０…レスポンス解析部、２１…レスポンス受信部、２２…ステータス抽出部、２３…レスポンス長抽出部、２４…ヘッダ情報抽出部、２５…特殊文字列抽出部、２６…レスポンス情報保存部、２７…レスポンス情報比較部、６０…Ｗｅｂサービス提供システム、６１…Ｗｅｂサーバ、６２…Ｗｅｂアプリケーション、６３…ＤＢサーバ
【特許請求の範囲】
【請求項１】
Ｗｅｂサーバを介してアプリケーションサービスを提供するＷｅｂサービス提供システムの検査を行うＷｅｂサービス提供システム検査装置であって、
正当なリクエスト中のパラメータを予め設定されたポジティブリクエスト文字列に基づいて変形して複数のポジティブリクエストを生成するポジティブリクエスト生成手段と、
正当なリクエスト中のパラメータを予め設定されたネガティブリクエスト文字列に基づいて変形して複数のネガティブリクエストを生成するネガティブリクエスト生成手段と、
前記各ポジティブリクエストと前記各ネガティブリクエストを前記Ｗｅｂサービス提供システムに供給する供給手段と、
前記各ポジティブリクエストと前記各ネガティブリクエストに対する前記Ｗｅｂサービス提供システムの応答を取得する取得手段と、
取得した前記各ポジティブリクエストと前記各ネガティブリクエストに対する前記Ｗｅｂサービス提供システムの応答中の特徴的な情報（応答パターン）を抽出する特徴抽出手段と、
前記ネガティブリクエストに対する前記応答パターンのいずれかが、前記ポジティブリクエストに対するどの応答パターンとも一致しないときに脆弱性が存在すると判定する判定手段と
を備えることを特徴とするＷｅｂサービス提供システム検査装置。
【請求項２】
前記応答中の特徴的な情報として、
前記応答のレスポンス長
前記応答に含まれるヘッダ情報
前記応答に含まれるステータスコード
前記応答に含まれる予め規定した特定の文字列
のいずれかを用いることを特徴とする請求項１記載のＷｅｂサービス提供システム検査装置。
【請求項３】
前記応答中の特徴的な情報として、
前記応答のレスポンス長及び前記応答に含まれるヘッダ情報及び前記応答に含まれるステータスコード及び前記応答に含まれる予め規定した特定の文字列を用いることを特徴とする請求項１記載のＷｅｂサービス提供システム検査装置。
【請求項４】
Ｗｅｂサーバを介してアプリケーションサービスを提供するＷｅｂサービス提供システムの検査を行うＷｅｂサービス提供システム検査プログラムであって、
正当なリクエスト中のパラメータを予め設定されたポジティブリクエスト文字列に基づいて変形して複数のポジティブリクエストを生成するポジティブリクエスト生成ステップと、
正当なリクエスト中のパラメータを予め設定されたネガティブリクエスト文字列に基づいて変形して複数のネガティブリクエストを生成するネガティブリクエスト生成ステップと、
前記各ポジティブリクエストと前記各ネガティブリクエストを前記Ｗｅｂサービス提供システムに供給する供給ステップと、
前記各ポジティブリクエストと前記各ネガティブリクエストに対する前記Ｗｅｂサービス提供システムの応答を取得する取得ステップと、
取得した前記各ポジティブリクエストと前記各ネガティブリクエストに対する前記Ｗｅｂサービス提供システムの応答中の特徴的な情報（応答パターン）を抽出する特徴抽出ステップと、
前記ネガティブリクエストに対する前記応答パターンのいずれかが、前記ポジティブリクエストに対するどの応答パターンとも一致しないときに脆弱性が存在すると判定する判定ステップと
を有することを特徴とするＷｅｂサービス提供システム検査プログラム。
【請求項１】
Ｗｅｂサーバを介してアプリケーションサービスを提供するＷｅｂサービス提供システムの検査を行うＷｅｂサービス提供システム検査装置であって、
正当なリクエスト中のパラメータを予め設定されたポジティブリクエスト文字列に基づいて変形して複数のポジティブリクエストを生成するポジティブリクエスト生成手段と、
正当なリクエスト中のパラメータを予め設定されたネガティブリクエスト文字列に基づいて変形して複数のネガティブリクエストを生成するネガティブリクエスト生成手段と、
前記各ポジティブリクエストと前記各ネガティブリクエストを前記Ｗｅｂサービス提供システムに供給する供給手段と、
前記各ポジティブリクエストと前記各ネガティブリクエストに対する前記Ｗｅｂサービス提供システムの応答を取得する取得手段と、
取得した前記各ポジティブリクエストと前記各ネガティブリクエストに対する前記Ｗｅｂサービス提供システムの応答中の特徴的な情報（応答パターン）を抽出する特徴抽出手段と、
前記ネガティブリクエストに対する前記応答パターンのいずれかが、前記ポジティブリクエストに対するどの応答パターンとも一致しないときに脆弱性が存在すると判定する判定手段と
を備えることを特徴とするＷｅｂサービス提供システム検査装置。
【請求項２】
前記応答中の特徴的な情報として、
前記応答のレスポンス長
前記応答に含まれるヘッダ情報
前記応答に含まれるステータスコード
前記応答に含まれる予め規定した特定の文字列
のいずれかを用いることを特徴とする請求項１記載のＷｅｂサービス提供システム検査装置。
【請求項３】
前記応答中の特徴的な情報として、
前記応答のレスポンス長及び前記応答に含まれるヘッダ情報及び前記応答に含まれるステータスコード及び前記応答に含まれる予め規定した特定の文字列を用いることを特徴とする請求項１記載のＷｅｂサービス提供システム検査装置。
【請求項４】
Ｗｅｂサーバを介してアプリケーションサービスを提供するＷｅｂサービス提供システムの検査を行うＷｅｂサービス提供システム検査プログラムであって、
正当なリクエスト中のパラメータを予め設定されたポジティブリクエスト文字列に基づいて変形して複数のポジティブリクエストを生成するポジティブリクエスト生成ステップと、
正当なリクエスト中のパラメータを予め設定されたネガティブリクエスト文字列に基づいて変形して複数のネガティブリクエストを生成するネガティブリクエスト生成ステップと、
前記各ポジティブリクエストと前記各ネガティブリクエストを前記Ｗｅｂサービス提供システムに供給する供給ステップと、
前記各ポジティブリクエストと前記各ネガティブリクエストに対する前記Ｗｅｂサービス提供システムの応答を取得する取得ステップと、
取得した前記各ポジティブリクエストと前記各ネガティブリクエストに対する前記Ｗｅｂサービス提供システムの応答中の特徴的な情報（応答パターン）を抽出する特徴抽出ステップと、
前記ネガティブリクエストに対する前記応答パターンのいずれかが、前記ポジティブリクエストに対するどの応答パターンとも一致しないときに脆弱性が存在すると判定する判定ステップと
を有することを特徴とするＷｅｂサービス提供システム検査プログラム。
【図１】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図１２】
【図１３】
【図１４】
【図１５】
【図１６】
【図１７】
【図１８】
【図１９】
【図２０】
【図２１】
【図２２】
【図２３】
【図２４】
【図２５】
【図２６】
【図２７】
【図２８】
【図２９】
【図３０】
【図３１】
【図３２】
【図３３】
【図３４】
【図３５】
【図３６】
【図３７】
【図３８】
【図３９】
【図４０】
【図４１】
【図４２】
【図４３】
【図４４】
【図４５】
【図４６】
【図４７】
【図４８】
【図４９】
【図５０】
【図５１】
【図５２】
【図５３】
【図５４】
【図５５】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図１２】
【図１３】
【図１４】
【図１５】
【図１６】
【図１７】
【図１８】
【図１９】
【図２０】
【図２１】
【図２２】
【図２３】
【図２４】
【図２５】
【図２６】
【図２７】
【図２８】
【図２９】
【図３０】
【図３１】
【図３２】
【図３３】
【図３４】
【図３５】
【図３６】
【図３７】
【図３８】
【図３９】
【図４０】
【図４１】
【図４２】
【図４３】
【図４４】
【図４５】
【図４６】
【図４７】
【図４８】
【図４９】
【図５０】
【図５１】
【図５２】
【図５３】
【図５４】
【図５５】
【公開番号】特開２００８−２９９５４０（Ｐ２００８−２９９５４０Ａ）
【公開日】平成２０年１２月１１日（２００８．１２．１１）
【国際特許分類】
【出願番号】特願２００７−１４４１１６（Ｐ２００７−１４４１１６）
【出願日】平成１９年５月３０日（２００７．５．３０）
【出願人】（５０７１７７８４７）株式会社ファイブドライブ (2)
【Ｆターム（参考）】
【公開日】平成２０年１２月１１日（２００８．１２．１１）
【国際特許分類】
【出願日】平成１９年５月３０日（２００７．５．３０）
【出願人】（５０７１７７８４７）株式会社ファイブドライブ (2)
【Ｆターム（参考）】
[ Back to top ]