JPWO2019026172A1 - セキュリティ診断装置およびセキュリティ診断方法 - Google Patents

Abstract

セキュリティ診断装置は、特権の第１のアカウントにより遷移先ＵＲＬに送信したＨＴＴＰリクエストに含まれるパラメータのうち、特権の第２のアカウントにより遷移先ＵＲＬに送信したＨＴＴＰリクエストに含まれるパラメータと値が同じである固定のパラメータを抽出する抽出部と、一般権のアカウントによる遷移先ＵＲＬへのＨＴＴＰリクエストのパラメータに抽出部で抽出された固定のパラメータが含まれており、値が特権のアカウントの値と異なる場合、固定のパラメータに特権のアカウントの値を設定したＨＴＴＰリクエストを出力するリクエスト生成部と、一般権のアカウントによりＨＴＴＰリクエストを遷移先ＵＲＬに送信し、ＨＴＴＰレスポンスを受信するリクエスト送受信部と、ＨＴＴＰレスポンスに基づいて遷移先ＵＲＬの脆弱性を判定する判定部と、を備えたので、遷移先ＵＲＬを事前に把握することなく権限管理の不備を診断できる。

Description

本発明は、権限管理の不備を診断するセキュリティ診断装置に関する。

インターネットに公開されているＷｅｂアプリケーションの脆弱性は日々発見されており、悪意のある攻撃者による攻撃は、警戒しなければならない脅威の一つである。Ｗｅｂアプリケーションの脆弱性の有無を確認する方法には、Ｗｅｂアプリケーション診断ツールやセキュリティ診断サービスがある。これらは、Ｗｅｂアプリケーションに対して疑似攻撃を実施することで、既知の脆弱性の有無を診断する。

Ｗｅｂアプリケーションの脆弱性の一つに、権限管理の不備がある。権限管理の不備とは、異なる権限を持つ２つのアカウントがあった場合、一方のアカウントでのみ遷移可能なページまたは有効な機能が、他方のアカウントでも遷移可能または実行可能なケースである。従来、診断の実施者が目視で遷移可能なページまたは有効な機能についてのアカウント間の差異を確認して、ツールに設定するまたは手動で疑似攻撃を実行することにより、権限管理の不備を診断することが行われている。しかしながら、人的コストが掛かかるため、人的コストを削減することが求められている。

特許文献１は、オブジェクトに対してアクセスを行った際の、権限要求ＡＰＩの呼出と実際のアクセスＡＰＩの呼出とをトレースすることで、想定されるアクセスＡＰＩを作成し、実際のアクセスＡＰＩの呼出と対応付けられているかを確認している。想定されるアクセスＡＰＩに対して実際のアクセスＡＰＩが対応付けられない場合、特許文献１は最小権限違反と判断している。

特開２０１０−１７６１６７号公報

しかしながら、特許文献１では、オブジェクトに対する権限の割当てが不明の場合には権限管理の不備があるかどうかを判断することができないという問題点があった。

本発明は上記のような問題点を解決するためになされたもので、Ｗｅｂアプリケーションの遷移先ＵＲＬを事前に把握することなく権限管理の不備があるかどうかを診断することができるセキュリティ診断装置を得ることを目的としている。

特権の第１のアカウントにより遷移先ＵＲＬに送信したＨＴＴＰリクエストに含まれるパラメータのうち、特権の第２のアカウントにより遷移先ＵＲＬに送信したＨＴＴＰリクエストに含まれるパラメータと値が同じである固定のパラメータを抽出する抽出部と、一般権のアカウントによる遷移先ＵＲＬへのＨＴＴＰリクエストのパラメータに抽出部で抽出された固定のパラメータが含まれており、値が特権のアカウントの値と異なる場合、固定のパラメータに特権のアカウントの値を設定したＨＴＴＰリクエストを出力するリクエスト生成部と、一般権のアカウントによりＨＴＴＰリクエストを遷移先ＵＲＬに送信し、ＨＴＴＰレスポンスを受信するリクエスト送受信部と、ＨＴＴＰレスポンスに基づいて遷移先ＵＲＬの脆弱性を判定する判定部と、を備えた。

本発明によれば、Ｗｅｂアプリケーションの遷移先ＵＲＬを事前に把握することなく権限管理の不備があるかどうかを診断することができるセキュリティ診断装置を得ることができる。

実施の形態１に係るセキュリティ診断装置のハードウェア構成の一例を示すブロック図。 実施の形態１に係る診断装置の機能構成の一例を示すブロック図。 実施の形態１に係るアカウント情報テーブルの一例を示す図。 実施の形態１に係るログインパラメータテーブルの一例を示す図。 実施の形態１に係る対象ＵＲＬテーブルの一例を示す図。 実施の形態１に係るＨＴＴＰリクエスト・レスポンステーブルの一例を示す図。 実施の形態１に係るパラメータテーブルの一例を示す図。 実施の形態１に係る固定パラメータテーブルの一例を示す図。 実施の形態１に係る診断結果テーブルの一例を示す図。 実施の形態１に係る結果詳細テーブルの一例を示す図。 実施の形態１に係る入力部、クローリング実施部および抽出部の処理の流れを示すフローチャート。 実施の形態１に係るＨＴＴＰリクエスト・レスポンステーブル４４１の一例を示す図。 実施の形態１に係るパラメータテーブル４５１の一例を示す図。 実施の形態１に係る比較部、リクエスト生成部、リクエスト送受信部、判定部及び出力部の処理の流れを示すフローチャート。 実施の形態１に係る図１４のステップＳ２０１の比較部の処理の詳細を示すフローチャート。 実施の形態２に係るＨＴＴＰリクエスト・レスポンステーブルの一例を示す図。 実施の形態２に係るパラメータテーブルの一例を示す図。 実施の形態２に係る固定パラメータテーブルの一例を示す図。 実施の形態２に係る固定パラメータテーブルの一例を示す図。 実施の形態２に係るＨＴＴＰリクエスト・レスポンステーブルの一例を示す図。 実施の形態２に係る図１４のステップＳ２０１の比較部の処理の詳細を示すフローチャート。 実施の形態２に係る診断結果テーブルの一例を示す図。 実施の形態２に係る結果詳細テーブルの一例を示す図。 実施の形態３に係る診断装置の機能構成の一例を含む全体のブロック図。 実施の形態３に係る入力部、クローリング実施部および抽出部の処理の流れを示すフローチャート。 実施の形態３に係る遷移データＤＢのパラメータテーブルの一例を示す図。 実施の形態３に係る比較部、リクエスト生成部、リクエスト送受信部、判定部及び出力部の処理の流れを示すフローチャート。 実施の形態４に係る診断対象抽出装置の機能構成の一例を含む全体のブロック図。 実施の形態４に係る診断実施装置の機能構成の一例を含む全体のブロック図。 実施の形態４に係る診断対象抽出装置の入力部、クローリング実施部および抽出部の処理の流れを示すフローチャート。 実施の形態４に係る診断実施装置の入力部、リクエスト生成部、リクエスト送受信部、判定部及び出力部の処理の流れを示すフローチャート。

以下この発明の実施の形態を、図を参照して説明する。なお、参照する図において同一もしくは相当する部分には同一の符号を付している。
実施の形態１．
はじめにハードウェア構成について説明する。
図１は、実施の形態１に係るセキュリティ診断装置（以下、診断装置と称す）２００のハードウェア構成の一例を示すブロック図である。
診断装置２００は、診断対象のＷｅｂアプリケーションとＨＴＴＰでの通信を行う通信インターフェース１０１、ＨＴＴＰリクエストとＨＴＴＰレスポンスに対する演算処理を行うプロセッサ１０２、演算結果などを保持するメモリ１０３、ユーザからの入力を受け付ける入力インターフェース１０４、データを記憶するための補助記憶装置１０５、および画面に結果を表示する出力インターフェース１０６を備える。

プロセッサ１０２は、メモリに記憶されたプログラムを実行するＣＰＵ、システムＬＳＩ（Ｌａｒｇｅ Ｓｃａｌｅ Ｉｎｔｅｇｒａｔｉｏｎ）等の処理回路により、実現される。プロセッサ１０２は、複数の処理回路が連携して構成されてもよい。メモリ１０３は、例えば、ＲＯＭ（Ｒｅａｄ Ｏｎｌｙ Ｍｅｍｏｒｙ）、ＲＡＭ（Ｒａｎｄｏｍ Ａｃｃｅｓｓ Ｍｅｍｏｒｙ）、ＳＳＤ（Ｓｏｌｉｄ Ｓｔａｔｅ Ｄｒｉｖｅ）で構成される。補助記憶装置１０５は、例えば、ＨＤＤ（Ｈａｒｄ Ｄｉｓｋ Ｄｒｉｖｅ）で構成される。

次に機能構成について説明する。
図２は、実施の形態１に係る診断装置２００の機能構成の一例を含む全体のブロック図である。
Ｗｅｂアプリケーション２０３は、診断装置２００からの指示に基づき、インターネット２０２を介してＷｅｂサーバ２０１にＨＴＴＰリクエストを送信する。Ｗｅｂアプリケーション２０３は、Ｗｅｂサーバ２０１からＨＴＴＰレスポンスを受信し、ＨＴＴＰレスポンスの内容を診断装置２００に出力する。診断装置２００は、Ｗｅｂサーバ２０１からＨＴＴＰレスポンスを受信する場合もある。

診断装置２００は、入力部３０１、クローリング実施部３０２、抽出部３０３、比較部３０４、リクエスト生成部３０５、リクエスト送受信部３０６、判定部３０７、出力部３０８、アカウント情報データベース（以下、アカウント情報ＤＢと称す）３０９、遷移データデータベース（以下、遷移データＤＢと称す）３１０、固定パラメータデータベース（以下、固定パラメータＤＢと称す）３１１および結果データデータベース（以下、結果データＤＢと称す）３１２を備える。

入力部３０１、クローリング実施部３０２、抽出部３０３、比較部３０４、リクエスト生成部３０５、リクエスト送受信部３０６、判定部３０７および出力部３０８の各機能を実現するためのプログラム及びデータは、メモリ１０３に記憶される。また、アカウント情報ＤＢ３０９、遷移データＤＢ３１０、固定パラメータＤＢ３１１および結果データＤＢ３１２はそれぞれ補助記憶装置１０５上に配置され、適宜メモリ１０３に展開される。

入力部３０１は、メモリ１０３に読み出され、プロセッサ１０２で実行される。入力部３０１は、入力インターフェース１０６を介して入力された値を補助記憶装置１０５へ保存する。入力部３０１は、入力された値を補助記憶装置１０５上のアカウント情報ＤＢ３０９と遷移データＤＢ３１０へ出力する。入力部３０１には、診断対象の対象ＵＲＬと、アカウント情報（ログイン情報、権限情報）が入力される。

アカウント情報ＤＢ３０９は、アカウント情報テーブル４１０およびログインパラメータテーブル４２０の２種類のテーブルを保持する。

図３は、実施の形態１に係るアカウント情報テーブルの一例を示す図である。
アカウント情報テーブル４１０は、Ｗｅｂアプリケーション２０３にログイン可能なアカウントのＩＤ、パスワード、アカウントに割り当てられた権限（アカウント権限）を保存するフィールドを持つテーブルである。アカウント権限は、特権と一般権の２種類がある。特権は、全ての操作が可能である管理者権限である。一般権は、一般ユーザが操作可能な範囲のみに操作範囲を制限した権限である。
アカウント情報テーブル４１０に保存するアカウントの数は各権限で２つ以上とする。同じ権限でアカウントの違いによるパラメータの差異をみるためである。

図４は、実施の形態１に係るログインパラメータテーブルの一例を示す図である。
ログインパラメータテーブル４２０は、ログイン時に必要なパラメータ名を保存するフィールドを持つテーブルである。

遷移データＤＢ３１０は、対象ＵＲＬテーブル４３０、ＨＴＴＰリクエスト・レスポンステーブル４４０およびパラメータテーブル４５０の３種類のテーブルを保持する。

図５は、実施の形態１に係る対象ＵＲＬテーブルの一例を示す図である。
対象ＵＲＬテーブル４３０は、入力部３０１で入力された対象ＵＲＬを保存するフィールドを持つテーブルである。

図６は、実施の形態１に係るＨＴＴＰリクエスト・レスポンステーブルの一例を示す図である。
ＨＴＴＰリクエスト・レスポンステーブル４４０は、ＨＴＴＰリクエストの送信先である遷移先ＵＲＬ、遷移先ＵＲＬへのＨＴＴＰリクエストに対するレスポンスコード、遷移先ＵＲＬへのＨＴＴＰリクエストに対するレスポンス内容、遷移先ＵＲＬへのＨＴＴＰリクエストの送信元である遷移元ＵＲＬ、および遷移先ＵＲＬへＨＴＴＰリクエストを送信したアカウントの権限を保存するフィールドを持つテーブルである。

図７は、実施の形態１に係るパラメータテーブル４５０の一例を示す図である。
パラメータテーブル４５０は、遷移先ＵＲＬ毎にＨＴＴＰリクエストのパラメータ名、パラメータの値、パラメータが記載されている位置を示す値（ＵＲＬのクエリ部、ヘッダ部またはボディ部）を保存するフィールドを持つテーブルである。パラメータが記載されている位置を示す値は、ＨＴＴＰリクエストのＵＲＬ内のクエリ文字列の名前の部分、ＨＴＴＰヘッダ部のヘッダ名、ＨＴＴＰボディ部の変数名である。また、パラメータの値は、パラメータに付与された値の部分である。

図２の診断装置２００の機能構成の説明に戻る。
クローリング実施部３０２は、メモリ１０３に読み出され、プロセッサ１０２で実行される。クローリング実施部３０２は、アカウント情報ＤＢ３０９と遷移データＤＢ３１０を補助記憶装置１０５から読み出す。クローリング実施部３０２は、遷移データＤＢ３１０に記憶された対象ＵＲＬに対して、アカウント情報ＤＢ３０９に記憶された各アカウントでログインを行い、ログインしたアカウントで遷移可能なＷｅｂページに対してクローリングを行う。クローリング実施部３０２の指示により、Ｗｅｂアプリケーション２０３はＨＴＴＰリクエストを生成し、インターネット２０２を介してＷｅｂサーバ２０１にＨＴＴＰリクエストを送信する。Ｗｅｂアプリケーション２０３からＨＴＴＰレスポンスを受信すると、ＨＴＴＰリクエストとそれに対するレスポンスをクローリング実施部３０２に出力する。クローリング実施部３０２は、クローリング時に発生するＨＴＴＰリクエストとそれに対するＨＴＴＰレスポンスを補助記憶装置１０５上の遷移データＤＢ３１０に保存する。

クローリングとは、クローラーと呼ばれるプログラムが、与えられたＵＲＬにある全てのハイパーリンクを辿り、遷移先のページ情報を収集してインデックス化を行う技術である。また、クローリングの実行時にローカルプロキシを介することで、ローカルプロキシから発生したＨＴＴＰリクエストとＨＴＴＰレスポンスの全ての情報を取得することが可能である。

抽出部３０３は、メモリ１０３に読み出され、プロセッサ１０２で実行される。抽出部３０３は遷移データＤＢ３１０を補助記憶装置１０５から読み出す。遷移データＤＢ３１０に記憶されたレコードのうち、遷移先ＵＲＬが同じであってアカウント権限が同じレコードについて、ＨＴＴＰリクエストのパラメータの差異を補助記憶装置１０５上の固定パラメータＤＢ３１１へ出力する。

固定パラメータＤＢ３１１は、固定パラメータテーブル４６０を保持する。
図８は、実施の形態１に係る固定パラメータテーブル４６０の一例を示す図である。固定パラメータテーブル４６０は、遷移先ＵＲＬ毎にＨＴＴＰリクエストのパラメータ名を保存するフィールドと、パラメータが固定か変動かを示すフィールドを持つテーブルである。

比較部３０４は、メモリ１０３に読み出され、プロセッサ１０２で実行される。比較部３０４は、遷移データＤＢ３１０を補助記憶装置１０５から読み出す。比較部３０４は、遷移データＤＢ３１０に記憶された遷移先ＵＲＬが同じレコードについてパラメータを比較し、異なる部分がある遷移先ＵＲＬを診断対象ＵＲＬとして結果データＤＢ３１２に出力する。

リクエスト生成部３０５は、メモリ１０３に読み出され、プロセッサ１０２で実行される。リクエスト生成部３０５は、結果データＤＢ３１２と遷移データＤＢ３１０を補助記憶装置１０５から読み出す。リクエスト送受信部３０６は、メモリ１０３に読み出され、プロセッサ１０２で実行される。

リクエスト生成部３０５は、診断対象ＵＲＬに対するＨＴＴＰリクエストの生成をリクエスト送受信部３０６に指示する。リクエスト送受信部３０６は、診断対象ＵＲＬに対するＨＴＴＰリクエストの生成をＷｅｂアプリケーション２０３に指示する。リクエスト送受信部３０６は、Ｗｅｂアプリケーション２０３が生成したＨＴＴＰリクエストをリクエスト生成部３０５に出力する。リクエスト生成部３０５は、診断対象ＵＲＬに対して一般権と特権と同じ操作が可能かを試行するため、Ｗｅｂアプリケーション２０３が生成したＨＴＴＰリクエストを試行用に書き換え、書き換えたＨＴＴＰリクエストをリクエスト送受信部３０６に出力する。リクエスト送受信部３０６は、インターネット２０２を介してリクエスト送受信部３０６から入力されたＨＴＴＰリクエストをＷｅｂサーバ２０１に送信する。リクエスト送受信部３０６は、インターネット２０２を介してＷｅｂサーバ２０１からＨＴＴＰリクエストに対するＨＴＴＰレスポンスを受信し、受信したＨＴＴＰレスポンスを判定部３０７に出力する。

判定部３０７は、メモリ１０３に読み出され、プロセッサ１０２で実行される。判定部３０７は、リクエスト送受信部３０６が受信したＨＴＴＰレスポンスと、遷移データＤＢ３１０を補助記憶装置１０５から読み出す。判定部３０７は、ＨＴＴＰレスポンスと遷移データＤＢ３１０に保存された特権でのＨＴＴＰリクエストに対するＨＴＴＰレスポンスから脆弱性の有無を判定して、判定した結果を結果データＤＢ３１２に出力する。

出力部３０８は、メモリ１０３に読み出され、プロセッサ１０２で実行される。出力部３０８は、補助記憶装置１０５に保存された結果データＤＢ３１２を補助記憶装置１０５から読み出す。出力部３０８は、結果データＤＢ３１２から読み出した判定結果を、出力インターフェース１０６に出力する。

結果データＤＢ３１２は、診断結果テーブル４７０および結果詳細テーブル４８０の２種類のテーブルを保持する。
図９は、実施の形態１に係る診断結果テーブル４７０の一例を示す図である。
図１０は、実施の形態１に係る結果詳細テーブル４８０の一例を示す図である。
診断結果テーブル４７０は、診断対象ＵＲＬ、判定部３０７の結果を保存するフィールドを持つテーブルである。結果詳細テーブル４８０は、脆弱性があると判定された診断対象ＵＲＬ、使用したパラメータ名を保存するフィールドを持つテーブルである。

次に動作について説明する。
図１１は、実施の形態１に係る入力部３０１、クローリング実施部３０２および抽出部３０３の処理の流れを示すフローチャートである。図１１のフローチャートにおいて、実線がフローの経路を示し、破線は各ＤＢに対するデータ書込みと呼出しを示す。
図１２は、実施の形態１に係るＨＴＴＰリクエスト・レスポンステーブル４４１の一例を示す図である。
図１３は、実施の形態１に係るパラメータテーブル４５１の一例を示す図である。
ステップＳ１０４の処理が終了すると図１２のＨＴＴＰリクエスト・レスポンステーブル４４１および図１３のパラメータテーブル４５１が得られる。

入力インターフェース１０６を介してアカウント情報および対象ＵＲＬが入力されると、入力部３０１は処理を開始する。
図１１のステップＳ１０１において、入力部３０１は、入力されたアカウント情報をアカウント情報ＤＢ３０９のアカウント情報テーブル４１０とログインパラメータ４２０に保存する。アカウント情報には、Ｗｅｂアプリケーション２０３にログインする際に必要なアカウントＩＤおよびパスワードといったログイン情報とそのアカウントのアカウント権限とログインするために必要なパラメータのパラメータ名とが含まれる。

入力部３０１は、アカウントＩＤ、パスワードおよびアカウント権限を、アカウント情報テーブル４１０のアカウントＩＤ、パスワード、権限の項目に保存する。図３において、例えば、項番Ｕ０１としてアカウントＩＤ「ｍｎｇ１」、パスワード「１２３４ａｂｃ」および権限「特権」が保存されている。

入力部３０１は、パラメータ名をログインパラメータテーブル４２０に保存する。図４において、項番ＩＤとしてパラメータ「ａｃｃｏｕｎｔｉｄ」、項番ＰＷＤとしてパラメータ「ｐａｓｓｗｄ」が保存されている。

また、入力部３０１は、入力された対象ＵＲＬを遷移データＤＢ３１０の対象ＵＲＬテーブル４３０に保存する。図５において、対象ＵＲＬテーブル４３０には、対象ＵＲＬ「http://xxx.com」が保存されている。処理はステップＳ１０２に進む。

ステップＳ１０２において、クローリング実施部３０２は、アカウント情報ＤＢ３０９に保存されたアカウント情報テーブル４１０から、クローリングが実施されていないアカウントのレコードを１つ選択し、アカウントＩＤおよびパスワードを読み出す。処理はステップＳ１０３に進む。

ステップＳ１０３において、クローリング実施部３０２は、遷移データＤＢ３１０の対象ＵＲＬテーブル４３０から対象ＵＲＬ「http://xxx.com」を読み出す。クローリング実施部３０２は、選択したアカウントのアカウントＩＤおよびパスワードでＷｅｂアプリケーション２０３にログインし、対象ＵＲＬに対してクローリングを実施する。

クローリング実施部３０２がアカウント情報テーブル４１０の項番Ｕ０１のアカウントでＷｅｂアプリケーション２０３にログインする場合を例に処理を説明する。クローリング実施部３０２は、対象ＵＲＬ「http://xxx.com」にＨＴＴＰリクエストを送信し、さらに「http://xxx.com」上のリンクである「http://xxx.com/login.php」にＨＴＴＰリクエストを送信する。「http://xxx.com/login.php」へのＨＴＴＰリクエストに対するＨＴＴＰレスポンスを受信すると、クローリング実施部３０２は、遷移データＤＢ３１０のＨＴＴＰリクエスト・レスポンステーブル４４１の項番ＵＲＬ０１にＨＴＴＰレスポンスの内容を保存する。クローリング実施部３０２は、遷移先ＵＲＬに「http://xxx.com/login.php」、レスポンスコードに「200」、レスポンス内容にレスポンスのHeader情報およびBody情報、遷移元ＵＲＬに「http://xxx.com」、権限に「特権」を保存する。権限には、ログインしたアカウントの権限の種類が保存される。また、遷移先ＵＲＬ「http://xxx.com/login.php」に送信したＨＴＴＰリクエストにパラメータが含まれている場合、クローリング実施部３０２は、遷移データＤＢ３１０のパラメータテーブル４５１に保存する。図１３のパラメータテーブル４５１には示していないが、パラメータが保存されたものとする。

次に、クローリング実施部３０２は、「http://xxx.com/login.php」上のリンクである「http://xxx.com/top.php」にＨＴＴＰリクエストを送信する。ＨＴＴＰレスポンスを受信すると、クローリング実施部３０２は、ＨＴＴＰリクエスト・レスポンステーブル４４１の項番ＵＲＬ０２にＨＴＴＰレスポンスの内容を保存する。クローリング実施部３０２は、遷移先ＵＲＬに「http://xxx.com/top.php」、レスポンスコードに「200」、レスポンス内容にレスポンスのHeader情報およびBody情報、遷移元ＵＲＬに「http://xxx.com/login.php」、権限に「特権」を保存する。遷移先ＵＲＬ「http://xxx.com/top.php」に送信したＨＴＴＰリクエストにパラメータａｕｔｈ、ｕｓｅｒＩＤが含まれている。クローリング実施部３０２は、パラメータ名、パラメータの値、パラメータが記載されている位置を示す値（ＵＲＬのクエリ部、ヘッダ部またはボディ部）をパラメータテーブル４５１の項番ＵＲＬ０２−０１、ＵＲＬ０２−０２に保存する。なお、項番ＵＲＬ０２−０１、ＵＲＬ０２−０２はＵＲＬ０２のパラメータであることを示している。パラメータをパラメータテーブル４５１に保存する際、クローリング実施部３０２は、どのＨＴＴＰリクエストに含まれたパラメータなのか対応付けがわかるように項番を付与している。本実施の形態では、項番で対応づけを示しているが、他の方法でもよい。

クローリング実施部３０２は、対象ＵＲＬ「http://xxx.com」とその配下にある全てのリンクを辿り、上述したように遷移先のページ情報を収集して、収集した情報をＨＴＴＰリクエスト・レスポンステーブル４４１およびパラメータテーブル４５１に保存する。遷移先のページでも遷移していないリンク先がなくなるまでページ情報を収集すると、クローリング実施部３０２は、クローリングを終了し、ログアウトする。処理はステップＳ１０４に進む。

ステップＳ１０４において、クローリング実施部３０２は、クローリングが未実施のアカウントがないか判定する。クローリング実施部３０２は、アカウント情報テーブル４１０の各アカウントについてクローリングを実施したかどうかを把握している。クローリングが未実施のアカウントがある場合、処理はステップＳ１０２に進み、クローリング実施部３０２は、クローリングが未実施のアカウントを選択してクローリングを実施する。

クローリング実施部３０２は、クローリングが未実施のアカウントがなくなるまでステップＳ１０２〜Ｓ１０４のフローを繰り返す。

図１２において、アカウントＩＤ「ｍｎｇ１」のクローリングで項番ＵＲＬ０１〜ＵＲＬ０２、アカウントＩＤ「ｍｎｇ２」のクローリングで項番ＵＲＬ０３〜ＵＲＬ０４のレコードが保存されたものとする。アカウントＩＤ「ｕｓｅｒ１」のクローリングで項番ＵＲＬ０５〜ＵＲＬ０６、アカウントＩＤ「ｕｓｅｒ２」のクローリングで項番ＵＲＬ０７〜ＵＲＬ０８のレコードが保存されたものとする。遷移先ＵＲＬと権限が同じレコードは、権限が同じであって異なるアカウントで実施したクローリングで得られた情報である。

図１３において、アカウントＩＤ「ｍｎｇ１」のクローリングで項番ＵＲＬ０２−０１〜ＵＲＬ０２−０２、アカウントＩＤ「ｍｎｇ２」のクローリングで項番ＵＲＬ０４−０１〜ＵＲＬ０４−０２のレコードが保存されたものとする。アカウントＩＤ「ｕｓｅｒ１」のクローリングで項番ＵＲＬ０６−０１〜ＵＲＬ０６−０２、アカウントＩＤ「ｕｓｅｒ２」のクローリングで項番ＵＲＬ０８−０１〜ＵＲＬ０８−０２のレコードが保存されたものとする。

図１１のフローチャートの説明に戻る。
ステップＳ１０４において、クローリングが未実施のアカウントがなければ処理はステップＳ１０５に進む。

ステップＳ１０５において、抽出部３０３は、同じ遷移先に対して権限が特権で同じレコードについてＨＴＴＰリクエストのパラメータの値の差異を抽出する処理を行う。
抽出部３０３は、ＨＴＴＰリクエスト・レスポンステーブル４４１から、権限が特権であって遷移先ＵＲＬが同じレコードを選択する。項番ＵＲＬ０２と項番ＵＲＬ０４を選択した場合を例に説明する。項番ＵＲＬ０２、ＵＲＬ０４に関するパラメータはパラメータテーブル４５１のＵＲＬ０２−０１〜ＵＲＬ０２−０２、ＵＲＬ０４−０１〜ＵＲＬ０４−０２に保存されている。抽出部３０３は、これらのパラメータの差異を抽出する。

ＵＲＬ０２−０１とＵＲＬ０４−０１は値が同じため、抽出部３０３は、固定パラメータテーブル４６０の項番ＰＡＲＡＭ０２−０１の対象に「ＵＲＬ０４−０１」、固定に「固定」を保存する。ＵＲＬ０２−０２とＵＲＬ０４−０２は値が異なるため、抽出部３０３は、固定パラメータテーブル４６０の項番ＰＡＲＡＭ０２−０２の対象に「ＵＲＬ０４−０２」、固定に「変動」を保存する。処理は終了する。

ＨＴＴＰリクエストのパラメータは、セッションＩＤや時刻などのログインするたびに毎回異なるパラメータの値、宛先ＵＲＬやｃｏｎｔｅｎｔ−ｔｙｐｅ等のヘッダ情報などのログインするたびに変わることがない固定のパラメータの値、ユーザＩＤなどのログインするたびに変わることがないがアカウントによって異なるパラメータの値、の３つに分別される。本実施の形態では、抽出部３０３は、ＨＴＴＰリクエストのパラメータから、ログインするたびに変わることがない固定のパラメータを抽出することが可能である。

図１４は、実施の形態１に係る比較部３０４、リクエスト生成部３０５、リクエスト送受信部３０６、判定部３０７及び出力部３０８の処理の流れを示すフローチャートである。実線がフローの経路を示し、破線は各ＤＢに対するデータの書込みと呼出しを示す。診断対象ＵＲＬに対して一般権と特権とで同じ操作が可能かを試行するため、一般権のアカウントでログインし、ＨＴＴＰリクエストを診断対象ＵＲＬに送信する。

ステップＳ２０１において、比較部３０４は、遷移データＤＢ３１０のＨＴＴＰリクエスト・レスポンステーブル４４１からレコードを選択し、他のレコードと比較する。図１５を用いてステップＳ２０１の詳細を説明する。

図１５は、実施の形態１に係る図１４のステップＳ２０１の比較部３０４の処理の詳細を示すフローチャートである。

ステップＳ３０１において、比較部３０４は、ＨＴＴＰリクエスト・レスポンステーブル４４１から１つレコードを選択し、遷移先ＵＲＬが同じレコードが他にあるか判定する。遷移先ＵＲＬが同じレコードが他になければ、処理はステップＳ３０２に進み、遷移先ＵＲＬが同じレコードが他にあれば、処理はステップＳ３０４に進む。

ステップＳ３０２において、比較部３０４は、選択したレコードの権限が特権か判定する。選択したレコードの権限が特権の場合、処理はステップＳ３０３に進む。選択したレコードの権限が特権でない場合、比較部３０４は、選択したレコードの遷移先ＵＲＬを診断対象から除外し、処理は終了する。

ステップＳ３０３において、比較部３０４は、選択したレコードの遷移先ＵＲＬを図９の結果データＤＢ３１２の診断結果テーブル４７０に保存し、処理は終了する。

ステップＳ３０４において、比較部３０４は、パラメータテーブル４５１を参照し、遷移先ＵＲＬが同じレコードについてパラメータ名が存在するのは特権のレコードのみか判定する。パラメータ名が存在するのは特権のレコードのみの場合、処理はステップＳ３０５に進む。パラメータ名が存在するのは特権のレコードのみでない場合、処理はステップＳ３０６に進む。

ステップＳ３０５において、比較部３０４は、選択したレコードの遷移先ＵＲＬとパラメータ名を結果データＤＢ３１２の診断結果テーブル４７０に保存し、処理は終了する。

ステップＳ３０６において、比較部３０４は、パラメータテーブル４５１を参照し、遷移先ＵＲＬが同じレコードについて特権と一般権で同じパラメータ名が存在するのか判定する。特権と一般権で同じパラメータ名が存在する場合、処理はステップＳ３０７に進む。特権と一般権で同じパラメータ名が存在しない場合、比較部３０４は、選択したレコードの遷移先ＵＲＬを診断対象から除外し、処理は終了する。

ステップＳ３０７において、比較部３０４は、パラメータテーブル４５１を参照し、特権と一般権で同じパラメータ名が存在し、値が同じか判定する。値が同じでない場合、処理はステップＳ３０８に進む。値が同じ場合、比較部３０４は、選択したレコードの遷移先ＵＲＬを診断対象から除外し、処理は終了する。

ステップＳ３０８において、比較部３０４は、固定パラメータテーブル４６０を参照し、パラメータが固定か判定する。パラメータが固定の場合、処理はステップＳ３０５に進む。パラメータが固定でない場合、比較部３０４は、選択したレコードの遷移先ＵＲＬを診断対象から除外し、処理は終了する。

図１４のフローチャートの説明に戻る。ステップＳ２０２において、リクエスト生成部３０５は、アカウント情報ＤＢ３０９に保存されている情報を用いて、一般権のアカウントでＷｅｂアプリケーション２０３にログインする。項番Ｕ０３のアカウント「ｕｓｅｒ１」でログインしたものとする。処理はステップＳ２０３に進む。

ステップＳ２０３において、リクエスト生成部３０５は、診断結果テーブル４７０から診断対象ＵＲＬを選択し、選択した診断対象ＵＲＬと合致する遷移先ＵＲＬが保存されているレコードをＨＴＴＰリクエスト・レスポンステーブル４４１から読み出す。読み出したレコードのアクセス権が特権のみの場合、遷移先ＵＲＬが特権の場合にのみ存在することを意味する。処理はステップＳ２０４に進む。一方、読み出したレコードのアクセス権が特権のレコードと一般権のレコードの両方がある場合、一般権でも診断対象ＵＲＬが存在することを意味する。処理はステップＳ２０５に進む。

ステップＳ２０４において、リクエスト生成部３０５は、リクエスト送受信部３０６を介して診断対象ＵＲＬをＷｅｂアプリケーション２０３に出力する。リクエスト生成部３０５は、リクエスト送受信部３０６を介してＷｅｂアプリケーション２０３から診断対象ＵＲＬへの一般権のＨＴＴＰリクエストを受け取る。リクエスト生成部３０５は、ＨＴＴＰリクエスト・レスポンステーブル４４１から読み出したレコードをもとにＨＴＴＰリクエストを生成する。読み出したレコードは特権のレコードである。リクエスト生成部３０５は、ＨＴＴＰリクエスト・レスポンステーブル４４１から読み出したレコードに対応付けられたパラメータテーブル４５１のレコードよりＨＴＴＰリクエストに設定されるパラメータを読み出す。読み出したパラメータは、特権の場合にＨＴＴＰリクエストに設定されるパラメータである。リクエスト生成部３０５は、固定パラメータＤＢ３１１の固定パラメータテーブル４６０を参照し、読み出したパラメータが固定の場合、ＨＴＴＰリクエストのパラメータの値を変更しない。読み出したパラメータが変動の場合、ＨＴＴＰリクエストのパラメータの値をＷｅｂアプリケーション２０３から受け取った一般権のＨＴＴＰリクエストのパラメータの値に変更する。また、リクエスト生成部３０５は、結果データＤＢ３１２の結果詳細テーブル４８０に診断対象ＵＲＬ、値を変更したパラメータ名を保存する。リクエスト生成部３０５は、このようにして生成したＨＴＴＰリクエストをリクエスト送受信部３０６に出力する。リクエスト送受信部３０６は、リクエスト生成部３０５から入力されたＨＴＴＰリクエストをＷｅｂサーバ２０１に送信し、Ｗｅｂサーバ２０１からＨＴＴＰレスポンスを受信すると判定部３０７に出力する。処理はステップＳ２０６に進む。

ステップＳ２０５において、リクエスト生成部３０５は、リクエスト送受信部３０６を介して診断対象ＵＲＬをＷｅｂアプリケーション２０３に出力し、リクエスト送受信部３０６を介してＷｅｂアプリケーション２０３から診断対象ＵＲＬへの一般権のＨＴＴＰリクエストを受け取る。リクエスト生成部３０５は、ステップＳ２０３においてＨＴＴＰリクエスト・レスポンステーブル４４１から読み出したレコードに対応付けられたパラメータテーブル４５１のレコードより特権の場合にＨＴＴＰリクエストに設定されるパラメータを読み出す。リクエスト生成部３０５は、固定パラメータＤＢ３１１の固定パラメータテーブル４６０を参照し、一般権のＨＴＴＰリクエストに含まれるパラメータに該当するレコードがあって固定の場合、ＨＴＴＰリクエストの該当のパラメータの値を特権のパラメータの値に変更する。また、リクエスト生成部３０５は、結果データＤＢ３１２の結果詳細テーブル４８０に診断対象ＵＲＬ、値を変更したパラメータ名を保存する。一般権のＨＴＴＰリクエストに含まれるパラメータに該当するレコードがあって変動の場合、リクエスト生成部３０５は、ＨＴＴＰリクエストの該当のパラメータの値を変更しない。固定のパラメータは、例えば権限識別のパラメータである。変動のパラメータは、例えば、ユーザＩＤ、時刻である。また、リクエスト生成部３０５は、読み出した特権のパラメータのうち一般権のＨＴＴＰリクエストに含まれていないパラメータをＨＴＴＰリクエストに追加する。リクエスト生成部３０５は、このようにして生成したＨＴＴＰリクエストをリクエスト送受信部３０６に出力する。リクエスト送受信部３０６は、リクエスト生成部３０５から入力されたＨＴＴＰリクエストをＷｅｂサーバ２０１に送信する。リクエスト送受信部３０６は、Ｗｅｂサーバ２０１からＨＴＴＰレスポンスを受信すると受信したＨＴＴＰレスポンスを判定部３０７に出力する。処理はステップＳ２０６に進む。

ステップＳ２０６において、判定部３０７は、入力されたＨＴＴＰレスポンスのレスポンスコードとＨＴＴＰリクエスト・レスポンステーブル４４１に保存されている正常なレスポンスのレスポンスコードを比較する。判定部３０７は、レスポンスコードの値を比較することで脆弱性を判定する。レスポンスコードが同じ場合、特権の操作が一般権でも実行できているため、判定部３０７は、脆弱ありと判定する。レスポンスコードが異なる場合、判定部３０７は、脆弱なしと判定する。判定部３０７は、判定した脆弱性の有無を診断結果テーブル４７０の診断対象ＵＲＬに該当するレコードの脆弱性に保存する。処理はステップＳ２０７に進む。

ステップＳ２０７において、判定部３０７は、診断結果テーブル４７０のすべてのレコードについて脆弱性の判定処理を完了したか判定する。判定部３０７は、診断結果テーブル４７０のすべてのレコードについて脆弱性の項目が設定されていれば、完了と判定する。完了した場合、処理はステップＳ２０８に進む。完了していない場合、処理はステップＳ２０２に戻る。診断結果テーブル４７０のすべてのレコードについて脆弱性の項目が設定されるまで、ステップＳ２０２〜Ｓ２０７の処理が繰り返される。

ステップＳ２０８において、出力部３０８は、結果データＤＢ３１２のデータを出力インターフェース１０４へ出力し、処理は終了となる。

なお、本実施の形態において、受信したＨＴＴＰレスポンスとＨＴＴＰリクエスト・レスポンステーブル４４１に保存されている正常なＨＴＴＰレスポンスのレスポンスコードが同じ場合、脆弱ありと判定したが、ＨＴＴＰレスポンスのＨｅａｄｅｒ情報またはＢｏｄｙ情報に含まれる値を用いて脆弱性を判定するようにしてもよい。

したがって、本実施の形態では、特権の第１のアカウントにより遷移先ＵＲＬに送信したＨＴＴＰリクエストに含まれるパラメータのうち、特権の第２のアカウントにより遷移先ＵＲＬに送信したＨＴＴＰリクエストに含まれるパラメータと値が同じである固定のパラメータを抽出する抽出部３０３と、一般権のアカウントによる遷移先ＵＲＬへのＨＴＴＰリクエストのパラメータに抽出部３０３で抽出された固定のパラメータが含まれており、値が特権のアカウントの値と異なる場合、固定のパラメータに特権のアカウントの値を設定したＨＴＴＰリクエストを出力するリクエスト生成部３０５と、一般権のアカウントによりＨＴＴＰリクエストを遷移先ＵＲＬに送信し、ＨＴＴＰレスポンスを受信するリクエスト送受信部３０６と、ＨＴＴＰレスポンスに基づいて遷移先ＵＲＬの脆弱性を判定する判定部３０７と、を備えたので、Ｗｅｂアプリケーションの遷移先ＵＲＬを事前に把握することなく権限管理の不備があるかどうかを診断することができる。一般権の画面上には表示されないページへの遷移や実行できない操作を実行できるかを確認することで、権限管理の不備がないかを診断する。診断装置２００が権限管理の不備を診断するため、人的コストを削減することもできる。

また、リクエスト生成部３０５は、一般権のアカウントによる遷移先ＵＲＬへのＨＴＴＰリクエストのパラメータに抽出部３０３で抽出された固定のパラメータが含まれていない場合、特権のアカウントの値を設定した固定のパラメータをＨＴＴＰリクエストに追加し、固定のパラメータが追加されたＨＴＴＰリクエストを出力するので、一般権のＨＴＴＰリクエストには含まれないパラメータについて権限管理の不備がないかを診断することができる。
また、抽出部３０３は、第１のアカウントにより遷移先ＵＲＬに送信したＨＴＴＰリクエストに含まれるパラメータのうち、第２のアカウントにより遷移先ＵＲＬに送信したＨＴＴＰリクエストに含まれるパラメータと値が異なる変動のパラメータを抽出し、リクエスト生成部３０５は、一般権のアカウントにより遷移先ＵＲＬに遷移しない場合、特権のアカウントによる遷移先ＵＲＬへのＨＴＴＰリクエストのうち抽出部３０３で抽出された変動のパラメータに一般権のアカウントによる遷移先ＵＲＬへのＨＴＴＰリクエストのパラメータの値を設定し、値を設定したＨＴＴＰリクエストを出力するので、一般権のアカウントでは遷移しない遷移先ＵＲＬについて、権限管理の不備がないかを診断することができる。

実施の形態２．
以上の実施の形態１においては、抽出部３０３がログインするたびに変わることがない固定のパラメータを抽出するようにしたものであるが、本実施の形態においては、遷移先ＵＲＬとパラメータの組み合わせが同じでログインするたびに値が変わるパラメータと変わらないパラメータを抽出する実施の形態を示す。
なお、本実施の形態においては、実施の形態１に記載の構成を全て備えた上で、更に付加的な構成について説明する。

図１６は、実施の形態２に係るＨＴＴＰリクエスト・レスポンステーブル４４２の一例を示す図である。
図１７は、実施の形態２に係るパラメータテーブル４５２の一例を示す図である。
まず、図１１のフローチャートについて、実施の形態１と異なる動作を説明する。

図１１のステップＳ１０３において、クローリング実施部３０２は、選択したアカウントでクローリングを実施し、ログアウトした後、同じアカウントでＷｅｂアプリケーション２０３に再度ログインし、対象ＵＲＬに対して２回目のクローリングを実施する。クローリング実施部３０２は、２回目のクローリングが終了すると、ログアウトする。

図１６は、アカウントＩＤ「ｍｎｇ１」の１回目のクローリングで項番ＵＲＬ０１〜ＵＲＬ０４、アカウントＩＤ「ｕｓｅｒ１」の１回目のクローリングで項番ＵＲＬ０５〜ＵＲＬ０７のレコードが保存されたものとする。

図１７は、アカウントＩＤ「ｍｎｇ１」の１回目のクローリングで項番ＵＲＬ０３−０１〜ＵＲＬ０３−０３、ＵＲＬ０４−０１〜ＵＲＬ０４−０３のレコードが保存されたものとする。アカウントＩＤ「ｕｓｅｒ１」の１回目のクローリングで項番ＵＲＬ０７−０１〜ＵＲＬ０７−０３のレコードが保存されたものとする。

２回目のクローリングにおいて、１回目のクローリングで得られた図１６のＨＴＴＰリクエスト・レスポンステーブル４４２および図１７のパラメータテーブル４５２と同じ値が保存されたＨＴＴＰリクエスト・レスポンステーブル４４３、パラメータテーブル４５３が得られる。なお、内容が同じため図示は省略する。

図１１のステップＳ１０５において、抽出部３０３は、１回目のクローリングで得られたＨＴＴＰリクエスト・レスポンステーブル４４２、パラメータテーブル４５２、２回目のクローリングで得られたＨＴＴＰリクエスト・レスポンステーブル４４３、パラメータテーブル４５３を参照し、ＨＴＴＰリクエスト・レスポンステーブル４４２の特権の各項番について、１回目のクローリングと２回目のクローリングでのパラメータの差異を抽出する。

図１８は、実施の形態２に係る固定パラメータテーブル４６２の一例を示す図である。１回目のクローリングと２回目のクローリングで同じ値が得られているため、固定パラメータテーブル４６１のすべてのパラメータは固定である。

次に、抽出部３０３は、ＨＴＴＰリクエスト・レスポンステーブル４４２のレコードのうち権限が特権のレコードを選択する。抽出部３０３は、ＨＴＴＰリクエスト・レスポンステーブル４４２から権限が特権であって、選択したレコードの遷移先ＵＲＬと同じレコードについて、パラメータの差異を抽出する。抽出部３０３は、抽出したパラメータの差異を固定パラメータテーブル４６２に保存する。

図１９は、実施の形態２に係る固定パラメータテーブル４６２の一例を示す図である。項番のＵＲＬ０３とＵＲＬ０４を比較するとＵＲＬおよびｕｓｅｒＩＤは値が同じため、固定パラメータテーブル４６２のＰＡＲＡＭ０３−０１およびＰＡＲＡＭ０３−０２の固定フィールドには「固定」が保存されている。一方、ｐａｇｅは値が異なるため、固定パラメータテーブル４６２のＰＡＲＡＭ０３−０３の固定フィールドには「変動」が保存されている。

図２０は、実施の形態２に係るＨＴＴＰリクエスト・レスポンステーブル４４４の一例を示す図である。
抽出部３０３は、固定パラメータテーブル４６２において固定フィールドに「変動」が保存されているパラメータｐａｇｅが、ページを一意に表すのに必要なパラメータであると判定する。抽出部３０３は、ＨＴＴＰリクエスト・レスポンステーブル４４２に遷移パラメータのフィールドを追加し、ｐａｇｅの値を設定したＨＴＴＰリクエスト・レスポンステーブル４４４を生成する。

次に、図１４のフローチャートについて、実施の形態１と異なる動作を説明する。

ステップＳ２０１において、比較部３０４は、遷移データＤＢ３１０のＨＴＴＰリクエスト・レスポンステーブル４４４からレコードを選択し、他のレコードと比較する。図２１を用いてステップＳ２０１の処理の詳細を説明する。

図２１は、実施の形態２に係る図１４のステップＳ２０１の比較部３０４の処理の詳細を示すフローチャートである。
図２２は、実施の形態２に係る診断結果テーブル４７１の一例を示す図である。
図２３は、実施の形態２に係る結果詳細テーブル４８１の一例を示す図である。

図２１のステップＳ４０１において、比較部３０４は、ＨＴＴＰリクエスト・レスポンステーブル４４４から１つレコードを選択し、遷移先ＵＲＬおよび遷移パラメータが同じレコードが他にあるか判定する。遷移先ＵＲＬおよび遷移パラメータが同じレコードが他になければ、処理はステップＳ４０２に進み、遷移先ＵＲＬおよび遷移パラメータが同じレコードが他にあれば、処理はステップＳ４０４に進む。

ステップＳ４０２において、比較部３０４は、選択したレコードの権限が特権か判定する。選択したレコードの権限が特権の場合、処理はステップＳ４０３に進む。選択したレコードの権限が特権でない場合、比較部３０４は、選択したレコードの遷移先ＵＲＬを診断対象から除外し、処理は終了する。

ステップＳ４０３において、比較部３０４は、選択したレコードの遷移先ＵＲＬおよび遷移パラメータを結果データＤＢ３１２の診断結果テーブル４７１に保存し、処理は終了する。

ステップＳ４０４において、比較部３０４は、パラメータテーブル４５２を参照し、遷移先ＵＲＬおよび遷移パラメータが同じレコードについてパラメータ名が存在するのは特権のレコードのみか判定する。パラメータ名が存在するのは特権のレコードのみの場合、処理はステップＳ４０５に進む。パラメータ名が存在するのは特権のレコードのみでない場合、処理はステップＳ４０６に進む。

ステップＳ４０５において、比較部３０４は、選択したレコードの遷移先ＵＲＬ、遷移パラメータおよびパラメータ名を結果データＤＢ３１２の結果詳細テーブル４８１に保存し、処理は終了する。

ステップＳ４０６において、比較部３０４は、パラメータテーブル４５２を参照し、遷移先ＵＲＬおよび遷移パラメータが同じレコードについて特権と一般権で同じパラメータ名が存在するのか判定する。特権と一般権で同じパラメータ名が存在する場合、処理はステップＳ４０７に進む。特権と一般権で同じパラメータ名が存在しない場合、比較部３０４は、選択したレコードの遷移先ＵＲＬおよび遷移パラメータを診断対象から除外し、処理は終了する。

ステップＳ４０７において、比較部３０４は、パラメータテーブル４４４を参照し、特権と一般権で同じパラメータ名が存在し、値が同じか判定する。値が同じでない場合、処理はステップＳ３０５に進む。値が同じ場合、比較部３０４は、選択したレコードの遷移先ＵＲＬおよび遷移パラメータを診断対象から除外し、処理は終了する。

なお、本実施の形態において、クローリング実施部３０２は、１回目と２回目のクローリングで得られた情報を識別せずにＨＴＴＰリクエスト・レスポンステーブル４４２およびパラメータテーブル４５２に保存したが、１回目と２回目のクローリングで得られた情報を識別できるように保存してもよい。テーブルを増やす、または、テーブルのカラムを増やすようにしてもよい。

以上のように、本実施の形態では、抽出部３０３は、第１のアカウントにより遷移先ＵＲＬに送信したＨＴＴＰリクエストに含まれるパラメータのうち、第２のアカウントにより遷移先ＵＲＬに送信したＨＴＴＰリクエストに含まれるパラメータと値が同じである固定のパラメータについて、第１のアカウントから遷移先ＵＲＬに複数回送信したＨＴＴＰリクエストに含まれる固定のパラメータ値が異なる場合、固定のパラメータを遷移先ＵＲＬとの組み合わせでページを一意に示す遷移パラメータとして抽出するので、ＵＲＬと遷移パラメータとの組み合わせでページを一意に示す場合でも権限管理の不備を診断することができる。

実施の形態３．
以上の実施の形態１においては、抽出部３０３が抽出したＨＴＴＰリクエストのパラメータが固定か変動かを固定パラメータＤＢ３１１の固定パラメータテーブル４６０に保存するようにしたものであるが、本実施の形態においては、遷移データＤＢ３１０のＨＴＴＰリクエスト・レスポンステーブルにフィールドを追加して保存する実施の形態を示す。

図２４は、実施の形態３に係る診断装置２１０の機能構成の一例を含む全体のブロック図である。実施の形態１の診断装置２００との違いは、固有データＤＢが削除されていることである。

図２５は、実施の形態３に係る入力部３０１、クローリング実施部３０２および抽出部３０３の処理の流れを示すフローチャートである。実施の形態１の図１１のフローチャートとの違いは、ステップＳ１０５から遷移データＤＢ３１０に出力することである。
図２６は、実施の形態３に係る遷移データＤＢ３１０のパラメータテーブル４５４の一例を示す図である。実施の形態１のパラメータテーブル４５１との違いは固定のフィールドが追加されていることである。

図２５のステップ１０５において、実施の形態１と異なる動作を説明する。
抽出部３０３は、同じ遷移先に対して権限が特権で同じレコードについてＨＴＴＰリクエストのパラメータの値の差異を抽出する。ＵＲＬ０２−０１とＵＲＬ０４−０１は値が同じため、抽出部３０３は、固定パラメータテーブル４６０の項番ＵＲＬ０２−０１と項番ＵＲＬ０４−０１の固定に「固定」を保存する。また、ＵＲＬ０２−０２とＵＲＬ０４−０２は値が異なるため、抽出部３０３は、固定パラメータテーブル４６０の項番ＰＡＲＡＭ０２−０２と項番ＵＲＬ０４−０２の固定に「変動」を保存する。処理は終了する。

図２７は、実施の形態３に係る比較部３０４、リクエスト生成部３０５、リクエスト送受信部３０６、判定部３０７及び出力部３０８の処理の流れを示すフローチャートである。実施の形態１の図１４のフローチャートとの違いは、ステップＳ２０１、ステップＳ２０４、ステップＳ２０５においてパラメータが固有かどうかの情報を遷移パラメータＤＢのパラメータテーブル４５４から読み出すことである。

なお、本実施の形態において、実施の形態２で示したようにアカウントごとに２回クローリングを実施してページ遷移に必要な特定のパラメータを決定する機能を含めるようにしてもよい。

したがって、本実施の形態では、遷移データＤＢ３１０が固有パラメータＤＢ３１１の情報も保持するため、遷移データＤＢ３１０のパラメータテーブルＴ２０３のレコードと同じ数のレコードを持つ固有パラメータＤＢ３１１を削減し、固有パラメータＤＢ３１１で使用するメモリリソースを削減することが可能である。

実施の形態４．
以上の実施の形態１においては、診断装置２００が診断対象ＵＲＬを抽出し、脆弱性の判定を行うようにしたものであるが、本実施の形態においては、診断対象抽出装置が診断対象ＵＲＬを抽出し、診断実施装置が抽出された診断対象ＵＲＬの脆弱性を判定する実施の形態を示す。

実施の形態３と異なる部分を説明する。
図２８は、実施の形態４に係る診断対象抽出装置２２０の機能構成の一例を含む全体のブロック図である。診断対象抽出装置２２０は、入力部３０１、クローリング実施部３０２、抽出部３０３、比較部３０４、アカウント情報ＤＢ３１３、遷移データＤＢ３１４および出力部３１５を備える。アカウント情報ＤＢ３１３、遷移データＤＢ３１４は実施の形態３のアカウント情報ＤＢ３０９、遷移データＤＢ３１０と同様の機能を保持する。

比較部３０４は、メモリ１０３に読み出され、プロセッサ１０２で実行される。比較部３０４は、遷移データＤＢ３１０を補助記憶装置１０５から読み出す。比較部３０４は、遷移データＤＢ３１０に記憶された遷移先ＵＲＬが同じレコードについてパラメータを比較し、異なる部分がある遷移先ＵＲＬを診断対象ＵＲＬとしてパラメータとともに出力部３１５に出力する。

出力部３１５は、メモリ１０３に読み出され、プロセッサ１０２で実行される。出力部３１５は、比較部３０４から入力された診断対象ＵＲＬを出力インターフェース１０６に出力する。

図２９は、実施の形態４に係る診断実施装置２３０の機能構成の一例を含む全体のブロック図である。診断実施装置２３０は、入力部３１６、リクエスト生成部３０５、リクエスト送受信部３０６、判定部３０７、出力部３０８、アカウント情報ＤＢ３１７、遷移データＤＢ３１８、結果データＤＢ３１９を備える。アカウント情報ＤＢ３１７、遷移データＤＢ３１８および結果データＤＢ３１９は実施の形態３のアカウント情報ＤＢ３０９、遷移データＤＢ３１０、結果データＤＢ３１２と同様の機能を保持する。

入力部３１６は、メモリ１０３に読み出され、プロセッサ１０２で実行される。入力インターフェース１０６を介して入力された値を補助記憶装置１０５へ保存する。入力部３１６は、入力されたアカウント情報（ログイン情報、権限情報）を補助記憶装置１０５上のアカウント情報ＤＢ３１７に出力する。また、入力部３１６は、診断対象ＵＲＬとパラメータを遷移データＤＢ３１８に出力する。

次に動作について説明する。
図３０は、実施の形態４に係る診断対象抽出装置２２０の入力部３０１、クローリング実施部３０２および抽出部３０３の処理の流れを示すフローチャートである。ステップＳ５０１〜Ｓ５０５の処理は、実施の形態３の図２５のステップＳ１０１〜Ｓ１０５の処理と同じである。

ステップＳ５０５において、抽出部３０３は、同じ遷移先に対して権限が特権で同じレコードについてＨＴＴＰリクエストの固定のパラメータを比較部３０４に出力する。

ステップＳ５０６において、比較部３０４は、抽出部３０３から入力されたパラメータが特権に存在して、一般権に存在しないまたは値が異なる場合、その遷移先ＵＲＬとパラメータの値を診断対象データ３２０として出力部３１５を介して出力する。また、出力部３１５は、アカウント情報ＤＢ３１３に保存されているアカウント情報を出力する。処理は終了する。

図３１は、実施の形態４に係る診断実施装置２３０の入力部３１６、リクエスト生成部３０５、リクエスト送受信部３０６、判定部３０７及び出力部３０８の処理の流れを示すフローチャートである。

ステップＳ６０１において、入力部３１６には、アカウント情報および診断対象データ３２０が入力される。入力部３１６は、入力されたアカウント情報をアカウント情報ＤＢ３１７に保存する。また、入力部３１６は、診断対象データ３２０を遷移データＤＢ３１８および結果データＤＢに保存する。

ステップＳ６０２〜Ｓ６０８は、実施の形態３のステップＳ２０２〜Ｓ２０８と同様である。

なお、本実施の形態において、実施の形態２で示したようにアカウントごとに２回クローリングを実施してページ遷移に必要な特定のパラメータを決定する機能を含めるようにしてもよい。

また、本実施の形態において、診断対象抽出装置２２０から出力される診断対象の情報を収集し、セキュリティ診断は既存の方法を用いるようにしてもよい。また、既存のセキュリティ診断で利用したＷｅｂアプリケーションより収集した診断対象の情報を診断実施装置２３０に入力するようにしてもよい。

したがって、本実施の形態では、特権の第１のアカウントにより遷移先ＵＲＬに送信したＨＴＴＰリクエストに含まれるパラメータのうち、特権の第２のアカウントにより遷移先ＵＲＬに送信したＨＴＴＰリクエストに含まれるパラメータと値が同じである固定のパラメータを抽出する抽出部３０３を備える診断対象抽出装置２２０と、一般権のアカウントによる遷移先ＵＲＬへのＨＴＴＰリクエストのパラメータに抽出部３０３で抽出された固定のパラメータが含まれており、値が特権のアカウントの値と異なる場合、固定のパラメータに特権のアカウントの値を設定したＨＴＴＰリクエストを出力するリクエスト生成部３０５と、一般権のアカウントによりＨＴＴＰリクエストを遷移先ＵＲＬに送信し、ＨＴＴＰレスポンスを受信するリクエスト送受信部３０６と、ＨＴＴＰレスポンスに基づいて遷移先ＵＲＬの脆弱性を判定する判定部３０７と、を備える診断実施装置２３０と、を備えたので、Ｗｅｂアプリケーションの遷移先ＵＲＬを事前に把握することなく権限管理の不備があるかどうかを診断することができる。

１０１ 通信インターフェース
１０２ プロセッサ
１０３ メモリ
１０４ 出力インターフェース
１０５ 補助記憶装置
１０６ 入力インターフェース
１０７ バス
２００、２１０ セキュリティ診断装置
２０１ Ｗｅｂサーバ
２０２ インターネット
２０３ Ｗｅｂアプリケーション
２２０ 診断対象抽出装置
２３０ 診断実施装置
３０１、３１６ 入力部
３０２ クローリング実施部
３０３ 抽出部
３０４ 比較部
３０５ リクエスト生成部
３０６ リクエスト送受信部
３０７ 判定部
３０８、３１５ 出力部
３０９、３１３、３１７ アカウント情報ＤＢ
３１０、３１４、３１８ 遷移データＤＢ
３１１ 固定パラメータＤＢ
３１２、３１９ 結果データＤＢ
４１０ アカウント情報テーブル
４２０ ログインパラメータテーブル
４３０ 対象ＵＲＬテーブル
４４０、４４１、４４２、４４３、４４４ ＨＴＴＰリクエスト・レスポンステーブル
４５０、４５１、４５２、４５３、４５４ パラメータテーブル
４６０、４６１、４６２ 固定パラメータテーブル
４７０、４７１ 診断結果テーブル
４８０、４８１ 結果詳細テーブル

入力インターフェース１０６を介してアカウント情報および対象ＵＲＬが入力されると、入力部３０１は処理を開始する。
図１１のステップＳ１０１において、入力部３０１は、入力されたアカウント情報をアカウント情報ＤＢ３０９のアカウント情報テーブル４１０とログインパラメータテーブル４２０に保存する。アカウント情報には、Ｗｅｂアプリケーション２０３にログインする際に必要なアカウントＩＤおよびパスワードといったログイン情報とそのアカウントのアカウント権限とログインするために必要なパラメータのパラメータ名とが含まれる。

ステップＳ４０７において、比較部３０４は、パラメータテーブル４５２を参照し、特権と一般権で同じパラメータ名が存在し、値が同じか判定する。値が同じでない場合、処理はステップＳ３０５に進む。値が同じ場合、比較部３０４は、選択したレコードの遷移先ＵＲＬおよび遷移パラメータを診断対象から除外し、処理は終了する。

Claims (7)

1. 特権の第１のアカウントにより遷移先ＵＲＬに送信したＨＴＴＰリクエストに含まれるパラメータのうち、特権の第２のアカウントにより前記遷移先ＵＲＬに送信したＨＴＴＰリクエストに含まれるパラメータと値が同じである固定のパラメータを抽出する抽出部と、
   一般権のアカウントによる前記遷移先ＵＲＬへのＨＴＴＰリクエストのパラメータに前記抽出部で抽出された前記固定のパラメータが含まれており、値が特権のアカウントの値と異なる場合、前記固定のパラメータに特権のアカウントの値を設定したＨＴＴＰリクエストを出力するリクエスト生成部と、
   一般権のアカウントにより前記ＨＴＴＰリクエストを前記遷移先ＵＲＬに送信し、ＨＴＴＰレスポンスを受信するリクエスト送受信部と、
   前記ＨＴＴＰレスポンスに基づいて前記遷移先ＵＲＬの脆弱性を判定する判定部と、
   を備えることを特徴とするセキュリティ診断装置。
2. 前記リクエスト生成部は、一般権のアカウントによる前記遷移先ＵＲＬへのＨＴＴＰリクエストのパラメータに前記抽出部で抽出された前記固定のパラメータが含まれていない場合、特権のアカウントの値を設定した前記固定のパラメータをＨＴＴＰリクエストに追加し、前記固定のパラメータが追加されたＨＴＴＰリクエストを出力することを特徴とする請求項１に記載のセキュリティ診断装置。
3. 前記抽出部は、前記第１のアカウントにより前記遷移先ＵＲＬに送信したＨＴＴＰリクエストに含まれるパラメータのうち、前記第２のアカウントにより前記遷移先ＵＲＬに送信したＨＴＴＰリクエストに含まれるパラメータと値が異なる変動のパラメータを抽出し、
   前記リクエスト生成部は、一般権のアカウントにより前記遷移先ＵＲＬに遷移しない場合、特権のアカウントによる前記遷移先ＵＲＬへのＨＴＴＰリクエストのうち前記抽出部で抽出された前記変動のパラメータに一般権のアカウントによる前記遷移先ＵＲＬへのＨＴＴＰリクエストのパラメータの値を設定し、値を設定したＨＴＴＰリクエストを出力することを特徴とする請求項１または２に記載のセキュリティ診断装置。
4. 前記抽出部は、前記第１のアカウントにより前記遷移先ＵＲＬに送信したＨＴＴＰリクエストに含まれるパラメータのうち、前記第２のアカウントにより前記遷移先ＵＲＬに送信したＨＴＴＰリクエストに含まれるパラメータと値が同じである固定のパラメータについて、前記第１のアカウントから前記遷移先ＵＲＬに複数回送信したＨＴＴＰリクエストに含まれる前記固定のパラメータ値が異なる場合、前記固定のパラメータを前記遷移先ＵＲＬとの組み合わせでページを一意に示す遷移パラメータとして抽出することを特徴とする請求項１から３のいずれか一項に記載のセキュリティ診断装置。
5. 入力されたＵＲＬに対して複数の特権のアカウントによりクローリングを実施し、前記遷移先ＵＲＬと前記遷移先ＵＲＬに送信したＨＴＴＰリクエストに含まれるパラメータと前記遷移先ＵＲＬから受信したＨＴＴＰレスポンスと前記ＨＴＴＰリクエストを送信したアカウントの権限とを対応づけて遷移データデータベースに保存するクローリング実施部と、
   前記遷移データデータベースに保存された前記複数の特権のアカウントの前記遷移先ＵＲＬと前記パラメータとに基づき、前記遷移先ＵＲＬを診断対象として出力する比較部と、
   を備えることを特徴とする請求項１から４のいずれか一項に記載のセキュリティ診断装置。
6. 特権の第１のアカウントにより遷移先ＵＲＬに送信したＨＴＴＰリクエストに含まれるパラメータのうち、特権の第２のアカウントにより前記遷移先ＵＲＬに送信したＨＴＴＰリクエストに含まれるパラメータと値が同じである固定のパラメータを抽出する抽出部を備えるセキュリティ診断対象抽出装置と、
   一般権のアカウントによる前記遷移先ＵＲＬへのＨＴＴＰリクエストのパラメータに前記抽出部で抽出された前記固定のパラメータが含まれており、値が特権のアカウントの値と異なる場合、前記固定のパラメータに特権のアカウントの値を設定したＨＴＴＰリクエストを出力するリクエスト生成部と、
   一般権のアカウントにより前記ＨＴＴＰリクエストを前記遷移先ＵＲＬに送信し、ＨＴＴＰレスポンスを受信するリクエスト送受信部と、
   前記ＨＴＴＰレスポンスに基づいて前記遷移先ＵＲＬの脆弱性を判定する判定部と、
   を備えるセキュリティ診断実施装置と、
   を備えることを特徴とするセキュリティ診断装置。
7. 特権の第１のアカウントにより遷移先ＵＲＬに送信したＨＴＴＰリクエストに含まれるパラメータのうち、特権の第２のアカウントにより前記遷移先ＵＲＬに送信したＨＴＴＰリクエストに含まれるパラメータと値が同じである固定のパラメータを抽出するステップと、
   一般権のアカウントによる前記遷移先ＵＲＬへのＨＴＴＰリクエストのパラメータに抽出された前記固定のパラメータが含まれており、値が特権のアカウントの値と異なる場合、前記固定のパラメータに特権のアカウントの値を設定したＨＴＴＰリクエストを出力するステップと、
   前記ＨＴＴＰリクエストを前記遷移先ＵＲＬに送信し、ＨＴＴＰレスポンスを受信するステップと、
   前記ＨＴＴＰレスポンスに基づいて前記遷移先ＵＲＬの脆弱性を判定するステップと、
   を有するセキュリティ診断方法。

Images