(57)【特許請求の範囲】
【請求項１】
所定のリクエストを受信した場合に他の機能を制御する文字列であるコマンド文字列を所定の構文に基づいて生成するサーバ装置の脆弱性を判定する脆弱性判定システムにおいて、
所定の文字列を含めることが可能なリクエストであって前記サーバ装置へ送信される第１リクエストを生成する元となる第１リクエスト生成用情報と、第１リクエストが所定の文字列を含む場合に第１リクエストの後に前記サーバ装置へ送信されることにより第１リクエストが含む所定の文字列と同一の文字列を含むコマンド文字列を前記サーバ装置に生成させる第２リクエストを生成する元となる第２リクエスト生成用情報とを一対として格納する一対情報格納部と、
前記一対情報格納部が格納する一対のうちの第１リクエスト生成用情報から第１リクエストを生成し、第２リクエスト生成用情報から第２リクエストを生成する正常リクエスト生成部と、
前記正常リクエスト生成部が生成した第１リクエストに前記所定の文字列と異なるとともに前記サーバ装置の脆弱性を検査する検査用の文字列を含めて検査リクエストを生成し、生成した検査リクエストと前記正常リクエスト生成部が生成した第２リクエストとを、検査リクエスト、第２リクエストの順で前記サーバ装置に送信する検査リクエスト生成部と
を備えた検査装置と、
前記サーバ装置がコマンド文字列を生成するかどうか監視してコマンド文字列を検出するコマンド文字列検出部と、
前記コマンド文字列検出部がコマンド文字列を検出した場合に、検出されたコマンド文字列に構文誤りがあるかどうかを解析して構文誤りの有無を示す構文誤り検出情報をメモリに記憶する構文解析部と、
前記構文解析部が前記メモリに記憶した構文誤り検出情報を要求する要求情報に応答して、前記メモリに記憶された構文誤り検出情報を送信する応答部と
を備えた監視装置と
を備え、
前記検査装置の検査リクエスト生成部は、
前記監視装置の前記構文解析部が前記メモリに記憶した構文誤り検出情報を前記監視装置に要求することにより、前記監視装置の前記応答部から構文誤り検出情報を取得し、取得した構文誤り検出情報に基づいて、前記サーバ装置が脆弱かどうかを判定することを特徴とする脆弱性判定システム。
【請求項２】
所定のリクエストを受信した場合に他の機能を制御する文字列であるコマンド文字列を所定の構文に基づいて生成するサーバ装置の脆弱性を検査する検査装置において、
所定の文字列を含めることが可能なリクエストであって前記サーバ装置へ送信される第１リクエストを生成する元となる第１リクエスト生成用情報と、第１リクエストが所定の文字列を含む場合に第１リクエストの後に前記サーバ装置へ送信されることにより第１リクエストが含む所定の文字列と同一の文字列を含むコマンド文字列を前記サーバ装置に生成させる第２リクエストを生成する元となる第２リクエスト生成用情報とを一対として格納する一対情報格納部と、
前記一対情報格納部が格納する一対のうちの第１リクエスト生成用情報から第１リクエストを生成し、第２リクエスト生成用情報から第２リクエストを生成する正常リクエスト生成部と、
前記正常リクエスト生成部が生成した第１リクエストに前記所定の文字列と異なるとともに前記サーバ装置の脆弱性を検査する検査用の文字列を含めて検査リクエストを生成し、生成した検査リクエストと前記正常リクエスト生成部が生成した第２リクエストとを、検査リクエスト、第２リクエストの順で前記サーバ装置に送信する検査リクエスト生成部と
を備えたことを特徴とする検査装置。
【請求項３】
前記検査リクエスト生成部は、
前記サーバ装置がコマンド文字列を生成するかどうか監視してコマンド文字列を検出した場合に検出したコマンド文字列に構文誤りがあるかどうかを解析して構文誤りの有無を示す構文誤り検出情報を記憶する監視装置から構文誤り検出情報を取得し、取得した構文誤り検出情報に基づいて、前記サーバ装置が脆弱かどうかを判定することを特徴とする請求項２記載の検査装置。
【発明の詳細な説明】
【技術分野】
【０００１】
この発明は、Ｗｅｂアプリケーションの脆弱性の有無を診断するシステムに関するものである。
【背景技術】
【０００２】
Ｗｅｂアプリケーション（Ｗｅｂアプリケーションプログラム）とは、Ｗｅｂサーバ上で動作し、Ｍｉｃｒｏｓｏｆｔ社のＩｎｔｅｒｎｅｔ  Ｅｘｐｌｏｒｅｒ（登録商標）等のＷｅｂブラウザソフトに表示されるＷｅｂページ上のフォームを操作することで利用可能なサービス（あるいはサービスを提供するプログラム）である。フォーム上で入力されたデータは、ＨＴＴＰ（Ｈｙｐｅｒ  Ｔｅｘｔ  Ｔｒａｎｓｆｅｒ  Ｐｒｏｔｏｃｏｌ）プロトコルを通じてＷｅｂアプリケーションへ送信される。
【０００３】
フォームから入力されるデータ以外にも、ブラウザからＷｅｂアプリケーションへ送信されるデータが幾つか存在する。代表的なものとしては、Ｃｏｏｋｉｅと呼ばれるデータであるが、他にもＨＴＴＰリクエスト中のＲｅｆｅｒｅｒヘッダやＵｓｅｒ−Ａｇｅｎｔヘッダ等を入力として使用するＷｅｂアプリケーションもある。
【０００４】
クライアント端末からのデータを受信したＷｅｂアプリケーション（Ｗｅｂアプリケーションプログラムを実行するサーバ装置）は、サービスを実現するために、必要に応じてＤＢ（Ｄａｔａ  Ｂａｓｅ）サーバ等のバックエンドサーバを呼び出す。一般に、バックエンドサーバの操作は、Ｗｅｂアプリケーションがクライアントからの入力データをもとにしてバックエンドサーバを操作するための文字列（以下「コマンド文字列」と呼ぶ）を作成し、その「コマンド文字列」をバックエンドサーバに送信することで行われる。
【０００５】
このとき、もしＷｅｂアプリケーションにおけるクライアントデータの入力チェックに問題がある場合には、Ｗｅｂアプリケーション（サーバ装置）が悪意のクライアントデータを受信した際に、Ｗｅｂアプリケーション設計者の意図しなかった「コマンド文字列」が生成され、その結果セキュリティ上問題のある誤動作が発生する場合がある。このような脆弱性の一種としてはＳＱＬ文に不正な命令が挿入されてしまうＳＱＬインジェクション脆弱性が代表的である。
【０００６】
Ｗｅｂアプリケーションの脆弱性診断は、Ｗｅｂアプリケーションに入力されるデータに擬似攻撃データを含ませたリクエストを送信し、そのリクエストに対するＷｅｂアプリケーションの応答にセキュリティホールの存在を示唆するような痕跡が無いかどうかを解析することで実施される。代表的な製品としては米国Ｓａｎｃｔｕｍ社のＡｐｐＳｃａｎ（登録商標）を挙げることができる（例えば非特許文献１）。
【０００７】
図２０を参照しながら、従来のＷｅｂアプリケーションの脆弱性診断システムの動作について述べる。
（１）システムは、まず、Ｗｅｂアプリケーションが受理するような正しいリクエストを雛形とし、それを改変することで、擬似攻撃リクエスト（診断リクエスト）を生成する。擬似攻撃は、もし脆弱性が存在していた場合に、Ｗｅｂアプリケーション内で生成される「コマンド文字列」に構文エラーを発生させるようなデータが選択される。
（２）診断リクエストの送信後、診断システム（診断ツール）は、Ｗｅｂアプリケーション（Ｗｅｂサーバ）からのレスポンス（応答）を解析し、エラーの発生をクライアントに通知するＨＴＭＬ（Ｈｙｐｅｒ  Ｔｅｘｔ  Ｍａｒｋｕｐ  Ｌａｎｇｕａｇｅ）が含まれているか、例えば「エラー」等のキーワードの検索を行うことで、脆弱性の有無を判断する。
【０００８】
以上のように、従来のＷｅｂアプリケーション診断装置（あるいは脆弱性診断システム）では、診断対象であるＷｅｂサーバからのＨＴＴＰレスポンスの内容のみで脆弱性の判定を行っており、「コマンド文字列」の構文エラーが発生した場合に、Ｗｅｂアプリケーション（Ｗｅｂサーバ）から返されるＨＴＭＬにエラーを示す情報が含まれている必要があった。
【０００９】
しかし、実際にどのようなＨＴＭＬが返されるかはＷｅｂアプリケーション内のエラー処理の実装に依存する。
このため、
（１）その実装によっては、脆弱性が存在してもＨＴＴＰレスポンスのＨＴＭＬ内にそれ（脆弱性の存在痕跡）が報告されず、結果として脆弱性の検出漏れを起こしてしまうという課題があった。
（２）また、Ｗｅｂアプリケーションに送信したＨＴＴＰリクエスト内の情報が、いつバックエンドサーバに渡されるかが不明であるため、複数のページ間にまたがった脆弱性の検出が不可能であった。
【非特許文献１】「ＳＡＮＣＴＵＭ  ＡｐｐＳｃａｎＴＭ  ３．５  Ｗｈｉｔｅ  Ｐａｐｅｒ」
【発明の開示】
【発明が解決しようとする課題】
【００１０】
本発明は、ＨＴＴＰレスポンスのＨＴＭＬ内に脆弱性の存在が現れない場合であっても、脆弱性を検出する手段を提供する。また複数のページ間にまたがった脆弱性の検出を可能とする手段を提供することを目的とする。
【課題を解決するための手段】
【００１１】
本発明の脆弱性判定システムは、
所定のリクエストを受信した場合に他の機能を制御する文字列であるコマンド文字列を所定の構文に基づいて生成するサーバ装置の脆弱性を判定する脆弱性判定システムにおいて、
前記サーバ装置の脆弱性を検査する検査リクエストを生成して前記サーバ装置に送信する検査リクエスト生成部を備えた検査装置と、
前記サーバ装置がコマンド文字列を生成するかどうか監視してコマンド文字列を検出するコマンド文字列検出部と、
前記コマンド文字列検出部がコマンド文字列を検出した場合に、検出されたコマンド文字列に構文誤りがあるかどうかを解析して構文誤りの有無を示す構文誤り検出情報をメモリに記憶する構文解析部と、
前記構文解析部が前記メモリに記憶した構文誤り検出情報を要求する要求情報に応答して、前記メモリに記憶された構文誤り検出情報を送信する応答部と
を備えた監視装置と
を備え、
前記検査装置の検査リクエスト生成部は、
前記監視装置の前記構文解析部が前記メモリに記憶した構文誤り検出情報を前記監視装置に要求することにより、前記監視装置の前記応答部から構文誤り検出情報を受信し、受信した構文誤り検出情報に基づいて、前記サーバ装置が脆弱かどうかを判定することを特徴とする。
【発明の効果】
【００１２】
本発明により、リクエストに応答する応答レスポンスに脆弱性の存在が現れない場合であっても、脆弱性を検出することが可能になる。
【発明を実施するための最良の形態】
【００１３】
実施の形態１．
図１〜図６を用いて実施の形態１を説明する。実施の形態１は、脆弱性の診断対象である診断対象Ｗｅｂサーバ２００から、バックエンドサーバ４００に送信される「コマンド文字列」を監視する通信モニタ装置３０１を備えた脆弱性診断システム１０００に関する。
【００１４】
脆弱性診断システム１０００は、Ｗｅｂアプリケーションプログラム（以下、Ｗｅｂアプリケーションという場合がある）の脆弱性を診断する。このＷｅｂアプリケーションプログラムは、コンピュータである診断対象Ｗｅｂサーバ２００により実行される。よって、「Ｗｅｂアプリケーションの脆弱性診断」は、「診断対象Ｗｅｂサーバ２００の脆弱性診断」と同じ内容である。
【００１５】
また、以下の実施の形態において使用する「コマンド文字列」とは、診断対象Ｗｅｂサーバ２００が所定のリクエストを受信した場合に生成する文字列であって、「他の機能を制御する文字列」である。以下の実施の形態では、診断対象Ｗｅｂサーバ２００は、バックエンドサーバ４００を制御する「コマンド文字列」を生成しているが、これは「他の機能を制御する」場合の一例である。また、「コマンド文字列」を発生させる「所定のリクエスト」とは、後述する「コマンド発生リクエスト」である。
【００１６】
図１は、実施の形態１の脆弱性診断システム１０００（脆弱性判定システム）の構成を示す図である。脆弱性診断システム１０００は、診断装置１０１（検査装置）と通信モニタ装置３０１（監視装置）とを備える。診断装置１０１は、診断対象Ｗｅｂサーバ２００（サーバ装置）にリクエストを送信し、またそのレスポンス（応答）を受信する。
【００１７】
通信モニタ装置３０１は、診断対象Ｗｅｂサーバ２００がＤＢサーバ等であるバックエンドサーバ４００に送信する「コマンド文字列」を監視して検出し、監視結果を診断装置１０１に送信する。
【００１８】
図２は、診断装置１０１の構成を示すブロック図である。診断装置１０１は、検査リクエスト生成部１１１と、正常リクエスト生成部１５と、状態保存部１６と、サイト構造情報保存部１７とを備える。検査リクエスト生成部１１１は、検査実施部１１と、リクエスト送信部１２と、レスポンス受信部１３と、監視結果要求部１４とを備える。診断装置１０１は、ネットワークを介して診断対象Ｗｅｂサーバ２００及び通信モニタ装置３０１に接続されている。
【００１９】
図３は、通信モニタ装置３０１の構成を示すブロック図である。通信モニタ装置３０１は、通信監視部３１（コマンド文字列検出部）と、構文解析部３２と、監視結果応答部３３（応答部）とを備える。通信モニタ装置３０１は、ネットワークを介して診断装置１０１と接続されていると同時に、診断対象Ｗｅｂサーバ２００とバックエンドサーバ４００との通信を傍受できる状態にある。
【００２０】
図４〜図６を用いて、脆弱性診断システム１０００の動作を説明する。
（１）まず、図４に示すようにＳ１０１において、検査実施者は、診断対象となるＷｅｂサイトの「サイト構造情報」を収集し、診断装置１０１の備えるサイト構造情報保存部１７に「サイト構造情報」を保存する。
【００２１】
ここで「サイト構造情報」とは、図５に示すように、診断対象となるサイトを構成するページを頂点とし、接続されているページ間に有向辺を張ることで構成される有向グラフとして表現される。辺には属性として、ＵＲＬ（Ｕｎｉｆｏｒｍ  Ｒｅｓｏｕｒｃｅ  Ｌｏｃａｔｏｒ）やフォームに与える情報等のページ遷移に必要な情報（以下、「遷移情報」と呼ぶ）が付与されている。この「サイト構造情報」を収集する手段は問わない。例えば、ユーザによって操作されるブラウザが送信するＨＴＴＰリクエストをプロキシサーバ等の内部で記録する方法等が考えられる。
【００２２】
次に、Ｓ１０２において、診断対象Ｗｅｂサーバ２００の稼動しているネットワーク上で通信モニタ装置３０１を起動する。なお、通信モニタ装置の起動後に「サイト構造情報」を収集しても構わない。通信モニタ装置３０１は、診断対象Ｗｅｂサーバ２００とバックエンドサーバ４００との通信を傍受できるネットワーク上に接続されていなければならない。
【００２３】
「サイト構造情報」の収集、及び通信モニタ装置３０１の起動を完了後、実際の脆弱性の診断を開始する。脆弱性の診断は、診断装置１０１内の検査実施部１１により制御される。以下に、図５、図６を用いて、診断装置１０１の動作を説明する。
【００２４】
はじめに、検査実施部１１は、サイト構造情報保存部１７に格納されている「グラフ情報」（サイト構造情報）から診断対象として一つの辺（以下、選択辺という場合がある）を選択し（Ｓ２０１）、サイトのトップページを現す頂点から、その選択辺の開始点となる頂点に至るまでの経路を算出し（Ｓ２０２）、算出した経路に従って順にサイト内の各ページにアクセスしていく（Ｓ２０３）。
【００２５】
ここで各ページへのアクセスを説明する。各ページのアクセスは、次のように行なう。検査実施部１１が経路上の各辺に付与された「遷移情報」を正常リクエスト生成部１５に渡す。正常リクエスト生成部１５は、検査実施部１１から渡された遷移情報と状態保存部１６が保存する情報から、Ｗｅｂサイトに受理される正しいＨＴＴＰリクエストを生成する機能を持つ。正常リクエスト生成部１５は、受け取った「遷移情報」によりＨＴＴＰリクエストを生成する。リクエスト送信部１２は、正常リクエスト生成部１５が生成したＨＴＴＰリクエストを送信する。レスポンス受信部１３は、その応答を受信する。Ｗｅｂサイト（診断対象Ｗｅｂサーバ）は、Ｃｏｏｋｉｅ等、各クライアントを識別するための情報をＨＴＴＰレスポンスに含めてクライアント端末に返す場合がある。これらの情報は、レスポンス受信部１３が、ＨＴＴＰレスポンス内から抽出し、状態保存部１６中に格納する。
【００２６】
一連のページアクセス終了後、検査実施部１１は、検査対象となる「対象辺」に付与されている遷移情報をパラメータとして正常リクエスト生成部１５を呼び出し、検査リクエストの雛形となる正常なリクエストを生成する（Ｓ２０４）。検査実施部１１は、その一部分を「擬似攻撃データ」に変更することで検査リクエストを生成する（Ｓ２０５）。
【００２７】
この「擬似攻撃データ」は、診断対象Ｗｅｂサーバ２００上のＷｅｂアプリケーション内で生成されるバックエンドサーバ４００への制御コマンド（コマンド文字列）が文法誤りを起こすような特殊な文字、例えばシングルクオート（‘）や改行コード（実際にはＨＴＴＰの規約に従い％０Ａ等の文字列に置換される）で構成される。
【００２８】
このようにして検査実施部１１は、生成した検査リクエストを、リクエスト送信部１２を用いて診断対象Ｗｅｂサーバ２００に送信する（Ｓ２０６）。
【００２９】
送信された検査リクエストは、診断対象Ｗｅｂサーバ２００内に構築されたＷｅｂアプリケーションに渡される（Ｓ２０７）。
【００３０】
Ｗｅｂアプリケーション（診断対象Ｗｅｂサーバ２００）は、検査リクエスト内に含まれている情報から、「必要に応じて」バックエンドサーバ４００を操作する「コマンド文字列」（例えばＳＱＬ文）を生成し、それをバックエンドサーバ４００に送信する（Ｓ２０８）。ここで、「必要に応じて」とは、Ｗｅｂアプリケーション（診断対象Ｗｅｂサーバ）は、検査リクエストを受信した場合でもコマンド文字列を生成しない場合があることを意味する。実施の形態２で後述するが、Ｗｅｂアプリケーションに「コマンド文字列」を発生させるリクエストを「コマンド文字列発生リクエスト」と呼ぶこととする。コマンド文字列が生成される際、もしＷｅｂアプリケーションにＳＱＬインジェクション等の脆弱性が存在していた場合には、擬似攻撃データ内の特殊な文字により、生成される「コマンド文字列」は構文誤りを含むようになる。
【００３１】
先に説明したとおり、通信モニタ装置３０１は、診断対象Ｗｅｂサーバ２００によってコマンド文字列が生成されたかどうかを検出するため、診断対象Ｗｅｂサーバ２００とバックエンドサーバ４００との間の通信を常時監視している（Ｓ２０９）。通信モニタ装置３０１の構文解析部３２は、通信監視部３１が傍受した通信データに含まれるバックエンドサーバ４００制御用の「コマンド文字列」を検出して解析し、構文誤りの有無を検査する。構文解析部３２は、構文誤りの有無を示す「構文誤り検出情報」を記憶装置（メモリ）に記録する。
【００３２】
診断装置１０１は、レスポンス受信部１３により診断対象Ｗｅｂサーバ２００からＨＴＴＰレスポンスを受信する（Ｓ２１０）。その後、診断装置１０１は、監視結果要求部１４を通じて、通信モニタ装置３０１に、「構文誤り検出情報」を要求する要求情報を送信する（Ｓ２１１）。
【００３３】
通信モニタ装置３０１は、診断装置１０１からの要求情報に応答して、記憶装置（メモリ）に記録した「構文誤り検出情報」を監視結果応答部３３を通じて診断装置１０１に送信する（Ｓ２１２）。
【００３４】
診断装置１０１の検査実施部１１は、受信した「構文誤り検出情報」により構文誤りが発生していたと判定した場合、診断対象Ｗｅｂサーバ２００に脆弱性が存在すると判定し、構文誤りが発生していなかった場合には、脆弱性無しと判定する（Ｓ２１３）。検査実施部１１は、この脆弱性の判定結果を表示装置（図示していない）、プリンタ（図示していない）、あるいは磁気ディスク装置などの記憶装置に出力する。これにより検査実施者は、診断対象Ｗｅｂサーバ２００に脆弱性が存在するかどうかを知ることができる。
【００３５】
なお、通信モニタ装置３０１は、「構文誤り検出情報」を診断装置１０１に送信した後、記憶装置に記憶した「構文誤り検出情報」の記録を消去する。
【００３６】
以上の動作を、サイト構造情報保存部１７内に格納されたグラフ情報（サイト構造情報）の全ての辺に対し行うことで、診断対象Ｗｅｂサーバ２００の検査を実施する。
【００３７】
本実施の形態１では、通信モニタ装置３０１の通信監視部３１が診断対象Ｗｅｂサーバ２００とバックエンドサーバ４００間ネットワークに流れる通信を傍受することにより「コマンド文字列」を検出する方式を説明した。しかし、診断対象Ｗｅｂサーバ２００から送信される「コマンド文字列」を傍受（検出）することができるのであれば、他の実現方法を用いても、もちろん構わない。「コマンド文字列」を検出する他の通信監視部３１の実現方法として、例えば、バックエンドサーバ４００上のログを監視する方法、バックエンドサーバ４００へのプロキシとして動作する方法、診断対象Ｗｅｂサーバ２００がバックエンドサーバ４００に「コマンド文字列」を送信する際に利用するライブラリ呼び出しの際のパラメータをＢＳＭ（Ｂａｓｉｃ  Ｓｅｃｕｒｉｔｙ  Ｍｏｄｕｌｅ）等の機構を利用して監視する方法を挙げることができる。
【００３８】
また、モニタする「コマンド文字列」がバックエンドサーバ４００を操作するものでなくても本実施の形態１は有効である。例えば、診断対象Ｗｅｂサーバ２００内に格納されているプログラムをＷｅｂアプリケーションが呼び出すために生成する「コマンド文字列」（他の機能を制御するための文字列）を監視させてもよい。その場合、通信監視部３１は、診断対象Ｗｅｂサーバ２００内のプログラム呼出の「コマンド文字列」を監視するように実装、配置する必要がある。この実現手段として、実施の形態５で後述するように、通信モニタ装置３０１の機能を実現するプログラムを診断対象Ｗｅｂサーバに組み込んで実行させてもよい。
【００３９】
以上のように、実施の形態１の脆弱性診断システム１０００は、診断対象Ｗｅｂサーバ２００とバックエンドサーバ４００との通信を監視し、「コマンド文字列」の構文誤りを検出する通信モニタ装置３０１を備えたので、診断対象Ｗｅｂサーバ２００からのレスポンスに変化が現れない場合であっても正確に脆弱性を検出することができる。
【００４０】
実施の形態２．
図７〜図１３を用いて実施の形態２を説明する。実施の形態２は、複数のページ間にまたがった脆弱性の検出を可能にする実施形態である。実施の形態２のシステム構成は、図１の脆弱性診断システム１０００と同様である。また、同一あるいは相当の機能部には同一の符号を用いて説明を省略する。
【００４１】
図７は、実施の形態２における診断装置１０２の構成を示す図である。実施の形態２の診断装置１０２は、実施の形態１の診断装置１０１に、さらに、識別文字列生成部１８と、コマンド生起関係保存部１９（一対情報格納部の一例）とを加えた構成である。
【００４２】
図８は、実施の形態２における通信モニタ装置３０２の構成を示す。通信モニタ装置３０２は、実施の形態１の通信モニタ装置３０１に、さらに、識別文字列確認部３４を加えた構成である。以下に図９〜図１３を用いて、本実施の形態２の動作を説明する。
【００４３】
本実施の形態２の場合も、実施の形態１と同様に、あらかじめ通信モニタ装置３０２を起動しておく必要がある。本実施の形態２における脆弱性の診断は、次の３つのフェーズを行なう。
（１）コマンド発生リクエスト調査フェーズ、
（２）コマンド反映リクエスト調査フェーズ、
（３）診断フェーズ
の３つである。
【００４４】
（１．コマンド発生リクエスト調査フェーズ）
はじめに、図９を用いて「コマンド発生リクエスト調査フェーズ」を説明する。診断装置１０２は、コマンド発生リクエスト調査フェーズを実行する。「コマンド発生リクエスト調査フェーズ」は、「コマンド文字列」を発生させるリクエストを調査するフェーズである。図９に示すように、「コマンド発生リクエスト調査フェーズ」では、診断装置１０２内の検査実施部１１は、サイト構造情報保存部１７に記録されている「サイト構造情報」に従い、正常リクエスト生成部１５、リクエスト送信部１２を用いて診断対象Ｗｅｂサーバ２００にＨＴＴＰリクエストを送信する。それに対する診断対象Ｗｅｂサーバ２００からのレスポンスを受信するごとに、検査実施部１１は、通信モニタ装置３０２に問い合わせを行い、「コマンド文字列」が発生したかどうかを確認する。「サイト構造情報」中の「ある辺」（ある遷移情報）に対応するＨＴＴＰリクエストの送信結果として、「コマンド文字列」が発生した場合、検査実施部１１は、その辺（その遷移情報）を、診断対象Ｗｅｂサーバ２００にコマンド文字列を発生させる「コマンド発生遷移」として、コマンド生起関係保存部１９に記憶する。例えば図９において、辺４０に基づくＨＴＴＰリクエスト４１によって診断対象Ｗｅｂサーバ２００が「コマンド文字列」を発生した場合、辺４０は「コマンド発生遷移」であり、ＨＴＴＰリクエスト４１は「コマンド発生リクエスト」である。
【００４５】
（２．コマンドに反映するリクエストを調査するフェーズ）
次に、診断装置１０２は「コマンド反映リクエスト調査フェーズ」に移行する。
「コマンド反映リクエスト調査フェーズ」とは、コマンド文字列に反映される文字列を有するリクエストを発見するフェーズである。図１０、図１１を用いて「コマンド反映リクエスト調査フェーズ」を説明する。図１０は、「コマンド反映リクエスト調査フェーズ」を説明するフローチャートである。図１１は、「コマンド反映リクエスト」と「コマンド発生リクエスト」との関係を説明する図である。最初に、検査実施部１１はサイト構造情報保存部１７から「ある特定の辺」（以下、特定辺という場合がある）を選択する（Ｓ３０１）。検査実施部１１は、図１１において、特定辺として、辺５１を選択したとする。検査実施部１１は、実施の形態１と同様に、トップページから順に「特定辺」の開始点となるページ（図１１ではページ２）までアクセスする（Ｓ３０２、Ｓ３０３）。次に「特定辺」に付与されている遷移情報をパラメータとして正常リクエスト生成部１５を呼び出し、正常リクエストを生成する（Ｓ３０４）。次に生成されたリクエストの一部を「調査データ」に置き換え、調査リクエストを生成する（Ｓ３０５）。
【００４６】
ここで、調査データを説明する。「調査データ」は、識別文字列生成部１８によって生成された文字列である。図１１の例では「ＡＢＣ」が生成されたとする。識別文字列生成部１８が生成する文字列は、各調査データを識別可能とするための文字列である。このような文字列の例を図１２に示す。もちろん他の形式の文字列であっても構わない。ただし、診断対象Ｗｅｂサーバ２００内で偶然生成される事が無いよう、ある程度複雑な文字列とする必要はある。
【００４７】
次に検査実施部１１は、図１１に示すように、リクエスト送信部１２を用いて「調査リクエスト」を送信する（Ｓ３０６）。その後、コマンド生起関係保存部１９からコマンド発生遷移を一つ選択し、先ほど選択した辺の接続先の頂点からコマンド発生遷移の開始点まで順にページアクセスを行い、最後にコマンド発生遷移に基づいたページアクセスを行う（Ｓ３０７）。図１１の例では、検査実施部１１は、コマンド発生遷移として、辺５２を選択したとする。
【００４８】
本フェーズにおける通信モニタ装置３０２の動作について説明する。実施の形態１と同様、通信モニタ装置３０２は通信監視部３１を通じて診断対象Ｗｅｂサーバ２００からバックエンドサーバ４００に送信される「コマンド文字列」を傍受し、内部に含まれている識別文字列を識別文字列確認部３４によって抽出し、識別文字列の有無を記憶する。
【００４９】
診断装置１０２は、コマンド発生遷移に基づいたリクエストを送信し（Ｓ３０８）、それに対する診断対象Ｗｅｂサーバ２００からのＨＴＴＰレスポンスをレスポンス受信部１３により受信後（Ｓ３０９）、監視結果要求部１４を通じて通信モニタ装置３０２に監視結果を要求する（Ｓ３１０）。通信モニタ装置３０２は、「識別文字列」の有無を監視結果応答部３３を通じて診断装置１０２に返す。「識別文字列」が含まれていた場合、調査リクエストの元となった遷移情報を「コマンド反映遷移」として、コマンド発生遷移と対で、コマンド生起関係保存部１９中に記憶する（Ｓ３１１）。図１１において、辺５２に基づくコマンド発生リクエスト５４が発生させるコマンド文字列は「ＸＹＺ」を含み、「ＡＢＣ」を含まない。よって、辺５２は、辺５１に対するコマンド発生遷移ではない。検査実施部１１は、「特定辺」（コマンド反映遷移となるべき辺）に対して、すべてのコマンド発生遷移を調査する。図１１の例では、辺５３に基づくコマンド発生リクエスト５５が「ＡＢＣ」を含むコマンド文字列を発生させる。よって、辺５３は、辺５１に対するコマンド発生遷移である。このように辺５１から生成される調査リクエスト（「ＡＢＣを含むリクエスト」）は、コマンド発生リクエスト５５が診断対象Ｗｅｂサーバ２００に発生させるコマンド文字列に自身の含む文字列「ＡＢＣ」を反映させる。この場合の調査リクエスト（「ＡＢＣを含むリクエスト」）をコマンド発生リクエスト５５に対してコマンド反映リクエストと呼ぶ。後述のように、診断装置１０２は、辺５１（コマンド反映遷移）と辺５３（コマンド発生遷移）とを、一対の組として記憶する。
【００５０】
以上の動作をサイト構造情報中の全ての辺、及びコマンド生起関係保存部１９中の全てのコマンド発生遷移に対して実施後、次の診断フェーズに移行する。
【００５１】
（３．診断フェーズ）
次に、図１３を用いて診断フェーズを説明する。「診断フェーズ」は、ページ間をまたがって脆弱性を検出するフェーズである。図１３に示すように、診断フェーズではまず、検査実施部１１が、コマンド生起関係保存部１９（一対情報格納部の一例）に保存された、「コマンド反映遷移」（第１リクエスト生成用情報の一例）、「コマンド発生遷移」（第２リクエスト生成用情報の一例）の一対を選択する。図１３に示すように、検査実施部１１が、辺５１である「コマンド反映遷移」（第１リクエスト生成用情報）、辺５３である「コマンド発生遷移」（第２リクエスト生成用情報）の一対を選択したものとする。検査実施部１１は、トップページを表す頂点（ページ１）から辺５１である「コマンド反映遷移」の開始点となる頂点までページアクセスを順に実施する（図１３の例ではページアクセスは１回である）。その後、検査実施部１１は、辺５１である「コマンド反映遷移」（第１リクエスト生成用情報）の情報に基づいた正常リクエスト（第１リクエストの一例）を正常リクエスト生成部１５を用いて生成する。次に、検査実施部１１は、生成された正常リクエスト（第１リクエスト）の識別文字列部分を、実施の形態１と同様に「特殊な文字」（検査用の文字列）に置き換えることで「診断リクエスト」（検査リクエスト）を生成し、リクエスト送信部１２を通じて診断リクエスト（検査リクエスト）を診断対象Ｗｅｂサーバ２００に送信する。
【００５２】
その後、検査実施部１１は、対となっている辺５３である「コマンド発生遷移」の開始点（図１３ではページ５）までページアクセスを順に実施し、最後に辺５３である「コマンド発生遷移」に基づいたページアクセスを行う。検査実施部１１は、このアクセスに対するレスポンスを受信後、監視結果要求部１４を介して通信モニタ装置３０２から「構文誤り検出情報」を取得して、「コマンド文字列」の構文誤りの有無を確認する。構文誤りが発生していた場合には、検査実施部１１は、Ｗｅｂアプリケーション内の「コマンド反映リクエスト」（辺５１から生成されるリクエスト）の処理を行う箇所に脆弱性があるとみなし、検査実施者に報告する。例えば、表示装置（図示していない）に警告を出力する。以上の動作を全ての「コマンド発生遷移」と「コマンド反映遷移」との対に対して行うことで診断を実施する。
【００５３】
このように、実施の形態１における脆弱性診断システムは、診断装置が、「コマンド文字列」を発生させる「コマンド文字列発生遷移」と「コマンド文字列発生遷移」の発生させる「コマンド文字列」に反映される内容を送信する「コマンド文字列反映遷移」とを一対としてあらかじめ識別して格納しておき、その後、検査を実施することにより、診断リクエスト（検査リクエスト）送信直後に「コマンド文字列」が発生しない場合でも、脆弱性の有無を検出できる。
【００５４】
実施の形態３．
図１４は、実施の形態３の診断装置１０３の構成を表す図である。診断装置１０３は、図７に示した実施の形態２の診断装置１０２の構成に、さらに、サイト構造情報最適化部２０を付加した構成である。このサイト構造情報最適化部２０は、検査実施部１１により呼び出され、あらかじめサイト構造情報保存部１７中に格納されたサイト構造情報から、トップページを頂点とした最小木を構成し、最適化されたサイト構造情報として再びサイト構造情報保存部１７に格納する機能を持つ。サイト構造情報の更新後の動作は、実施の形態２と同じである。
【００５５】
このように検査実施前に、与えられたサイト構造情報を最小木に変換しておくことで、コマンド反映リクエスト調査フェーズにかかる時間的コストを軽減できるという特長がある。
【００５６】
なお、サイト構造情報最適化部２０は、実施の形態１にも適用可能であることは言うまでも無い。
【００５７】
実施の形態４．
図１５、図１６は、実施の形態４の診断装置１０４、通信モニタ装置３０４の構成を示す図である。
診断装置１０４は、図７に示す実施の形態２の診断装置１０２に、識別文字列送信部２１を加えた構成である。また、本実施の形態４の通信モニタ装置３０４は、図８に示す実施の形態２の通信モニタ装置３０２に、識別文字列受信部３５と識別文字列保存部３６とを加えた構成である。診断装置１０４の識別文字列生成部１８は、毎回異なる文字列を生成することを特徴としている。生成された識別文字列は識別文字列送信部２１によって通信モニタ装置３０４に送信される。通信モニタ装置３０４は、識別文字列受信部３５を通じて識別文字列を受信し、識別文字列保存部３６中に保存する。識別文字列確認部３４は、識別文字列保存部３６中に格納された識別文字列が「コマンド文字列」中にあるかどうかを監視する。
【００５８】
以上のように、毎回異なる識別文字列を生成し、通信モニタ装置３０４で監視させることで、過去に投入した識別文字列が「コマンド文字列」に再び現れてしまっても誤検出をおこす恐れがなくなる、という特長がある。
【００５９】
実施の形態５．
図１７〜図１９を用いて実施の形態５を説明する。実施の形態５は、以上の実施の形態で説明した通信モニタ装置の動作を、プログラム及びプログラムを記録した記録媒体により実施する実施形態である。通信モニタ装置の動作を実行するプログラムは、コンピュータである診断対象Ｗｅｂサーバ２００に組み込まれて実行されることによりコマンド文字列の生成を監視しても構わない。
【００６０】
前記の実施の形態においては、通信モニタ装置における「〜部」として示した各構成要素の動作は互いに関連しており、動作の関連を考慮しながら、コンピュータに実施させる一連の処理（プログラム）に置き換えることができる。各構成要素の動作を一連の処理に置き換えることにより、コマンド文字列監視プログラムの実施形態として把握することができる。また、このコマンド文字列監視プログラムを、コンピュータ読み取り可能な記録媒体に記録させることで、プログラムを記録したコンピュータ読み取り可能な記録媒体の実施形態とすることができる。
【００６１】
図１７は、図３、図８、図１６等に示した通信モニタ装置の通信監視部３１の動作、構文解析部３２の動作、及び監視結果応答部３０３の動作という一連の動作をコンピュータに実行させる一連の処理に置き換えたフローチャートである。
【００６２】
Ｓ４０１は、診断対象Ｗｅｂサーバ２００（サーバ装置）の脆弱性を検査する診断装置（検査装置）が送信したリクエストを受信した診断対象Ｗｅｂサーバ２００がバックエンドサーバ４００（他の機能の一例）を制御する文字列であるコマンド文字列を生成するかどうか監視してコマンド文字列を検出する処理である。通信監視部３１（コマンド文字列検出部）の動作に対応する。
【００６３】
Ｓ４０２は、コマンド文字列が検出された場合に、検出されたコマンド文字列に構文誤りがあるかどうかを解析して構文誤りの有無を示す構文誤り検出情報を記憶する処理である。構文解析部３２の動作に対応する。
【００６４】
Ｓ４０３は、記憶された構文誤り検出情報を要求する要求情報に応答して、記憶された構文誤り検出情報を送信する処理である。監視結果応答部３３（応答部）の動作に対応する。
【００６５】
プログラムの実施の形態及びプログラムを記録したコンピュータ読み取り可能な記録媒体の実施の形態は、すべてコンピュータで動作可能なプログラムにより構成することができる。
【００６６】
図１８は、図１の診断対象Ｗｅｂサーバ２００の外観の一例を示す図であり、コンピュータシステムである診断対象Ｗｅｂサーバ２００がコマンド文字列監視プログラムを実装している場合を想定する図である。図１８において、コンピュータシステム８００である診断対象Ｗｅｂサーバ２００は、システムユニット８３０、液晶ディスプレイ８１３、キーボード（Ｋ／Ｂ）８１４、マウス８１５、コンパクトディスク装置（ＣＤＤ）８１８、プリンタ８１９を備え、これらはケーブルで接続されている。また、コンピュータシステム８００は、ネットワークを介して診断装置１０１、バックエンドサーバ４００と接続している。
【００６７】
図１９は、図１８のコンピュータシステム８００のハードウェア構成図である。図１９において、コンピュータシステム８００は、プログラムを実行するＣＰＵ（Ｃｅｎｔｒａｌ  Ｐｒｏｃｅｓｓｉｎｇ  Ｕｎｉｔ）８１０を備えている。ＣＰＵ８１０は、バス８２５を介してＲＯＭ８１１、ＲＡＭ８１２、液晶ディスプレイ８１３、Ｋ／Ｂ８１４、マウス８１５、通信ボード８１６、ＦＤＤ８１７、ＣＤＤ８１８、プリンタ８１９、及び磁気ディスク装置８２０と接続されている。
【００６８】
磁気ディスク装置８２０には、オペレーティングシステム（ＯＳ）８２１、ウィンドウシステム８２２、プログラム群８２３、ファイル群８２４が記憶されている。プログラム群８２３は、ＣＰＵ８１０、ＯＳ８２１、ウィンドウシステム８２２により実行される。
【００６９】
上記プログラム群８２３には、Ｗｅｂアプリケーションプログラム、コマンド文字列監視プログラム等が格納されている。これらのプログラムは、ＣＰＵ８１０により読み出され実行される。
「構文誤り検出情報」はＲＡＭ８１２に記憶される。また、ファイル群８２４には、ＲＡＭ８１２に記憶された「構文誤り検出情報」などをファイルとして格納しても構わない。
【００７０】
通信モニタ装置の構成を示す図３、図８、図１６等において「〜部」として説明したものは、ＲＯＭ８１１に記憶されたファームウェアで実現されていても構わない。或いは、ソフトウェアのみ、或いは、ハードウェアのみ、或いは、ソフトウェアとハードウェアとの組み合わせ、さらには、ファームウェアとの組み合わせで実施されても構わない。
【００７１】
プログラムの実施の形態及びプログラムを記録したコンピュータ読み取り可能な記録媒体の実施の形態における各処理は、プログラムで実行されるが、このプログラムは、前述のようにプログラム群８２３に記録されている。そして、プログラム群８２３からＣＰＵ８１０に読み込まれ、ＣＰＵ８１０によって、プログラムの各処理が実行される。また、ソフトウェア、あるいはプログラムは、ＲＯＭ８１１に記憶されたファームウェアで実行されても構わない。あるいは、ソフトウェアとファームウェアとハードウェアの組み合わせでプログラムを実行しても構わない。
【００７２】
実施の形態５のコマンド文字列監視プログラムは、診断対象Ｗｅｂサーバ２００がコマンド文字列を生成するかどうか監視してコマンド文字列を検出し、検出されたコマンド文字列に構文誤りがあるかどうかを解析して構文誤りの有無を示す構文誤り検出情報を記憶するとともに、記憶された構文誤り検出情報を要求する要求情報に応答して、記憶された構文誤り検出情報を送信する一連の処理を実行するので、リクエストに対応する応答レスポンスに脆弱性の存在が現れない場合であっても、脆弱性を検出することが可能になる。
【００７３】
以上の実施の形態では、通信モニタ装置によりＷｅｂアプリケーションとバックエンドサーバとの間の通信を監視するシステムを説明した。このシステムでは、バックエンドサーバのログを監視しても良いし、バックエンドサーバのプロキシとして通信を監視しても良いし、Ｗｅｂアプリケーションがバックエンドサーバを呼び出すためのライブラリ呼出を監視しても良いし、バックエンドサーバでなく、例えばＯＳの機能を呼び出すための「コマンド文字列」を監視してもよい。
【００７４】
以上の実施の形態では、通信モニタにＷｅｂアプリケーションからバックエンドサーバに渡される「コマンド文字列」の構文誤りを検出する構文解析手段を含む通信モニタ装置を説明した。また、通信モニタ装置による構文誤り検出情報に基づいて、脆弱性の判定を行う診断装置を説明した。また、サイト構造情報保存手段によりページ間のつながりやページ間の移動に必要なリクエストを保持する診断装置を説明した。
【００７５】
以上の実施の形態では、最初に正常なＷｅｂアクセスを行って、Ｗｅｂアプリケーションとバックエンドサーバとの通信が発生するＷｅｂアクセスを特定するシステムを説明した。また、正常なＷｅｂアクセスの一部を改変して送信し、その後上記Ｗｅｂアクセスを行い、「コマンド文字列」の内容を解析することで、「コマンド文字列」に影響を与えるＷｅｂアクセスを特定するシステムを説明した。また最後に上記Ｗｅｂアクセスの対に対して脆弱性診断を実施するシステムを説明した。
【００７６】
以上の実施の形態では、サイト構造情報最適化手段により、与えられたサイト構造情報を最小木に変換する診断装置を説明した。
【００７７】
以上の実施の形態では、毎回異なる識別文字列を生成し、通信モニタ中に記憶させるシステムを説明した。
【図面の簡単な説明】
【００７８】
【図１】実施の形態１における脆弱性診断システム１０００の構成図。
【図２】実施の形態１における診断装置１０１の構成図。
【図３】実施の形態１における通信モニタ装置３０１の構成図。
【図４】実施の形態１における脆弱性診断の前段階を示す図。
【図５】実施の形態１における脆弱性診断システム１０００の動作を説明する図。
【図６】実施の形態１における脆弱性診断システム１０００の動作を説明するフローチャート。
【図７】実施の形態２における診断装置１０２の構成図。
【図８】実施の形態２における通信モニタ装置３０２の構成図。
【図９】実施の形態２におけるコマンド発生リクエスト調査フェーズを説明する図。
【図１０】実施の形態２におけるコマンド反映リクエスト調査フェーズを説明するフローチャート。
【図１１】実施の形態２におけるコマンド反映リクエスト調査フェーズを説明する図。
【図１２】実施の形態２における調査用文字列を示す図。
【図１３】実施の形態２における診断フェーズを説明する図。
【図１４】実施の形態３における診断装置１０３の構成図。
【図１５】実施の形態４における診断装置１０４の構成図。
【図１６】実施の形態４における通信モニタ装置３０４の構成図。
【図１７】実施の形態５におけるコマンド文字列監視プログラムの処理を示すフローチャート。
【図１８】実施の形態５におけるコンピュータシステム８００の外観。
【図１９】実施の形態５におけるコンピュータシステム８００のハードウェア構成図。
【図２０】従来技術を示す図。
【符号の説明】
【００７９】
１１  検査実施部、１２  リクエスト送信部、１３  レスポンス受信部、１４  監視結果要求部、１５  正常リクエスト生成部、１６  状態保存部、１７  サイト構造情報保存部、１８  識別文字列生成部、１９  コマンド生起関係保存部、２０  サイト構造情報最適化部、２１  識別文字列送信部、３１  通信監視部、３２  構文解析部、３３  監視結果応答部、３４  識別文字列確認部、３５  識別文字列受信部、３６  識別文字列保存部、４０  辺、４１  ＨＴＴＰリクエスト、５１，５２，５３  辺、５４，５５  コマンド発生リクエスト、１０１，１０２，１０３，１０４  診断装置、１１１  検査リクエスト生成部、２００  診断対象Ｗｅｂサーバ、３０１，３０２，３０４  通信モニタ装置、４００  バックエンドサーバ、８００  コンピュータシステム、８１０  ＣＰＵ、８１１  ＲＯＭ、８１２  ＲＡＭ、８１３  液晶ディスプレイ、８１４  キーボード、８１５  マウス、８１６  通信ボード、８１７  ＦＤＤ、８１８  ＣＤＤ、８１９  プリンタ、８２０  磁気ディスク装置、８２１  ＯＳ、８２２  ウィンドウシステム、８２３  プログラム群、８２４  ファイル群、８３０  システムユニット、１０００  脆弱性診断システム。
【図１】
0004745819.tif 000002
【図２】
0004745819.tif 000003
【図３】
0004745819.tif 000004
【図４】
0004745819.tif 000005
【図５】
0004745819.tif 000006
【図６】
0004745819.tif 000007
【図７】
0004745819.tif 000008
【図８】
0004745819.tif 000009
【図９】
0004745819.tif 000010
【図１０】
0004745819.tif 000011
【図１１】
0004745819.tif 000012
【図１２】
0004745819.tif 000013
【図１３】
0004745819.tif 000014
【図１４】
0004745819.tif 000015
【図１５】
0004745819.tif 000016
【図１６】
0004745819.tif 000017
【図１７】
0004745819.tif 000018
【図１８】
0004745819.tif 000019
【図１９】
0004745819.tif 000020
【図２０】
0004745819.tif 000021