(57)【要約】【課題】  システムのセキュリティを確保するためのチェックルールを生成する。【解決手段】  通信情報監視装置２０１は、擬似クライアント５０１、監視部５０２、統合部５０３から構成される。擬似クライアント５０１は、パラメータとしてトレース値を含むリクエストメッセージをウェブアプリケーションに送信する。またウェブアプリケーションから返信されたレスポンスメッセージの解析を行う。監視部５０２は、システム内の様々な箇所において、擬似クライアント５０１によって送信されたトレース値が使用されているかどうかを監視する。統合部５０３は、擬似クライアント５０１および監視部５０２での処理結果と、予め登録されているチェックポリシー５１０を元に、チェックルールを生成する。チェックポリシー５１０には、パラメータの利用用途とチェック処理の対応が登録されている。【選択図】        図４
2007004685.tif 000002
【特許請求の範囲】
【請求項１】
ネットワークを介してクライアントにサービスを提供するシステムに使用される通信情報監視装置であって、
トレース値を含むリクエストを送信する擬似クライアントと、
前記システムの各箇所においてトレース値の監視を行う監視部とを備え、
前記システムの各箇所におけるトレース値を監視することによりパラメータの使用箇所の特定を行う
ことを特徴とする通信情報監視装置。
【請求項２】
請求項１記載の通信情報監視装置において、
前記パラメータの使用箇所の特定は、
ウェブアプリケーションのパラメータの使用箇所を特定する
ことを特徴とした通信情報監視装置。
【請求項３】
請求項２に記載の通信情報監視装置において
前記トレース値の監視を行う監視部には、
データベースにアクセスするためのＳＱＬ文の監視を行うＳＱＬ監視部と、
前記ウェブアプリケーションに返信するためのレスポンスメッセージの監視を行うレスポンス監視部とを有する
ことを特徴とする通信情報監視装置。
【請求項４】
請求項１〜３のいずれかに記載の通信情報監視装置において、
前記パラメータの使用箇所の特定結果と予め設定されているセキュリティポリシーとを統合する統合部を備え、
通信情報監視におけるチェックルールを生成する
ことを特徴とする通信情報監視装置。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、例えば情報セキュリティに使用して好適な通信情報監視装置に関し、特に、ネットワークを介してサービスを提供するシステムにおいて、ネットワークを介した各種攻撃からシステムを防御するための技術に関するものである。
【背景技術】
【０００２】
〔導入〕
インターネットやイントラネットなどのネットワーク技術が発達したことにより、現在、多くのシステムがネットワークを介してクライアントにサービスを提供している。このようなネットワークを介してサービスを提供するシステムとして、例えばウェブアプリケーションがある。
【０００３】
〔ウェブアプリケーションの概要〕
ウェブアプリケーションを利用する場合、クライアントはウェブアプリケーションに対してリクエストメッセージを送信する。それに対してウェブアプリケーションはレスポンスメッセージを返信する。リクエストメッセージおよびレスポンスメッセージは、ＨＴＴＰ（HyperText Transfer Protocol）を用いて送受信される。また、レスポンスメッセージには、ＨＴＭＬ（HyperText Markup Language）を用いて記述されたウェブページが含まれている。
【０００４】
〔ウェブアプリケーションのパラメータ〕
クライアントが送信するリクエストメッセージには、様々なパラメータが含まれていることがある。これらのパラメータは、例えばＰＯＳＴペイロードやＵＲＬクエリやクッキー（Cookie）などに含まれている。これらのパラメータは、ウェブアプリケーションにおいて様々な処理に利用される。例えば、データベースへアクセスするためのＳＱＬ（Structured Query Language）文の一部として利用されたり、クライアントへ送信するウェブページに含まれたりする。
【０００５】
〔パラメータを使った攻撃〕
このように、クライアントから送信されるパラメータはウェブアプリケーションの動作に影響を与えるため、パラメータ内に不正なコマンドやスクリプトが記述されているとウェブアプリケーションが想定外の動作をすることがある。そのため、リクエストメッセージに含まれるパラメータは、しばしばウェブアプリケーションへの攻撃に利用されることがある。パラメータを利用したウェブアプリケーションへの攻撃手法として、例えばクロスサイトスクリプティング（以下、ＸＳＳと記す）攻撃やＳＱＬインジェクションなどがある。
【０００６】
〔ＸＳＳ攻撃〕
ウェブアプリケーションが、受信したパラメータをそのままレスポンスのウェブページ内に含める場合、ＸＳＳ攻撃に対する脆弱性が存在する可能性がある。ＸＳＳ攻撃が成功すると、パラメータ内に記述された不正なスクリプトが、ウェブアプリケーションの返信するウェブページの中に含まれ、クライアント上で実行されてしまう。これにより、クッキー（Cookie）の盗聴や改ざんなど、重大な問題を引き起こす可能性がある。
【０００７】
〔ＳＱＬインジェクション〕
ウェブアプリケーションが、受信したパラメータを、データベースにアクセスするためのＳＱＬ文の一部として使用する場合、ＳＱＬインジェクションに対する脆弱性が存在する可能性がある。ＳＱＬインジェクションが成功すると、パラメータ内に記述された文字列により、想定外の意味を持つＳＱＬ文が発行されてしまう。これにより、なりすましや重要データの漏洩など、重大な問題を引き起こす可能性がある。
【０００８】
〔従来の対策方法（ウェブアプリケーションファイアウォール）〕
これらのパラメータを利用したウェブアプリケーションへの攻撃を防ぐには、クライアントから送信されたパラメータに不正な文字列が含まれていないかチェックをすることが有効である。リクエストメッセージに含まれるパラメータのチェックを行うシステムは、例えばウェブアプリケーションファイアウォール（以下、ＷＡＦと記す）などと呼ばれ、すでに実用化されている。
【０００９】
以下では、図１３を参照しながらパラメータチェックの例を説明する。図１３の例では、セキュリティフィルタ１０３により、パラメータのチェックが実行される。クライアント１０１とセキュリティフィルタ１０３は、ネットワーク１０２を介して接続されている。セキュリティフィルタ１０３とウェブアプリケーション１０４は、ネットワークを介して接続されていてもよいし、同じ計算機上で動作していてもよい。
【００１０】
クライアント１０１は、ウェブアプリケーション１０４に対してリクエストメッセージを送信する。セキュリティフィルタ１０３は、クライアントから送信されたリクエストメッセージを遮断し、パラメータのチェックを行う。チェックは、予め設定されたチェックルール１０５に基づいて実行される。
【００１１】
パラメータのチェックにはいくつかの方法がある。例えば、セキュリティ上問題を引き起こす可能性のある文字列を、予め禁止文字列としてチェックルール１０５に設定しておくことがある。この場合、セキュリティフィルタ１０３は、クライアントからのリクエストを遮断しパラメータ内に禁止文字列が含まれていないかチェックする。
【００１２】
すなわち、禁止文字列が含まれていない場合はリクエストをそのままウェブアプリケーション１０４に転送する。禁止文字列が含まれている場合は、リクエストを拒否しクライアント１０１にエラーを返す。このようなパラメータのチェックを実施することで、ウェブアプリケーションへの攻撃からシステムを防御することができる。
【００１３】
ここで、セキュリティフィルタ１０３を有効に機能させるには、適切なチェックルール１０５を設定する必要があるが、チェックルール１０５の設定は煩雑な作業になることが多い。すなわち、禁止文字列を指定するには、各攻撃手法の詳細な知識が必要になる。そのため、チェックルールの設定には、高度なセキュリティの知識が求められる。
【００１４】
また、ＸＳＳ攻撃に使用される文字列とＳＱＬインジェクションに使用される文字列は異なる。そのため、ＸＳＳ攻撃に利用される恐れがあるパラメータに対しては、ＸＳＳ攻撃用のチェックルールを、ＳＱＬインジェクションに利用される恐れがあるパラメータに対しては、ＳＱＬインジェクション用のチェックルールを設定しておく必要がある。
【００１５】
従って、ウェブアプリケーションへの攻撃からシステムを防御するための適切なチェックルールを設定するには、ウェブアプリケーションの詳細な知識が必要になる。このように、チェックルールの設定は、セキュリティの知識とウェブアプリケーションの知識の両方を求められる高度な作業である。
【００１６】
そこで、このようなチェックルールの設定に関する技術としては、例えばレスポンスメッセージを解析することにより、パラメータが取りうる値の範囲を限定する技術が知られている（例えば、特許文献１参照。）。
【００１７】
また、ＸＳＳ攻撃の脆弱性を検出する技術として、リクエストメッセージにトレース値を挿入し、その結果得られるレスポンスメッセージを解析することで、ウェブアプリケーションがＸＳＳ攻撃に対する脆弱性を持つかどうかを識別する技術もある（例えば、特許文献２参照。）。
【００１８】
すなわち、チェックルールの設定する技術や、ＸＳＳ攻撃に対する脆弱性を持つかどうかを識別する技術は、特許文献１や特許文献２によって知られているものである。
【特許文献１】特表２００３−５０４７２３号公報
【特許文献２】特開２００４−１６４６１７号公報
【発明の開示】
【発明が解決しようとする課題】
【００１９】
ところが特許文献１に記載の技術では、記述の自由度が高いパラメータについては、値の限定が困難であり、十分なチェックが実行できない可能性がある。また、特許文献２に記載の技術では、レスポンスメッセージの解析しか行わないため、例えばＳＱＬインジェクションのような、ウェブアプリケーションの内部で不正なコマンドを実行するような攻撃を検出することができない。
【００２０】
本発明は、上記の問題点を解決するために創出されたものであって、本発明の目的は、セキュリティの知識やウェブアプリケーションの詳細な知識がなくても、適切なチェックルールを容易に作成できるようにすることにある。
【課題を解決するための手段】
【００２１】
上記の目的を達成するため、本発明の通信情報監視装置は、擬似クライアントと監視部と統合部とから構成される。
【００２２】
すなわち本発明は、擬似クライアントおよび監視部によりパラメータの追跡を行い、パラメータが使用される箇所を特定する。擬似クライアントは、ネットワークを介してクライアントにサービスを提供するシステムに対して、パラメータの値としてトレース値を設定したリクエストメッセージを送信する。監視部はシステムの各箇所においてトレース値が使用されているかどうか監視を行う。これにより、リクエストメッセージ内のパラメータが使用される箇所を特定することができる。
【００２３】
さらに統合部は、擬似クライアントおよび監視部による追跡結果と、予め設定したチェックポリシーとを元に、適切なチェックルールを生成する。チェックポリシーには、様々なパラメータの使用箇所に対する適切なチェックルールが設定してある。そのため、パラメータの使用箇所が記述されている追跡結果と付き合わせることで、適切なチェックルールを容易に生成することができる。
【発明の効果】
【００２４】
以上述べた本発明を適用することにより、高度なセキュリティ知識を持たない者や、システムの詳細な情報を知らない者でも、容易にチェックルールを作成することができる。また、本発明を適用することにより、システム構築の工数の削減や設定ミスの軽減を期待することができる。
【発明を実施するための最良の形態】
【００２５】
以下、図面を参照しながら本発明を実施するための最良の形態を説明する。
【００２６】
以下の説明では、クライアントにサービスを提供するシステムの例としてウェブアプリケーションについて実施の形態を説明するが、本発明の適用範囲はウェブアプリケーションのみに限定されるものではない。また、以下の例では、ウェブアプリケーションの外部に存在するセキュリティフィルタによってパラメータのチェックを行う。しかし、本発明は、ウェブアプリケーションの内部においてパラメータのチェックを行う場合についても適用可能である。
【００２７】
〔システム全体の概要〕
図１は、本実施形態に関わるシステム全体の構成を示す図である。ウェブアプリケーション１０４は、クライアント（図示しない）に対してサービスを提供する。セキュリティフィルタ１０３は、ウェブアプリケーション１０４に対する攻撃を防ぐため、リクエストメッセージに含まれるパラメータのチェックを行う。パラメータのチェックは、チェックルール１０５に従って実行される。チェックルール１０５は、以下で詳しく説明するように、通信情報監視装置１０４によって生成される。
【００２８】
〔計算機のハードウェア構成〕
ウェブアプリケーション１０４、セキュリティフィルタ１０３、通信情報監視装置２０１は、図２に示すような一般的な計算機３０１を用いて実現することができる。計算機３０１は、ＣＰＵ３０５と、メモリ３０６と、ハードディスクなどの記憶装置３０７と、キーボードやマウスなどの入力装置３０３と，ディスプレイなどの出力装置３０４と、ネットワークに接続するための通信装置３０２とを備える。
【００２９】
計算機３０１は、通信装置１０５を介してインターネットなどのネットワーク１０２に接続されている。計算機３０１では、ＣＰＵ３０５が、メモリ３０６上に呼び出された所定のプログラムを実行することにより、各機能が実現される。ウェブアプリケーション１０４、セキュリティフィルタ１０３、通信情報監視装置２０１は、それぞれ別の計算機上で実行されてもよいし、１つの計算機上で実行されてもよい。
【００３０】
〔ウェブアプリケーションの内部構成〕
図３に、ウェブアプリケーション１０４の内部構成の例を示す。ウェブアプリケーション１０４は、クライアントからリクエストメッセージを受信すると、リクエストメッセージに応じて様々な業務処理を行い、クライアントにレスポンスメッセージを返信する。クライアントから送信されたリクエストメッセージは、ＨＴＴＰ処理部４０１によって受信される。
【００３１】
業務処理部４０３で行う処理は、ウェブアプリケーションごとに大きく異なる。例えばオンラインショッピングのウェブアプリケーションでは、商品検索や商品購入などの処理を行う。業務データベース４０４には、業務処理を実行する際に必要となる各種データが格納されている。例えば商品データなどが業務データベース４０４に格納されている。業務処理部４０３では、リクエストメッセージに含まれているパラメータを利用して業務データベース４０４にアクセスするためのＳＱＬ文を生成する。
【００３２】
データベースアクセス部４０２は、業務処理部４０３によって生成されたＳＱＬ文を元に、業務データベース４０４にアクセスしデータの検索や更新などの処理を行う。また、業務処理部４０３は、業務データベース４０４へアクセスした結果やリクエストメッセージに含まれるパラメータなどを利用して、クライアントに返信するウェブページを生成する。生成されたウェブページは、ＨＴＴＰ処理部４０１によってクライアントに返信される。
【００３３】
〔通信情報監視装置の内部構成〕
図４に、通信情報監視装置２０１の内部構成の例を示す。通信情報監視装置は、擬似クライアント５０１、監視部５０２、統合部５０３から構成される。
【００３４】
〔擬似クライアントの説明〕
擬似クライアント５０１は、以下で詳しく説明するように、パラメータとしてトレース値を含むリクエストメッセージをウェブアプリケーションに送信する。またウェブアプリケーションから返信されたレスポンスメッセージの解析を行う。擬似クライアント５０１は、画面入出力処理部５０４とリクエスト生成部５０５とレスポンス解析部５０７とＨＴＴＰ処理部５０６によって構成される。ＨＴＴＰ処理部５０６は、リクエストメッセージの送信やレスポンスメッセージの受信を行う。
【００３５】
レスポンス解析部５０７は、ウェブアプリケーションから返信されるレスポンスメッセージの解析を行い、以下で説明するパラメータ一覧を生成する。画面入出力処理部５０４は、レスポンス解析部５０７による解析結果を画面表示したり、ユーザの入力を受け付けたりする。リクエスト生成部は、パラメータとしてトレース値を含むリクエストメッセージを生成する。
【００３６】
〔監視部の説明〕
監視部５０２は、システム内の様々な箇所において、擬似クライアント５０１によって送信されたトレース値が使用されているかどうかを監視する。本実施形態では、監視処理の例として、ＳＱＬ文の監視とレスポンスメッセージの監視について説明する。必要に応じて、この他の箇所で監視を行ってもよい。
【００３７】
ＳＱＬ文監視部５０８は、業務データベース４０４へのアクセスの際に使用されたＳＱＬ文の監視を行う。ＳＱＬ文の監視は、例えばデータベースアクセス部４０２と連携したり、データベースアクセス部４０２と業務データベース４０４間の通信をモニタリングしたりすることで実現することができる。また、この他の方法によりＳＱＬ文の監視を実現してもよい。
【００３８】
レスポンス監視部５０９は、ウェブアプリケーション１０４返信されるレスポンスデータの監視を行う。レスポンスメッセージの監視は、例えば擬似クライアント５０１のＨＴＴＰ処理部５０６と連携したり、ウェブアプリケーション１０４と擬似クライアント５０１間の通信をモニタリングしたりすることで実現できる。また、この他の方法によりレスポンスデータの監視を実現してもよい。
【００３９】
〔統合部の説明〕
統合部５０３は、擬似クライアント５０１および監視部５０２での処理結果と、予め登録されているチェックポリシー５１０を元に、チェックルール１０５を生成する。チェックポリシー５１０には、パラメータの利用用途とチェック処理の対応が登録されている。
【００４０】
以下では、図５に示すフローチャートを参照しながら、チェックルール生成処理の詳細について説明する。チェックルール生成処理は、ユーザが例えばＧＵＩ（Graphical User Interface）を用いて、通信情報監視装置２０１に指示を入力することで実行される。
【００４１】
そこで指示が入力されると、まずステップＳ６０１で、ユーザは擬似クライアント５０１に、ウェブアプリケーションのＵＲＬを入力する。次に、ステップＳ６０２で、擬似クライアント５０１は、通常のブラウザと同様にして、ウェブアプリケーション１０４にリクエストメッセージを送信し、レスポンスメッセージを受信する。ここで、図６にウェブアプリケーションから返信されるレスポンスメッセージの例を示し、具体例を説明する。
【００４２】
図６に示される本レスポンスメッセージは、ＨＴＭＬを用いて記述されている。なお、図６の各行の先頭には、説明のために行番号が付けてあるが、実際のレスポンスメッセージには行番号は含まれないものである。
【００４３】
図６に示したメッセージでは、０１行目から２１行目がhtmlタグで囲まれている。これは、htmlタグで囲まれた内容が、ＨＴＭＬで記述されたデータであることを表す。また、０２行目から２０行目はボディ（body）タグで囲まれている。これは、ボディタグで囲まれた内容が、ＨＴＬＭの本文であることを表す。さらに０４行目では、「商品購入システム」の文字列がh2タグで囲まれている。これは、「商品購入システム」の文字が見出しであることを表す。
【００４４】
また、０６行目から１８行目がフォーム（form）タグで囲まれている。これは、フォームタグで囲まれた内容が、一つのフォームであることを表す。このフォームタグのアクション（action）属性（０６行目）は、入力内容の送信先のＵＲＬを表す。またフォームタグのメソッド（method）属性（０７行目）は、入力内容の送信する際に使用するＨＴＴＰメソッドを表す。
【００４５】
さらに０９行目から１２行目は、セレクト（select）タグで囲まれている。これは、セレクトタグで囲まれた内容が、一つのセレクトボックスであることを表す。セレクトボックスは、フォーム下の部品の一つであり、ここで選択された値はパラメータの一つとしてウェブアプリケーションに送信される。パラメータを送信する際、セレクトタグのネーム（name）属性（０９行目）はパラメータの名前として使用される。
【００４６】
１０行目及び１１行目のオプション（option）タグは、それぞれセレクトボックスの選択候補を表す。これは、オプションタグで囲まれた内容が選択された場合、オプションタグのヴァリュー（value）属性の値が、パラメータ値としてウェブアプリケーションに送信されるものである。
【００４７】
例えば「テレビ」が選択された場合、名前が「item」、値が「tv」であるパラメータがウェブアプリケーションに送信される。また、「ビデオ」が選択された場合、名前が「item」、値が「video」であるパラメータがウェブアプリケーションに送信される。なお、１０行目のセレクトタグは、セレクテッド（selcted）属性を持つ。これは、１０行目のオプションタグが次善選択されていることを表す。
【００４８】
さらに１３行目及び１６行目の＜br＞は、改行を表す。また、１５行目及び１７行目のインプット（input）タグは、それぞれ入力フォームの部品の一つを表す。
【００４９】
ここで、１５行目のようにタイプ（type）属性としてテキスト（text）を持つインプットタグは、テキスト入力フィールドを表す。このインプットタグのネーム属性は、パラメータを送信する際、パラメータの名前として使用される。１５行目では、ネーム属性の名前が「bikou」であるため、本テキスト入力フィールドに入力された値は、名前が「bikou」であるパラメータの値としてウェブアプリケーションに送信される。
【００５０】
また、１７行目のようにタイプ（type）属性としてサブミット（submit）を持つインプットタグは、実行ボタンを表す。ここでこの実行ボタンが押されると、入力フォームの内容がパラメータとしてウェブアプリケーションに送信される。このようにして、擬似クライアント５０１からウェブアプリケーション１０４に送信されたリクエストメッセージに対してレスポンスメッセージが受信される。
【００５１】
そこで図５のステップＳ６０２では、受信したレスポンスメッセージがレスポンス解析部５０７によって解析され、画面入出力処理部５０４によって画面に表示される。図７に表示された画面の例８０１を示す。画面上部の対象画面８０２は、ウェブアプリケーションによって返信されたレスポンスメッセージを、通常のブラウザと同じようにして表示したものである。画面下部のパラメータ一覧８０３は、次のリクエストによってクライアントから送信されるパラメータを、ＨＴＭＬの内容から判断して一覧表示したものである。
【００５２】
パラメータ一覧８０３の各項目には、チェックボックス８０７と、ＵＲＬ８０８と、名前８０９と、値８１０と、状況８１１と、結果８１２が表示される。チェックボックス８０７は、以下で説明するように、ユーザが、追跡を行うパラメータを指定する際に利用する。ＵＲＬ８０８は、パラメータを送信する先のＵＲＬを示す欄である。図６に示すＨＴＭＬでは、フォーム（form）タグのアクション（action）属性７０１にＵＲＬ（http://example.com/purchase）が記述されている。
【００５３】
名前８０９は、パラメータの名前を示す欄である。図６に示すＨＴＭＬでは、セレクト（select）タグのネーム（name）属性７０２に名前「item」、及びインプット（input）タグのネーム（name）属性７０３に名前「bikou」が記述されている。
【００５４】
値８１０は、パラメータの値を示す欄である。ＨＴＭＬ内において、初期値や事前選択された値が指定されている場合は、ここに表示する。図６に示すＨＴＭＬでは、名前が「item」であるパラメータ（以下、「item」パラメータと記す）については、値「tv」が事前選択されているため、値８１０には「tv」と表示される。名前が「bikou」であるパラメータ（以下、「bikou」パラメータと記す）については、初期値や事前選択された値が存在しないため、空白のテキストボックスが表示される。
【００５５】
状況８１１は、各パラメータの追跡状況を表示する欄である。ただし、ステップＳ６０２においては、まだパラメータの追跡を実行していないので、全てのパラメータについて「未追跡」の文字が表示されている。使用箇所８１２は、各パラメータの追跡結果が表示される欄である。ステップ６０２においては、まだパラメータの追跡を実行していないので、全てのパラメータについてまだ結果が出ていないことを示す斜線「−」が表示されている。
【００５６】
そこで図５のフローチャートに戻って、ステップＳ６０３で、ユーザは追跡を行うパラメータを指定する。ここでユーザは、パラメータ一覧８０３に表示されたパラメータのうち、追跡を行う対象とするパラメータを選択し、チェックボックス８０７にマークを付ける。以下で説明するように、チェックボックス８０７にマークを付けたパラメータには、パラメータ値としてトレース値が設定される。
【００５７】
また、追跡を行わないパラメータ、すなわちチェックボックス８０７にマークを付けなかったにパラメータについては、値８１０欄を編集することで、任意の文字列をパラメータ値に設定することができる。さらに、パラメータの指定が完了すると、ユーザはリクエスト送信ボタン８１３を押す。
【００５８】
そしてステップＳ６０４でリクエスト送信ボタン８１３が押されると、リクエスト生成部５０５はパラメータ追跡用の擬似リクエストメッセージを生成する。図８に生成された擬似リクエストの例を示す。図８の例では、リクエストメッセージのうちパラメータを含むＰＯＳＴペイロードだけを記述している。
【００５９】
またリクエスト生成部では、チェックボックス８０７にマークされたパラメータについては、パラメータ値としてトレース値を設定する。トレース値には、例えばランダムな文字列を用いることができる。複数のパラメータにトレース値を設定する場合は、それぞれ異なるトレース値を設定する。図８の例では、「bikou」パラメータにトレース値としてランダムな文字列「H8rJi4」が設定されている。
【００６０】
さらにステップＳ６０５で、監視部５０２では、トレース値の監視を開始する。擬似リクエストが送信されると、監視部５０２内の各監視部は、システムの監視を開始する。すなわち、ＳＱＬ文管理部５０８は、業務データベースに対して送信されるＳＱＬ文の監視を行い、ステップ６０４にて生成されたリクエストメッセージの監視を行う。発行されるＳＱＬ文にトレース値が含まれている場合、追跡対象のパラメータがＳＱＬ文に使用されていることが分かる。
【００６１】
また、レスポンス管理部５０９は、ウェブアプリケーションからクライアントに返信されるレスポンスメッセージの監視を行う。レスポンスメッセージに、トレース値が含まれている場合、追跡対象のパラメータが画面出力に使用されていることが分かる。
【００６２】
さらにステップＳ６０６で、擬似クライアント５０１のＨＴＴＰ処理部５０６は、レクエスト生成部５０５によって生成された擬似リクエストを、ウェブアプリケーションに送信する。またステップＳ６０７で、ウェブアプリケーション１０４では、通常のリクエストを受信した場合と同様に処理を行う。すなわち、擬似リクエストを受信し、業務処理を実行し、擬似クライアントにレスポンスを返信する。
【００６３】
そしてステップＳ６０８で、ウェブアプリケーションからレスポンスメッセージが返信されると、擬似クライアントは、ユーザに追跡結果を表示する。
【００６４】
図９に追跡結果の表示の例を示す。画面の基本的な画面構成は図７と同様である。対象画面８０２には、ステップＳ６０７で返信されたＨＴＭＬを、通常のブラウザと同様の方法で表示する。パラメータ一覧８０３には、ステップＳ６０２で表示したパラメータに加え、さらにステップ６０７で返信されたＨＴＭＬに含まれるパラメータが新たに追加される。また図９の例では、新たに名前が「busho」であるパラメータが追加されている。本パラメータの送信先は「http://example.com/department」である。
【００６５】
さらにパラメータ一覧８０３には、ステップＳ６０２で表示したパラメータ（「item」パラメータと「bikou」パラメータ）について、監視部５０２によって監視した追跡結果が表示される。ここで使用箇所８１２には、ＳＱＬ文監視部５０８でトレース値が検出された場合は“ＳＱＬ文”、レスポンス監視部５０９でトレース値が検出された場合は“レスポンス”の文字が出力される。これにより、ユーザは各パラメータが、システム内のどの部分で使われているかを知ることができる。
【００６６】
そしてステップＳ６０９で、ユーザは、パラメータの追跡処理を続行するか、追跡処理を終了し、チェックルールの作成をするか選択する。ここで、追跡を終了する場合、ユーザはステップＳ６１０でチェックツール生成ボタン８１４を押す。チェックツール生成ボタン８１４が押されると、ステップＳ６１１で監視部５０２は監視を終了する。その後、ステップＳ６１２で、統合部５０３によりチェックルールが生成される。
【００６７】
なお、統合部には、予めチェックの方針を示したチェックポリシー５１０を設定しておく。チェックポリシーには、例えば図１０に示す情報を設定しておく。図１０の各行がそれぞれ一つのチェックポリシーを表している。１列目１１０１は、説明のために付けている行番号である。２列目１１０２は、パラメータの使用箇所を表す。パラメータの使用箇所としては、例えばＳＱＬ文やレスポンスメッセージなどがある。３列目１１０３は、禁止文字を表す。パラメータの値に、ここで指定した文字が含まれている場合、リクエストを拒否し、クライアントにエラーを返す。
【００６８】
すなわち、図１０の１行目１１０４は、ＳＱＬ文で使用するパラメータで、パラメータの値として、コロン（：）、セミコロン（；）、イコール（＝）、ダブルクオート（“）、シングルクオート（‘）のいずれかが使用されている場合には、リクエストを拒否してクライアントにエラーを返す、というチェックポリシーを表す。
【００６９】
ここで、コロン、セミコロン、イコール、ダブルクオート、シングルクオートなどの文字は、ＳＱＬでは特別の意味を持つため、これらの文字を悪用されるとＳＱＬインジェクション攻撃を受ける可能性がある。そこでこれらの文字の使用を禁止することで、ＳＱＬインジェクションを防ぐことができる。
【００７０】
また、図１０の２行目１１０５は、レスポンスメッセージのＨＴＭＬで使用するパラメータで、パラメータの値として、小なり括弧（＜）、大なり括弧（＞）、ダブルクオート（“）、シングルクオート（‘）、アンド（＆）のいずれかが使用されている場合には、リクエストを拒否してエラーを返す、というチェックポリシーを表す。
【００７１】
ここで、小なり括弧、大なり括弧、ダブルクオート、シングルクオート、アンドなどの文字は、スクリプトを記述する際に使用する文字であり、これらの文字を悪用されるとクロスサイトスクリプティング攻撃を受ける可能性がある。そこでこれらの文字の使用を禁止することで、クロスサイトスクリプティングを防ぐことができる。
【００７２】
さらに図１０の例では、この他にも、パラメータをＯＳコマンドとして使用する際に、ＯＳコマンドインジェクションを防ぐためのチェックポリシー（３行目１１０６）、パラメータをＬＤＡＰクリエとして使用する際に、ＬＤＡＰインジェクションを防ぐためのチェックポリシー（４行目１１０７）、パラメータをＸＰａｔｈクリエとして使用する際に、ＸＰａｔｈインジェクションを防ぐためのチェックポリシー（５行目１１０６）が設定してある。
【００７３】
そこで統合部５０３では、パラメータの追跡結果とチェックポリシー５１０を元に、チェックルール１０５を生成する。すなわちパラメータの追跡結果が図１１であった場合、生成されるチェックルールは、図１２のようになる。このようにして、図１０に示したチェックポリシーと図１１に示した追跡結果を付き合わせ、統合すれば、図１２に示すチェックルールは容易に生成することができる。
【００７４】
以上で説明した方法により、ウェブアプリケーション１０４の関する詳細な知識がなくても、容易にチェックルール１０３を生成することができる。セキュリティフィルタ１０３では、チェックルール１０５を利用して、適切なチェック処理を行うことができる。
【００７５】
こうして、本発明の通信情報監視装置によれば、ネットワークを介してクライアントにサービスを提供するシステムに使用される装置であって、トレース値を含むリクエストを送信する擬似クライアントと、システムの各箇所においてトレース値の監視を行う監視部とを備え、システムの各箇所におけるトレース値を監視することによりパラメータの使用箇所の特定を行うことによって、セキュリティの知識やウェブアプリケーションの詳細な知識がなくても、適切なチェックルールを容易に作成できるようになる。
【００７６】
なお、本発明は、以上説明した実施の形態に限定されるものではなく、特許請求の範囲に記載した本発明の要旨を逸脱しない範囲において、さらに多くの実施形態を含むものであることは言うまでもない。
【図面の簡単な説明】
【００７７】
【図１】本発明の実施形態に関わるシステムの構成図である。
【図２】本発明を実施する計算機のハードウェア構成図である。
【図３】その説明のためのウェブアプリケーションの内部構成図である。
【図４】本発明の適用される通信情報監視装置の内部構成図である。
【図５】本発明の適用されるチェックルール生成処理のフロー図である。
【図６】その説明のためのレスポンスメッセージの例を示す線図である。
【図７】その説明のための擬似クライアントが生成する出力画面の例を示す線図である。
【図８】その説明のための擬似クライアントが生成するリクエストメッセージの例を示す線図である。
【図９】その説明のための擬似クライアントが生成する追跡結果の例を示す線図である。
【図１０】その説明のためのチェックポリシーの例を示す線図である。
【図１１】その説明のためのパラメータ追跡結果の例を示す線図である。
【図１２】その説明のためのチェックツール生成装置によって生成されたチェックルールの例を示す線図である。
【図１３】パラメータのチェックを行うシステムの構成図である。
【符号の説明】
【００７８】
１０１…クライアント、１０３…セキュリティフィルタ、１０４…ウェブアプリケーション、１０５…チェックルール、２０１…通信情報監視装置、４０１…ＨＴＴＰ処理部、４０２…データベースアクセス部、４０３…業務処理部、４０４…業務データベース、５０１…擬似クライアント、５０２…監視部、５０３…統合部、５０４…画面入出力処理部、５０５…リクエスト生成部、５０６…ＨＴＴＰ処理部、５０７…レスポンス解析部、５０８…ＳＱＬ文監視部、５０９…レスポンス監視部、５１０…チェックポリシー
【図１】
2007004685.tif 000003
【図２】
2007004685.tif 000004
【図３】
2007004685.tif 000005
【図４】
2007004685.tif 000006
【図５】
2007004685.tif 000007
【図６】
2007004685.tif 000008
【図７】
2007004685.tif 000009
【図８】
2007004685.tif 000010
【図９】
2007004685.tif 000011
【図１０】
2007004685.tif 000012
【図１１】
2007004685.tif 000013
【図１２】
2007004685.tif 000014
【図１３】
2007004685.tif 000015