(57)【特許請求の範囲】
【請求項１】
アプリケーション検査管理手段からの検査開始通知を受け、検査対象のアプリケーションのソースコードについて、ソースコード外部からのデータをその入力箇所ごとに区別し、変数の参照する値およびメソッドによる遷移を解析することで脆弱性の検査を行い、脆弱性の可能性のあるコードの位置およびその原因となるアプリケーション外部からのデータの入力位置と該データが経由するメソッドの情報を取得する第１のステップと、
前記第１のステップで検出した箇所について、アプリケーション供給手段が供給する検査対象アプリケーションに対し、検査のためのリクエストデータを送付し、そのレスポンスデータ及び予め登録している脆弱性判定コードと比較することにより、脆弱性が含まれるかどうかを判定し、脆弱であるものと、そうでないものを区別して出力する第２のステップを備えることを特徴とするアプリケーションの脆弱性検査方法。
【請求項２】
アプリケーション検査管理手段からの検査開始通知を受け、検査対象のアプリケーションのソースコードについて、ソースコード外部からのデータをその入力箇所ごとに区別し、変数の参照する値およびメソッドによる遷移を解析することで脆弱性の検査を行い、脆弱性の可能性のあるコードの位置およびその原因となるアプリケーション外部からのデータの入力位置と該データが経由するメソッドの情報を取得する第１の手段と、
前記第１の手段で検出した箇所について、アプリケーション供給手段が供給する検査対象アプリケーションに対し、検査のためのリクエストデータを送付し、そのレスポンスデータ及びあらかじめ登録している脆弱性判定コードと比較することにより、脆弱性が含まれるかどうかを判定し、脆弱であるものと、そうでないものを区別して出力する第２の手段を備えることを特徴とするアプリケーションの脆弱性検査装置。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、Webアプリケーションなどのアプリケーションを検査し、そのソースコード内に含まれる脆弱性が生じる箇所を検出するとともにプログラマの脆弱性の修正作業を支援する情報を提供するアプリケーションの脆弱性検査装置に関するものである。
【背景技術】
【０００２】
一般に、ソフトウェア（アプリケーション）に含まれる脆弱性を検査する方法には、稼動中のソフトウェアを調べる方法と、ソフトウェアのソースコードを静的に調べる方法の２つがある。
稼動中のソフトウェアの検査手法は、動作するソフトウェアに様々なデータを入力し、それに対する結果を元に脆弱性が含まれているかどうかを判断するものである。
例えばOWASPで公開されているWebScarabのManual Interceptプラグインを利用した検査が挙げられる。
【０００３】
一方、静的なソフトウェアの検査手法とは、ソースコードを検査し、プログラミング言語の標準ライブラリなどに含まれる「危険なメソッド」の使用箇所を検出するものである。「危険なメソッド」とは、プログラマがその使用に注意しないとソフトウェアに脆弱性を生じさせるメソッドのことである。
静的検査方法については、下記の非特許文献１の２章に詳しく述べられている。
【０００４】
【非特許文献１】情報処理振興事業協会セキュリティセンター：オープンソース・ソフトウェアのセキュリティ確保に関する調査報告書  第２部  オープンソース・ソフトウェアの効率的な検査技術の調査：平成１５年２月
【発明の開示】
【発明が解決しようとする課題】
【０００５】
ソフトウェアがソフトウェア外部から取得した文字列データを「危険なメソッド」で処理する場合、脆弱性となる。この脆弱性の例として、OSコマンド挿入脆弱性やSQLコマンド挿入脆弱性、クロスサイトスクリプティング脆弱性などがある。
このような脆弱性を含むソースコードの検査を従来の静的検査方法で行った場合、脆弱な可能性のある箇所を検出できるものの、具体的にどこから外部データが入力され、どのメソッドを経由して脆弱となる可能性のあるメソッドに渡されるのかについての情報を提供する技術はない。そのため、プログラマが目視して本当に脆弱性であるかの判断をする場合や脆弱性の対策を行う場合にかかる作業工数が多いという問題がある。
また、実際に脆弱性が生じる場合と、脆弱性ではないものの該当箇所以外のコードを少し変更しただけで脆弱性となってしまう場合（潜在的な脆弱性）の区別がなされず同じように出力されるため、対策を行うための優先度順位を付けられない。そのため、効果的な対策を実施することができないという問題がある。
【０００６】
一方、従来の動的検査方法で検査を行った場合、上述の潜在的な脆弱性は検出されない。ソースコード内での脆弱性の原因となるコードの場所が指摘されない。また、Ｗｅｂアプリケーションに対して送信されるリクエストデータに含まれるパラメータおよびヘッダフィールドのうち、どの値がWebアプリケーションのソースコード内で利用されているか分からないため、すべてのパラメータおよびヘッダフィールドについて、擬似的な攻撃コードを設定して検査する必要がある。
【０００７】
本発明の目的は、プログラマに対し脆弱な遷移を伴うメソッド呼び出し箇所だけでなく、外部入力データ箇所および該データが経由するメソッドの情報を提供し、脆弱性の判断および対策に要する作業量を軽減すること、および脆弱な箇所以外に現状では脆弱ではないが該当箇所以外のコードを少し変更しただけで脆弱となってしまう潜在的に脆弱な箇所も検出すること、および該脆弱な箇所と該潜在的に脆弱な箇所を区別して検出し、プログラマが危険度の高いものから順番に効果的に対策を行えるようにすることができるアプリケーションの脆弱性検査方法及び装置を提供することにある。
【課題を解決するための手段】
【０００８】
上記目的を達成するために、本発明に係るアプリケーションの脆弱性検査方法は、アプリケーション検査管理手段からの検査開始通知を受け、検査対象のアプリケーションのソースコードについて、ソースコード外部からのデータをその入力箇所ごとに区別し、変数の参照する値およびメソッドによる遷移を解析することで脆弱性の検査を行い、脆弱性の可能性のあるコードの位置およびその原因となるアプリケーション外部からのデータの入力位置と該データが経由するメソッドの情報を取得する第１のステップと、前記第１のステップで検出した箇所について、アプリケーション供給手段が供給する検査対象アプリケーションに対し、検査のためのリクエストデータを送付し、そのレスポンスデータ及び予め登録している脆弱性判定コードと比較することにより、脆弱性が含まれるかどうかを判定し、脆弱であるものと、そうでないものを区別して出力する第２のステップを備えることを特徴とする。
【０００９】
また、本発明に係るアプリケーションの脆弱性検査装置は、アプリケーション検査管理手段からの検査開始通知を受け、検査対象のアプリケーションのソースコードについて、ソースコード外部からのデータをその入力箇所ごとに区別し、変数の参照する値およびメソッドによる遷移を解析することで脆弱性の検査を行い、脆弱性の可能性のあるコードの位置およびその原因となるアプリケーション外部からのデータの入力位置と該データが経由するメソッドの情報を取得する第１の手段と、前記第１の手段で検出した箇所について、アプリケーション供給手段が供給する検査対象アプリケーションに対し、検査のためのリクエストデータを送付し、そのレスポンスデータ及び予め登録している脆弱性判定コードと比較することにより、脆弱性が含まれるかどうかを判定し、脆弱であるものと、そうでないものを区別して出力する第２の手段を備えることを特徴とする。
【発明の効果】
【００１０】
本発明によれば、プログラマに対し脆弱な遷移を伴うメソッド呼び出し箇所だけでなく、外部入力データ箇所および該データが経由するメソッドの情報を提供できるため、プログラマの目視による脆弱性の判断および対策に要する作業量を軽減することができる。
また、脆弱な箇所だけでなく、現状では脆弱ではないものの該当箇所以外のコードを少し変更しただけで脆弱となってしまう潜在的に脆弱な箇所まで検出できる。
また、該脆弱な箇所と該潜在的に脆弱な箇所を区別して検出できるため、プログラマが危険度の高いものから順番に効果的に対策を行えるようになる。
【発明を実施するための最良の形態】
【００１１】
以下、本発明の実施形態を図面により詳細に説明する。
なお、以下の実施形態にいては、java言語を使用したアプリケーションを例に挙げて説明する。また、以下の説明および図面では、パッケージ名を省略しjava.io.PrintWriterをPrintWriter、java.lang.StringをString、javax.servlet.http.HttpServletRequest、HttpServletRequest、javax.servlet.http.HttpServletRequestをHttpServletResponse、javax.servlet.jsp.JspWriterをJspWriterと表記する。
また、前提として、外部からデータを取得するメソッドにHttpServletRequest.getParameter(String)がある。
これは第１引数に指定した名前を持つパラメータの値を取得するメソッドであり、第１引き数値からパラメータ名を取得できる。一方、strutsフレームワークを用いたソースコードの場合、フォームビーンのsetterメソッドにより外部からのデータを取得するが、このメソッドの名前にパラメータ名が含まれる。そのため同様にパラメータ名を取得できる。このような方法で取得したパラメータの名前を外部データＤＢ１２Ｅに登録する。
【００１２】
図１は、本発明の一実施の形態を表すシステム構成図である。
図１において、サーバ１とクライアント２は、ネットワーク３によって繋がっている。サーバ１は、ＣＰＵ１１Ａ、メモリ１１Ｂからなる端末装置１１と、ソースコードを解析して脆弱性の検査を行うソースコード検査手段１２Ａと、予めライブラリメソッドを登録しておくライブラリメソッドＤＢ１２Ｂと、プログラマが定義したメソッドを管理するためのプログラマ定義メソッドＤＢ１２Ｃ、変数の値を管理する変数ＤＢ１２Ｄと、外部データを取得した位置を管理する外部データＤＢ１２Ｅと、検査によって得られた脆弱性を生じる可能性のあるコードに関する情報を記録するための中間結果レポート１２Ｆと、クラス名とURLを対応付けたクラスURLマッピングＤＢ１２Gと、Webアプリケーションの稼動環境であるWebアプリケーション供給手段１２Ｈが格納されている外部記憶装置１２と、通信ポート１３から構成されている。
【００１３】
クライアント２は、ＣＰＵ２１Ａ、メモリ２１Ｂからなる端末装置２１と、Webアプリケーション検査管理手段２２Ａと、Webアプリケーション実行検査手段２２Ｂと、クライアントからWebアプリケーションに対し入力される、Webアプリケーション開発者が想定する正常なパラメータ値を登録したリクエストパラメータＤＢ２２Ｃと、Webアプリケーション実行検査手段２２Ｂが利用するための判断基準であるレスポンス脆弱性判定ＤＢ２２Ｄと、検査データＤＢ２２Ｅと、脆弱性検査の結果を記述する結果レポート２２Ｆが格納されている外部記憶装置２２と、通信ポート２３から構成されている。
【００１４】
図２は、検査対象Webアプリケーションのソースコードである。説明のため最も左端に行番号を記載している。import文は省略している。このソースコードでは、3、4、10行目にてプログラム外部からのデータを取得している。
PrintWriter.println(String)メソッドもしくはそれを内部で呼ぶメソッドの呼び出しが6、7、8、9、12行目で行われており、このうち6、7、8、9行目が脆弱である。それに対し12行目は、第一引き数に渡されるデータの内容が、その手前の11行目の条件文でチェックされているため、脆弱性ではない。ただし、この12行目は、該当箇所以外の箇所、今の場合11行目の条件文のコードを少し変更しただけで、脆弱性が発生してしまう潜在的に脆弱な箇所である。
【００１５】
図３は、検査対象のWebアプリケーションに対応する入力ページの例である。
図４は、マッピングＤＢ１２Ｇの例である。該ＤＢはWebアプリケーション名、ソースコード名、クラス名、URL名からなる。URLにはWebアプリケーションのルートからの相対パスを指定する。URLが無い場合は空白とする。
【００１６】
図５はクライアント端末のWebアプリケーション検査管理手段２２Ａと、サーバのWebアプリケーション実行検査手段２２Ｂ、ソースコード検査手段１２Ａ、およびWebアプリケーション供給手段１２Ｆの間でやりとりされる命令及びデータの流れを示した図である。なお、検査対象のWebアプリケーションは、Webアプリケーション供給手段１２Ｃによりサービスを提供可能な状態にあるとする。
まず始めに、Webアプリケーション検査管理手段２２Ａは検査対象アプリケーション名をソースコード検査手段１２Ａに伝達する（ステップ５０１）。
ソースコード検査手段１２Ａは、マッピングＤＢ１２Gに登録された該検査対象アプリケーションに相当するソースコード１２Ｉを取得し、そのソースコード検査を実施し（ステップ５０２）、その結果を中間結果レポートとしてWebアプリケーション検査管理手段２２Ａに送付する。
この時、クラス名とURLを対応付けたクラスURLマッピングＤＢ１２Gも同時に送付する（ステップ５０３）。
【００１７】
次に、Webアプリケーション検査管理手段２２Ａは、Webアプリケーション実行検査手段１２Ｂに対し、中間結果レポート１２ＦおよびクラスURLマッピングＤＢをWebアプリケーション実行検査手段１２Ｂに送付する（ステップ５０４）。
Webアプリケーション実行検査手段１２Ｂはこれらから検査ページURLと検査パラメータ名の情報を取得するとともに、リクエストパラメータＤＢおよび検査データＤＢを参照することで、検査用リクエストデータを組み立て、それをWebアプリケーション供給手段１２Ｆにより供給されている検査対象Webアプリケーションに送付する（ステップ５０５）。
その後、Webアプリケーション実行検査手段１２ＢはWebアプリケーションからの応答を受信し（ステップ５０６、５０７）、脆弱性判定ＤＢ２２Ｄの脆弱性判定データと比較することで脆弱性かどうかを判定する（ステップ５０８）。そして、ステップ５０５から５０８までは各パラメータおよび検査データ値について繰り返す。
そして、その結果を、Webアプリケーション検査管理手段２２Ａに通知し（ステップ５０９）、最終的に結果レポートを生成する。このとき、ソースコード検査及びWebアプリケーション実行検査の両方で脆弱性と判定されたものは深刻度高、ソースコード検査でのみ脆弱性と判定されたものは深刻度低として出力する（ステップ５１０）。
最後に検査終了をWebアプリケーション実行検査手段１２Ｂおよびソースコード検査手段１２Ａに告げる（ステップ５１１）。
【００１８】
図６は、ライブラリメソッドＤＢ１２Ｂの格納データの例である。
ライブラリメソッドＤＢ１２Ｂは、標準ライブラリに含まれるメソッド等のデータ遷移を予め登録したデータベースである。１列目はメソッド名、２列目はどの値がどこに遷移するかを示すデータ遷移のリストである。ここではデータ遷移を’→’を用いて表記し、’→’の左を遷移元、’→’の右を遷移先とする。遷移元および遷移先の値に設定する値には、引数番号、外部データを表すIN、戻り値を表すR、脆弱性を生じる可能性のある遷移先であるVUL_XSS、obj.method() 形式のメソッド呼び出しのobjを指すメソッド呼び出し元オブジェクトフラグTHISがある。遷移先にはこれらのうちのいずれかを、遷移元にはこれらのいずれかもしくはその組み合わせを設定する。
【００１９】
図７は、プログラマ定義メソッドＤＢ１２Ｃの格納データの例である。
プログラマ定義メソッドＤＢ１２Ｃには、プログラマが定義したメソッドについてのデータ遷移情報を、ソースコード解析中に登録する。本ＤＢのうち１列目および２列目は、ライブラリメソッドＤＢ１２Ｂと同様である。ただし、遷移値の遷移元に外部データを設定する場合は、INの代わりにINi(i=1,・・n)（nは十分大きな正の整数）が設定される。
３列目の解析済みフラグはそのメソッド定義の解析を終了したかどうかを表すフラグである。解析済みフラグは0か1の値をとり、解析済みフラグが0であるメソッドは、後述の手順９０６から９１１までの解析が終了していないことを表し、一方、１であるメソッドは前記解析が終了していることを表す。初期値は0とする。以下、前記解析が終了していないメソッドの状態を未解析であると呼ぶ。
４列目の脆弱メソッド名は初期値をnullとし、遷移値の遷移先に脆弱メソッドフラグVUL_XSSが設定されている場合にのみ脆弱なメソッドの名前を登録する。
【００２０】
図８は、変数ＤＢ１２Ｄの格納データの例である。
１列目は変数ＤＢ１２Ｄに登録された変数の識別番号である。この変数番号は、static変数の場合、負の整数値で−１、−２と降順に付ける。仮引数の場合、引数番号と一致する正の整数値を付ける。ローカル変数の場合、既に登録されている仮引数の変数番号に続くように昇順に付ける。正の整数値が１つも登録されていない場合、１から順に昇順に付ける。
２列目は変数の種別を表し、仮引数を登録する場合は’A’、ローカル変数なら’L’、static変数なら'S'を格納する。
３列目は変数名である。
４列目は変数の保持する値であり、初期値は変数番号と同一の値とする。値が定数の場合は、Cとする。後述する検査対象ソースコードに配列変数の遷移がないため、簡略化して記述したが、変数ＤＢ１２Ｄに変数の次元を加えることで引数変数に書き込むデータ遷移などにも対応できる。
【００２１】
図９は、本実施形態のソースコード脆弱性検査装置の処理手順を示すフローチャートである。
ソースコード検査手段１２Ａが起動されると、検査対象のWebアプリケーションのソースコードを読み込み、そのソースコードを全てたどり、見つかったプログラマ定義メソッドをプログラマ定義メソッドＤＢ１２Ｃに、static変数を変数ＤＢ１２Ｄに、それぞれ登録する。static変数の変数番号は、負の整数値で−１から降順に付ける（ステップ９０１）。
次に、ソースコードの先頭を探索開始位置にする（ステップ９０２）。ソースファイルが複数ある場合、任意のファイルの先頭を探索開始位置とする。
次に、ソースコード中から、未解析であるメソッド定義を探索する（ステップ９０３）。未解析のメソッドが無い場合は後述するステップ９１２に移る（ステップ９０３）。該当メソッドが見つかれば、次に、該当メソッドの定義の中で、未解析のメソッド呼び出しが行われていないかを探索する（ステップ９０４）。未解析のメソッド呼び出しが行われている場合、探索開始位置をソースコード中の次のメソッド定義位置に移し（ステップ９０５）、ステップ９０３に戻る。未解析のメソッド呼び出しが行われていない場合、該メソッドを処理対象メソッドとし、解析を開始する（ステップ９０６）。対象メソッドの仮引数があればそれを変数ＤＢ１２Ｄに登録する（ステップ９０７）。このとき、仮引数の変数番号は、その引数番号と一致するように登録する。そして、メソッド定義内解析処理（ステップ９０８）に移る。これは図１０に示す。
【００２２】
対象メソッドの終了箇所に至るまで、ステップ９０８を繰り返す。対象メソッドの処理を終えたら、解析済みフラグを１に設定し、ステップ９１０に移る（ステップ９０９）。
次に、変数ＤＢ１２Ｄから仮引数とローカル変数についての登録データを削除する。static変数の値のうちINi以外の値を初期化する（ステップ９１１）。対象メソッドについての処理を終え、ステップ９０３に戻る。
ステップ９１２では変数ＤＢ１２Ｄに、前回解析時と比較して、static変数の値の変化があるかどうかを調べる。変更がある場合、プログラマ定義メソッドＤＢ１２Ｃの解析済みフラグの値をすべて０に初期化し、ステップ９０３へ戻る。一方、無い場合は処理を終了する。
【００２３】
次に、図１０に示すメソッド内解析処理のフローチャートについて説明する。
ここでは、解析箇所がローカル変数定義箇所でなければ、ステップ９２０３に移る（ステップ９２０１）。ローカル変数定義箇所であれば、定義されている変数を変数ＤＢ１２Ｄに登録する。変数番号は、正の整数で昇順に付ける（ステップ９２０２）。
解析箇所が変数アクセス箇所でなければ、ステップ９２０５に移る（ステップ９２０３）。変数アクセス箇所であれば、変数ＤＢ１２Ｄから該変数の値を取得する（ステップ９２０４）。
解析箇所がメソッド呼び出し箇所でなければ、終了する（ステップ９２０５）。メソッド呼び出し箇所であれば、メソッド名でライブラリメソッドＤＢ１２Ｂおよびプログラマ定義メソッドＤＢ１２Ｂを探索し、該当メソッドの遷移値を取得する（ステップ９２０６）。
【００２４】
遷移値がない場合、処理を終える（ステップ９２０７）。遷移値がある場合、最初の遷移値を取り出す。遷移の遷移元が正の整数（引数番号）である場合、その遷移元を引数番号に相当する実引数値に修正後、以下の処理を行う。
遷移元がTHISである場合、メソッド呼び出し元の変数の値に修正後、以下の処理を行う。それ以外の場合、何もせず以下の処理を行う（ステップ９２０８）。
遷移先がVUL_XSSで、遷移元にINiを含むデータ遷移であれば、ソース中の該当箇所への警告を検査結果として出力するため、ステップ９２１０の中間出力レポート処理に移る（ステップ９２０９）。ステップ９２１０については図１１で説明する。この手順を追えるとステップ９２０６に移る（ステップ９２１０）。
遷移元にINを含む遷移を持つライブラリメソッドである外部データ取得メソッドの呼び出し箇所であれば、ステップ９２１２で外部データＤＢに登録した後、ステップ９２１３に移る。そうでなければステップ９２１３に移る。外部データＤＢ１２Ｅに登録する外部データフラグ名は１箇所目はIN1、２箇所目はIN2、・・とする（ステップ９２１１、９２１２）。
【００２５】
ステップ９２１３において、データ遷移の遷移先の値に応じて処理を行う。遷移先が変数番号であれば、変数ＤＢ１２Ｄの該当する変数値を更新する。遷移先が戻り値を表すRであれば、以後の処理で遷移元の値を持つ変数が該メソッドの位置に記述されていた場合と同じように扱う。
遷移先が変数番号でない遷移の場合、プログラマ定義メソッドＤＢ１２Ｃに追加する。
なお、代入文についても、右辺が左辺に遷移するデータ遷移として、メソッド呼び出しと同様に処理する。
【００２６】
次に、図１１のフローチャートについて説明する。このフローチャートは中間出力レポートへの１つのレコードを出力する際の手順を示したものである。なお重複するレコードは出力しない。
まず、脆弱箇所に脆弱メソッド名および、クラス名と行番号からなる位置の組を設定する（ステップ９３０１）。遷移元の名前INiを元に外部データＤＢを検索し、該当レコードの入力データ情報を取得し、それを入力箇所に設定する（ステップ９３０２）。経由メソッドの初期値をnullとする（ステップ９３０３）。
脆弱メソッド名がライブラリメソッドＤＢ１２Ｂ内になければ、ステップ９３０５に移る。あれば、ステップ９３０６に移る（ステップ９３０４）。ステップ９３０５では、該メソッドをプログラム定義メソッドＤＢ１２Ｃから検索し、該当レコードのメソッド名を経由メソッドに追加登録する。ステップ９３０６では、脆弱箇所、入力箇所、経由メソッドを出力する。そして処理を終える。
【００２７】
次に、図２のソースコードに対して、図９〜図１１の処理を適用した場合の処理を説明する。
まず、内部で他のプログラマ定義メソッド呼び出しのないmethod2およびmethodRetが最初に解析される。
次に、内部で用いられているプログラマ定義メソッドがmethod2だけであるmethod1及びmethoＤＢ1が解析され最後にdoGetが解析される。ここでは特に、doGetメソッド定義の処理について説明する。
method1、method2、methoＤＢ1、methodRetについてステップ９０１終了時のプログラマ定義メソッドＤＢ１２Ｃを図１２に示す。
図１２において、method1、method2、methoＤＢ1の遷移値は1→VUL_XSSである。method2では内部でPrintWriter.println(String)が、method1では内部でmethod2が、methoＤＢ1ではその両方が、第一引数の値が各第１引き数に渡される形で呼ばれている。よって脆弱メソッド名は図示のようになる。
【００２８】
method1、method2、methoＤＢ1、methodRetの解析後、doGetメソッドが未解析で、定義内で未解析のメソッド呼び出しが行われていないことが分かる（ステップ９０３および３４０４）。よって、doGetを解析対象のメソッド（対象メソッド）とする（ステップ９０６）。
まず対象メソッドdoGetに対し、仮引数とローカル変数を変数ＤＢ１２Ｄに登録する（ステップ９０７）。３行目および４行目では外部データ取得メソッドHttpServletRequest.getParameter(String)メソッドがあるため、外部データＤＢ１２Ｅの格納データは図１３のようになる。
【００２９】
doGetについて５行目までの解析終了時の変数ＤＢ１２Ｄの格納データが、図１４である。
次に、６行目のメソッドmethod1の呼び出しによるデータ遷移の処理を行う（ステップ９０８）。method1の遷移値を、ライブラリメソッドＤＢ１２Ｂおよびプログラマ定義メソッドＤＢ１２Ｃより検索し取り出す。すると、1→VUL_XSSの遷移が取得される。遷移元の1は第一引き数を表し、第１引き数に与えられた変数sの参照する値を変数ＤＢ１２Ｄから得て遷移元を書き換えるとIN1→VUL_XSSと、脆弱な遷移となるため、この行を脆弱な箇所として中間レポートに出力する。このとき入力箇所については外部データＤＢのフラグ名がIN１のレコードから取得し、経由メソッドについてはプログラマ定義メソッドＤＢの脆弱メソッド名から取得する。
【００３０】
次に７行目のメソッドmethod２の呼び出しによるデータ遷移の処理を行う（ステップ９０８）。６行目の処理とほぼ同じであるが、第１引き数に与えられた変数の値がIN1およびIN2である。そのため入力箇所は２箇所を並列に並べて出力する。
次に８行目のメソッドmethoＤＢ1の呼び出しによるデータ遷移の処理を行う（ステップ９０８）。６行目の処理とほぼ同じであるが、脆弱メソッド名が２つあるため、経由メソッドも２つ並べて出力される。
【００３１】
次に９、１２行目のメソッドPrintWriter.println(String)の呼び出しによるデータ遷移の処理を行う（ステップ９０８）。６行目の処理とほぼ同じであるが、直接脆弱なライブラリメソッドを呼び出しているため、経由メソッドはない。
以上で対象メソッドdoGetの処理を終える（ステップ９０９）。ステップ９０９終了時のプログラマ定義メソッドＤＢ１２Ｃは図１２のdoGetの解析済みフラグを１に変更したものである。
未解析のメソッド探索（ステップ９０３）にて該当メソッドが見つからないのでステップ９１２に移る。
この検査対象ソースコードにはstatic変数は定義されていない。よって検査を終了する。
【００３２】
図１５は中間出力レポート１３００の例である。
１列目の１３０１は脆弱な遷移を伴うメソッド呼び出しが行われている脆弱箇所、２列目の１３０２はその原因となる外部データの入力箇所、３列目の１３０３は原因となる外部データが脆弱なライブラリメソッドに渡されるまでに経由するメソッドを経由する順番に表す経由メソッドである。その内容は前述した通りである。
【００３３】
図１６は検査データＤＢ２２Ｅの格納データ１４０１の例である。
図１７(a)はクライアントからWebアプリケーションに対し入力される、Webアプリケーション開発者が想定する正常なリクエストパラメータ値を登録したリクエストパラメータＤＢ２２Ｃの格納データの例であり、検査対象ページのＵＲＬ１５０１、パラメータ名１５０２、パラメータ値１５０３の組からなる。
【００３４】
図１７(b)は図１７(a)に対応するリクエストデータの例である。ステップ５０５では、このリクエストデータのうち、検査すべきパラメータのデータ値だけを検査データ値に変更したリクエストデータを組み立てて、Webアプリケーション実行検査手段２２ＢからWebアプリケーション検査管理手段２２Ａに対して送信する。
【００３５】
図１８はレスポンス脆弱性判定ＤＢ２２Ｄの格納データの例であり、レスポンス脆弱性判定コード１６０１からなる。このＤＢ２２Ｄに登録されたコードがレスポンスデータに含まれた場合に脆弱性であると判断する。
【００３６】
図１９は結果レポートの例を示す図である。
１列目は脆弱性の深刻度合いを表す深刻度、２列目は脆弱な遷移を伴うメソッド呼び出しが行われている脆弱箇所、３列目はその原因となる外部データの入力箇所、４列目は原因となる外部データが脆弱なライブラリメソッドに渡されるまでに経由するメソッドを経由する順番に表す経由メソッドである。
Webアプリケーション実行検査の結果、図１５の中間結果レポートのうち、上から４箇所については脆弱で、５箇所目についてはそうではないという結果が得られ、その内容をステップ５０９にてWebアプリケーション検査管理手段２２Ａに通知し、Webアプリケーション検査管理手段２２Ａが最終的な検査結果の通知として、ステップ５１０で生成したのが図１９の結果レポートである。
ソースコード検査及びWebアプリケーション実行検査の両方で脆弱性と判定されたものは深刻度高、ソースコード検査でのみ脆弱性と判定されたものは深刻度低として出力する。後者は脆弱性ではないものの該当箇所以外のコードを少し変更しただけで脆弱性となってしまう箇所（潜在的な脆弱性）である。このような箇所は脆弱性対策の優先度は低いが、深刻度の高い箇所の対策が済んだ時点でソフトウェア開発の工数に余裕があればできれば対策を行っておいた方が良い所である。
経由メソッドは特にメソッドの数がある程度多く、メソッド呼び出しが深いときに役立つ。
経由メソッドが出力されない従来の方法では、例えばＡクラスの６行目で指摘を出しても、その具体的な理由である、外部データ取得メソッド、経由メソッド、脆弱メソッドの情報が無ければ対処に時間が掛かってしまう。それに対し、本発明の方法では、脆弱なメソッドの使い方次第であるが、例の場合method1は経由メソッドに記述されるいずれかの場所でサニタイジングすればよいと分かり脆弱性対策にかかる工数が少なくて済む。
【００３７】
なお、上記の実施形態については、本発明をWebアプリケーションの検査を行う適用例について説明したが、本発明はこれに限定されるものではなく、各種のアプリケーションに適用可能であることは言うまでもない。
【図面の簡単な説明】
【００３８】
【図１】本発明の一実施の形態例を示すシステム構成図である。
【図２】検査対象Webアプリケーションのソースコードの例を示す図である。
【図３】検査対象Webアプリケーションの入力ページの例を示す図である。
【図４】クラス名URLマッピングＤＢの格納データの例を示す図である。
【図５】本発明の脆弱性検査の動作を示すシーケンス図である。
【図６】ライブラリメソッドＤＢの格納データの構成図である。
【図７】プログラマ定義メソッドＤＢの格納データの構成図である。
【図８】変数ＤＢの格納データの構成図である。
【図９】ソースコード検査手段の処理手順を表すフローチャートである。
【図１０】メソッド定義内解析処理の処理手順を表すフローチャートである。
【図１１】中間結果出力処理の処理手順を表すフローチャートである。
【図１２】プログラマ定義メソッドＤＢの格納データの例を示す図である。
【図１３】外部データＤＢの格納データの例を示す図である。
【図１４】変数ＤＢの格納データの例を示す図である。
【図１５】中間結果レポートの例を示す図である。
【図１６】検査データＤＢの格納データの例を示す図である。
【図１７】リクエストパラメータＤＢの格納データとリクエストデータの例を示す図である。
【図１８】レスポンス脆弱性判定ＤＢの格納データの例を示す図である。
【図１９】結果レポートの例を示す図である。
【符号の説明】
【００３９】
１１Ａ、２１Ａ…ＣＰＵ、１１Ｂ、２１Ｂ…メモリ、１３、２３…通信ポート、１１、２１…端末装置、１２、２２…外部記憶装置、３…ネットワーク、１２Ａ…ソースコード検査手段、１２Ｂ…ライブラリメソッドＤＢ、１２Ｃ…プログラマ定義メソッドＤＢ、１２Ｄ…変数ＤＢ、１２Ｅ…外部データＤＢ、１２Ｆ…中間結果レポート、１２Ｇ…クラスＵＲＬマッピングＤＢ、１２Ｈ…Ｗｅｂアプリケーション供給手段、１２I…ソースコード、２２Ａ…Ｗｅｂアプリケーション検査管理手段、２２Ｂ…Ｗｅｂアプリ実行検査手段、２２C…リクエストパラメータＤＢ、２２Ｄ…レスポンス脆弱性判定ＤＢ、２２Ｅ…検査データＤＢ、２２Ｆ…結果レポート。
【図１】
0004587976.tif 000002
【図２】
0004587976.tif 000003
【図３】
0004587976.tif 000004
【図４】
0004587976.tif 000005
【図５】
0004587976.tif 000006
【図６】
0004587976.tif 000007
【図７】
0004587976.tif 000008
【図８】
0004587976.tif 000009
【図９】
0004587976.tif 000010
【図１０】
0004587976.tif 000011
【図１１】
0004587976.tif 000012
【図１２】
0004587976.tif 000013
【図１３】
0004587976.tif 000014
【図１４】
0004587976.tif 000015
【図１５】
0004587976.tif 000016
【図１６】
0004587976.tif 000017
【図１７】
0004587976.tif 000018
【図１８】
0004587976.tif 000019
【図１９】
0004587976.tif 000020