JP7217400B2 - ウェブサイトの脆弱性診断装置、診断システム、診断方法および診断プログラム - Google Patents

Description

本発明は、ウェブサイトの脆弱性を診断する脆弱性診断装置に関し、特に、対象ウェブサイトの脆弱性を自動的に診断する方法に関する。

近年、ウェブサイトを活用したサービスが増加しているが、その反面、ウェブサイトから個人情報等が漏洩する問題が生じている。ウェブサイトは、個人情報が漏洩しないようにセキュリティを考慮して設計されているが、それでも、ハッカー等がウェブサイトの欠陥を探し出し、そこから個人情報等を盗用することが行われている。

個人情報の漏洩を防止する技術として、特許文献１は、既知の攻撃パターンを検査対象のウェブサイトに対してテスト目的で仕掛けることで脆弱性の有無を検出する方法を開示している。また、特許文献２のウェブサイトの検査装置は、ウェブサイトとクライアントとの通信内容を取得し、通信内容に含まれるセッションを特定するセッション追跡パラメータを推定し、推定されたセッション追跡パラメータに基づきウェブサイトに内在する脆弱性を分析している。

米国特許第６３１１２７８号公報 特開２００４－３１０２６７号公報

一般的なウェブサイトでは、どの利用者にどの操作を許可するかを管理する、いわゆる認可制御が行われている。ある認可制御されたウェブサイトでは、管理者は、メインコンテンツと管理ページの双方にアクセスし、それらの情報を閲覧することが可能であり、一般のユーザーは、メインコンテンツにのみアクセスが許可される。また、ある認可制御されたウェブサイトでは、ユーザーＡは、ユーザーＢの個人的な情報コンテンツにアクセスし、その情報を閲覧することができず、同様に、ユーザーＢは、ユーザーＡの個人的な情報コンテンツにアクセスし、その情報を閲覧することができない。

例えば、ショッピングサイトまたは電子商取引サイトにおいて、ユーザーＡは、ユーザーＢとして商品を購入することはできないし、ユーザーＢの商品購入履歴を閲覧することはできない。あるいは、コミュニティサイトであれば、ユーザーＡは、ユーザーＢとしてメッセージやコメントを送信できないし、ユーザーＢのプロフィールを変更することはできない。このように、ウェブサイトでは、どの利用者にどの操作を許可するかを管理する認可制御が行われている。

ウェブサイトは、適切に認可制御される必要があり、そのためにウェブサイトの脆弱性を防御する方法が講じられている。図１１（Ａ）は、サーバーにおいて、アクセス権の管理テーブルを用い、どの利用者／管理者等がどのページにアクセスすることが認可されるのかを定義している。例えば、管理者であれば、管理ページ、商品管理ページ、商品閲覧ページの全てにアクセスすることが許され、販売業者であれば、管理ページへのアクセスが禁止され、それ以外のページへのアクセスが許可され、一般ユーザーであれば、商品閲覧ページのみのアクセスが許される。

また、図１１（Ｂ）に示す防御方法は、ログインセッションと、表示するユーザー情報とが等しいか否かをチェックし、一致しない場合には、そのアクセスを拒否するものである。サーバーは、ウェブサイトにユーザーからのＨＴＴＰリクエストがあると（Ｓ１０）、アクセス先のページのユーザーのログインＩＤを取得する（Ｓ２０）。ログインＩＤは、例えば、ログインＩＤが紐つけられたＵＲＬやパラメータ等から取得される。次に、ユーザーがウェブサイトにアクセスしたときに、ユーザーのアクセスを管理するセッションに割り当てられたユーザーＩＤが取得され（Ｓ３０）、ログインＩＤとユーザーＩＤが等しいか否かが確認される（Ｓ４０）。双方のＩＤが等しくない場合には、ユーザーになりすましたハッカーやクラッカー等による不正アクセスと判定し、ウェブサイトへのアクセスが拒否される。

認可制御の脆弱性とは、第１に、設定の間違いにより、想定していない利用者により一定の操作が行われてしまうことである。例えば、一般ユーザーが管理ページを閲覧し、その管理項目を操作してしまう。第２に、悪意のあるユーザーからのクラッキングにより予期していない操作が行われてしまうことである。例えば、他人のショッピングサイトでの購買履歴にアクセスできるように、ＵＲＬや各パラメータの数字が操作されてしまう。

このような認可制御の脆弱性は、セキュリティエンジニアによって診断されてきたが、ウェブサイトの増加に伴い、セキュリティエンジニアの数も不足し、脆弱性の診断に膨大なコストと時間がかかってしまうという課題がある。

本発明は、上記従来の課題を解決するものであり、ウェブサイトの認可制御の脆弱性を自動的に診断可能な脆弱性の診断装置、診断システム、診断方法および診断プログラムを提供することを目的とする。

本発明に係る脆弱性診断装置は、対象ウェブサイトの脆弱性を診断するものであって、対象ウェブサイトとの通信内容から対象ウェブサイトへの複数のユーザーのリクエスト情報を取得する第１の取得手段と、複数のユーザーのリクエスト情報に基づき複数の診断用リクエストを生成する生成手段と、複数の診断用リクエストに対する複数のユーザーのレスポンス情報を対象ウェブサイトから取得する第２の取得手段と、異なるユーザー間のレスポンス情報を比較する比較手段と、前記比較手段の比較結果に基づき対象ウェブサイトの複数のユーザーの認可制御の脆弱性を診断する診断手段とを有する。

ある実施態様では、前記生成手段は、複数のリクエスト情報の差分を抽出し、当該差分に基づき診断用リクエストを生成する。ある実施態様では、前記診断用リクエストは、ユーザーの個人情報が含まれるページを取得するためのリクエストを含む。ある実施態様では、前記生成手段は、前記リクエスト情報に含まれる予め決められた情報に基づき診断用リクエストを生成する。ある実施態様では、前記比較手段は、レスポンス情報に含まれるＨＴＭＬから文字列を抽出し、抽出された文字列の類似度を算出する。ある実施態様では、複数のユーザーのリクエストは、対象ウェブサイトの管理者のリクエストを含む。ある実施態様では、脆弱性診断装置は、ウェブサイトを巡回する巡回手段を含み、前記第１の取得手段は、前記巡回手段により対象ウェブサイトが巡回されたときの通信内容からユーザーのリクエスト情報を取得する。ある実施態様では、前記第２の取得手段は、他人のユーザーのレスポンス情報を取得するとき、他人になりすましたリクエストを送信する。ある実施態様では、

本発明に係る脆弱性診断システムは、上記構成の脆弱性診断装置と、当該脆弱性診断装置とネットワークを介して接続されたサーバーとを含むものであって、前記脆弱性診断装置は、ネットワークを介して前記サーバーの対象ウェブサイトをアクセスする。

本発明に係る対象ウェブサイトの脆弱性を診断する方法は、ウェブサイトが自動的に巡回されるときに、対象ウェブサイトとの通信内容から対象ウェブサイトへの複数のユーザーのリクエスト情報を取得し、複数のユーザーのリクエスト情報に基づき複数の診断用リクエストを生成し、前記複数の診断用リクエストに対する複数のユーザーのレスポンスを対象ウェブサイトから取得し、異なるユーザー間のレスポンス情報を比較し、比較結果に基づき対象ウェブサイトの複数のユーザーの認可制御の脆弱性を診断する。

本発明に係る診断プログラムは、対象ウェブサイトの脆弱性を診断する脆弱性診断装置が実行するものであって、ウェブサイトが自動的に巡回されるときに、対象ウェブサイトとの通信内容から対象ウェブサイトへの複数のユーザーのリクエスト情報を取得し、複数のユーザーのリクエスト情報に基づき複数の診断用リクエストを生成し、前記複数の診断用リクエストに対する複数のユーザーのレスポンスを対象ウェブサイトから取得し、異なるユーザー間のレスポンス情報を比較し、比較結果に基づき対象ウェブサイトの複数のユーザーの認可制御の脆弱性を診断する。

本発明によれば、対象ウェブサイトの通信内容からリクエスト情報を取得し、リクエスト情報に基づき診断用リクエストを生成し、診断用リクエストにより得られたレスポンス情報により認可制御の脆弱性を診断するようにしたので、ウェブサイトの脆弱性の診断を自動で行うことが可能になる。また、指数関数的に増加するウェブサイトの脆弱性を自動化することで、診断に要する時間的コストおよび作業コストを大幅に低減することができる。

本発明の実施例に係る脆弱性診断システムの全体構成を示す図である。 本発明の実施例に係る脆弱性診断システムの概要を説明する図である。 本発明の実施例に係る脆弱性診断装置の機能的な構成を示すブロック図である。 本発明の実施例に係る脆弱性診断装置による認証制御のフローを示す図である。 本発明の実施例に係る脆弱性診断装置の診断動作を示すフロー図である。 本発明の実施例に係るＨＴＴＰ取得動作を示すフロー図である。 ＨＴＴＰリクエストの差分ＵＲＬの例を示す図である。 診断用リクエストの組合せ例を示す図である。 本発明の実施例に係るレスポンス間距離計測部の計測例を示すフロー図である。 本発明の実施例に係る脆弱性判定部の診断例を示すフロー図である。 従来の脆弱性を防御する方法を説明する図である。

本発明の１つの実施態様では、脆弱性診断装置がインターネットを介してサーバーに接続され、脆弱性診断装置は、サーバー上のウェブサイトの脆弱性を自動的に診断する機能を備えている。１つの実施態様では、本発明の脆弱性診断装置は、１つまたは複数のコンピュータ装置により実施され、その診断機能は、コンピュータ装置に搭載されたプログラムまたはソフトウエアを利用して実行される。

次に、本発明の実施例について図面を参照して詳細に説明する。図１は、本発明の実施例に係るウェブサイトの脆弱性診断システムの一例を示す図である。同図に示すように、本実施例の脆弱性診断システム１００は、ウェブサイトの認可制御の脆弱性を診断する機能を備えた脆弱性診断装置２００と、脆弱性診断装置２００とネットワーク３００を介して接続された対象ウェブサイト４００とを含む。

対象ウェブサイト４００は、単一または複数のコンピュータ装置により構成され、例えば、対象ウェブサイト４００は、ＨＴＴＰに準じてコンテンツを提供する１つまたは複数のウェブサーバーである。ウェブサーバーは、ＨＴＭＬ形式のコンテンツを格納し、例えば、ショッピングサイト、ＳＮＳサイト、掲示板サイト、広告サイトなど多様のウェブサイトを提供する。個人情報を取り扱うウェブサイトは、ユーザー毎にウェブページを提供し、ユーザー毎のアクセスを管理するために、クッキー等のセッションＩＤを用いる。

ネットワーク３００は、ＨＴＴＰに準じた通信（例えば、インターネット）であり、ウェブサイト４００は、ネットワーク３００を介してユーザーまたはクライアントからのリクエストに応答してコンテンツを提供する。

脆弱性診断装置２００は、対象ウェブサイト４００とＨＴＴＰに準じた通信を行うことができる１つまたは複数のコンピュータ装置により構成される。脆弱性診断装置２００は、例えば、対象ウェブサイト４００から提供されたコンテンツを閲覧、およびＪａｖａＳｃｒｉｐｔ(登録商標)等クライアントサイドのプログラムを実行するブラウザ機能と、ブラウザと対象ウェブサイト４００との間の通信を中継し、かつその通信内容を取得するプロキシ機能と、取得された通信内容に基づき対象ウェブサイトの脆弱性を自動診断する診断機能とを含む。さらに脆弱性診断装置２００は、ネットワーク上に接続されたサーバー上の複数のウェブサイトを自動的に巡回する巡回機能を含み、ウェブサイトを自動的に巡回したときの通信内容を利用して対象ウェブサイトの脆弱性の自動診断を行うことも可能である。

ＨＴＴＰによる通信では、ブラウザからウェブサイトに対してＨＴＴＰリクエストが送信され、ウェブサイトは、このＨＴＴＰリクエストに応答してレスポンスをブラウザに送信する。ＨＴＴＰリクエストは、リクエストヘッダとリクエストボディとを含み、ＨＴＴＰリクエストには、ウェブサイトのＵＲＬや、ウェブサイトの個人のページにアクセスする際に必要となる、ログインＩＤ、ユーザーＩＤ、パスワード、クッキー、セッションＩＤ等が含まれる。レスポンスは、レスポンスヘッダとレスポンスボディとを含み、レスポンスボディは、ＨＴＭＬコンテンツを含む。

ここで、本実施例による脆弱性診断装置２００の診断内容の概略について、図２に示すショッピングサイトを例に説明する。脆弱性診断装置２００は、複数のウェブサイトを一定の時間間隔または決められた時間で巡回するクローラを含む。クローラは、脆弱性診断装置２００にプログラムとして実装される。クローラによりウェブサイトの巡回が行われるとき、その通信内容を利用して、ショッピングサイトの脆弱性が診断される。本例では、ショッピングサイトとして、２名のユーザーＡ、ユーザーＢを例示し、ショッピングサイトは、ユーザーＡ、ユーザーＢについて認可制御されているものとする。つまり、ユーザーＡおよびユーザーＢがアクセスし、そのコンテンツを閲覧することができる共通のページと、ユーザーＡのみが閲覧を許可される個人用のページＡ１と、ユーザーＢのみが閲覧を許可される個人用のページＢ１とを含む。ページＡ１は、例えば、ユーザーＡの購買履歴であり、そのＵＲＬは、http://example.jp/history/1001であり、ページＢ２は、ユーザーＢの購買履歴であり、そのＵＲＬは、http:// example.jp/history/1002である。認可制御が正しく設定されていれば、ユーザーＡは、ユーザーＢの購買履歴のページＢ２を閲覧することはできないし、ユーザーＢは、ユーザーＡの購買履歴のページＡ１を閲覧することはできない。そのような不適切なリクエストがあった場合には、例えば、エラーページがレスポンスとして送信される。例えば、ユーザーＢのリクエストが不適切であれば、エラーページが脆弱性診断装置２００に送信され、それがブラウザに表示される。

クローラによりアクセスできるページは、閲覧されても良いページであり、クローラによりアクセスできないページは脆弱性を有するページ候補と仮定する。図２の例では、共通のページは、閲覧されても良いページであり、ユーザーＩＤあるいはセッションＩＤを必要とする個人のページＡ１、Ａ２、Ｂ１、Ｂ２は、脆弱性を有するページ候補である。

脆弱性診断装置２００は、次のような手順で、認可制御の脆弱性を診断する。
手順１．クローラによりウェブサイトの巡回が行われるとき、クローラは、ブラウザ等に予め準備されたＵＲＬやログイン情報を利用してウェブサイトを巡回する。この巡回中に、クローラは、ユーザーＡのログインＩＤ、ユーザーＢのログインＩＤ等を用いてショッピングサイトをアクセスする。図２には、ユーザーＡについては、共通ページとページＡ１が巡回され、ページＡ２が非巡回であり、ユーザーＢについては、共通ページとページＢ２が巡回であり、ページＢ１が非巡回であることが示されている。

手順２．クローラによりショッピングサイトが巡回されたときの通信内容から、ユーザーＡ、ユーザーＢのＨＴＴＰリクエストを取得し、ユーザーＡ、ユーザーＢのＨＴＴＰリクエストに記載されているＵＲＬを比較し、差分ＵＲＬを抽出する。ＵＲＬが一致するページは、ユーザーＡ、ユーザーＢの共通ページであり、相互に一致しないＵＲＬは、ユーザーＡ、ユーザーＢの個人情報が記載されたページである。図２の例で言えば、ユーザーＡの購入履歴のページＡ１と、ユーザーＢの購入履歴のページＢ２のＵＲＬが差分として抽出される。また、差分は、ＵＲＬに対してのみ取られるのではなく、ＧＥＴパラメータやＰＯＳＴパラメータに対しても取得される。

手順３．差分ＵＲＬから診断用リクエストを生成する。図の例で言えば、診断用リクエストは、「http://example.jp/history/1001」を含むＨＴＴＰリクエストと「http://example.jp/history/1002」を含むＨＴＴＰリクエストとを含む。脆弱性診断装置２００は、クローラがユーザーＡの非巡回ページＡ２をアクセスするとき、診断用リクエストに含まれるセッションＩＤ（クッキー）をユーザーＡからユーザーＢに変更し、ユーザーＢの個人ページＢ２へのアクセスを試みる。また、クローラがユーザーＢの非巡回ページＢ１をアクセスする、診断用リクエストのセッションＩＤ（クッキー）をユーザーＢからユーザーＡに変更し、ユーザーＡの個人ページＡ１のアクセスを試みる。

手順４．巡回したときのページと、診断用リクエストにより他人の個人ページをアクセスして取得されたページとの距離を計測する。本例では、クローラがページＢ１を巡回したときに、診断用リクエストのセッションＩＤをユーザーＢからユーザーＡに変更し、ユーザーＡのページＡ１をアクセスしたときに取得されたページと、ページＢ１との距離を計測する。
・診断用リクエストにより取得されたページがエラーページに近いとき、認可制御ができていると判定する（脆弱性診断装置２００には、エラーページが表示されているため）。
・診断用リクエストにより取得されたページがユーザーＢの購買履歴のページＢ２に近いとき、認可制御ができていると判定する(ユーザーＢのページが表示されているため)。
・診断用リクエストにより取得されたページがユーザーＡの購買履歴のページＡ１に近いとき、認可制御ができていないと判定する（ユーザーＡの個人情報のページが閲覧されているため）。
このような判定に基づく診断結果が脆弱性診断装置２００に出力される。

次に、本実施例の脆弱性診断装置２００の詳細について説明する。図３に、本実施例の脆弱性診断装置２００の機能的な構成を示す。脆弱性診断装置２００は、装置全体の機能を制御するメイン部２１０、ウェブサイトの巡回を制御するクローラ部２１２、ブラウザを制御するブラウザ制御部２１４、ウェブサイトから送信されるコンテンツを表示したり、ウェブサイトを検索するブラウザ部２１６、ブラウザ部２１６とウェブサイトの通信を中継するサーバーとして機能し、かつウェブサイトとの間の通信内容を取得する機能を備えたプロキシ部２１８を含む。

クロ―ラ部２１２は、ウェブサイトの巡回を行うとき、ブラウザ制御部２１４に格納されているユーザーＵＲＬ、ユーザーＩＤ、ログインＩＤ、パスワード等を読出し、プロキシ部２１８を介してウェブサイトをアクセスする。巡回の目的は、任意であるが、例えば、ウェブサイトから最新の情報を取得し、これをブラウザ制御部２１４に格納する。ブラウザ制御部２１４は、ブラウザ部２１６が起動されたとき、最新の情報を閲覧できるようにする。ブラウザ制御部２１４はさらに、例えば、ＪａｖａＳｃｒｉｐｔ(登録商標)が動作するブラウザ部２１６を制御することで、ＪａｖａＳｃｒｉｐｔ(登録商標)の動作にも対応する。プロキシ部２１８は、ウェブサイトにＨＴＴＰリクエストを傍受したり、同様にウェブサイトからのレスポンスを傍受し、これらの通信内容をメイン部２１０へ提供する。

本実施例では、メイン部２１０はさらに、ウェブサイトの脆弱性を診断する機能を備える。具体的には、メイン部２１０は、クローラ部２１２によりウェブサイトの巡回が行われるとき、プロキシ部２１８によって取得された通信内容に基づき対象ウェブサイト４００へ送信されたＨＴＴＰリクエストを取得するＨＴＴＰリクエスト取得部２２０と、ＨＴＴＰリクエスト取得部２２０で取得された各リクエストを比較し、そこに含まれる差分ＵＲＬを抽出するリクエスト比較部２２２と、リクエスト比較部２２２により抽出された差分ＵＲＬに基づき診断用リクエストを生成する診断ＨＴＴＰリクエスト生成部２２４と、診断用リクエストに応答して各ウェブサイト４００から送信されたレスポンスをプロキシ部２１８の傍受した内容から取得するレスポンス取得部２２６と、診断ＨＴＴＰリクエスト生成部２２４で生成されたリクエストの組合せを生成するリクエスト組合せ生成部２２８と、リクエスト組合せ生成部２２８で生成されたリクエストの組合せに対応するレスポンス間の類似度を算出するレスポンス間類似度算出部２３０と、レスポンス間類似度算出部２３０の算出結果に基づきページの脆弱性を判定する脆弱性判定部２３２と、脆弱性判定部２３２の判定結果に基づきウェブサイトの認可制御の脆弱性診断結果を出力する診断結果出力部２３４とを有する。

脆弱性診断装置２００は、対象ウェブサイト４００を診断するとき、図４に示すような認証制御を行う。すなわち、クローラ部２１２は、ウェブサイトを巡回するとき、ブラウザ制御部２１４の一例であるＳｅｌｅｎｉｕｍに格納されたユーザーのログイン情報（例えば、ログインＵＲＬ、アカウント、パスワードなど）を参照してＨＴＴＰリクエストを作成し、プロキシ部２１８を介してＨＴＴＰリクエストを対象ウェブサイトに送信させる。メイン部２１０は、対象ウェブサイト４００の脆弱性を診断するとき、ログインしているユーザーのセッションＩＤを変更することで、他人に成りすました変更したＨＴＴＰリクエストを診断ＨＴＴＰリクエスト生成部２２４から送信させる。

次に、本実施例の対象ウェブサイトの診断方法を図５のフローチャートを参照して説明する。ここでは、図２に示すようなショッピングサイトを診断する例を説明する。先ず、クローラ部２１２によりウェブサイトの巡回が行われるとき、ＨＴＴＰリクエスト取得部２２０は、プロキシ部２１８を介して取得された対象ウェブサイトとの通信内容からユーザーＡのＨＴＴＰリクエストおよびユーザーＢのＨＴＴＰリクエストを取得する（Ｓ１００、Ｓ１１０）。

図６に、ＨＴＴＰリクエストを取得するときの一例を示す。クロ―ラ部２１２は、ウェブサイトを巡回するとき、ブラウザ制御部２１４のＳｅｌｅｎｉｕｍに格納されたログイン情報（ログインＵＲＬ、アカウント、パスワード等）に基づきＨＴＴＰリクエストを作成し、プロキシ部２１８を介して対象ユーザーにてウェブサイトにログインする（Ｓ２００）。

ウェブサイトの１回目の巡回では（Ｓ２１０）、クロ―ラ部２１２は、プロキシ部２１６を介してリンク、ボタンクリック、ランダムのフォーム入力などを行い、自動で網羅的にウェブサイトを巡回する。また、１回目の巡回において、図２に示すようなユーザーＡ、ユーザーＢの購買処理を自動で行い、ユーザーＡ、ユーザーＢの個人ページを新たに作り込んだり、あるいはウェブサイトのコンテンツを増加させることができる。

ウェブサイトの２回目の巡回では（Ｓ２２０）、クロ―ラ部２１２により、購買履歴や個人ページなど脆弱性候補のページが巡回される。ＨＴＴＰリクエスト取得部２２０は、２回目の巡回において、プロキシ部２１８で取得された通信内容からユーザーＡ、ユーザーＢのＨＴＴＰリクエストを取得する（Ｓ２３０）。このＨＴＴＰリクエストは、ユーザーＡ、ユーザーＢの個人情報をアクセスするためのＵＲＬを含む。

再び、図５に戻り、リクエスト比較部２２２は、取得されたユーザーＡ、ユーザーＢのＨＴＴＰリクエストを比較し、相互にないＨＴＴＰリクエストを抽出する（Ｓ１２０）。具体的には、ＨＴＴＰリクエストを比較し、相互にないＵＲＬを含むＨＴＴＰリクエストを抽出する。相互にないＨＴＴＰリクエストは、図２の例で言えば、ユーザーＡのページＡ１を表すＵＲＬやユーザーＢのページＢ２を表すＵＲＬである。また、共通するＨＴＴＰリクエストは、共通のＵＲＬを含み、図２の例で言えば、ユーザーＡとユーザーＢの共通のページを表すＵＲＬである。図７に、ユーザーＡのＨＴＴＰリクエストとユーザーＢのＨＴＴＰリクエストとを比較したときに抽出された差分ＵＲＬの一例を示す。

次に、診断ＨＴＴＰリクエスト生成部２２４は、リクエスト比較部２２２により抽出された相互にないＨＴＴＰリクエストに基づき診断用リクエストを生成する（Ｓ１３０）。１つの態様では、診断用リクエストは、リクエスト比較部２２２によって抽出された相互にないＵＲＬを含むものであり、例えば、図７に示すユーザーＡの差分ＵＲＬのそれぞれに対応する診断用リクエストと、ユーザーＢの差分ＵＲＬのそれぞれに対応する診断用リクエストである。これらの診断用リクエストは、ユーザーＡ、ユーザーＢのそれぞれの個人ページをアクセスするためのリクエストとなる。

さらに診断ＨＴＴＰリクエスト生成部２２４は、エラーページを取得するための診断用リクエストと、セッションＩＤまたはクッキーを他人のＩＤに置き換えた成りすましのための診断用リクエストとを生成する。成りすましのための診断用リクエストは、図７の例で言えば、ＨＴＴＰリクエストのセッションＩＤまたはクッキーをユーザーＡからユーザーＢに置き換えたもの、あるいはユーザーＢのＨＴＴＰリクエストにおいて、セッションＩＤまたはクッキーをユーザーＢからユーザーＡに置き換えたものである。

また、他の態様では、診断ＨＴＴＰリクエスト生成部２２４は、差分ＵＲＬの特定の階層（ディレクトリ）または差分ＵＲＬに含まれる特定のパラメータに着目し、着目された情報が含まれた差分ＵＲＬに絞って診断用リクエストを生成してもよい。例えば、診断ＨＴＴＰリクエスト生成部２２４は、ｍｅｔｈｏｄ、ＵＲＬ、ｇｅｔパラメータ、ｐｏｓｔパラメータの差分に着目し、その際に、ｇｅｔ／ｐｏｓｔパラメータから下記を削除する。
・Ｅｍａｉｌ、ＩＤ、パスワードなど各ユーザーのアカウント情報
・ワンタイムトークン
Ｅｍａｉｌ、ＩＤ、パスワードは、プログラムに入力されているため、それに該当する場合には、パラメータを削除する。ワンタイムトークンは、ｋｅｙに”ｔｋｎ”、“ｔｏｋｅｎ”を含むパラメータを削除する。

診断ＨＴＴＰリクエスト生成部２２４は、診断用リクエストを生成すると、これをプロキシ部２１８に提供し、プロキシ部２１８は、対象ウェブサイトに診断用リクエストを送信する。診断用リクエストの各々は、差分ＵＲＬに基づくものであるから、対象ウェブサイト４００から複数のユーザーのレスポンスを取得することになる。例えば、ユーザーＡの診断用リクエストを送信し、次いで、ユーザーＢに成りすましのための診断用リクエストを送信し、対象ウェブサイトは、これらの診断用リクエストに対応するレスポンスを脆弱性診断装置２００へ送信する。プロキシ部２１８は、対象ウェブサイトからレスポンスを取得し（Ｓ１４０）、これをレスポンス取得部２２６へ提供する。

次に、リクエスト組合せ生成部２２８は、診断用リクエストの組合せを作成する（Ｓ１５０）。対象ウェブサイトの複数のユーザー間の認可制御の脆弱性を診断するため、リクエスト組合せ生成部２２８は、異なるユーザー間での診断用リクエストの組合せを生成する。例えば、ユーザーＡの診断用リクエストに対するユーザーＢの診断用リクエストの組合せを生成する。複数の診断用リクエストの全ての組合せを生成してもよいし、予め決められたルールに従い特定の診断用リクエストの組合せを生成してもよい。例えば、ユーザーＡの診断用リクエストのＵＲＬの特定の階層と共通する階層を有するユーザーＢの診断用リクエストの組合せが生成される。図８に、診断用リクエストの組合せの一例を示す。例えば、同図に示すように、ユーザーＡのＵＲＬの２番目までの階層と等しいユーザーＢの診断用リクエストの組合せが生成される。

次に、レスポンス間類似度算出部２３０は、診断用リクエストの組合せに対応するレスポンスの類似度を算出する。対象ウェブサイトからのレスポンスは、ＨＴＭＬコンテンツを含むものであり、ＨＴＭＬコンテンツの類似度または距離が算出される。類似度の算出方法は、特に限定されないが、１つの例では、ＨＴＭＬコンテンツからタグを除去し、文字列を抽出し、抽出された文字列の重複度合が算出される。

図９に、ＨＴＭＬコンテンツ間の距離（類似度）の計測方法の一例を示す。ユーザーＡのＨＴＭＬコンテンツが取得され（Ｓ３００）、ＨＴＭＬコンテンツからタグが除去され、文字列が抽出され（Ｓ３１０）、抽出された文字列について形態素解析が行われる（Ｓ３２０）。ユーザーＢのＨＴＭＬコンテンツについても同様の処理が行われる。次に、形態素解析が行われた単語の“ｂａｇ－ｏｆ－ｗｏｒｄｓ”が作成され（Ｓ３３０）、次いで２つのＨＴＭＬコンテンツの距離が計算される（Ｓ３４０）。距離の計算は、例えば、距離＝共通ワード数／全体のワード数によって算出される。

次に、脆弱性診断部２３２は、レスポンス間類似度（距離）に基づき認可制御の脆弱性を判定する（Ｓ１７０）。１つの態様では、他人に成りすましたリクエストに対応するレスポンスが、当該他人のリクエストに対応するレスポンスに類似している場合には、認可制御の脆弱性の疑いがあると判定される。つまり、認可制御が正しく設定されていない可能性がある。他方、他人になりすましたリクエストに対応するレスポンスが、当該他人のリクエストに類似していない場合、あるいはエラーページに類似している場合には、脆弱性なしと判定される。

図１０に、脆弱性の判定フローの一例を示す。
１は、ユーザーＡへのリクエストを表し、例えば、図２のユーザーＡのページＡ１にアクセスするためのリクエストである。
２は、ユーザーＢへのリクエストを表し、例えば、図２のユーザーＢのページＢ２にアクセスするためのリクエストである。
３は、エラーページへのリクエストを表し、例えば、図２のエラーページにアクセスするためのリクエストである。
４は、ユーザーＢのページＢ１へのアクセスにおいて、そのＣｏｏｋｉｅをユーザーＡに置き換えたユーザーＡに成りすましたリクエストである。

図１０に示す１～４のリクエストは、診断ＨＴＴＰリクエスト生成部２２４によって生成されたリクエストであり、４と３の比較、４と２の比較、４と１との比較は、リクエスト組合せ生成部２２８によって生成された組合せであり、これらのリクエストの組合せに応じたレスポンス間の類似度（距離）は、レスポンス間類似度算出部２３０によって算出される。

先ず、４と３との比較により（Ｓ４００）、両者のレスポンス（ＨＴＭＬコンテンツ）が類似している場合には、脆弱性なしと判定される（Ｓ４１０）。これは、他人の成りすましにリクエストに対して適切にエラーメッセージが返信されているためであり、認可制御が正しく機能している。類似か否かは、例えば、図９に示す距離の計算結果が予め設定された閾値以上であれば類似、閾値未満であれば非類似とされる。

次に、４と３との比較により、両者のレスポンスが非類似の場合、４と２との比較が行われ（Ｓ４２０）、両者が類似している場合には、脆弱性なしと判定される（Ｓ４３０）。ユーザーＡになりすましたリクエストのレスポンスが、ユーザーＢのレスポンスに類似しているのであれば、ユーザーＡの個人情報は閲覧されていないので、認可制御が正しく機能していると考えられる。

４と２の比較により、両者のレスポンスが非類似の場合、４と１の比較が行われ（Ｓ４４０）、両者が類似している場合には、脆弱性の疑いがあると判定される（Ｓ４５０）。ユーザーＡになりすましたリクエストのレスポンスが、ユーザーＡのレスポンスに類似しているのであれば、ユーザーＡの個人情報が閲覧されることになるので、認可制御が正しく機能していないと考えられる。他方、４と１の比較により、両者のレスポンスが非類似であれば、脆弱性なしと判定される（Ｓ４６０）。

図５に戻り、診断結果出力部２３４は、脆弱性判定部２３２の判定結果に基づき診断結果を出力する。診断結果は、例えば、脆弱性診断装置２００の表示部等に出力される。診断結果は、例えば、図１０に示すようなリクエストの比較結果の詳細を含むものであってもよい。

このように本実施例によれば、ウェブサイトを巡回するときに、同時にウェブサイトの認可制御の脆弱性を自動的に診断するようにしたので、膨大なウェブサイトの脆弱性の診断を短時間で効果的に行うことができる。

上記実施例では、ユーザーＡとユーザーＢの認可制御を例示したが、一般ユーザーと管理ユーザーの権限をチェックすることも可能である。すなわち、以下のようにユーザーを割り当てることで、管理者と一般ユーザー間の認可制御を確認することが可能である。
ユーザーＡ＝一般ユーザー、ユーザーＢ＝管理ユーザー

また、ログインユーザーと非ログインユーザーの権限をチェックすることも可能である。すなわち、以下のようにユーザーを割り当てることで、ログインユーザーと非ログインユーザー間の認可制御を確認することが可能である。
ユーザーＡ＝非ログインユーザー、ユーザーＢ＝ログインユーザー

さらに上記実施例では、ユーザーＡ、ユーザーＢの認可制御を例示したが、これは一例であり、本発明は、３人以上の複数のユーザー間の認可制御の脆弱性診断にも適用することが可能である。

上記実施例では、ＨＴＭＬコンテンツの類似度（距離）を全ワード数に対する共通ワード数により算出したが、これは一例であり、他の算出方法を用いることも可能である。ＨＴＭＬ構造非依存のものには、ｂａｇ－ｏｆ－ｗｏｒｄｓ、Ｎ-ｇｒａｍ、潜在意味解析等の順序非依存や、ＷＭＤ、ｓｔｒ２ｖｅｃ、編集距離(ｓｔｒ)、構文を意味解析したときのノード間の編集距離（意味木構造編集距離）等の順序依存のものがある。また、ＨＴＭＬ構造依存のものには、編集距離（ｔａｇ）、木構造編集距離（ｔａｇ）などがある。勿論、これらの方法を組み合わせることも可能である。

以上、本発明の好ましい実施の形態について詳述したが、本発明は、特定の実施形態に限定されるものではなく、特許請求の範囲に記載された発明の要旨の範囲において、種々の変形、変更が可能である。

１００：脆弱性診断システム ２００：脆弱性診断装置
２１０：メイン部 ２１２：クロ―ラ部
２１４：ブラウザ制御部 ２１６：ブラウザ部
２１８：プロキシ部 ２２０：ＨＴＴＰリクエスト取得部
２２２：リクエスト比較部 ２２４：診断ＨＴＴＰリクエスト生成部
２２６：レスポンス取得部 ２２８：リクエスト組合せ生成部
２３０：レスポンス間類似度算出部 ２３２：脆弱性判定部
２３４：診断結果出力部 ３００：ネットワーク
４００：対象ウェブサイト

Claims (10)

1. 対象ウェブサイトの認可制御の脆弱性を診断する脆弱性診断装置であって、
   ウェブサイトを巡回する巡回手段であって、当該巡回手段は、予め用意された複数のユーザーのそれぞれのログイン情報を用いて対象ウェブサイトへのリクエストを作成し、当該リクエストを対象ウェブサイトに送信し、対象ウェブサイトからレスポンス情報を受信することで対象ウェブサイトを巡回する、前記巡回手段と、
   前記巡回手段によって対象ウェブサイトの巡回が行われたとき、対象ウェブサイトとの通信内容から対象ウェブサイトへの複数のユーザーのそれぞれのリクエストを取得する第１の取得手段と、
   前記第１の取得手段によって取得されたリクエストを比較し、相互にないＵＲＬを含むリクエストを抽出し、抽出したリクエストに対応する診断用リクエストと、エラーページを取得するための診断用リクエストと、他人に成りすますための診断用リクエストとを含む複数の診断用リクエストを生成する生成手段と、
   前記複数の診断用リクエストに対する複数のユーザーのレスポンス情報を対象ウェブサイトから取得する第２の取得手段と、
   対象ウェブサイトの各ユーザーの認可制御の脆弱性を診断するため、異なるユーザー間の診断用リクエストの組合せを生成し、当該組合せに対応するレスポンス情報の類似度を算出する算出手段と、
   前記算出手段により算出された類似度に基づき対象ウェブサイトの認可制御の脆弱性を診断する診断手段と、
   を有する脆弱性診断装置。
2. 前記生成手段は、ログインしているユーザーのセッションＩＤまたはクッキーを他のユーザーのセッションＩＤまたはクッキーに置き換えることによって、前記他人に成りすますための診断用リクエストを生成する、請求項１に記載の脆弱性診断装置。
3. 前記生成手段は、ＵＲＬに含まれる特定のパラメータに基づき抽出されたリクエストの名から特定のリクエストを選択し、選択したリクエストに基づき診断用リクエストを生成する、請求項１に記載の脆弱性診断装置。
4. 前記算出手段は、レスポンス情報に含まれるＨＴＭＬから文字列を抽出し、抽出された文字列の類似度を算出する、請求項１に記載の脆弱性診断装置。
5. 前記算出手段は、診断用リクエストのＵＲＬの特定の階層と共通する階層を有する別のユーザーの診断用リクエストの組合せを生成する、請求項１に記載の脆弱性診断装置。
6. 前記診断手段は、他人に成りすました診断用リクエストに対応するレスポンスと当該他人の診断用リクエストに対応するレスポンスとが類似している場合、対象ウェブサイトの認可制御に脆弱性があると判定し、類似していない場合、対象ウェブサイトの認可制御に脆弱性がないと判定する、請求項１に記載の脆弱性診断装置。
7. 前記診断手段は、ユーザーＢに成りすましたユーザーＡの診断用リクエストに対応する第１のレスポンスとエラーページのための診断用リクエストに対応する第２のレスポンスとを比較し、両者が類似している場合には、認可制御の脆弱性がないと判定し、両者が類似していない場合には、さらに第１のレスポンスとユーザーＢの診断用リクエストに対応する第３のレスポンスとを比較し、両者が類似している場合には、認可制御の脆弱性がないと判定し、類似していない場合には、さらに第１のレスポンスとユーザーＡの診断用リクエストに対応する第４のレスポンスとを比較し、両者が類似している場合には、認可制御の脆弱性があると判定し、類似していない場合には、認可制御の脆弱性がないと判定する、請求項１に記載の脆弱性診断装置。
8. 請求項１ないし７いずれか１つに記載の脆弱性診断装置と、当該脆弱性診断装置とネットワークを介して接続されたサーバーとを含む脆弱性診断システムであって、
   前記脆弱性診断装置は、ネットワークを介して前記サーバーの対象ウェブサイトをアクセスする、脆弱性診断システム。
9. 対象ウェブサイトの認可制御の脆弱性を診断する脆弱性診断装置における診断方法であって、
   前記脆弱性診断装置は、予め用意された複数のユーザーのそれぞれのログイン情報を用いて対象ウェブサイトへのリクエストを作成し、当該リクエストを対象ウェブサイトに送信し、対象ウェブサイトからレスポンス情報を受信することで対象ウェブサイトを巡回し、
   前記脆弱性診断装置は、対象ウェブサイトが自動的に巡回されるときに、対象ウェブサイトとの通信内容から対象ウェブサイトへの複数のユーザーのそれぞれのリクエストを取得し、
   前記脆弱性診断装置は、取得されたリクエストを比較し、相互にないＵＲＬを含むリクエストを抽出し、抽出したリクエストに対応する診断用リクエストと、エラーページを取得するための診断用リクエストと、他人に成りすますための診断用リクエストとを含む複数の診断用リクエストを生成し、
   前記脆弱性診断装置は、前記複数の診断用リクエストに対する複数のユーザーのレスポンスを対象ウェブサイトから取得し、
   前記脆弱性診断装置は、対象ウェブサイトの各ユーザーの認可制御の脆弱性を診断するため、異なるユーザー間の診断用リクエストの組合せを生成し、当該組合せに対応するレスポンス情報の類似度を算出し、
   前記脆弱性診断装置は、算出された類似度に基づき対象ウェブサイトの認可制御の脆弱性を診断する、
   脆弱性を診断する方法。
10. 対象ウェブサイトの認可制御の脆弱性を診断する脆弱性診断装置が実行する診断プログラムであって、
    予め用意された複数のユーザーのそれぞれのログイン情報を用いて対象ウェブサイトへのリクエストを作成し、当該リクエストを対象ウェブサイトに送信し、対象ウェブサイトからレスポンス情報を受信することで対象ウェブサイトを巡回し、
    対象ウェブサイトが自動的に巡回されるときに、対象ウェブサイトとの通信内容から対象ウェブサイトへの複数のユーザーのそれぞれのリクエストを取得し、
    取得されたリクエストを比較し、相互にないＵＲＬを含むリクエストを抽出し、抽出したリクエストに対応する診断用リクエストと、エラーページを取得するための診断用リクエストと、他人に成りすますための診断用リクエストとを含む複数の診断用リクエストを生成し、
    前記複数の診断用リクエストに対する複数のユーザーのレスポンスを対象ウェブサイトから取得し、
    対象ウェブサイトの各ユーザーの認可制御の脆弱性を診断するため、異なるユーザー間の診断用リクエストの組合せを生成し、当該組合せに対応するレスポンス情報の類似度を算出し、
    算出された類似度に基づき対象ウェブサイトの認可制御の脆弱性を診断する、
    診断プログラム。

Images