JP2007233432A - アプリケーションの脆弱性検査方法および装置 - Google Patents
アプリケーションの脆弱性検査方法および装置 Download PDFInfo
- Publication number
- JP2007233432A JP2007233432A JP2006050560A JP2006050560A JP2007233432A JP 2007233432 A JP2007233432 A JP 2007233432A JP 2006050560 A JP2006050560 A JP 2006050560A JP 2006050560 A JP2006050560 A JP 2006050560A JP 2007233432 A JP2007233432 A JP 2007233432A
- Authority
- JP
- Japan
- Prior art keywords
- data
- inspection
- vulnerability
- application
- source code
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Granted
Links
Images
Abstract
【課題】 プログラマに対し脆弱な遷移を伴うメソッド呼び出し箇所だけでなく、外部入力データ箇所および該データが経由するメソッドの情報と、潜在的な脆弱な箇所を区別して検出して提示すること。
【解決手段】 検査対象アプリケーションのソースコードについて、ソースコード外部からのデータをその入力箇所ごとに区別し、変数の参照する値およびメソッドによる遷移を解析することで脆弱性の検査を行い、脆弱性の可能性のあるコードの位置およびその原因となる外部からのデータの入力位置と該データが経由するメソッドの情報を取得した後、検出した箇所について、検査対象アプリケーションに対し、検査のためのリクエストデータを送付しそのレスポンスデータ及び予め登録している脆弱性判定コードと比較することにより、脆弱性が含まれるかどうかを判定し、その結果、脆弱であるものと、そうでないものを区別して出力する。
【選択図】 図５
【解決手段】 検査対象アプリケーションのソースコードについて、ソースコード外部からのデータをその入力箇所ごとに区別し、変数の参照する値およびメソッドによる遷移を解析することで脆弱性の検査を行い、脆弱性の可能性のあるコードの位置およびその原因となる外部からのデータの入力位置と該データが経由するメソッドの情報を取得した後、検出した箇所について、検査対象アプリケーションに対し、検査のためのリクエストデータを送付しそのレスポンスデータ及び予め登録している脆弱性判定コードと比較することにより、脆弱性が含まれるかどうかを判定し、その結果、脆弱であるものと、そうでないものを区別して出力する。
【選択図】 図５
Description
本発明は、Webアプリケーションなどのアプリケーションを検査し、そのソースコード内に含まれる脆弱性が生じる箇所を検出するとともにプログラマの脆弱性の修正作業を支援する情報を提供するアプリケーションの脆弱性検査装置に関するものである。
一般に、ソフトウェア（アプリケーション）に含まれる脆弱性を検査する方法には、稼動中のソフトウェアを調べる方法と、ソフトウェアのソースコードを静的に調べる方法の２つがある。
稼動中のソフトウェアの検査手法は、動作するソフトウェアに様々なデータを入力し、それに対する結果を元に脆弱性が含まれているかどうかを判断するものである。
例えばOWASPで公開されているWebScarabのManual Interceptプラグインを利用した検査が挙げられる。
稼動中のソフトウェアの検査手法は、動作するソフトウェアに様々なデータを入力し、それに対する結果を元に脆弱性が含まれているかどうかを判断するものである。
例えば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メソッドにより外部からのデータを取得するが、このメソッドの名前にパラメータ名が含まれる。そのため同様にパラメータ名を取得できる。このような方法で取得したパラメータの名前を外部データＤＢ１２Ｅに登録する。
なお、以下の実施形態にいては、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アプリケーション供給手段１２Ｈが格納されている外部記憶装置１２と、通信ポート１３から構成されている。
図１において、サーバ１とクライアント２は、ネットワーク３によって繋がっている。サーバ１は、ＣＰＵ１１Ａ、メモリ１１Ｂからなる端末装置１１と、ソースコードを解析して脆弱性の検査を行うソースコード検査手段１２Ａと、予めライブラリメソッドを登録しておくライブラリメソッドＤＢ１２Ｂと、プログラマが定義したメソッドを管理するためのプログラマ定義メソッドＤＢ１２Ｃ、変数の値を管理する変数ＤＢ１２Ｄと、外部データを取得した位置を管理する外部データＤＢ１２Ｅと、検査によって得られた脆弱性を生じる可能性のあるコードに関する情報を記録するための中間結果レポート１２Ｆと、クラス名と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行目の条件文のコードを少し変更しただけで、脆弱性が発生してしまう潜在的に脆弱な箇所である。
PrintWriter.println(String)メソッドもしくはそれを内部で呼ぶメソッドの呼び出しが6、7、8、9、12行目で行われており、このうち6、7、8、9行目が脆弱である。それに対し12行目は、第一引き数に渡されるデータの内容が、その手前の11行目の条件文でチェックされているため、脆弱性ではない。ただし、この12行目は、該当箇所以外の箇所、今の場合11行目の条件文のコードを少し変更しただけで、脆弱性が発生してしまう潜在的に脆弱な箇所である。
図３は、検査対象のWebアプリケーションに対応する入力ページの例である。
図４は、マッピングＤＢ１２Ｇの例である。該ＤＢはWebアプリケーション名、ソースコード名、クラス名、URL名からなる。URLにはWebアプリケーションのルートからの相対パスを指定する。URLが無い場合は空白とする。
図４は、マッピングＤＢ１２Ｇの例である。該ＤＢはWebアプリケーション名、ソースコード名、クラス名、URL名からなる。URLにはWebアプリケーションのルートからの相対パスを指定する。URLが無い場合は空白とする。
図５はクライアント端末のWebアプリケーション検査管理手段２２Ａと、サーバのWebアプリケーション実行検査手段２２Ｂ、ソースコード検査手段１２Ａ、およびWebアプリケーション供給手段１２Ｆの間でやりとりされる命令及びデータの流れを示した図である。なお、検査対象のWebアプリケーションは、Webアプリケーション供給手段１２Ｃによりサービスを提供可能な状態にあるとする。
まず始めに、Webアプリケーション検査管理手段２２Ａは検査対象アプリケーション名をソースコード検査手段１２Ａに伝達する（ステップ５０１）。
ソースコード検査手段１２Ａは、マッピングＤＢ１２Gに登録された該検査対象アプリケーションに相当するソースコード１２Ｉを取得し、そのソースコード検査を実施し（ステップ５０２）、その結果を中間結果レポートとしてWebアプリケーション検査管理手段２２Ａに送付する。
この時、クラス名とURLを対応付けたクラスURLマッピングＤＢ１２Gも同時に送付する（ステップ５０３）。
まず始めに、Webアプリケーション検査管理手段２２Ａは検査対象アプリケーション名をソースコード検査手段１２Ａに伝達する（ステップ５０１）。
ソースコード検査手段１２Ａは、マッピングＤＢ１２Gに登録された該検査対象アプリケーションに相当するソースコード１２Ｉを取得し、そのソースコード検査を実施し（ステップ５０２）、その結果を中間結果レポートとしてWebアプリケーション検査管理手段２２Ａに送付する。
この時、クラス名とURLを対応付けたクラスURLマッピングＤＢ１２Gも同時に送付する（ステップ５０３）。
次に、Webアプリケーション検査管理手段２２Ａは、Webアプリケーション実行検査手段１２Ｂに対し、中間結果レポート１２ＦおよびクラスURLマッピングＤＢをWebアプリケーション実行検査手段１２Ｂに送付する（ステップ５０４）。
Webアプリケーション実行検査手段１２Ｂはこれらから検査ページURLと検査パラメータ名の情報を取得するとともに、リクエストパラメータＤＢおよび検査データＤＢを参照することで、検査用リクエストデータを組み立て、それをWebアプリケーション供給手段１２Ｆにより供給されている検査対象Webアプリケーションに送付する（ステップ５０５）。
その後、Webアプリケーション実行検査手段１２ＢはWebアプリケーションからの応答を受信し（ステップ５０６、５０７）、脆弱性判定ＤＢ２２Ｄの脆弱性判定データと比較することで脆弱性かどうかを判定する（ステップ５０８）。そして、ステップ５０５から５０８までは各パラメータおよび検査データ値について繰り返す。
そして、その結果を、Webアプリケーション検査管理手段２２Ａに通知し（ステップ５０９）、最終的に結果レポートを生成する。このとき、ソースコード検査及びWebアプリケーション実行検査の両方で脆弱性と判定されたものは深刻度高、ソースコード検査でのみ脆弱性と判定されたものは深刻度低として出力する（ステップ５１０）。
最後に検査終了をWebアプリケーション実行検査手段１２Ｂおよびソースコード検査手段１２Ａに告げる（ステップ５１１）。
Webアプリケーション実行検査手段１２Ｂはこれらから検査ページURLと検査パラメータ名の情報を取得するとともに、リクエストパラメータＤＢおよび検査データＤＢを参照することで、検査用リクエストデータを組み立て、それをWebアプリケーション供給手段１２Ｆにより供給されている検査対象Webアプリケーションに送付する（ステップ５０５）。
その後、Webアプリケーション実行検査手段１２ＢはWebアプリケーションからの応答を受信し（ステップ５０６、５０７）、脆弱性判定ＤＢ２２Ｄの脆弱性判定データと比較することで脆弱性かどうかを判定する（ステップ５０８）。そして、ステップ５０５から５０８までは各パラメータおよび検査データ値について繰り返す。
そして、その結果を、Webアプリケーション検査管理手段２２Ａに通知し（ステップ５０９）、最終的に結果レポートを生成する。このとき、ソースコード検査及びWebアプリケーション実行検査の両方で脆弱性と判定されたものは深刻度高、ソースコード検査でのみ脆弱性と判定されたものは深刻度低として出力する（ステップ５１０）。
最後に検査終了をWebアプリケーション実行検査手段１２Ｂおよびソースコード検査手段１２Ａに告げる（ステップ５１１）。
図６は、ライブラリメソッドＤＢ１２Ｂの格納データの例である。
ライブラリメソッドＤＢ１２Ｂは、標準ライブラリに含まれるメソッド等のデータ遷移を予め登録したデータベースである。１列目はメソッド名、２列目はどの値がどこに遷移するかを示すデータ遷移のリストである。ここではデータ遷移を’→’を用いて表記し、’→’の左を遷移元、’→’の右を遷移先とする。遷移元および遷移先の値に設定する値には、引数番号、外部データを表すIN、戻り値を表すR、脆弱性を生じる可能性のある遷移先であるVUL_XSS、obj.method() 形式のメソッド呼び出しのobjを指すメソッド呼び出し元オブジェクトフラグTHISがある。遷移先にはこれらのうちのいずれかを、遷移元にはこれらのいずれかもしくはその組み合わせを設定する。
ライブラリメソッドＤＢ１２Ｂは、標準ライブラリに含まれるメソッド等のデータ遷移を予め登録したデータベースである。１列目はメソッド名、２列目はどの値がどこに遷移するかを示すデータ遷移のリストである。ここではデータ遷移を’→’を用いて表記し、’→’の左を遷移元、’→’の右を遷移先とする。遷移元および遷移先の値に設定する値には、引数番号、外部データを表すIN、戻り値を表すR、脆弱性を生じる可能性のある遷移先であるVUL_XSS、obj.method() 形式のメソッド呼び出しのobjを指すメソッド呼び出し元オブジェクトフラグTHISがある。遷移先にはこれらのうちのいずれかを、遷移元にはこれらのいずれかもしくはその組み合わせを設定する。
図７は、プログラマ定義メソッドＤＢ１２Ｃの格納データの例である。
プログラマ定義メソッドＤＢ１２Ｃには、プログラマが定義したメソッドについてのデータ遷移情報を、ソースコード解析中に登録する。本ＤＢのうち１列目および２列目は、ライブラリメソッドＤＢ１２Ｂと同様である。ただし、遷移値の遷移元に外部データを設定する場合は、INの代わりにINi(i=1,・・n)（nは十分大きな正の整数）が設定される。
３列目の解析済みフラグはそのメソッド定義の解析を終了したかどうかを表すフラグである。解析済みフラグは0か1の値をとり、解析済みフラグが0であるメソッドは、後述の手順９０６から９１１までの解析が終了していないことを表し、一方、１であるメソッドは前記解析が終了していることを表す。初期値は0とする。以下、前記解析が終了していないメソッドの状態を未解析であると呼ぶ。
４列目の脆弱メソッド名は初期値をnullとし、遷移値の遷移先に脆弱メソッドフラグVUL_XSSが設定されている場合にのみ脆弱なメソッドの名前を登録する。
プログラマ定義メソッドＤＢ１２Ｃには、プログラマが定義したメソッドについてのデータ遷移情報を、ソースコード解析中に登録する。本ＤＢのうち１列目および２列目は、ライブラリメソッドＤＢ１２Ｂと同様である。ただし、遷移値の遷移元に外部データを設定する場合は、INの代わりにINi(i=1,・・n)（nは十分大きな正の整数）が設定される。
３列目の解析済みフラグはそのメソッド定義の解析を終了したかどうかを表すフラグである。解析済みフラグは0か1の値をとり、解析済みフラグが0であるメソッドは、後述の手順９０６から９１１までの解析が終了していないことを表し、一方、１であるメソッドは前記解析が終了していることを表す。初期値は0とする。以下、前記解析が終了していないメソッドの状態を未解析であると呼ぶ。
４列目の脆弱メソッド名は初期値をnullとし、遷移値の遷移先に脆弱メソッドフラグVUL_XSSが設定されている場合にのみ脆弱なメソッドの名前を登録する。
図８は、変数ＤＢ１２Ｄの格納データの例である。
１列目は変数ＤＢ１２Ｄに登録された変数の識別番号である。この変数番号は、static変数の場合、負の整数値で−１、−２と降順に付ける。仮引数の場合、引数番号と一致する正の整数値を付ける。ローカル変数の場合、既に登録されている仮引数の変数番号に続くように昇順に付ける。正の整数値が１つも登録されていない場合、１から順に昇順に付ける。
２列目は変数の種別を表し、仮引数を登録する場合は’A’、ローカル変数なら’L’、static変数なら'S'を格納する。
３列目は変数名である。
４列目は変数の保持する値であり、初期値は変数番号と同一の値とする。値が定数の場合は、Cとする。後述する検査対象ソースコードに配列変数の遷移がないため、簡略化して記述したが、変数ＤＢ１２Ｄに変数の次元を加えることで引数変数に書き込むデータ遷移などにも対応できる。
１列目は変数ＤＢ１２Ｄに登録された変数の識別番号である。この変数番号は、static変数の場合、負の整数値で−１、−２と降順に付ける。仮引数の場合、引数番号と一致する正の整数値を付ける。ローカル変数の場合、既に登録されている仮引数の変数番号に続くように昇順に付ける。正の整数値が１つも登録されていない場合、１から順に昇順に付ける。
２列目は変数の種別を表し、仮引数を登録する場合は’A’、ローカル変数なら’L’、static変数なら'S'を格納する。
３列目は変数名である。
４列目は変数の保持する値であり、初期値は変数番号と同一の値とする。値が定数の場合は、Cとする。後述する検査対象ソースコードに配列変数の遷移がないため、簡略化して記述したが、変数ＤＢ１２Ｄに変数の次元を加えることで引数変数に書き込むデータ遷移などにも対応できる。
図９は、本実施形態のソースコード脆弱性検査装置の処理手順を示すフローチャートである。
ソースコード検査手段１２Ａが起動されると、検査対象のWebアプリケーションのソースコードを読み込み、そのソースコードを全てたどり、見つかったプログラマ定義メソッドをプログラマ定義メソッドＤＢ１２Ｃに、static変数を変数ＤＢ１２Ｄに、それぞれ登録する。static変数の変数番号は、負の整数値で−１から降順に付ける（ステップ９０１）。
次に、ソースコードの先頭を探索開始位置にする（ステップ９０２）。ソースファイルが複数ある場合、任意のファイルの先頭を探索開始位置とする。
次に、ソースコード中から、未解析であるメソッド定義を探索する（ステップ９０３）。未解析のメソッドが無い場合は後述するステップ９１２に移る（ステップ９０３）。該当メソッドが見つかれば、次に、該当メソッドの定義の中で、未解析のメソッド呼び出しが行われていないかを探索する（ステップ９０４）。未解析のメソッド呼び出しが行われている場合、探索開始位置をソースコード中の次のメソッド定義位置に移し（ステップ９０５）、ステップ９０３に戻る。未解析のメソッド呼び出しが行われていない場合、該メソッドを処理対象メソッドとし、解析を開始する（ステップ９０６）。対象メソッドの仮引数があればそれを変数ＤＢ１２Ｄに登録する（ステップ９０７）。このとき、仮引数の変数番号は、その引数番号と一致するように登録する。そして、メソッド定義内解析処理（ステップ９０８）に移る。これは図１０に示す。
ソースコード検査手段１２Ａが起動されると、検査対象のWebアプリケーションのソースコードを読み込み、そのソースコードを全てたどり、見つかったプログラマ定義メソッドをプログラマ定義メソッドＤＢ１２Ｃに、static変数を変数ＤＢ１２Ｄに、それぞれ登録する。static変数の変数番号は、負の整数値で−１から降順に付ける（ステップ９０１）。
次に、ソースコードの先頭を探索開始位置にする（ステップ９０２）。ソースファイルが複数ある場合、任意のファイルの先頭を探索開始位置とする。
次に、ソースコード中から、未解析であるメソッド定義を探索する（ステップ９０３）。未解析のメソッドが無い場合は後述するステップ９１２に移る（ステップ９０３）。該当メソッドが見つかれば、次に、該当メソッドの定義の中で、未解析のメソッド呼び出しが行われていないかを探索する（ステップ９０４）。未解析のメソッド呼び出しが行われている場合、探索開始位置をソースコード中の次のメソッド定義位置に移し（ステップ９０５）、ステップ９０３に戻る。未解析のメソッド呼び出しが行われていない場合、該メソッドを処理対象メソッドとし、解析を開始する（ステップ９０６）。対象メソッドの仮引数があればそれを変数ＤＢ１２Ｄに登録する（ステップ９０７）。このとき、仮引数の変数番号は、その引数番号と一致するように登録する。そして、メソッド定義内解析処理（ステップ９０８）に移る。これは図１０に示す。
対象メソッドの終了箇所に至るまで、ステップ９０８を繰り返す。対象メソッドの処理を終えたら、解析済みフラグを１に設定し、ステップ９１０に移る（ステップ９０９）。
次に、変数ＤＢ１２Ｄから仮引数とローカル変数についての登録データを削除する。static変数の値のうちINi以外の値を初期化する（ステップ９１１）。対象メソッドについての処理を終え、ステップ９０３に戻る。
ステップ９１２では変数ＤＢ１２Ｄに、前回解析時と比較して、static変数の値の変化があるかどうかを調べる。変更がある場合、プログラマ定義メソッドＤＢ１２Ｃの解析済みフラグの値をすべて０に初期化し、ステップ９０３へ戻る。一方、無い場合は処理を終了する。
次に、変数ＤＢ１２Ｄから仮引数とローカル変数についての登録データを削除する。static変数の値のうちINi以外の値を初期化する（ステップ９１１）。対象メソッドについての処理を終え、ステップ９０３に戻る。
ステップ９１２では変数ＤＢ１２Ｄに、前回解析時と比較して、static変数の値の変化があるかどうかを調べる。変更がある場合、プログラマ定義メソッドＤＢ１２Ｃの解析済みフラグの値をすべて０に初期化し、ステップ９０３へ戻る。一方、無い場合は処理を終了する。
次に、図１０に示すメソッド内解析処理のフローチャートについて説明する。
ここでは、解析箇所がローカル変数定義箇所でなければ、ステップ９２０３に移る（ステップ９２０１）。ローカル変数定義箇所であれば、定義されている変数を変数ＤＢ１２Ｄに登録する。変数番号は、正の整数で昇順に付ける（ステップ９２０２）。
解析箇所が変数アクセス箇所でなければ、ステップ９２０５に移る（ステップ９２０３）。変数アクセス箇所であれば、変数ＤＢ１２Ｄから該変数の値を取得する（ステップ９２０４）。
解析箇所がメソッド呼び出し箇所でなければ、終了する（ステップ９２０５）。メソッド呼び出し箇所であれば、メソッド名でライブラリメソッドＤＢ１２Ｂおよびプログラマ定義メソッドＤＢ１２Ｂを探索し、該当メソッドの遷移値を取得する（ステップ９２０６）。
ここでは、解析箇所がローカル変数定義箇所でなければ、ステップ９２０３に移る（ステップ９２０１）。ローカル変数定義箇所であれば、定義されている変数を変数ＤＢ１２Ｄに登録する。変数番号は、正の整数で昇順に付ける（ステップ９２０２）。
解析箇所が変数アクセス箇所でなければ、ステップ９２０５に移る（ステップ９２０３）。変数アクセス箇所であれば、変数ＤＢ１２Ｄから該変数の値を取得する（ステップ９２０４）。
解析箇所がメソッド呼び出し箇所でなければ、終了する（ステップ９２０５）。メソッド呼び出し箇所であれば、メソッド名でライブラリメソッドＤＢ１２Ｂおよびプログラマ定義メソッドＤＢ１２Ｂを探索し、該当メソッドの遷移値を取得する（ステップ９２０６）。
遷移値がない場合、処理を終える（ステップ９２０７）。遷移値がある場合、最初の遷移値を取り出す。遷移の遷移元が正の整数（引数番号）である場合、その遷移元を引数番号に相当する実引数値に修正後、以下の処理を行う。
遷移元がTHISである場合、メソッド呼び出し元の変数の値に修正後、以下の処理を行う。それ以外の場合、何もせず以下の処理を行う（ステップ９２０８）。
遷移先がVUL_XSSで、遷移元にINiを含むデータ遷移であれば、ソース中の該当箇所への警告を検査結果として出力するため、ステップ９２１０の中間出力レポート処理に移る（ステップ９２０９）。ステップ９２１０については図１１で説明する。この手順を追えるとステップ９２０６に移る（ステップ９２１０）。
遷移元にINを含む遷移を持つライブラリメソッドである外部データ取得メソッドの呼び出し箇所であれば、ステップ９２１２で外部データＤＢに登録した後、ステップ９２１３に移る。そうでなければステップ９２１３に移る。外部データＤＢ１２Ｅに登録する外部データフラグ名は１箇所目はIN1、２箇所目はIN2、・・とする（ステップ９２１１、９２１２）。
遷移元がTHISである場合、メソッド呼び出し元の変数の値に修正後、以下の処理を行う。それ以外の場合、何もせず以下の処理を行う（ステップ９２０８）。
遷移先がVUL_XSSで、遷移元にINiを含むデータ遷移であれば、ソース中の該当箇所への警告を検査結果として出力するため、ステップ９２１０の中間出力レポート処理に移る（ステップ９２０９）。ステップ９２１０については図１１で説明する。この手順を追えるとステップ９２０６に移る（ステップ９２１０）。
遷移元にINを含む遷移を持つライブラリメソッドである外部データ取得メソッドの呼び出し箇所であれば、ステップ９２１２で外部データＤＢに登録した後、ステップ９２１３に移る。そうでなければステップ９２１３に移る。外部データＤＢ１２Ｅに登録する外部データフラグ名は１箇所目はIN1、２箇所目はIN2、・・とする（ステップ９２１１、９２１２）。
ステップ９２１３において、データ遷移の遷移先の値に応じて処理を行う。遷移先が変数番号であれば、変数ＤＢ１２Ｄの該当する変数値を更新する。遷移先が戻り値を表すRであれば、以後の処理で遷移元の値を持つ変数が該メソッドの位置に記述されていた場合と同じように扱う。
遷移先が変数番号でない遷移の場合、プログラマ定義メソッドＤＢ１２Ｃに追加する。
なお、代入文についても、右辺が左辺に遷移するデータ遷移として、メソッド呼び出しと同様に処理する。
遷移先が変数番号でない遷移の場合、プログラマ定義メソッドＤＢ１２Ｃに追加する。
なお、代入文についても、右辺が左辺に遷移するデータ遷移として、メソッド呼び出しと同様に処理する。
次に、図１１のフローチャートについて説明する。このフローチャートは中間出力レポートへの１つのレコードを出力する際の手順を示したものである。なお重複するレコードは出力しない。
まず、脆弱箇所に脆弱メソッド名および、クラス名と行番号からなる位置の組を設定する（ステップ９３０１）。遷移元の名前INiを元に外部データＤＢを検索し、該当レコードの入力データ情報を取得し、それを入力箇所に設定する（ステップ９３０２）。経由メソッドの初期値をnullとする（ステップ９３０３）。
脆弱メソッド名がライブラリメソッドＤＢ１２Ｂ内になければ、ステップ９３０５に移る。あれば、ステップ９３０６に移る（ステップ９３０４）。ステップ９３０５では、該メソッドをプログラム定義メソッドＤＢ１２Ｃから検索し、該当レコードのメソッド名を経由メソッドに追加登録する。ステップ９３０６では、脆弱箇所、入力箇所、経由メソッドを出力する。そして処理を終える。
まず、脆弱箇所に脆弱メソッド名および、クラス名と行番号からなる位置の組を設定する（ステップ９３０１）。遷移元の名前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ではその両方が、第一引数の値が各第１引き数に渡される形で呼ばれている。よって脆弱メソッド名は図示のようになる。
まず、内部で他のプログラマ定義メソッド呼び出しのない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に対し、仮引数とローカル変数を変数ＤＢ１２Ｄに登録する（ステップ９０７）。３行目および４行目では外部データ取得メソッドHttpServletRequest.getParameter(String)メソッドがあるため、外部データＤＢ１２Ｅの格納データは図１３のようになる。
doGetについて５行目までの解析終了時の変数ＤＢ１２Ｄの格納データが、図１４である。
次に、６行目のメソッドmethod1の呼び出しによるデータ遷移の処理を行う（ステップ９０８）。method1の遷移値を、ライブラリメソッドＤＢ１２Ｂおよびプログラマ定義メソッドＤＢ１２Ｃより検索し取り出す。すると、1→VUL_XSSの遷移が取得される。遷移元の1は第一引き数を表し、第１引き数に与えられた変数sの参照する値を変数ＤＢ１２Ｄから得て遷移元を書き換えるとIN1→VUL_XSSと、脆弱な遷移となるため、この行を脆弱な箇所として中間レポートに出力する。このとき入力箇所については外部データＤＢのフラグ名がIN１のレコードから取得し、経由メソッドについてはプログラマ定義メソッドＤＢの脆弱メソッド名から取得する。
次に、６行目のメソッドmethod1の呼び出しによるデータ遷移の処理を行う（ステップ９０８）。method1の遷移値を、ライブラリメソッドＤＢ１２Ｂおよびプログラマ定義メソッドＤＢ１２Ｃより検索し取り出す。すると、1→VUL_XSSの遷移が取得される。遷移元の1は第一引き数を表し、第１引き数に与えられた変数sの参照する値を変数ＤＢ１２Ｄから得て遷移元を書き換えるとIN1→VUL_XSSと、脆弱な遷移となるため、この行を脆弱な箇所として中間レポートに出力する。このとき入力箇所については外部データＤＢのフラグ名がIN１のレコードから取得し、経由メソッドについてはプログラマ定義メソッドＤＢの脆弱メソッド名から取得する。
次に７行目のメソッドmethod２の呼び出しによるデータ遷移の処理を行う（ステップ９０８）。６行目の処理とほぼ同じであるが、第１引き数に与えられた変数の値がIN1およびIN2である。そのため入力箇所は２箇所を並列に並べて出力する。
次に８行目のメソッドmethoＤＢ1の呼び出しによるデータ遷移の処理を行う（ステップ９０８）。６行目の処理とほぼ同じであるが、脆弱メソッド名が２つあるため、経由メソッドも２つ並べて出力される。
次に８行目のメソッドmethoＤＢ1の呼び出しによるデータ遷移の処理を行う（ステップ９０８）。６行目の処理とほぼ同じであるが、脆弱メソッド名が２つあるため、経由メソッドも２つ並べて出力される。
次に９、１２行目のメソッドPrintWriter.println(String)の呼び出しによるデータ遷移の処理を行う（ステップ９０８）。６行目の処理とほぼ同じであるが、直接脆弱なライブラリメソッドを呼び出しているため、経由メソッドはない。
以上で対象メソッドdoGetの処理を終える（ステップ９０９）。ステップ９０９終了時のプログラマ定義メソッドＤＢ１２Ｃは図１２のdoGetの解析済みフラグを１に変更したものである。
未解析のメソッド探索（ステップ９０３）にて該当メソッドが見つからないのでステップ９１２に移る。
この検査対象ソースコードにはstatic変数は定義されていない。よって検査を終了する。
以上で対象メソッドdoGetの処理を終える（ステップ９０９）。ステップ９０９終了時のプログラマ定義メソッドＤＢ１２Ｃは図１２のdoGetの解析済みフラグを１に変更したものである。
未解析のメソッド探索（ステップ９０３）にて該当メソッドが見つからないのでステップ９１２に移る。
この検査対象ソースコードにはstatic変数は定義されていない。よって検査を終了する。
図１５は中間出力レポート１３００の例である。
１列目の１３０１は脆弱な遷移を伴うメソッド呼び出しが行われている脆弱箇所、２列目の１３０２はその原因となる外部データの入力箇所、３列目の１３０３は原因となる外部データが脆弱なライブラリメソッドに渡されるまでに経由するメソッドを経由する順番に表す経由メソッドである。その内容は前述した通りである。
１列目の１３０１は脆弱な遷移を伴うメソッド呼び出しが行われている脆弱箇所、２列目の１３０２はその原因となる外部データの入力箇所、３列目の１３０３は原因となる外部データが脆弱なライブラリメソッドに渡されるまでに経由するメソッドを経由する順番に表す経由メソッドである。その内容は前述した通りである。
図１６は検査データＤＢ２２Ｅの格納データ１４０１の例である。
図１７(a)はクライアントからWebアプリケーションに対し入力される、Webアプリケーション開発者が想定する正常なリクエストパラメータ値を登録したリクエストパラメータＤＢ２２Ｃの格納データの例であり、検査対象ページのＵＲＬ１５０１、パラメータ名１５０２、パラメータ値１５０３の組からなる。
図１７(a)はクライアントからWebアプリケーションに対し入力される、Webアプリケーション開発者が想定する正常なリクエストパラメータ値を登録したリクエストパラメータＤＢ２２Ｃの格納データの例であり、検査対象ページのＵＲＬ１５０１、パラメータ名１５０２、パラメータ値１５０３の組からなる。
図１７(b)は図１７(a)に対応するリクエストデータの例である。ステップ５０５では、このリクエストデータのうち、検査すべきパラメータのデータ値だけを検査データ値に変更したリクエストデータを組み立てて、Webアプリケーション実行検査手段２２ＢからWebアプリケーション検査管理手段２２Ａに対して送信する。
図１８はレスポンス脆弱性判定ＤＢ２２Ｄの格納データの例であり、レスポンス脆弱性判定コード１６０１からなる。このＤＢ２２Ｄに登録されたコードがレスポンスデータに含まれた場合に脆弱性であると判断する。
図１９は結果レポートの例を示す図である。
１列目は脆弱性の深刻度合いを表す深刻度、２列目は脆弱な遷移を伴うメソッド呼び出しが行われている脆弱箇所、３列目はその原因となる外部データの入力箇所、４列目は原因となる外部データが脆弱なライブラリメソッドに渡されるまでに経由するメソッドを経由する順番に表す経由メソッドである。
Webアプリケーション実行検査の結果、図１５の中間結果レポートのうち、上から４箇所については脆弱で、５箇所目についてはそうではないという結果が得られ、その内容をステップ５０９にてWebアプリケーション検査管理手段２２Ａに通知し、Webアプリケーション検査管理手段２２Ａが最終的な検査結果の通知として、ステップ５１０で生成したのが図１９の結果レポートである。
ソースコード検査及びWebアプリケーション実行検査の両方で脆弱性と判定されたものは深刻度高、ソースコード検査でのみ脆弱性と判定されたものは深刻度低として出力する。後者は脆弱性ではないものの該当箇所以外のコードを少し変更しただけで脆弱性となってしまう箇所（潜在的な脆弱性）である。このような箇所は脆弱性対策の優先度は低いが、深刻度の高い箇所の対策が済んだ時点でソフトウェア開発の工数に余裕があればできれば対策を行っておいた方が良い所である。
経由メソッドは特にメソッドの数がある程度多く、メソッド呼び出しが深いときに役立つ。
経由メソッドが出力されない従来の方法では、例えばＡクラスの６行目で指摘を出しても、その具体的な理由である、外部データ取得メソッド、経由メソッド、脆弱メソッドの情報が無ければ対処に時間が掛かってしまう。それに対し、本発明の方法では、脆弱なメソッドの使い方次第であるが、例の場合method1は経由メソッドに記述されるいずれかの場所でサニタイジングすればよいと分かり脆弱性対策にかかる工数が少なくて済む。
１列目は脆弱性の深刻度合いを表す深刻度、２列目は脆弱な遷移を伴うメソッド呼び出しが行われている脆弱箇所、３列目はその原因となる外部データの入力箇所、４列目は原因となる外部データが脆弱なライブラリメソッドに渡されるまでに経由するメソッドを経由する順番に表す経由メソッドである。
Webアプリケーション実行検査の結果、図１５の中間結果レポートのうち、上から４箇所については脆弱で、５箇所目についてはそうではないという結果が得られ、その内容をステップ５０９にてWebアプリケーション検査管理手段２２Ａに通知し、Webアプリケーション検査管理手段２２Ａが最終的な検査結果の通知として、ステップ５１０で生成したのが図１９の結果レポートである。
ソースコード検査及びWebアプリケーション実行検査の両方で脆弱性と判定されたものは深刻度高、ソースコード検査でのみ脆弱性と判定されたものは深刻度低として出力する。後者は脆弱性ではないものの該当箇所以外のコードを少し変更しただけで脆弱性となってしまう箇所（潜在的な脆弱性）である。このような箇所は脆弱性対策の優先度は低いが、深刻度の高い箇所の対策が済んだ時点でソフトウェア開発の工数に余裕があればできれば対策を行っておいた方が良い所である。
経由メソッドは特にメソッドの数がある程度多く、メソッド呼び出しが深いときに役立つ。
経由メソッドが出力されない従来の方法では、例えばＡクラスの６行目で指摘を出しても、その具体的な理由である、外部データ取得メソッド、経由メソッド、脆弱メソッドの情報が無ければ対処に時間が掛かってしまう。それに対し、本発明の方法では、脆弱なメソッドの使い方次第であるが、例の場合method1は経由メソッドに記述されるいずれかの場所でサニタイジングすればよいと分かり脆弱性対策にかかる工数が少なくて済む。
なお、上記の実施形態については、本発明をWebアプリケーションの検査を行う適用例について説明したが、本発明はこれに限定されるものではなく、各種のアプリケーションに適用可能であることは言うまでもない。
１１Ａ、２１Ａ…ＣＰＵ、１１Ｂ、２１Ｂ…メモリ、１３、２３…通信ポート、１１、２１…端末装置、１２、２２…外部記憶装置、３…ネットワーク、１２Ａ…ソースコード検査手段、１２Ｂ…ライブラリメソッドＤＢ、１２Ｃ…プログラマ定義メソッドＤＢ、１２Ｄ…変数ＤＢ、１２Ｅ…外部データＤＢ、１２Ｆ…中間結果レポート、１２Ｇ…クラスＵＲＬマッピングＤＢ、１２Ｈ…Ｗｅｂアプリケーション供給手段、１２I…ソースコード、２２Ａ…Ｗｅｂアプリケーション検査管理手段、２２Ｂ…Ｗｅｂアプリ実行検査手段、２２C…リクエストパラメータＤＢ、２２Ｄ…レスポンス脆弱性判定ＤＢ、２２Ｅ…検査データＤＢ、２２Ｆ…結果レポート。
Claims (2)
- アプリケーション検査管理手段からの検査開始通知を受け、検査対象のアプリケーションのソースコードについて、ソースコード外部からのデータをその入力箇所ごとに区別し、変数の参照する値およびメソッドによる遷移を解析することで脆弱性の検査を行い、脆弱性の可能性のあるコードの位置およびその原因となるアプリケーション外部からのデータの入力位置と該データが経由するメソッドの情報を取得する第１のステップと、
前記第１のステップで検出した箇所について、アプリケーション供給手段が供給する検査対象アプリケーションに対し、検査のためのリクエストデータを送付し、そのレスポンスデータ及び予め登録している脆弱性判定コードと比較することにより、脆弱性が含まれるかどうかを判定し、脆弱であるものと、そうでないものを区別して出力する第２のステップを備えることを特徴とするアプリケーションの脆弱性検査方法。 - アプリケーション検査管理手段からの検査開始通知を受け、検査対象のアプリケーションのソースコードについて、ソースコード外部からのデータをその入力箇所ごとに区別し、変数の参照する値およびメソッドによる遷移を解析することで脆弱性の検査を行い、脆弱性の可能性のあるコードの位置およびその原因となるアプリケーション外部からのデータの入力位置と該データが経由するメソッドの情報を取得する第１の手段と、
前記第１の手段で検出した箇所について、アプリケーション供給手段が供給する検査対象アプリケーションに対し、検査のためのリクエストデータを送付し、そのレスポンスデータ及びあらかじめ登録している脆弱性判定コードと比較することにより、脆弱性が含まれるかどうかを判定し、脆弱であるものと、そうでないものを区別して出力する第２の手段を備えることを特徴とするアプリケーションの脆弱性検査装置。
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP2006050560A JP4587976B2 (ja) | 2006-02-27 | 2006-02-27 | アプリケーションの脆弱性検査方法および装置 |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP2006050560A JP4587976B2 (ja) | 2006-02-27 | 2006-02-27 | アプリケーションの脆弱性検査方法および装置 |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| JP2007233432A true JP2007233432A (ja) | 2007-09-13 |
| JP4587976B2 JP4587976B2 (ja) | 2010-11-24 |
Family
ID=38554009
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| JP2006050560A Expired - Fee Related JP4587976B2 (ja) | 2006-02-27 | 2006-02-27 | アプリケーションの脆弱性検査方法および装置 |
Country Status (1)
| Country | Link |
|---|---|
| JP (1) | JP4587976B2 (ja) |
Cited By (7)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JP2010277288A (ja) * | 2009-05-28 | 2010-12-09 | Mitsubishi Electric Corp | Ｗｅｂアプリケーション診断装置、Ｗｅｂアプリケーション診断プログラム及びＷｅｂアプリケーション診断方法 |
| JP2013182441A (ja) * | 2012-03-02 | 2013-09-12 | Nec Corp | 異常原因特定支援システム、異常原因特定支援方法及び異常原因特定支援プログラム |
| JP2014174577A (ja) * | 2013-03-05 | 2014-09-22 | Ntt Data Corp | 検証装置、検証方法、及びプログラム |
| US9501646B2 (en) | 2012-09-26 | 2016-11-22 | Mitsubishi Electric Corporation | Program verification apparatus, program verification method, and computer readable medium |
| US9507933B2 (en) | 2012-08-01 | 2016-11-29 | Mitsubishi Electric Corporation | Program execution apparatus and program analysis apparatus |
| KR101876685B1 (ko) * | 2017-08-08 | 2018-07-10 | 엘에스웨어(주) | Spdx 기술을 이용하여 소프트웨어의 취약점을 관리하기 위한 시스템 및 그 방법 |
| JP2019053729A (ja) * | 2017-09-15 | 2019-04-04 | 富士通株式会社 | スマートコントラクトのテスト方法及びテスト装置 |
Citations (2)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| WO2004095176A2 (en) * | 2003-04-18 | 2004-11-04 | Ounce Labs, Inc. | Detecting vulnerabilities in source code |
| WO2005121953A1 (en) * | 2004-06-04 | 2005-12-22 | Fortify Software, Inc. | Apparatus and method for developing, testing and monitoring secure software |
-
2006
- 2006-02-27 JP JP2006050560A patent/JP4587976B2/ja not_active Expired - Fee Related
Patent Citations (2)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| WO2004095176A2 (en) * | 2003-04-18 | 2004-11-04 | Ounce Labs, Inc. | Detecting vulnerabilities in source code |
| WO2005121953A1 (en) * | 2004-06-04 | 2005-12-22 | Fortify Software, Inc. | Apparatus and method for developing, testing and monitoring secure software |
Cited By (7)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JP2010277288A (ja) * | 2009-05-28 | 2010-12-09 | Mitsubishi Electric Corp | Ｗｅｂアプリケーション診断装置、Ｗｅｂアプリケーション診断プログラム及びＷｅｂアプリケーション診断方法 |
| JP2013182441A (ja) * | 2012-03-02 | 2013-09-12 | Nec Corp | 異常原因特定支援システム、異常原因特定支援方法及び異常原因特定支援プログラム |
| US9507933B2 (en) | 2012-08-01 | 2016-11-29 | Mitsubishi Electric Corporation | Program execution apparatus and program analysis apparatus |
| US9501646B2 (en) | 2012-09-26 | 2016-11-22 | Mitsubishi Electric Corporation | Program verification apparatus, program verification method, and computer readable medium |
| JP2014174577A (ja) * | 2013-03-05 | 2014-09-22 | Ntt Data Corp | 検証装置、検証方法、及びプログラム |
| KR101876685B1 (ko) * | 2017-08-08 | 2018-07-10 | 엘에스웨어(주) | Spdx 기술을 이용하여 소프트웨어의 취약점을 관리하기 위한 시스템 및 그 방법 |
| JP2019053729A (ja) * | 2017-09-15 | 2019-04-04 | 富士通株式会社 | スマートコントラクトのテスト方法及びテスト装置 |
Also Published As
| Publication number | Publication date |
|---|---|
| JP4587976B2 (ja) | 2010-11-24 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| JP5507699B2 (ja) | 悪性サイト検出装置及び方法 | |
| US9720798B2 (en) | Simulating black box test results using information from white box testing | |
| JP4587976B2 (ja) | アプリケーションの脆弱性検査方法および装置 | |
| TWI575397B (zh) | 利用運行期代理器及動態安全分析之應用程式逐點保護技術 | |
| US9152795B2 (en) | Security vulnerability correction | |
| US9390270B2 (en) | Security testing using semantic modeling | |
| JP2007241906A (ja) | Ｗｅｂアプリケーション脆弱性動的検査方法およびシステム | |
| CN103699480A (zh) | 一种基于java的web动态安全漏洞检测方法 | |
| JPWO2006087780A1 (ja) | 脆弱性監査プログラム、脆弱性監査装置、脆弱性監査方法 | |
| US8572747B2 (en) | Policy-driven detection and verification of methods such as sanitizers and validators | |
| JP5725529B2 (ja) | Ｗｅｂ脆弱性補修システム、Ｗｅｂ脆弱性補修方法、及びプログラム | |
| Weigert et al. | Practical experiences in using model-driven engineering to develop trustworthy computing systems | |
| US20150302191A1 (en) | Program execution apparatus and program analysis apparatus | |
| CN110958221B (zh) | 动态检测xml外部实体注入漏洞的方法及装置 | |
| CN113114680B (zh) | 用于文件上传漏洞的检测方法和检测装置 | |
| CN108959071B (zh) | 一种基于RASP的PHP变形webshell的检测方法及系统 | |
| Chen et al. | DroidCIA: A novel detection method of code injection attacks on HTML5-based mobile apps | |
| CN111884876A (zh) | 一种网络协议的协议类型检测方法、装置、设备及介质 | |
| CN109657475A (zh) | 代码漏洞排查方法、装置、设备及存储介质 | |
| CN111125714A (zh) | 一种安全检测方法、装置及电子设备 | |
| Mostafa et al. | Netdroid: Summarizing network behavior of android apps for network code maintenance | |
| CN115310087A (zh) | 一种基于抽象语法树的网站后门检测方法和系统 | |
| KR100924519B1 (ko) | 소프트웨어 보안 테스팅을 수행하기 위한 알려지지 않은파일 포맷 분석 시스템 및 방법 | |
| CN111338956A (zh) | 一种自动化的压测方法、装置、设备和存储介质 | |
| CN116415244A (zh) | 项目代码的测试方法和装置、存储介质及电子装置 |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| A621 | Written request for application examination |
Free format text: JAPANESE INTERMEDIATE CODE: A621 Effective date: 20080708 |
|
| TRDD | Decision of grant or rejection written | ||
| A01 | Written decision to grant a patent or to grant a registration (utility model) |
Free format text: JAPANESE INTERMEDIATE CODE: A01 Effective date: 20100907 |
|
| A01 | Written decision to grant a patent or to grant a registration (utility model) |
Free format text: JAPANESE INTERMEDIATE CODE: A01 |
|
| A61 | First payment of annual fees (during grant procedure) |
Free format text: JAPANESE INTERMEDIATE CODE: A61 Effective date: 20100907 |
|
| R150 | Certificate of patent or registration of utility model |
Free format text: JAPANESE INTERMEDIATE CODE: R150 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20130917 Year of fee payment: 3 |
|
| R250 | Receipt of annual fees |
Free format text: JAPANESE INTERMEDIATE CODE: R250 |
|
| LAPS | Cancellation because of no payment of annual fees |