Ｗｅｂアプリケーション脆弱性動的検査方法およびシステム
【課題】Webアプリケーションソフトウェアに含まれる脆弱性を検出する際に、ソースコード中に記述された実行されないコードが原因の誤った検出が生じることがなく、プログラマが脆弱性の対策を行いやすいように脆弱性の原因となるコードのソースコード中での位置を指摘でき、検査データを対象Webアプリケーションに送信する回数が少なく効率的にすることを目的とする。
【解決手段】Webアプリケーションが提供するWebページへの検査要求を受け、Webアプリケーションを供給するサーバにおいて検査対象ページに対応するコードの中のWebアプリケーション外部からのデータを取得するメソッド呼び出し箇所を検査用コードに変更し脆弱性の検査用Webアプリケーションを構築する。検査対象ページに対してリクエストデータを送付し、そのレスポンスデータと予め登録してある脆弱性判定コードとを比較し脆弱性が含まれるかを判定し結果を出力する。
【解決手段】Webアプリケーションが提供するWebページへの検査要求を受け、Webアプリケーションを供給するサーバにおいて検査対象ページに対応するコードの中のWebアプリケーション外部からのデータを取得するメソッド呼び出し箇所を検査用コードに変更し脆弱性の検査用Webアプリケーションを構築する。検査対象ページに対してリクエストデータを送付し、そのレスポンスデータと予め登録してある脆弱性判定コードとを比較し脆弱性が含まれるかを判定し結果を出力する。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、Webアプリケーションソフトウェアを検査し、取り扱いに注意が必要なメソッド呼び出しによって生じる脆弱性の有無とそのソースコード内での位置および実行時にそのメソッドに渡されるデータの情報を提供する脆弱性検査の技術に関する。
【背景技術】
【０００２】
一般に、ソフトウェアに含まれる脆弱性を検査する方法には、ソフトウェアのソースコードを調べるソースコード静的解析方法と稼動中のソフトウェアを調べる稼動検査方法の２つがある。
【０００３】
ソースコード静的解析方法とは、ソースコードを検査してソースコード中に含まれる危険なコードを検出する技術である。このような技術の１つに、例えばRATSがある。これはあらかじめ用意した危険な関数データベースとソースコード中に含まれる関数呼び出しの比較を行い、一致した箇所を検出するというものである。RATSについては、下記非特許文献１の２章に詳しく述べられている。
【０００４】
稼動検査方法は、稼動しているソフトウェアに対して検査用のデータを入力した結果起こる動作から脆弱性が含まれるかどうか判断するという技術である。例えば、OWASPで公開されているWebScarabのManual Interceptプラグインを利用した検査が挙げられる。これは、稼動しているソフトウェアに対して送信されるデータをインターセプトし、そのデータに攻撃コードを含ませた後、当該ソフトウェアに対し送付し、その応答から、脆弱性の有無を判断するという検査方法である。
【０００５】
本発明は、ソフトウェアのうち、特にネットワーク上のWebサーバで用いられるWebアプリケーションソフトウェアの脆弱性を検査する技術に関するものである。Webアプリケーションソフトウェアに含まれる代表的な脆弱性には、クロスサイトスクリプティング脆弱性やSQLインジェクション脆弱性がある。これらは、それぞれ、HTMLに出力するメソッド呼び出しとSQL文を実行するメソッド呼び出し箇所で生じる。これらのメソッドに渡されるデータにソフトウェア外部からのデータが含まれる場合、該メソッドに渡される前に、該データに対し悪意のある者が攻撃を行うときに利用する特殊文字を無害化する処理を行うことが必要とされる。該無害化処理を行っていない場合、前記メソッド呼び出し箇所に脆弱性が存在する。以下の説明では、これらの脆弱性が生じる可能性のあるメソッドを脆弱メソッド、ソフトウェア外部からのデータを外部データ、外部データを受け取るためのメソッドを外部データ取得メソッドと呼ぶ。該外部データとは、例えば、クライアントからWebアプリケーションに対して送信されるリクエストデータ内のリクエストパラメータやヘッダフィールドの値がWebアプリケーションのソースコード内で利用されている場合の該リクエストパラメータと該ヘッダフィールドの値などである。
【非特許文献１】情報処理振興事業協会セキュリティセンター：オープンソース・ソフトウェアのセキュリティ確保に関する調査報告書 第II部 オープンソース・ソフトウェアの効率的な検査技術の調査：平成１５年２月
【発明の開示】
【発明が解決しようとする課題】
【０００６】
上記脆弱性を含むWebアプリケーションソフトウェアの検査をソースコード静的解析方法により行った場合、ソースコードだけから判断するため、例えば実際には実行されない箇所が原因で誤った検出が生じてしまうことがある。
【０００７】
一方、稼動検査方法により検査した場合、実行されない箇所が原因の誤った検出が生じることはないものの、プログラマが検査の後に脆弱性を修正する際に有効な、ソースコード内での脆弱性の原因となるコードの位置の情報は提供されない。そのため、プログラマがソースコード内で原因となる箇所を探す際の負担が大きい。また、稼動検査方法の場合、Webアプリケーションに対して送信されるリクエストデータに含まれるパラメータおよびヘッダフィールドのうち、どの値がWebアプリケーションのソースコード内で利用されているか分からないため、すべてのパラメータおよびヘッダフィールドについて、各値に擬似的な攻撃コードを設定して検査する必要がある。このように検査不要なパラメータやヘッダフィールドについても検査をするため、検査用のリクエストデータをWebアプリケーションに対し送信する回数が多く、効率が悪い。
【０００８】
本発明の目的は、ソースコード中に記述された実行されないコードが原因の誤った検出が生じることがなく、かつプログラマが脆弱性の対策を行いやすいように脆弱性の原因となるコードのソースコード中での位置を指摘でき、検査データを対象Webアプリケーションに送信する回数が少ない効率的な脆弱性検出方法およびシステムを提供することにある。
【課題を解決するための手段】
【０００９】
上記目的を達成するために、本発明は、サーバ上で稼働するWebアプリケーションの脆弱性を検査するため、所定の検査要求発行手段からサーバのWebアプリケーションが提供するWebページへ送信される検査要求を受け、該Webアプリケーションを供給するサーバにおいて該検査対象ページに対応するコードの中のWebアプリケーション外部からのデータを取得するメソッド呼び出し箇所を検査用のコードに変更し、脆弱性を検査するための検査用Webアプリケーションを構築し、該検査用Webアプリケーションの該検査ページに対して検査のためのリクエストデータを送付し、該リクエストデータに応じて出力されるレスポンスデータとあらかじめ登録してある脆弱性判定コードとを比較することにより、該Webアプリケーションに脆弱性が含まれるかどうかを判定し、その判定結果を出力することを特徴とするものである。
【００１０】
Webアプリケーション外部からのデータを取得するメソッドのソースコード中での位置に関する情報と、脆弱性を生じる可能性のあるメソッドのソースコード中での位置に関する情報と、実行時に該脆弱性を生じる可能性のあるメソッドに渡されるデータ値とを、取得し、一時結果レポートとして出力するメソッドを、前記Webアプリケーションのコード中に追加し、前記検査のためのリクエストに応じた処理の過程で前記メソッドにより前記一時結果レポートを出力する処理を行うようにしてもよい。
【００１１】
また、（１）前記Webアプリケーションにすべての検査用コードの定義を追加し、（２）前記Webアプリケーションの検査対象ページに、受信したリクエストデータに含まれるパラメータから動的にデータを取得するコードを、追加し、（３）前記Webアプリケーション外部からのデータを取得するメソッド呼び出し箇所を、前記リクエストデータに含まれるパラメータから動的に取得したデータに基づいて前記追加したすべての検査用コードの中から指定された、検査用コードを取得するコードに、変更する処理を行い、前記検査のためのリクエストデータのパラメータに、前記検査用コードを動的に指定するデータを含めて、リクエストデータを送付するようにしてもよい。
【発明の効果】
【００１２】
本発明によれば、Webアプリケーションソフトウェアに含まれる脆弱性の検査において、実行されない箇所が原因の誤った検出が生じることなく、かつ脆弱性の対策を行いやすいようにソースコード内での脆弱性の原因となるコードの位置の情報を提供することができる。また、検査データを対象Webアプリケーションに送信する回数が少なくて済む。
【発明を実施するための最良の形態】
【００１３】
以下、本発明の実施形態を図面により詳細に説明する。ここでは、Webアプリケーションが提供するある一つのWebページについて、そのページに入力されたデータが原因でWebアプリケーションのコード内のいずれかの場所で発生する脆弱性が存在するどうか検査する手法について説明する。
【００１４】
また以下の説明では、Java（登録商標）言語により記述されたWebアプリケーションを例として挙げるが、本処理手順は他のプログラミング言語で記述されたソースコードにも適用可能である。また以下の説明では検査対象のページに対応する中間コードを編集しているが、中間コードではなくソースコードを編集してもよい。一般的にソースコード中にその内容と直接関係のない脆弱性検知を目的とした情報を記述することは敬遠されるが、中間コードを編集した場合、ソースコードには変更を加えないという利点がある。Java（登録商標）の中間コードを編集する手段としてJakarta Projectが公開しているBCELを利用する方法などがある。
【００１５】
図１は、本発明の一実施の形態を表すシステム構成図である。
【００１６】
図１において、サーバ１とクライアント２は、ネットワーク３によって接続されている。サーバ１は、ＣＰＵ１１Ａおよびメモリ１１Ｂを備えた端末装置１１、外部記憶装置１２、および通信ポート１３を備える。外部記憶装置１２には、Webアプリケーションを記述したソースコードをコンパイルした結果生成される中間コード群１２Ａと、そのWebアプリケーションの中間コードを編集する手段であるWebアプリケーション管理手段１２Ｂと、APIとして提供されている外部データ取得メソッドを登録した外部データ取得メソッドDB１２Ｃと、APIとして提供されている脆弱メソッドを登録した脆弱メソッドDB１２Ｄと、脆弱性の検査のための攻撃コードを登録した擬似攻撃コードDB１２Ｅと、検査によって得られた脆弱性を生じる可能性のあるコードに関する情報を一時的に記録するための一時結果レポート１２Ｆと、Webアプリケーションの稼動環境であるWebアプリケーション供給手段１２Ｇとが格納されている。ここで、Webアプリケーション供給手段１２Ｇとは、Jakarta Projectが公開しているTomcatなどを指す。外部データ取得メソッドDB１２Ｃの例は図５で、脆弱メソッドDB１２Ｄの例は図６で、擬似攻撃コードDB１２Ｅの例は図７(a)で、それぞれ説明する。
【００１７】
クライアント２は、ＣＰＵ２１Ａおよびメモリ２１Ｂを備えた端末装置２１、外部記憶装置２２、および通信ポート２３を備える。外部記憶装置２２には、脆弱性を判定するための手段である脆弱性判定手段２２Ａと、クライアントからWebアプリケーションに対し入力される、Webアプリケーション開発者が想定する正常なパラメータ値を登録したリクエストパラメータDB２２Ｂと、脆弱性判定手段が利用するための判断基準であるレスポンス脆弱性判定DB２２Ｃと、脆弱性検査の結果を記述する結果レポート２２Ｄとが格納されている。リクエストパラメータDB２２Ｂの例は図８(a)で、レスポンス脆弱性判定DB２２Ｃの例は図１１で、それぞれ説明する。
【００１８】
図１にはサーバ１とクライアント２の二台の装置を例示したが、外部記憶装置１２および外部記憶装置２２の両方に格納された手段およびデータを併せ持つ外部記憶装置を有する一台の装置で実現することもできる。
【００１９】
図２は、クライアント端末２の脆弱性判定手段２２Ａ、サーバ１のWebアプリケーション管理手段１２Ｂ、およびサーバ１のWebアプリケーション供給手段１２Ｇの間でやりとりされる命令およびデータの流れを示した図である。なお、Webアプリケーションの中間コード群１２Ａは適切な場所に配置されており、Webアプリケーション供給手段１２Ｇによりサービスを提供可能な状態にあるとする。
【００２０】
まず始めに、脆弱性判定手段２２Ａは、リクエストパラメータDB２２Ｂ（例えば図８(a)）から検査対象ページに対するリクエストパラメータの情報を取得する（手順２００）。そして、検査対象のページ名称をWebアプリケーション管理手段１２Ｂに伝える（手順２０１）。
【００２１】
Webアプリケーション管理手段１２Ｂは、外部データ取得メソッドDB１２Ｃ、脆弱メソッドDB１２Ｄ、および擬似攻撃コードDB１２Ｅを読み込む（手順２０２）。検査対象ページに対応する中間コード内から脆弱メソッド呼び出し（脆弱メソッドDB１２Ｄに登録されているもの）をすべて探し、その呼び出し箇所の前に、呼び出しが行われたクラスと行番号、脆弱メソッド名、および実行時に脆弱メソッドの脆弱性の原因となる引数に渡されるデータ値を一時結果レポート１２Ｆに出力するメソッドを、追加する。行番号の代わりに呼び出しが行われたメソッド定義を出力してもよい（手順２０３）。次に、Webアプリケーション管理手段１２Ｂは、擬似攻撃コードDB１２Ｅ（例えば図７(a)）から取得した攻撃コードのリストとその各要素を取得するメソッドが定義された中間コード（例えば図７(b)のソースの中間コード）を生成し、対象Webアプリケーションの中間コード群１２Ａに追加する（手順２０４）。
【００２２】
次に、Webアプリケーション管理手段１２Ｂは、検査対象ページに対応する中間コード内の外部データ取得メソッド呼び出し（外部データ取得メソッドDB１２Ｃに登録されているもの）を探す。見つからない場合は、検査を終了し、脆弱性判定手段２２Ａに対し終了を通知する（手順２１５）。一方、外部データ取得メソッド呼び出しが見つかった場合、そのメソッド呼び出しを、攻撃コードのリストの一要素を取得するメソッドに、変更する。また、その外部データ取得メソッド呼び出しが行われたクラスと行番号、該当メソッド名、および攻撃コードを一時結果レポート１２Ｆに出力するメソッドを追加する。行番号の代わりに呼び出しが行われたメソッド定義を出力してもよい（手順２０５）。そして、検査用Webアプリケーション構築完了通知を脆弱性判定手段２２Ａに送付する（手順２０６）。
【００２３】
クライアント２の脆弱性判定手段２２Ａは、前記手順２００により取得したリクエストパラメータの情報を元にして当該検査対象ページに対するリクエスト（例えば図８(b)）を送る（手順２０７）。Webアプリケーション供給手段１２Ｇにより供給されているWebアプリケーションは、そのリクエストを処理し、脆弱性判定手段２２Ａに対しレスポンス（例えば図９または図１０）を送付する。このリクエスト処理の過程で、一時結果レポート１２Ｆへの出力が行われる（手順２０８、２０９）。
【００２４】
クライアント２の脆弱性判定手段２２Ａは、受信したレスポンスとレスポンス脆弱性判定DB２２Ｃ（例えば図１１）から脆弱性かどうかを判断する（手順２１０）。脆弱性である場合、Webアプリケーション管理手段１２Ｂに対し、一時結果レポート要求を送る（手順２１１）。Webアプリケーション管理手段１２Ｂは、一時結果レポート１２Ｆを脆弱性判定手段２２Ａに送付する（手順２１２）。そして、脆弱性判定手段２２Ａは、当該一時結果レポート１２Ｆの内容を結果レポート２２Ｄに出力する。一方、手順２１０の判断で脆弱性ではないと判断した場合、脆弱性判定手段２２Ａは、結果レポート２２Ｄに何も出力しない（手順２１３）。
【００２５】
次に、脆弱性判定手段２２Ａは、Webアプリケーション管理手段１２Ｂに対して判定終了通知を送付する（手順２１４）。
【００２６】
手順２０５から手順２１４までは、外部データ取得メソッド呼び出しの数および攻撃コードの要素数だけ繰り返し行う。すなわち、手順２１４を終えたとき、先の手順２０５で使った攻撃コードのリストの一要素が該リストに登録された最後の要素でない場合には、同じ外部データ取得メソッド呼び出し箇所に対して、次の攻撃コード要素を用いて、手順２０５からの処理に移る。一方、攻撃コードリストの最後の要素である場合には、検査対象ページの中間コード中の次の外部データ取得メソッド呼び出しを検索する。見つからない場合は検査を終了し、脆弱性判定手段２２Ａに対し終了を通知する（手順２１５）。見つかった場合、その外部データ取得メソッド呼び出しに対して手順２０５からの処理を続行する。
【００２７】
図３は、サーバ１のWebアプリケーション管理手段１２Ｂの詳細な動作を示すフローチャートである。
【００２８】
Webアプリケーション管理手段１２Ｂは、脆弱性判定手段２２Ａより検査対象ページ名を取得する（手順３０１）。次に、Webアプリケーション管理手段１２Ｂは、外部データ取得メソッドDB１２Ｃ、脆弱メソッドDB１２Ｄ、および擬似攻撃コードDB１２Ｅを読み込む（手順３０２：図２の手順２０２に対応）。
【００２９】
検査対象ページに対応する中間コード内の脆弱メソッド呼び出しをすべて探し、その呼び出しと同じ行の直前箇所に、呼び出しが行われたクラスと行番号、脆弱メソッド名、および実行時に脆弱メソッドの脆弱性の原因となる引数に渡されるデータ値を一時結果レポート１２Ｆに出力するメソッドを、追加する。行番号の代わりに、呼び出しが行われたメソッド定義を出力してもよい（手順３０３：図２の手順２０３に対応）。次に、Webアプリケーション管理手段１２Ｂは、擬似攻撃コードDB１２Ｅから取得した攻撃コードのリストとその各要素を取得するメソッドが定義された中間コードを生成し、対象Webアプリケーションの中間コード群１２Ａに追加する（手順３０４：図２の手順２０４に対応）。
【００３０】
次に、攻撃コードリストの各要素を識別するためのインデックスであるiに1を代入する。また、コード中の外部データ取得メソッド呼び出しを識別するためのインデックスであるjに１を代入する（手順３０５）。検査対象ページの中間コードから、j番目の外部データ取得メソッド呼び出しを探す（手順３０６）。該メソッドが見つからない場合（手順３０７）、すなわち当該中間コード内に存在する全ての外部データ取得メソッドについて処理を終えている場合は、検査を終了し、脆弱性判定手段２２Ａに対し終了を通知する（手順３１４：図２の手順２１５に対応）。
【００３１】
一方、j番目の外部データ取得メソッド呼び出しが見つかった場合、該メソッド呼び出しを攻撃コードリストの一要素を取得するメソッドに変更する。また、呼び出しが行われたクラスと行番号、該当メソッド名、および攻撃コードを一時結果レポート１２Ｆに出力するメソッドを、追加する。行番号の代わりに、呼び出しが行われたメソッド定義を出力してもよい（手順３０８：図２の手順２０５に対応）。そして、検査用Webアプリ構築完了通知を脆弱性判定手段２２Ａに送付し（手順３０９：図２の手順２０６に対応）、待ち状態となる。
【００３２】
脆弱性判定手段２２Ａから一時結果レポート要求（図２の手順２１１で発行されたもの）を受信すると、一時結果レポート１２Ｆを脆弱性判定手段２２Ａに送付する。送付後、一時結果レポート１２Ｆを初期化する（手順３１０：図２の手順２１２に対応）。次に、iにi+1を代入する（手順３１１）。iと攻撃コード総数を比較し、両者が等しいか、または攻撃コード総数の方が大きい場合、次の攻撃コード要素を用いて処理を続行するため、手順３０８の処理に移る。そうでない場合、以下の手順３１３に移る（手順３１２）。次に、iに1を代入し、jにj+1を代入する（手順３１３）。手順３１３の後、手順３０６に戻る。
【００３３】
図３の手順３０８では、変数iの値を用いて攻撃コードi番目要素取得メソッドに変更しているが、このiの部分をクライアントから与えられる動的な値とし、検査対象コードにその値をクライアントからのリクエストパラメータ値として受信するためのコードを追加するという方法もある。この場合、検査対象コードを編集する回数が少なくて済む。
【００３４】
図４は、クライアント２の脆弱性判定手段２２Ａの詳細な動作を示すフローチャートである。まず始めに、脆弱性判定手段２２Ａは、リクエストパラメータDB２２Ｂから検査対象ページに対するリクエストパラメータの情報を取得する（手順４０１：図２の手順２００に対応）。そして、検査対象のページ名称をWebアプリケーション管理手段１２Ｂに伝える（手順４０２：図２の手順２０１に対応）。その後、一旦、待ち状態となる。
【００３５】
Webアプリケーション管理手段１２Ｂは、図２で説明したように手順２０２〜２０６を経て検査用Webアプリケーション構築完了通知を脆弱性判定手段２２Ａへ送る。該検査用Webアプリケーション構築完了通知を受けとった脆弱性判定手段２２Ａは、前記手順４０１により取得したリクエストパラメータの情報を元にして検査対象ページに対してリクエストを送る（手順４０３：図２の手順２０７に対応）。そして、待ち状態となる。当該リクエストは、図２の手順２０８でWebアプリケーション供給手段１２Ｇにより処理され、レスポンスが送信される（図２の手順２０９）。
【００３６】
当該レスポンスを受信した脆弱性判定手段２２Ａは、そのレスポンスとレスポンス脆弱性判定DB２２Ｃから脆弱性かどうかを判断し（手順４０６：図２の手順２１０）、脆弱性である場合、Webアプリケーション管理手段１２Ｂから一時結果レポート１２Ｆを取得する（手順４０７：図２の手順２１１，２１２に対応）。その内容を結果レポート２２Ｄに出力し（手順４０８：図２の手順２１３に対応）、手順４０９に移る。そうでない場合、結果レポート２２Ｄには何も出力せず、手順４０９に移る。最後に、判定終了通知をWebアプリケーション管理手段１２Ｂに送付する（手順４０９：図２の手順２１４に対応）。そして、待ち状態となる。
【００３７】
なお、図２でも説明した通り、検査用Webアプリケーション構築完了通知は、外部データ取得メソッド呼び出しの数および攻撃コードの要素数だけ繰り返し出力されるから、引き続き、検査用Webアプリケーション構築完了通知を受信した場合は、手順４０３に移るものとする。一方、終了通知を受け取った場合は検査を終了する。
【００３８】
図５は、外部データ取得メソッドDB１２Ｃの例である。本DBは、サーバ１において、APIで提供されている外部データ取得メソッドの名前５０１を登録しておくDBである。
【００３９】
図６は、脆弱メソッドDB１２Ｄの例である。本DBは、サーバ１において、APIで提供されている脆弱メソッドについての情報を登録しておくDBである。本DBには、脆弱メソッド名６０１と、脆弱性の原因となる引数の位置を表す引数番号６０２との組データを登録しておく。
【００４０】
図７(a)は、擬似攻撃コードDB１２Ｅの例である。本DBは、サーバ１において、検査をするために用いる攻撃コード７０１を登録するDBである。ここでは、攻撃コード要素を１つだけ図示した。
【００４１】
図７(b)は、攻撃コードリストとその各要素を取得するためのメソッドを定義したソースコードの例である。図３の手順３０４（図２の手順２０４）で、このソースコードに対応する中間コードを中間コード群１２Ａに追加する。
【００４２】
図８(a)は、クライアントからWebアプリケーションに対し入力される、Webアプリケーション開発者が想定する正常なリクエストパラメータ値を登録したリクエストパラメータDB２２Ｂの例である。本DBには、検査対象ページのＵＲＬ８０１、パラメータ名８０２、およびパラメータ値８０３の組データを登録しておく。この例では一つの検査対象ページに対して一つのパラメータしか示していないが、複数のパラメータがあっても良く、その場合、同じＵＲＬでパラメータ名が異なる複数のレコードが登録される。ヘッダフィールドについては、通常のHTTPのリクエスト発行時に設定されるため、特に登録する必要はない。
【００４３】
図８(b)は、図８(a)に対応するリクエストデータの例である。このようなリクエストデータが、手順４０３（図２の手順２０７）で脆弱性判定手段２２ＡからWebアプリケーション供給手段１２Ｇに対して送信される。前記WebScarabなどを使用した従来の稼動検査方式では、リクエストデータ内のどのリクエストパラメータとヘッダフィールドの値がWebアプリケーションで利用されているか分からないため、すべてについて検査をする必要があった。例えば、図８(b)の場合、リクエストパラメータnameとヘッダフィールドHostの両方に、攻撃コードを含ませて検査していた。一方、本発明では、Webアプリケーション内の外部データ取得メソッド箇所に攻撃コードを含ませて検査する。
【００４４】
図９は、図８(b)のリクエストデータを送付した場合のレスポンスの例である。これは、手順４０６（図２の手順２１０）で脆弱ではないと判断されるものの一例である。
【００４５】
図１０は、攻撃コードを検査対象コードに埋め込み検査した結果、その攻撃が成功した場合のレスポンスデータの例である。図８(b)のパラメータnameの値を取得するメソッドの代わりに、図７(a)に登録の攻撃コードに変更した場合のレスポンスを示している。これは、手順４０６で脆弱であると判断されるものの一例である。
【００４６】
図１１は、レスポンス脆弱性判定DB２２Ｃの例である。本DBは、レスポンス脆弱性判定コード８０１を登録するDBである。このDBに登録されたコードがレスポンスデータに含まれていた場合に、脆弱性であると判断する。この例以外に、レスポンス脆弱性判定コード８０１に想定されるレスポンスデータをすべて登録しておき、それ以外のレスポンスデータが得られた場合に脆弱性であると判定するというような使用方法が考えられる。
【００４７】
図１２は、脆弱性検査の結果が記述された結果レポート２２Ｄの例である。この結果レポート２２Ｄは、外部データ取得メソッドの呼び出しが行われたクラス名１２１および呼び出し行番号１２２と、外部データ取得メソッド名１２３と、攻撃コード１２４と、脆弱メソッドの呼び出しが行われたクラス名１２５および呼び出し行番号１２６と、脆弱メソッド名１２７と、実行時に脆弱性の原因となる脆弱メソッドの引数箇所に与えられた実行時引数データ値１２８との組データからなる。この引数箇所は、脆弱メソッドDB１２Ｄの引数番号６０２に登録されている値から決まる。行番号の代わりに呼び出しが行われたメソッド定義としてもよい。
【００４８】
この結果レポート２２Ｄの例では、検査対象Webアプリケーションに脆弱性が含まれていることと、その原因となる外部データ取得箇所、および脆弱性が生じている脆弱メソッド呼び出し箇所の候補が分かる。実行時引数データ値より二つの脆弱メソッド呼び出し箇所のうち２１行目が原因であると判断できる。この脆弱メソッド呼び出し箇所の候補をあらかじめ絞る方法として、手順３０３において実行時引数データ値の中に擬似攻撃コードDB１２Ｅに登録された攻撃コードが含まれたもののみ、一時結果レポート１２Ｆに出力するという方法がある。
【図面の簡単な説明】
【００４９】
【図１】本発明の一実施の形態を表すシステム構成図である。
【図２】クライアント端末の脆弱性判定手段、サーバのWebアプリケーション管理手段、サーバのWebアプリケーション供給手段の間でやりとりされる命令およびデータの流れを示した図である。
【図３】Webアプリケーション管理手段の動作を示すフローチャートである。
【図４】脆弱性判定手段の動作を示すフローチャートである。
【図５】APIで提供されている外部データ取得メソッドについての情報を登録しておくための外部データ取得メソッドDBの例である。
【図６】APIで提供されている脆弱メソッドについての情報を登録しておくための脆弱メソッドDBの例である。
【図７】擬似攻撃コードDBの例、および攻撃コードリストとその各要素を取得するためのメソッドを定義したソースコードの例である。
【図８】Webアプリケーションに対してクライアントから入力される、Webアプリケーション開発者が想定する正常なパラメータ値を登録したリクエストパラメータDBの例、およびリクエストデータの例である。
【図９】リクエストデータを送付した場合のレスポンスの例であり、脆弱ではないと判断されるものの一例である。
【図１０】攻撃コードを検査対象コードに埋め込み検査した結果、その攻撃が成功した場合のレスポンスデータの例であり、脆弱であると判断されるものの一例である。
【図１１】レスポンス脆弱性判定DBの例である。
【図１２】脆弱性検査の結果が記述された結果レポートの例である。
【符号の説明】
【００５０】
１１Ａ、２１Ａ…ＣＰＵ、１１Ｂ、２１Ｂ…メモリ、１３、２３…通信ポート、１１、２１…端末装置、１２、２２…外部記憶装置、３…ネットワーク、１２Ａ…Webアプリケーション中間コード群、１２Ｂ…Webアプリケーション管理手段、１２Ｃ…外部データ取得メソッドDB、１２Ｄ…脆弱メソッドDB、１２Ｅ…擬似攻撃コードDB、１２Ｆ…一時結果レポート、１２Ｇ…Webアプリケーション供給手段、２２Ａ…脆弱性判定手段、２２Ｂ…リクエストパラメータDB、２２Ｃ…レスポンス脆弱性判定DB、２２Ｄ…結果レポート。
【技術分野】
【０００１】
本発明は、Webアプリケーションソフトウェアを検査し、取り扱いに注意が必要なメソッド呼び出しによって生じる脆弱性の有無とそのソースコード内での位置および実行時にそのメソッドに渡されるデータの情報を提供する脆弱性検査の技術に関する。
【背景技術】
【０００２】
一般に、ソフトウェアに含まれる脆弱性を検査する方法には、ソフトウェアのソースコードを調べるソースコード静的解析方法と稼動中のソフトウェアを調べる稼動検査方法の２つがある。
【０００３】
ソースコード静的解析方法とは、ソースコードを検査してソースコード中に含まれる危険なコードを検出する技術である。このような技術の１つに、例えばRATSがある。これはあらかじめ用意した危険な関数データベースとソースコード中に含まれる関数呼び出しの比較を行い、一致した箇所を検出するというものである。RATSについては、下記非特許文献１の２章に詳しく述べられている。
【０００４】
稼動検査方法は、稼動しているソフトウェアに対して検査用のデータを入力した結果起こる動作から脆弱性が含まれるかどうか判断するという技術である。例えば、OWASPで公開されているWebScarabのManual Interceptプラグインを利用した検査が挙げられる。これは、稼動しているソフトウェアに対して送信されるデータをインターセプトし、そのデータに攻撃コードを含ませた後、当該ソフトウェアに対し送付し、その応答から、脆弱性の有無を判断するという検査方法である。
【０００５】
本発明は、ソフトウェアのうち、特にネットワーク上のWebサーバで用いられるWebアプリケーションソフトウェアの脆弱性を検査する技術に関するものである。Webアプリケーションソフトウェアに含まれる代表的な脆弱性には、クロスサイトスクリプティング脆弱性やSQLインジェクション脆弱性がある。これらは、それぞれ、HTMLに出力するメソッド呼び出しとSQL文を実行するメソッド呼び出し箇所で生じる。これらのメソッドに渡されるデータにソフトウェア外部からのデータが含まれる場合、該メソッドに渡される前に、該データに対し悪意のある者が攻撃を行うときに利用する特殊文字を無害化する処理を行うことが必要とされる。該無害化処理を行っていない場合、前記メソッド呼び出し箇所に脆弱性が存在する。以下の説明では、これらの脆弱性が生じる可能性のあるメソッドを脆弱メソッド、ソフトウェア外部からのデータを外部データ、外部データを受け取るためのメソッドを外部データ取得メソッドと呼ぶ。該外部データとは、例えば、クライアントからWebアプリケーションに対して送信されるリクエストデータ内のリクエストパラメータやヘッダフィールドの値がWebアプリケーションのソースコード内で利用されている場合の該リクエストパラメータと該ヘッダフィールドの値などである。
【非特許文献１】情報処理振興事業協会セキュリティセンター：オープンソース・ソフトウェアのセキュリティ確保に関する調査報告書 第II部 オープンソース・ソフトウェアの効率的な検査技術の調査：平成１５年２月
【発明の開示】
【発明が解決しようとする課題】
【０００６】
上記脆弱性を含むWebアプリケーションソフトウェアの検査をソースコード静的解析方法により行った場合、ソースコードだけから判断するため、例えば実際には実行されない箇所が原因で誤った検出が生じてしまうことがある。
【０００７】
一方、稼動検査方法により検査した場合、実行されない箇所が原因の誤った検出が生じることはないものの、プログラマが検査の後に脆弱性を修正する際に有効な、ソースコード内での脆弱性の原因となるコードの位置の情報は提供されない。そのため、プログラマがソースコード内で原因となる箇所を探す際の負担が大きい。また、稼動検査方法の場合、Webアプリケーションに対して送信されるリクエストデータに含まれるパラメータおよびヘッダフィールドのうち、どの値がWebアプリケーションのソースコード内で利用されているか分からないため、すべてのパラメータおよびヘッダフィールドについて、各値に擬似的な攻撃コードを設定して検査する必要がある。このように検査不要なパラメータやヘッダフィールドについても検査をするため、検査用のリクエストデータをWebアプリケーションに対し送信する回数が多く、効率が悪い。
【０００８】
本発明の目的は、ソースコード中に記述された実行されないコードが原因の誤った検出が生じることがなく、かつプログラマが脆弱性の対策を行いやすいように脆弱性の原因となるコードのソースコード中での位置を指摘でき、検査データを対象Webアプリケーションに送信する回数が少ない効率的な脆弱性検出方法およびシステムを提供することにある。
【課題を解決するための手段】
【０００９】
上記目的を達成するために、本発明は、サーバ上で稼働するWebアプリケーションの脆弱性を検査するため、所定の検査要求発行手段からサーバのWebアプリケーションが提供するWebページへ送信される検査要求を受け、該Webアプリケーションを供給するサーバにおいて該検査対象ページに対応するコードの中のWebアプリケーション外部からのデータを取得するメソッド呼び出し箇所を検査用のコードに変更し、脆弱性を検査するための検査用Webアプリケーションを構築し、該検査用Webアプリケーションの該検査ページに対して検査のためのリクエストデータを送付し、該リクエストデータに応じて出力されるレスポンスデータとあらかじめ登録してある脆弱性判定コードとを比較することにより、該Webアプリケーションに脆弱性が含まれるかどうかを判定し、その判定結果を出力することを特徴とするものである。
【００１０】
Webアプリケーション外部からのデータを取得するメソッドのソースコード中での位置に関する情報と、脆弱性を生じる可能性のあるメソッドのソースコード中での位置に関する情報と、実行時に該脆弱性を生じる可能性のあるメソッドに渡されるデータ値とを、取得し、一時結果レポートとして出力するメソッドを、前記Webアプリケーションのコード中に追加し、前記検査のためのリクエストに応じた処理の過程で前記メソッドにより前記一時結果レポートを出力する処理を行うようにしてもよい。
【００１１】
また、（１）前記Webアプリケーションにすべての検査用コードの定義を追加し、（２）前記Webアプリケーションの検査対象ページに、受信したリクエストデータに含まれるパラメータから動的にデータを取得するコードを、追加し、（３）前記Webアプリケーション外部からのデータを取得するメソッド呼び出し箇所を、前記リクエストデータに含まれるパラメータから動的に取得したデータに基づいて前記追加したすべての検査用コードの中から指定された、検査用コードを取得するコードに、変更する処理を行い、前記検査のためのリクエストデータのパラメータに、前記検査用コードを動的に指定するデータを含めて、リクエストデータを送付するようにしてもよい。
【発明の効果】
【００１２】
本発明によれば、Webアプリケーションソフトウェアに含まれる脆弱性の検査において、実行されない箇所が原因の誤った検出が生じることなく、かつ脆弱性の対策を行いやすいようにソースコード内での脆弱性の原因となるコードの位置の情報を提供することができる。また、検査データを対象Webアプリケーションに送信する回数が少なくて済む。
【発明を実施するための最良の形態】
【００１３】
以下、本発明の実施形態を図面により詳細に説明する。ここでは、Webアプリケーションが提供するある一つのWebページについて、そのページに入力されたデータが原因でWebアプリケーションのコード内のいずれかの場所で発生する脆弱性が存在するどうか検査する手法について説明する。
【００１４】
また以下の説明では、Java（登録商標）言語により記述されたWebアプリケーションを例として挙げるが、本処理手順は他のプログラミング言語で記述されたソースコードにも適用可能である。また以下の説明では検査対象のページに対応する中間コードを編集しているが、中間コードではなくソースコードを編集してもよい。一般的にソースコード中にその内容と直接関係のない脆弱性検知を目的とした情報を記述することは敬遠されるが、中間コードを編集した場合、ソースコードには変更を加えないという利点がある。Java（登録商標）の中間コードを編集する手段としてJakarta Projectが公開しているBCELを利用する方法などがある。
【００１５】
図１は、本発明の一実施の形態を表すシステム構成図である。
【００１６】
図１において、サーバ１とクライアント２は、ネットワーク３によって接続されている。サーバ１は、ＣＰＵ１１Ａおよびメモリ１１Ｂを備えた端末装置１１、外部記憶装置１２、および通信ポート１３を備える。外部記憶装置１２には、Webアプリケーションを記述したソースコードをコンパイルした結果生成される中間コード群１２Ａと、そのWebアプリケーションの中間コードを編集する手段であるWebアプリケーション管理手段１２Ｂと、APIとして提供されている外部データ取得メソッドを登録した外部データ取得メソッドDB１２Ｃと、APIとして提供されている脆弱メソッドを登録した脆弱メソッドDB１２Ｄと、脆弱性の検査のための攻撃コードを登録した擬似攻撃コードDB１２Ｅと、検査によって得られた脆弱性を生じる可能性のあるコードに関する情報を一時的に記録するための一時結果レポート１２Ｆと、Webアプリケーションの稼動環境であるWebアプリケーション供給手段１２Ｇとが格納されている。ここで、Webアプリケーション供給手段１２Ｇとは、Jakarta Projectが公開しているTomcatなどを指す。外部データ取得メソッドDB１２Ｃの例は図５で、脆弱メソッドDB１２Ｄの例は図６で、擬似攻撃コードDB１２Ｅの例は図７(a)で、それぞれ説明する。
【００１７】
クライアント２は、ＣＰＵ２１Ａおよびメモリ２１Ｂを備えた端末装置２１、外部記憶装置２２、および通信ポート２３を備える。外部記憶装置２２には、脆弱性を判定するための手段である脆弱性判定手段２２Ａと、クライアントからWebアプリケーションに対し入力される、Webアプリケーション開発者が想定する正常なパラメータ値を登録したリクエストパラメータDB２２Ｂと、脆弱性判定手段が利用するための判断基準であるレスポンス脆弱性判定DB２２Ｃと、脆弱性検査の結果を記述する結果レポート２２Ｄとが格納されている。リクエストパラメータDB２２Ｂの例は図８(a)で、レスポンス脆弱性判定DB２２Ｃの例は図１１で、それぞれ説明する。
【００１８】
図１にはサーバ１とクライアント２の二台の装置を例示したが、外部記憶装置１２および外部記憶装置２２の両方に格納された手段およびデータを併せ持つ外部記憶装置を有する一台の装置で実現することもできる。
【００１９】
図２は、クライアント端末２の脆弱性判定手段２２Ａ、サーバ１のWebアプリケーション管理手段１２Ｂ、およびサーバ１のWebアプリケーション供給手段１２Ｇの間でやりとりされる命令およびデータの流れを示した図である。なお、Webアプリケーションの中間コード群１２Ａは適切な場所に配置されており、Webアプリケーション供給手段１２Ｇによりサービスを提供可能な状態にあるとする。
【００２０】
まず始めに、脆弱性判定手段２２Ａは、リクエストパラメータDB２２Ｂ（例えば図８(a)）から検査対象ページに対するリクエストパラメータの情報を取得する（手順２００）。そして、検査対象のページ名称をWebアプリケーション管理手段１２Ｂに伝える（手順２０１）。
【００２１】
Webアプリケーション管理手段１２Ｂは、外部データ取得メソッドDB１２Ｃ、脆弱メソッドDB１２Ｄ、および擬似攻撃コードDB１２Ｅを読み込む（手順２０２）。検査対象ページに対応する中間コード内から脆弱メソッド呼び出し（脆弱メソッドDB１２Ｄに登録されているもの）をすべて探し、その呼び出し箇所の前に、呼び出しが行われたクラスと行番号、脆弱メソッド名、および実行時に脆弱メソッドの脆弱性の原因となる引数に渡されるデータ値を一時結果レポート１２Ｆに出力するメソッドを、追加する。行番号の代わりに呼び出しが行われたメソッド定義を出力してもよい（手順２０３）。次に、Webアプリケーション管理手段１２Ｂは、擬似攻撃コードDB１２Ｅ（例えば図７(a)）から取得した攻撃コードのリストとその各要素を取得するメソッドが定義された中間コード（例えば図７(b)のソースの中間コード）を生成し、対象Webアプリケーションの中間コード群１２Ａに追加する（手順２０４）。
【００２２】
次に、Webアプリケーション管理手段１２Ｂは、検査対象ページに対応する中間コード内の外部データ取得メソッド呼び出し（外部データ取得メソッドDB１２Ｃに登録されているもの）を探す。見つからない場合は、検査を終了し、脆弱性判定手段２２Ａに対し終了を通知する（手順２１５）。一方、外部データ取得メソッド呼び出しが見つかった場合、そのメソッド呼び出しを、攻撃コードのリストの一要素を取得するメソッドに、変更する。また、その外部データ取得メソッド呼び出しが行われたクラスと行番号、該当メソッド名、および攻撃コードを一時結果レポート１２Ｆに出力するメソッドを追加する。行番号の代わりに呼び出しが行われたメソッド定義を出力してもよい（手順２０５）。そして、検査用Webアプリケーション構築完了通知を脆弱性判定手段２２Ａに送付する（手順２０６）。
【００２３】
クライアント２の脆弱性判定手段２２Ａは、前記手順２００により取得したリクエストパラメータの情報を元にして当該検査対象ページに対するリクエスト（例えば図８(b)）を送る（手順２０７）。Webアプリケーション供給手段１２Ｇにより供給されているWebアプリケーションは、そのリクエストを処理し、脆弱性判定手段２２Ａに対しレスポンス（例えば図９または図１０）を送付する。このリクエスト処理の過程で、一時結果レポート１２Ｆへの出力が行われる（手順２０８、２０９）。
【００２４】
クライアント２の脆弱性判定手段２２Ａは、受信したレスポンスとレスポンス脆弱性判定DB２２Ｃ（例えば図１１）から脆弱性かどうかを判断する（手順２１０）。脆弱性である場合、Webアプリケーション管理手段１２Ｂに対し、一時結果レポート要求を送る（手順２１１）。Webアプリケーション管理手段１２Ｂは、一時結果レポート１２Ｆを脆弱性判定手段２２Ａに送付する（手順２１２）。そして、脆弱性判定手段２２Ａは、当該一時結果レポート１２Ｆの内容を結果レポート２２Ｄに出力する。一方、手順２１０の判断で脆弱性ではないと判断した場合、脆弱性判定手段２２Ａは、結果レポート２２Ｄに何も出力しない（手順２１３）。
【００２５】
次に、脆弱性判定手段２２Ａは、Webアプリケーション管理手段１２Ｂに対して判定終了通知を送付する（手順２１４）。
【００２６】
手順２０５から手順２１４までは、外部データ取得メソッド呼び出しの数および攻撃コードの要素数だけ繰り返し行う。すなわち、手順２１４を終えたとき、先の手順２０５で使った攻撃コードのリストの一要素が該リストに登録された最後の要素でない場合には、同じ外部データ取得メソッド呼び出し箇所に対して、次の攻撃コード要素を用いて、手順２０５からの処理に移る。一方、攻撃コードリストの最後の要素である場合には、検査対象ページの中間コード中の次の外部データ取得メソッド呼び出しを検索する。見つからない場合は検査を終了し、脆弱性判定手段２２Ａに対し終了を通知する（手順２１５）。見つかった場合、その外部データ取得メソッド呼び出しに対して手順２０５からの処理を続行する。
【００２７】
図３は、サーバ１のWebアプリケーション管理手段１２Ｂの詳細な動作を示すフローチャートである。
【００２８】
Webアプリケーション管理手段１２Ｂは、脆弱性判定手段２２Ａより検査対象ページ名を取得する（手順３０１）。次に、Webアプリケーション管理手段１２Ｂは、外部データ取得メソッドDB１２Ｃ、脆弱メソッドDB１２Ｄ、および擬似攻撃コードDB１２Ｅを読み込む（手順３０２：図２の手順２０２に対応）。
【００２９】
検査対象ページに対応する中間コード内の脆弱メソッド呼び出しをすべて探し、その呼び出しと同じ行の直前箇所に、呼び出しが行われたクラスと行番号、脆弱メソッド名、および実行時に脆弱メソッドの脆弱性の原因となる引数に渡されるデータ値を一時結果レポート１２Ｆに出力するメソッドを、追加する。行番号の代わりに、呼び出しが行われたメソッド定義を出力してもよい（手順３０３：図２の手順２０３に対応）。次に、Webアプリケーション管理手段１２Ｂは、擬似攻撃コードDB１２Ｅから取得した攻撃コードのリストとその各要素を取得するメソッドが定義された中間コードを生成し、対象Webアプリケーションの中間コード群１２Ａに追加する（手順３０４：図２の手順２０４に対応）。
【００３０】
次に、攻撃コードリストの各要素を識別するためのインデックスであるiに1を代入する。また、コード中の外部データ取得メソッド呼び出しを識別するためのインデックスであるjに１を代入する（手順３０５）。検査対象ページの中間コードから、j番目の外部データ取得メソッド呼び出しを探す（手順３０６）。該メソッドが見つからない場合（手順３０７）、すなわち当該中間コード内に存在する全ての外部データ取得メソッドについて処理を終えている場合は、検査を終了し、脆弱性判定手段２２Ａに対し終了を通知する（手順３１４：図２の手順２１５に対応）。
【００３１】
一方、j番目の外部データ取得メソッド呼び出しが見つかった場合、該メソッド呼び出しを攻撃コードリストの一要素を取得するメソッドに変更する。また、呼び出しが行われたクラスと行番号、該当メソッド名、および攻撃コードを一時結果レポート１２Ｆに出力するメソッドを、追加する。行番号の代わりに、呼び出しが行われたメソッド定義を出力してもよい（手順３０８：図２の手順２０５に対応）。そして、検査用Webアプリ構築完了通知を脆弱性判定手段２２Ａに送付し（手順３０９：図２の手順２０６に対応）、待ち状態となる。
【００３２】
脆弱性判定手段２２Ａから一時結果レポート要求（図２の手順２１１で発行されたもの）を受信すると、一時結果レポート１２Ｆを脆弱性判定手段２２Ａに送付する。送付後、一時結果レポート１２Ｆを初期化する（手順３１０：図２の手順２１２に対応）。次に、iにi+1を代入する（手順３１１）。iと攻撃コード総数を比較し、両者が等しいか、または攻撃コード総数の方が大きい場合、次の攻撃コード要素を用いて処理を続行するため、手順３０８の処理に移る。そうでない場合、以下の手順３１３に移る（手順３１２）。次に、iに1を代入し、jにj+1を代入する（手順３１３）。手順３１３の後、手順３０６に戻る。
【００３３】
図３の手順３０８では、変数iの値を用いて攻撃コードi番目要素取得メソッドに変更しているが、このiの部分をクライアントから与えられる動的な値とし、検査対象コードにその値をクライアントからのリクエストパラメータ値として受信するためのコードを追加するという方法もある。この場合、検査対象コードを編集する回数が少なくて済む。
【００３４】
図４は、クライアント２の脆弱性判定手段２２Ａの詳細な動作を示すフローチャートである。まず始めに、脆弱性判定手段２２Ａは、リクエストパラメータDB２２Ｂから検査対象ページに対するリクエストパラメータの情報を取得する（手順４０１：図２の手順２００に対応）。そして、検査対象のページ名称をWebアプリケーション管理手段１２Ｂに伝える（手順４０２：図２の手順２０１に対応）。その後、一旦、待ち状態となる。
【００３５】
Webアプリケーション管理手段１２Ｂは、図２で説明したように手順２０２〜２０６を経て検査用Webアプリケーション構築完了通知を脆弱性判定手段２２Ａへ送る。該検査用Webアプリケーション構築完了通知を受けとった脆弱性判定手段２２Ａは、前記手順４０１により取得したリクエストパラメータの情報を元にして検査対象ページに対してリクエストを送る（手順４０３：図２の手順２０７に対応）。そして、待ち状態となる。当該リクエストは、図２の手順２０８でWebアプリケーション供給手段１２Ｇにより処理され、レスポンスが送信される（図２の手順２０９）。
【００３６】
当該レスポンスを受信した脆弱性判定手段２２Ａは、そのレスポンスとレスポンス脆弱性判定DB２２Ｃから脆弱性かどうかを判断し（手順４０６：図２の手順２１０）、脆弱性である場合、Webアプリケーション管理手段１２Ｂから一時結果レポート１２Ｆを取得する（手順４０７：図２の手順２１１，２１２に対応）。その内容を結果レポート２２Ｄに出力し（手順４０８：図２の手順２１３に対応）、手順４０９に移る。そうでない場合、結果レポート２２Ｄには何も出力せず、手順４０９に移る。最後に、判定終了通知をWebアプリケーション管理手段１２Ｂに送付する（手順４０９：図２の手順２１４に対応）。そして、待ち状態となる。
【００３７】
なお、図２でも説明した通り、検査用Webアプリケーション構築完了通知は、外部データ取得メソッド呼び出しの数および攻撃コードの要素数だけ繰り返し出力されるから、引き続き、検査用Webアプリケーション構築完了通知を受信した場合は、手順４０３に移るものとする。一方、終了通知を受け取った場合は検査を終了する。
【００３８】
図５は、外部データ取得メソッドDB１２Ｃの例である。本DBは、サーバ１において、APIで提供されている外部データ取得メソッドの名前５０１を登録しておくDBである。
【００３９】
図６は、脆弱メソッドDB１２Ｄの例である。本DBは、サーバ１において、APIで提供されている脆弱メソッドについての情報を登録しておくDBである。本DBには、脆弱メソッド名６０１と、脆弱性の原因となる引数の位置を表す引数番号６０２との組データを登録しておく。
【００４０】
図７(a)は、擬似攻撃コードDB１２Ｅの例である。本DBは、サーバ１において、検査をするために用いる攻撃コード７０１を登録するDBである。ここでは、攻撃コード要素を１つだけ図示した。
【００４１】
図７(b)は、攻撃コードリストとその各要素を取得するためのメソッドを定義したソースコードの例である。図３の手順３０４（図２の手順２０４）で、このソースコードに対応する中間コードを中間コード群１２Ａに追加する。
【００４２】
図８(a)は、クライアントからWebアプリケーションに対し入力される、Webアプリケーション開発者が想定する正常なリクエストパラメータ値を登録したリクエストパラメータDB２２Ｂの例である。本DBには、検査対象ページのＵＲＬ８０１、パラメータ名８０２、およびパラメータ値８０３の組データを登録しておく。この例では一つの検査対象ページに対して一つのパラメータしか示していないが、複数のパラメータがあっても良く、その場合、同じＵＲＬでパラメータ名が異なる複数のレコードが登録される。ヘッダフィールドについては、通常のHTTPのリクエスト発行時に設定されるため、特に登録する必要はない。
【００４３】
図８(b)は、図８(a)に対応するリクエストデータの例である。このようなリクエストデータが、手順４０３（図２の手順２０７）で脆弱性判定手段２２ＡからWebアプリケーション供給手段１２Ｇに対して送信される。前記WebScarabなどを使用した従来の稼動検査方式では、リクエストデータ内のどのリクエストパラメータとヘッダフィールドの値がWebアプリケーションで利用されているか分からないため、すべてについて検査をする必要があった。例えば、図８(b)の場合、リクエストパラメータnameとヘッダフィールドHostの両方に、攻撃コードを含ませて検査していた。一方、本発明では、Webアプリケーション内の外部データ取得メソッド箇所に攻撃コードを含ませて検査する。
【００４４】
図９は、図８(b)のリクエストデータを送付した場合のレスポンスの例である。これは、手順４０６（図２の手順２１０）で脆弱ではないと判断されるものの一例である。
【００４５】
図１０は、攻撃コードを検査対象コードに埋め込み検査した結果、その攻撃が成功した場合のレスポンスデータの例である。図８(b)のパラメータnameの値を取得するメソッドの代わりに、図７(a)に登録の攻撃コードに変更した場合のレスポンスを示している。これは、手順４０６で脆弱であると判断されるものの一例である。
【００４６】
図１１は、レスポンス脆弱性判定DB２２Ｃの例である。本DBは、レスポンス脆弱性判定コード８０１を登録するDBである。このDBに登録されたコードがレスポンスデータに含まれていた場合に、脆弱性であると判断する。この例以外に、レスポンス脆弱性判定コード８０１に想定されるレスポンスデータをすべて登録しておき、それ以外のレスポンスデータが得られた場合に脆弱性であると判定するというような使用方法が考えられる。
【００４７】
図１２は、脆弱性検査の結果が記述された結果レポート２２Ｄの例である。この結果レポート２２Ｄは、外部データ取得メソッドの呼び出しが行われたクラス名１２１および呼び出し行番号１２２と、外部データ取得メソッド名１２３と、攻撃コード１２４と、脆弱メソッドの呼び出しが行われたクラス名１２５および呼び出し行番号１２６と、脆弱メソッド名１２７と、実行時に脆弱性の原因となる脆弱メソッドの引数箇所に与えられた実行時引数データ値１２８との組データからなる。この引数箇所は、脆弱メソッドDB１２Ｄの引数番号６０２に登録されている値から決まる。行番号の代わりに呼び出しが行われたメソッド定義としてもよい。
【００４８】
この結果レポート２２Ｄの例では、検査対象Webアプリケーションに脆弱性が含まれていることと、その原因となる外部データ取得箇所、および脆弱性が生じている脆弱メソッド呼び出し箇所の候補が分かる。実行時引数データ値より二つの脆弱メソッド呼び出し箇所のうち２１行目が原因であると判断できる。この脆弱メソッド呼び出し箇所の候補をあらかじめ絞る方法として、手順３０３において実行時引数データ値の中に擬似攻撃コードDB１２Ｅに登録された攻撃コードが含まれたもののみ、一時結果レポート１２Ｆに出力するという方法がある。
【図面の簡単な説明】
【００４９】
【図１】本発明の一実施の形態を表すシステム構成図である。
【図２】クライアント端末の脆弱性判定手段、サーバのWebアプリケーション管理手段、サーバのWebアプリケーション供給手段の間でやりとりされる命令およびデータの流れを示した図である。
【図３】Webアプリケーション管理手段の動作を示すフローチャートである。
【図４】脆弱性判定手段の動作を示すフローチャートである。
【図５】APIで提供されている外部データ取得メソッドについての情報を登録しておくための外部データ取得メソッドDBの例である。
【図６】APIで提供されている脆弱メソッドについての情報を登録しておくための脆弱メソッドDBの例である。
【図７】擬似攻撃コードDBの例、および攻撃コードリストとその各要素を取得するためのメソッドを定義したソースコードの例である。
【図８】Webアプリケーションに対してクライアントから入力される、Webアプリケーション開発者が想定する正常なパラメータ値を登録したリクエストパラメータDBの例、およびリクエストデータの例である。
【図９】リクエストデータを送付した場合のレスポンスの例であり、脆弱ではないと判断されるものの一例である。
【図１０】攻撃コードを検査対象コードに埋め込み検査した結果、その攻撃が成功した場合のレスポンスデータの例であり、脆弱であると判断されるものの一例である。
【図１１】レスポンス脆弱性判定DBの例である。
【図１２】脆弱性検査の結果が記述された結果レポートの例である。
【符号の説明】
【００５０】
１１Ａ、２１Ａ…ＣＰＵ、１１Ｂ、２１Ｂ…メモリ、１３、２３…通信ポート、１１、２１…端末装置、１２、２２…外部記憶装置、３…ネットワーク、１２Ａ…Webアプリケーション中間コード群、１２Ｂ…Webアプリケーション管理手段、１２Ｃ…外部データ取得メソッドDB、１２Ｄ…脆弱メソッドDB、１２Ｅ…擬似攻撃コードDB、１２Ｆ…一時結果レポート、１２Ｇ…Webアプリケーション供給手段、２２Ａ…脆弱性判定手段、２２Ｂ…リクエストパラメータDB、２２Ｃ…レスポンス脆弱性判定DB、２２Ｄ…結果レポート。
【特許請求の範囲】
【請求項１】
サーバ上で稼働するWebアプリケーションの脆弱性を検査するWebアプリケーション脆弱性動的検査方法であって、
所定の検査要求発行手段から前記サーバのWebアプリケーションが提供するWebページへ送信される検査要求を受け、該Webアプリケーションを供給するサーバにおいて該検査対象ページに対応するコードの中のWebアプリケーション外部からのデータを取得するメソッド呼び出し箇所を検査用のコードに変更し、脆弱性を検査するための検査用Webアプリケーションを構築する第一のステップと、
該検査用Webアプリケーションの該検査ページに対して検査のためのリクエストデータを送付し、該リクエストデータに応じて出力されるレスポンスデータとあらかじめ登録してある脆弱性判定コードとを比較することにより、該Webアプリケーションに脆弱性が含まれるかどうかを判定し、その判定結果を出力する第二のステップと
を備えることを特徴とするWebアプリケーション脆弱性動的検査方法。
【請求項２】
請求項１に記載のWebアプリケーション脆弱性動的検査方法において、
前記第一のステップは、Webアプリケーション外部からのデータを取得するメソッドのソースコード中での位置に関する情報と、脆弱性を生じる可能性のあるメソッドのソースコード中での位置に関する情報と、実行時に該脆弱性を生じる可能性のあるメソッドに渡されるデータ値とを、取得し、一時結果レポートとして出力するメソッドを、前記Webアプリケーションのコード中に追加する処理を含み、
前記第二のステップは、前記検査のためのリクエストに応じた処理の過程で前記メソッドにより前記一時結果レポートを出力する処理を含む
ことを特徴とするWebアプリケーション脆弱性動的検査方法。
【請求項３】
請求項１または２に記載のWebアプリケーション脆弱性動的検査方法において、
前記第一のステップは、
（１）前記Webアプリケーションにすべての検査用コードの定義を追加し、
（２）前記Webアプリケーションの検査対象ページに、受信したリクエストデータに含まれるパラメータから動的にデータを取得するコードを、追加し、
（３）前記Webアプリケーション外部からのデータを取得するメソッド呼び出し箇所を、前記リクエストデータに含まれるパラメータから動的に取得したデータに基づいて前記追加したすべての検査用コードの中から指定された、検査用コードを取得するコードに、変更する
処理を含み、
前記第二のステップは、前記検査のためのリクエストデータのパラメータに、前記検査用コードを動的に指定するデータを含めて、リクエストデータを送付する処理を含む
ことを特徴とするWebアプリケーション脆弱性動的検査方法。
【請求項４】
Webアプリケーションが稼働するサーバと該サーバ上で稼働するWebアプリケーションに対してリクエストデータを送信しそのレスポンスデータを受信するクライアント端末とが接続されたシステムにおいて、前記Webアプリケーションの脆弱性を検査するWebアプリケーション脆弱性動的検査方法であって、
前記クライアント端末から前記サーバのWebアプリケーションが提供するWebページへ検査要求を送信するステップと、
前記検査要求を受信した、前記Webアプリケーションを供給するサーバが、該検査対象ページに対応するコードの中のWebアプリケーション外部からのデータを取得するメソッド呼び出し箇所を、検査用のコードに変更し、脆弱性を検査するための検査用Webアプリケーションを構築するステップと、
前記クライアント端末から前記サーバの検査用Webアプリケーションの該検査対象ページに対して検査のためのリクエストデータを送付するステップと、
該リクエストデータを受信した前記サーバが、該リクエストに応じて前記検査用Webアプリケーションを動作させ、レスポンスデータを返信するステップと、
該レスポンスデータを受信した前記クライアント端末が、該レスポンスデータとあらかじめ登録してある脆弱性判定コードとを比較し、該比較の結果に基づいて前記Webアプリケーションに脆弱性が含まれるかどうかを判定し、その結果を出力するステップと
を備えることを特徴とするWebアプリケーション脆弱性動的検査方法。
【請求項５】
サーバ上で稼働するWebアプリケーションの脆弱性を検査するWebアプリケーション脆弱性動的検査システムであって、
所定の検査要求発行手段から前記サーバのWebアプリケーションが提供するWebページへ送信される検査要求を受け、該Webアプリケーションを供給するサーバにおいて該検査対象ページに対応するコードの中のWebアプリケーション外部からのデータを取得するメソッド呼び出し箇所を検査用のコードに変更し、脆弱性を検査するための検査用Webアプリケーションを構築する第一の手段と、
該検査用Webアプリケーションの該検査ページに対して検査のためのリクエストデータを送付し、該リクエストデータに応じて出力されるレスポンスデータとあらかじめ登録してある脆弱性判定コードとを比較することにより、該Webアプリケーションに脆弱性が含まれるかどうかを判定し、その判定結果を出力する第二の手段と
を備えることを特徴とするWebアプリケーション脆弱性動的検査システム。
【請求項６】
請求項５に記載のWebアプリケーション脆弱性動的検査システムにおいて、
前記第一の手段は、Webアプリケーション外部からのデータを取得するメソッドのソースコード中での位置に関する情報と、脆弱性を生じる可能性のあるメソッドのソースコード中での位置に関する情報と、実行時に該脆弱性を生じる可能性のあるメソッドに渡されるデータ値とを、取得し、一時結果レポートとして出力するメソッドを、前記Webアプリケーションのコード中に追加する処理を含み、
前記第二の手段は、前記検査のためのリクエストに応じた処理の過程で前記メソッドにより前記一時結果レポートを出力する処理を含む
ことを特徴とするWebアプリケーション脆弱性動的検査システム。
【請求項７】
請求項５または６に記載のWebアプリケーション脆弱性動的検査システムにおいて、
前記第一の手段は、
（１）前記Webアプリケーションにすべての検査用コードの定義を追加し、
（２）前記Webアプリケーションの検査対象ページに、受信したリクエストデータに含まれるパラメータから動的にデータを取得するコードを、追加し、
（３）前記Webアプリケーション外部からのデータを取得するメソッド呼び出し箇所を、前記リクエストデータに含まれるパラメータから動的に取得したデータに基づいて前記追加したすべての検査用コードの中から指定された、検査用コードを取得するコードに、変更する
処理を含み、
前記第二の手段は、前記検査のためのリクエストデータのパラメータに、前記検査用コードを動的に指定するデータを含めて、リクエストデータを送付する処理を含む
ことを特徴とするWebアプリケーション脆弱性動的検査システム。
【請求項８】
Webアプリケーションが稼働するサーバと該サーバ上で稼働するWebアプリケーションに対してリクエストデータを送信しそのレスポンスデータを受信するクライアント端末とが接続されたシステムにおいて、前記Webアプリケーションの脆弱性を検査するWebアプリケーション脆弱性動的検査システムであって、
前記クライアント端末は、
前記サーバのWebアプリケーションが提供するWebページへ検査要求を送信する手段と、
前記サーバから送信された検査用Webアプリケーション構築完了通知を受信したとき、前記サーバの検査用Webアプリケーションの該検査対象ページに対して検査のためのリクエストデータを送付する手段と、
前記リクエストデータに応じて前記サーバから送信されたレスポンスデータを受信したとき、該レスポンスデータとあらかじめ登録してある脆弱性判定コードとを比較し、該比較の結果に基づいて前記Webアプリケーションに脆弱性が含まれるかどうかを判定し、その結果を出力する手段と
を備え、
前記Webアプリケーションを供給するサーバは、
前記クライアント端末から送信される検査要求を受信したとき、検査対象ページに対応するコードの中のWebアプリケーション外部からのデータを取得するメソッド呼び出し箇所を、検査用のコードに変更し、脆弱性を検査するための検査用Webアプリケーションを構築する手段と、
前記クライアント端末に、該検査用Webアプリケーションの構築が完了したことを通知する検査用Webアプリケーション構築完了通知を、送信する手段と、
前記クライアント端末から送信されたリクエストデータに応じて前記検査用Webアプリケーションを動作させ、レスポンスデータを返信するステップと
を備えることを特徴とするWebアプリケーション脆弱性動的検査方法。
【請求項１】
サーバ上で稼働するWebアプリケーションの脆弱性を検査するWebアプリケーション脆弱性動的検査方法であって、
所定の検査要求発行手段から前記サーバのWebアプリケーションが提供するWebページへ送信される検査要求を受け、該Webアプリケーションを供給するサーバにおいて該検査対象ページに対応するコードの中のWebアプリケーション外部からのデータを取得するメソッド呼び出し箇所を検査用のコードに変更し、脆弱性を検査するための検査用Webアプリケーションを構築する第一のステップと、
該検査用Webアプリケーションの該検査ページに対して検査のためのリクエストデータを送付し、該リクエストデータに応じて出力されるレスポンスデータとあらかじめ登録してある脆弱性判定コードとを比較することにより、該Webアプリケーションに脆弱性が含まれるかどうかを判定し、その判定結果を出力する第二のステップと
を備えることを特徴とするWebアプリケーション脆弱性動的検査方法。
【請求項２】
請求項１に記載のWebアプリケーション脆弱性動的検査方法において、
前記第一のステップは、Webアプリケーション外部からのデータを取得するメソッドのソースコード中での位置に関する情報と、脆弱性を生じる可能性のあるメソッドのソースコード中での位置に関する情報と、実行時に該脆弱性を生じる可能性のあるメソッドに渡されるデータ値とを、取得し、一時結果レポートとして出力するメソッドを、前記Webアプリケーションのコード中に追加する処理を含み、
前記第二のステップは、前記検査のためのリクエストに応じた処理の過程で前記メソッドにより前記一時結果レポートを出力する処理を含む
ことを特徴とするWebアプリケーション脆弱性動的検査方法。
【請求項３】
請求項１または２に記載のWebアプリケーション脆弱性動的検査方法において、
前記第一のステップは、
（１）前記Webアプリケーションにすべての検査用コードの定義を追加し、
（２）前記Webアプリケーションの検査対象ページに、受信したリクエストデータに含まれるパラメータから動的にデータを取得するコードを、追加し、
（３）前記Webアプリケーション外部からのデータを取得するメソッド呼び出し箇所を、前記リクエストデータに含まれるパラメータから動的に取得したデータに基づいて前記追加したすべての検査用コードの中から指定された、検査用コードを取得するコードに、変更する
処理を含み、
前記第二のステップは、前記検査のためのリクエストデータのパラメータに、前記検査用コードを動的に指定するデータを含めて、リクエストデータを送付する処理を含む
ことを特徴とするWebアプリケーション脆弱性動的検査方法。
【請求項４】
Webアプリケーションが稼働するサーバと該サーバ上で稼働するWebアプリケーションに対してリクエストデータを送信しそのレスポンスデータを受信するクライアント端末とが接続されたシステムにおいて、前記Webアプリケーションの脆弱性を検査するWebアプリケーション脆弱性動的検査方法であって、
前記クライアント端末から前記サーバのWebアプリケーションが提供するWebページへ検査要求を送信するステップと、
前記検査要求を受信した、前記Webアプリケーションを供給するサーバが、該検査対象ページに対応するコードの中のWebアプリケーション外部からのデータを取得するメソッド呼び出し箇所を、検査用のコードに変更し、脆弱性を検査するための検査用Webアプリケーションを構築するステップと、
前記クライアント端末から前記サーバの検査用Webアプリケーションの該検査対象ページに対して検査のためのリクエストデータを送付するステップと、
該リクエストデータを受信した前記サーバが、該リクエストに応じて前記検査用Webアプリケーションを動作させ、レスポンスデータを返信するステップと、
該レスポンスデータを受信した前記クライアント端末が、該レスポンスデータとあらかじめ登録してある脆弱性判定コードとを比較し、該比較の結果に基づいて前記Webアプリケーションに脆弱性が含まれるかどうかを判定し、その結果を出力するステップと
を備えることを特徴とするWebアプリケーション脆弱性動的検査方法。
【請求項５】
サーバ上で稼働するWebアプリケーションの脆弱性を検査するWebアプリケーション脆弱性動的検査システムであって、
所定の検査要求発行手段から前記サーバのWebアプリケーションが提供するWebページへ送信される検査要求を受け、該Webアプリケーションを供給するサーバにおいて該検査対象ページに対応するコードの中のWebアプリケーション外部からのデータを取得するメソッド呼び出し箇所を検査用のコードに変更し、脆弱性を検査するための検査用Webアプリケーションを構築する第一の手段と、
該検査用Webアプリケーションの該検査ページに対して検査のためのリクエストデータを送付し、該リクエストデータに応じて出力されるレスポンスデータとあらかじめ登録してある脆弱性判定コードとを比較することにより、該Webアプリケーションに脆弱性が含まれるかどうかを判定し、その判定結果を出力する第二の手段と
を備えることを特徴とするWebアプリケーション脆弱性動的検査システム。
【請求項６】
請求項５に記載のWebアプリケーション脆弱性動的検査システムにおいて、
前記第一の手段は、Webアプリケーション外部からのデータを取得するメソッドのソースコード中での位置に関する情報と、脆弱性を生じる可能性のあるメソッドのソースコード中での位置に関する情報と、実行時に該脆弱性を生じる可能性のあるメソッドに渡されるデータ値とを、取得し、一時結果レポートとして出力するメソッドを、前記Webアプリケーションのコード中に追加する処理を含み、
前記第二の手段は、前記検査のためのリクエストに応じた処理の過程で前記メソッドにより前記一時結果レポートを出力する処理を含む
ことを特徴とするWebアプリケーション脆弱性動的検査システム。
【請求項７】
請求項５または６に記載のWebアプリケーション脆弱性動的検査システムにおいて、
前記第一の手段は、
（１）前記Webアプリケーションにすべての検査用コードの定義を追加し、
（２）前記Webアプリケーションの検査対象ページに、受信したリクエストデータに含まれるパラメータから動的にデータを取得するコードを、追加し、
（３）前記Webアプリケーション外部からのデータを取得するメソッド呼び出し箇所を、前記リクエストデータに含まれるパラメータから動的に取得したデータに基づいて前記追加したすべての検査用コードの中から指定された、検査用コードを取得するコードに、変更する
処理を含み、
前記第二の手段は、前記検査のためのリクエストデータのパラメータに、前記検査用コードを動的に指定するデータを含めて、リクエストデータを送付する処理を含む
ことを特徴とするWebアプリケーション脆弱性動的検査システム。
【請求項８】
Webアプリケーションが稼働するサーバと該サーバ上で稼働するWebアプリケーションに対してリクエストデータを送信しそのレスポンスデータを受信するクライアント端末とが接続されたシステムにおいて、前記Webアプリケーションの脆弱性を検査するWebアプリケーション脆弱性動的検査システムであって、
前記クライアント端末は、
前記サーバのWebアプリケーションが提供するWebページへ検査要求を送信する手段と、
前記サーバから送信された検査用Webアプリケーション構築完了通知を受信したとき、前記サーバの検査用Webアプリケーションの該検査対象ページに対して検査のためのリクエストデータを送付する手段と、
前記リクエストデータに応じて前記サーバから送信されたレスポンスデータを受信したとき、該レスポンスデータとあらかじめ登録してある脆弱性判定コードとを比較し、該比較の結果に基づいて前記Webアプリケーションに脆弱性が含まれるかどうかを判定し、その結果を出力する手段と
を備え、
前記Webアプリケーションを供給するサーバは、
前記クライアント端末から送信される検査要求を受信したとき、検査対象ページに対応するコードの中のWebアプリケーション外部からのデータを取得するメソッド呼び出し箇所を、検査用のコードに変更し、脆弱性を検査するための検査用Webアプリケーションを構築する手段と、
前記クライアント端末に、該検査用Webアプリケーションの構築が完了したことを通知する検査用Webアプリケーション構築完了通知を、送信する手段と、
前記クライアント端末から送信されたリクエストデータに応じて前記検査用Webアプリケーションを動作させ、レスポンスデータを返信するステップと
を備えることを特徴とするWebアプリケーション脆弱性動的検査方法。
【図１】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図１２】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図１２】
【公開番号】特開２００７−２４１９０６（Ｐ２００７−２４１９０６Ａ）
【公開日】平成１９年９月２０日（２００７．９．２０）
【国際特許分類】
【出願番号】特願２００６−６６８２２（Ｐ２００６−６６８２２）
【出願日】平成１８年３月１１日（２００６．３．１１）
【出願人】（０００２３３０５５）日立ソフトウエアエンジニアリング株式会社 (1,610)
【Ｆターム（参考）】
【公開日】平成１９年９月２０日（２００７．９．２０）
【国際特許分類】
【出願日】平成１８年３月１１日（２００６．３．１１）
【出願人】（０００２３３０５５）日立ソフトウエアエンジニアリング株式会社 (1,610)
【Ｆターム（参考）】
[ Back to top ]