JP6942277B1 - セキュリティテストシステム - Google Patents

Abstract

【課題】アプリケーションのセキュリティの検証を、開発者が開発工程の中の一工程として組み込まれた「セキュリティテスト」として実施することを可能とする。【解決手段】ブラウザ２０上での対象アプリケーション４に対する操作による画面遷移の情報を記録する遷移記録部２１と、複数の画面遷移の情報をマージした遷移グラフをグラフＤＢ３７に遷移シナリオとして記録するシナリオ管理部３３と、遷移シナリオの内容に従って対象アプリケーション４に対してリクエストを送信する遷移再現部３４と、遷移再現部３４により送信されたリクエストを取得して、指定された脆弱性の検査パターンに従って内容を改変して対象アプリケーション４に対して送信し、受信したレスポンスの内容に基づいて脆弱性の有無を検査する診断処理部３５とを有する。【選択図】図１

Description

本発明は、アプリケーションの開発技術に関し、特に、アプリケーションの脆弱性を検査するセキュリティテストシステムに適用して有効な技術に関するものである。

昨今のアプリケーションやシステムではネットワークの利用がほぼ前提となっており、セキュリティの管理は重要な要件となっている。

アプリケーションやシステムにおけるセキュリティ管理の技術として、例えば、特開２００５−１３４９９５号公報（特許文献１）には、パラメータ名と検査項目との対応関係を定義した設定ファイルを保持し、検査対象となるパラメータが指定されると、設定ファイルに基づいてこれに対応する検査項目を特定して、当該パラメータに対して実行することで、システム管理者がプログラムレベルでセキュリティ対策の状況を把握することを可能とするセキュリティ管理システムが記載されている。

一方、このようなアプリケーションやシステムに対するセキュリティ管理を実施もしくは支援する仕組みに加えて、アプリケーションやシステムの開発段階においても、セキュリティホールや脆弱性等の有無を検査してこれを排除しておくことが求められている。この点、従来は、アプリケーションの開発工程（例えば、仕様策定→設計→実装→単体テスト→結合テスト→総合テスト）とは切り離された活動として、開発者や開発チームとは別の「セキュリティ診断士」のようなスペシャリストに依頼して診断を行ってもらい、セキュリティを担保するというのが通常であった。

特開２００５−１３４９９５号公報

アプリケーションの開発段階におけるセキュリティの担保を、「セキュリティ診断士」のようなスペシャリストに依頼して診断してもらうことには以下のような課題がある。すなわち、診断を行うスペシャリストや外部のベンダ等にスケジュールが依存してしまい、実施のスケジュールを自由にコントロールしにくい上に、リソースの状況によっては断られてしまい、診断すらできないこともある。

また、発注や作業依頼のためのオーバーヘッドコストが大きく、細かい単位で柔軟に診断を依頼することが難しいため、例えば、ある程度開発テーマがまとまったタイミングで実施することになり、診断未了のままアプリケーションがリリースされてしまう場合もある。さらに、アプリケーションの開発工程とは別工程となるため、開発者側によるアプリケーションの動作に係るテスト工程が完了してからセキュリティの診断を実施するケースも多く、問題が検知されるタイミングが遅くなってその分手戻りのリスクやコストも大きくなってしまう。

そこで本発明の目的は、アプリケーションの開発段階におけるセキュリティの担保を、アプリケーションの開発工程とは切り離された活動として「セキュリティ診断士」のようなスペシャリストが実施するのではなく、開発者や開発チームが一連の開発工程の中の一工程として組み込まれた「セキュリティテスト」として実施することを可能とするセキュリティテストシステムを提供することにある。

本発明の前記ならびにその他の目的と新規な特徴は、本明細書の記載および添付図面から明らかになるであろう。

本願において開示される発明のうち、代表的なものの概要を簡単に説明すれば、以下のとおりである。

本発明の代表的な実施の形態であるセキュリティテストシステムは、アプリケーションにおけるセキュリティの脆弱性の有無を検査するセキュリティテストシステムであって、ユーザによるブラウザ上での前記アプリケーションに対する操作により発生するリクエスト／レスポンスの情報を含む画面遷移の情報を記録する遷移記録部と、複数の前記画面遷移の情報をマージした遷移グラフをグラフ記録部に遷移シナリオとして記録するシナリオ管理部と、前記遷移シナリオの内容に従って前記アプリケーションに対してリクエストを送信する遷移再現部と、前記遷移再現部により送信されたリクエストを取得して、指定された脆弱性の検査パターンに従って当該リクエストの内容を改変して前記アプリケーションに対して送信し、前記アプリケーションから受信したレスポンスの内容に基づいて前記指定された脆弱性の有無を検査する診断処理部と、を有するものである。

本願において開示される発明のうち、代表的なものによって得られる効果を簡単に説明すれば、以下のとおりである。

すなわち、本発明の代表的な実施の形態によれば、アプリケーションの開発段階におけるセキュリティの担保を、開発者や開発チームが一連の開発工程の中の一工程として組み込まれた「セキュリティテスト」として実施することが可能となる。

本発明の一実施の形態であるセキュリティテストシステムの構成例について概要を示した図である。 本発明の一実施の形態におけるセキュリティテストのユースケースの例について概要を示した図である。 本発明の一実施の形態における遷移シナリオの管理の例について概要を示した図である。 本発明の一実施の形態における遷移シナリオの記録手法の例について概要を示したシーケンス図である。 本発明の一実施の形態における脆弱性検査結果を統合する例について概要を示した図である。 本発明の一実施の形態における脆弱性検査結果を統合する際のルールの例について概要を示した図である。 本発明の一実施の形態におけるブラウザに表示される画面の例について概要を示した図である。 本発明の一実施の形態におけるブラウザに表示される画面の他の例について概要を示した図である。

以下、本発明の実施の形態を図面に基づいて詳細に説明する。なお、実施の形態を説明するための全図において、同一部には原則として同一の符号を付し、その繰り返しの説明は省略する。一方で、ある図において符号を付して説明した部位について、他の図の説明の際に再度の図示はしないが同一の符号を付して言及する場合がある。

＜概要＞
本発明の一実施の形態であるセキュリティテストシステムは、アプリケーションやシステムの開発段階において、その開発工程の中の一工程として、開発者や開発チームが独自に「セキュリティテスト」を実施することを可能とする情報処理システムである。

これにより、例えば、開発チームにおいてテストの一つとして実施することができるため、外部のベンダ等の都合に合わせる必要がなく、開発の進捗に合わせてスケジュールを調整していつでもテストすることが可能となる。また、開発における内部プロセスとして実施するため、発注や作業依頼のためのオーバーヘッドコストがないことから、開発やリリースの単位に合わせた柔軟で細かい単位での実施が可能となり、セキュリティがチェックされていない（完了していない）状態でのリリースがされるのを防止することができる。さらに、モジュール間での機能疎通がとれるようになったタイミングで個々のモジュールごとにセキュリティテストを実施することが可能となるため、早期にテストを実施して問題を洗い出すことが可能となる。また、修正後の再確認もすぐに行えるため、問題発見→修正のサイクルを効率的に回してセキュリティを強固にしていくことが可能となる。

アプリケーションの開発工程にセキュリティテストを組み込むとした場合でも、例えば、開発チームにセキュリティの知識を持ったエンジニアがいない、もしくはそもそもセキュリティに取り組んだことがない、何らかのツールを用いるとしても、セキュリティエンジニア向けのツールでは開発チームで使いこなせない、ツールのコストが高いなど、通常は容易に組み込むことは難しい。

そこで本実施の形態では、セキュリティの知識をもったエンジニア向けではなく、「開発者」向けのセキュリティテストシステムとすることで、開発工程に容易に組み込むことを可能とするものである。具体的には、例えば、クラウドサービスとして実装することで、サーバ機器等のセットアップなどを必要とせずに、テストシナリオの登録から実行・結果確認までを開発者がブラウザで行うことができるようにする。そして、テストシナリオ（画面遷移）の登録やテストの実行について、画面遷移の部分単位で各開発者が柔軟に行えるようにするとともに、シナリオやテスト結果の情報を開発チームで共有できるようにすることで、必要な部分だけを必要なタイミングで対応可能な開発者がテストする等、効率的でスピーディーなテスト実施と管理を可能とするものである。

＜システム構成＞
図１は、本発明の一実施の形態であるセキュリティテストシステムの構成例について概要を示した図である。セキュリティテストシステム１は、例えば、サーバ機器やクラウドコンピューティングサービス上に構築された仮想サーバ等によりサーバシステムとして構成されたセキュリティテストサーバ３と、各開発者がそれぞれ使用するパーソナルコンピュータ（ＰＣ）等の情報処理端末であるユーザ端末２とからなり、これらが図示しないインターネットやＶＰＮ（Virtual Private Network）、ＬＡＮ（Local Area Network）などのネットワークを介して相互に接続される構成を有する。

そして、ユーザ端末２やセキュリティテストサーバ３は、それぞれ、図示しない開発用のサーバシステム等にアクセスして、開発中のアプリケーションやシステム、すなわちセキュリティテストの対象である対象アプリケーション４を実行させることができる。

ユーザ端末２は、例えば、ブラウザ２０を備え、開発者からの指示や操作に基づいて、ブラウザ２０を介して対象アプリケーション４を実行することができる。また、セキュリティテストサーバ３にアクセスして、対象アプリケーション４に係るセキュリティテストの実施やテストシナリオの登録、テスト結果の確認などを行うことができる。ブラウザ２０は、ユーザが拡張機能やアドオンを実装することができるＡＰＩ（Application Programming Interface）等のインタフェースを有するものであれば、一般的に用いられているＷｅｂブラウザを適宜使用することができる。以下では、特に断らない限りブラウザ２０としてＧｏｏｇｌｅ Ｃｈｒｏｍｅ（登録商標、以下同じ）を用いるものとして説明する。

ブラウザ２０は、拡張機能やアドオン（Ｇｏｏｇｌｅ Ｃｈｒｏｍｅの場合はＥｘｔｅｎｓｉｏｎｓ）として実装された遷移記録部２１を有する。遷移記録部２１は、ブラウザ２０上でユーザが対象アプリケーション４を実行・操作した際における、ブラウザ２０が送信したリクエストと受信したレスポンスの組合せを記録することで、ユーザによる操作や画面遷移を記録する機能を有する。記録した情報は、後述するセキュリティテストサーバ３に送られ、これに基づいて遷移シナリオが生成・登録される。なお、Ｗｅｂブラウザがアプリケーションとの間で授受するリクエストとレスポンスに基づいて画面遷移を記録し、さらに、記録したリクエストの内容を改変することで画面遷移や動作内容を変更する手法については、一般的なＷｅｂアプリケーションのテストツールにおいて広く用いられていることから、詳細な説明は行わない。

セキュリティテストサーバ３は、図示しないＣＰＵ（Central Processing Unit）により、ＨＤＤ（Hard Disk Drive）等の記録装置からメモリ上に展開したＯＳ（Operating System）、Ｗｅｂサーバ等のミドルウェアや、その上で稼働するソフトウェアを実行することで、開発チームによるセキュリティテストの実施に係る後述する各種機能を実現する。なお、本実施の形態では、セキュリティテストサーバ３は、クラウドコンピューティングサービス上に構築された仮想サーバにより実装するものとする。

このセキュリティテストサーバ３は、例えば、ソフトウェアにより実装されたＵＩ処理部３１、基盤機能部３２、シナリオ管理部３３、遷移再現部３４、診断処理部３５、およびテナント管理部３６などの各部を有する。また、データベースやファイル等により実装されたグラフデータベース（ＤＢ）３７、診断データＤＢ３８、およびユーザＤＢ３９などの各データストアを有する。

ＵＩ処理部３１は、例えば、図示しないＷｅｂサーバプログラムを介してユーザ端末２上のブラウザ２０からの要求を受け、後述するようなセキュリティテストに係る各種の管理画面やテストの実行に係る画面等をブラウザ２０に表示する機能を有する。基盤機能部３２は、セキュリティテストサーバ３での各種処理の際に各部により共通的に用いられる各種の基盤機能を提供する機能を有する。基盤機能としては、例えば、いわゆるＣＩ／ＣＤ（継続的インテグレーション／継続的デリバリー）環境、本システム自体のセキュリティ機能やログ管理機能などが含まれる。

シナリオ管理部３３は、例えば、ブラウザ２０により記録された画面遷移等に係る情報に基づいて、後述するように、対象アプリケーション４の画面遷移に係る構造を有向グラフ（遷移グラフ）として表現し、これをグラフＤＢ３７に保持する機能を有する。また、ユーザから指定された検査対象のＵＲＬ（Uniform Resource Locator）に対して、当該ＵＲＬに至る最適経路（遷移シナリオ）を遷移グラフに基づいて生成し、出力する機能を有する。

遷移再現部３４は、例えば、シナリオ管理部３３により生成された遷移シナリオに係るリクエストを生成して、対象アプリケーション４に対して送信することで画面遷移を再現する機能を有する。診断処理部３５は、例えば、セキュリティテストを実施する際に、遷移再現部３４が対象アプリケーション４に対して送信したリクエストをインターセプトして、ユーザに指定された１つもしくは複数のシグネチャ（検査対象の脆弱性ごとの検査のパターン）に従ってパラメータを書き換え、そのレスポンスを判定することで、セキュリティホールや脆弱性の有無を診断し、診断結果を診断データＤＢ３８に記録する機能を有する。

テナント管理部３６は、例えば、複数の開発者が共同もしくは分担してセキュリティテストを行えるようにするためのチームの管理やテナント（契約者）の管理を行う機能を有する。開発者やチーム、テナントの情報についてはユーザＤＢ３９に登録する。

＜ユースケース＞
図２は、本発明の一実施の形態におけるセキュリティテストのユースケースの例について概要を示した図である。検査対象の画面（ＵＲＬ）に対するセキュリティテストを実施するためには、検査対象の画面に実際に遷移する必要がある。本実施の形態では、まず、ユーザは、ブラウザ２０の拡張機能である遷移記録部２１により、検査対象の画面に至るまでのブラウザ２０上での操作をレコード（記録）することで、画面遷移の情報を登録する（Ｓ１）。一度登録した遷移情報は、他のユーザも含めて繰り返し再利用することができる。

その後、ユーザは、検査対象の画面（ＵＲＬ）と、シグネチャ（検査パターン）を選択してスキャン（脆弱性検査）を実行する（Ｓ２）。ここでは、セキュリティテストサーバ３の遷移再現部３４および診断処理部３５により、開発サーバ上の対象のＵＲＬにアクセスして、書き換えたリクエストを投げ続けることになる。

スキャンの実施後は、検知された脆弱性について、ユーザ（対象のテストを実施した者自身であってもよいし、開発チームのリーダーや担当者、上司等の承認権者であってもよい）がトリアージ（検査結果精査）を行う（Ｓ３）。すなわち、検知された脆弱性が誤検知によるものか否かの判定、および当該脆弱性に対する対応の要否の判定を行う。検査結果については、複数のユーザがそれぞれ行ったスキャン結果を統合・マージして一元的に管理するため、ユーザは、自身が一部の小さい単位のスキャンのみを行っていたとしても、全体の検査結果の一覧を見れば、自身が行ったスキャンの結果も含めて全体の状況を把握することができる。なお、トリアージを行うには一定の知識や経験が必要となるため、脆弱性の解説や、検知時のログ情報、過去のトリアージ時のコメント等の付随情報が重要となり、これらを当該脆弱性に関連付けて管理・提示できるようにするのが望ましい。

検知された脆弱性については、開発者がこれを修正する（Ｓ４）。修正後は、脆弱性が解消されていることを確認するため、ステップＳ２に戻って、スキャン以降の一連のステップを脆弱性が解消されるまで繰り返す。本実施の形態では、上述したように、スキャンの際に検査対象のＵＲＬとシグネチャを指定して、小さい単位でスキャンすることができるため、修正後のスキャンでは、修正した箇所だけに絞り込んでスキャンして効率的に確認することが可能である。

＜遷移シナリオ管理＞
図３は、本発明の一実施の形態における遷移シナリオの管理の例について概要を示した図である。上述の図２のステップＳ１においてブラウザ２０の遷移記録部２１によりレコードされた画面遷移の情報について、本実施の形態では、図３の左側の図に示すように、遷移中の各画面をノードとし、画面間の遷移をエッジとした有向グラフ（遷移グラフ）として表現し、グラフＤＢ３７に登録して保持する。このとき、例えば、「１」→「２」→「３」→「４」の経路の遷移と、「１」→「２」→「５」→「４」の経路の遷移における「１」、「２」、「４」のノードのように、複数のレコード結果において共通する画面については同一のノードにマージして表す。これにより、遷移した画面について遷移グラフ上のリンク（経路）をたどって当該画面をノードとして追加する（レコードする）ことで、リンク網が大きくなり、到達可能な検査対象のＵＲＬが増えていくことになる。

ユーザにより検査対象のＵＲＬが指定されると、セキュリティテストサーバ３のシナリオ管理部３３は、遷移グラフから最適経路を生成する。例えば、図３の左側の図の遷移グラフにおいて、検査対象のＵＲＬとして「９」のノード（画面）が指定された場合に、ここに至る最適経路として、「１」→「６」→「７」→「９」の経路を生成する。なお、この最適経路は、必ずしも最短経路であることを要するものではない。生成された経路が図３の右側の図に示すように遷移シナリオとなり、この遷移に従ってスキャン（脆弱性検査）が行われる。

なお、遷移シナリオには、画面遷移の経路に加えて、例えば、各画面間の遷移を発生させるために必要となる画面操作（アクション）をレコードした情報も含まれる。例えば、「１」の画面から「６」の画面に遷移させるためには、「詳細」をクリックした後、「ユーザ情報」のボタンをクリックするアクションが必要であることを示している。これらの情報は、例えば、ブラウザ２０が発生させるＤＯＭ（Document Object Model）のイベントや、ＸＰａｔｈ（XML Path Language）等により取得した当該画面のロケータ情報として表すことができる。

図４は、本発明の一実施の形態における遷移シナリオの記録手法の例について概要を示したシーケンス図である。まず、ユーザが、ブラウザ２０上で対象の画面（ＵＲＬ）に至るまで操作を行うことで、ブラウザ２０の拡張機能の遷移記録部２１が、対象の画面までの遷移を記録する（図中１）。遷移記録部２１は、シナリオ管理部３３に対して、記録した遷移がグラフＤＢ３７に登録されているか否かを確認する（図中２）。シナリオ管理部３３は、対象のＵＲＬに到達するまでの最適経路の遷移シナリオを生成して返却する（図中３）。

その後、ユーザが、ブラウザ２０上のローカル環境で、返却された遷移シナリオに基づいて画面遷移を再現できるか否かをテストし（図中４）、結果がＯＫの場合は、対象のＵＲＬまでの画面遷移をシナリオ管理部３３に対して本登録する（図中５）。シナリオ管理部３３では、遷移シナリオをグラフＤＢ３７に本登録した上で、これを遷移再現部３４に送信する（図中６）。そして、遷移再現部３４は、取得した遷移シナリオに基づいて対象アプリケーション４に対してリクエストを送信して画面遷移を再現できるか否かをテストする（図中７）。テストがＯＫの場合は、シナリオ管理部３３により、対象の遷移シナリオをスキャン可能であるとしてグラフＤＢ３７に登録する（図中８）。

その後、ユーザは、シナリオ管理部３３を介してブラウザ２０に一覧表示等されたスキャン可能なＵＲＬの中から検査対象のＵＲＬを選択し、シグネチャを指定してスキャンの実行を指示する（図中９）。シナリオ管理部３３では、指定されたＵＲＬに係る遷移シナリオを、グラフＤＢ３７に登録された遷移グラフに基づいて生成し、遷移再現部３４により対象アプリケーション４上で遷移シナリオに従った画面遷移を再現するとともに、診断処理部３５によりリクエストをインターセプトしてパラメータを書き換えることで、指定されたシグネチャに対する脆弱性検査を実行する（図中１０）。

＜脆弱性検査結果の統合＞
本実施の形態では、複数のユーザがそれぞれ個別に行った複数のスキャンの結果について、対象のＵＲＬ、指定したパラメータ、および検知された脆弱性の組み合わせを単位として、同様の結果があった場合でもこれらをマージすることで、一元的に管理する。これにより、各ユーザは、それぞれが小さい単位でスキャンを繰り返していたとしても、自身が行ったスキャンの結果も含めて開発チーム全体の検査結果の状況を把握することができる。

図５は、本発明の一実施の形態における脆弱性検査結果を統合する例について概要を示した図である。図中の左側では、対象のＵＲＬに対する「スキャン１」の結果として、「パラメータＡ」、「パラメータＢ」、および「パラメータＣ」を指定した場合に脆弱性が検知され、また、対象のＵＲＬに対する別の「スキャン２」の結果として、「パラメータＡ」を指定した場合に「スキャン１」と同様の脆弱性が検知され、「パラメータＢ」、および「パラメータＣ」を指定した場合には脆弱性は検知されなかったという例を示している。

本実施の形態では、これら「スキャン１」と「スキャン２」の検査結果を統合（マージ）して一元化する。図中の右側では、マージした検査結果の例を示しており、対象のＵＲＬについて「パラメータＡ」ではいずれのスキャンでも同様の脆弱性が検知されたことから、検査結果が「検知」と設定されていることを示している。

また、「パラメータＢ」では「スキャン１」で脆弱性が検知されたものの、その後の「スキャン２」では検知されず、その間に修正対応がされていた（例えば、いずれかのスキャン結果に対してこのようなコメントが残されていた等）ということで、検査結果が「対応済み」と設定されていることを示している。また、「パラメータＣ」では「スキャン１」で脆弱性が検知されたが、誤検知であると判断されている場合、その後の「スキャン２」で再度脆弱性が検知されたとしても、検査結果が自動的に「誤検知」と設定され、改めて検知結果を精査する必要がないことを示している。

図６は、本発明の一実施の形態における脆弱性検査結果を統合する際のルールの例について概要を示した図である。ここでは、同一のＵＲＬに対して同一のパラメータで行った２つの脆弱性検査の結果について、一方の結果に他方の結果をマージするときに脆弱性の検知状況をどのように設定するかの例を示している。なお、３つ以上の検査結果がある場合は、例えば、時系列に沿って過去の検査結果から１つずつ順にマージしていくことで最終的に全ての検査結果をマージすることができる。

図示するように、本実施の形態では、「検知」、「受容」、「誤検知」、「確認待ち」、および「対応済み」の５つの検知状況の遷移によって管理する。概ね、「検知」は脆弱性が検知されている状況、「受容」は当該脆弱性の存在を受け入れた状況、「誤検知」は検知されていた脆弱性が誤検知であったという状況、「確認待ち」は検知された脆弱性に対して修正等がなされたため検知されなくなったという状況において、脆弱性が実際に解消したか否かを確認中である状況、「対応済み」は脆弱性が解消したことが確認できた状況であることを示している。

なお、複数の検査結果をマージするには、それぞれのＵＲＬが同一であることが必要となり、ＵＲＬの同一性が問題となるが、ＵＲＬが僅かに相違するだけで実質的には同一の画面であるということもある。したがって、実質的に同一であるＵＲＬを名寄せするためのルールや条件を設定できるようにしてもよい。

＜ユーザインタフェース＞
本実施の形態では、セキュリティテストサーバ３のＵＩ処理部３１によりブラウザ２０に表示される画面（ＵＩ）として、ＳＰＡ（Single Page Application）として実装され、主に複数の情報の一覧的な表示や、各種の設定を行う画面を表示するメインＵＩと、ブラウザ２０の拡張機能により、主に一覧から選択された個別の事項の詳細な情報や、画面遷移の記録に係る内容を表示するサブＵＩを有する。

メインＵＩでは、例えば、テナント（契約）単位での情報と、開発チーム単位での情報、さらにチーム内の個人の単位での情報を表示する。テナント単位では、例えば、テナント内での開発チームの管理（チームの作成・削除・アーカイブなど）や、テナントの設定（請求・課金管理、テナント内で共通の設定など）に係る画面を表示する。また、個人単位では、例えば、個人設定（表示名やアイコン等の変更など）やパスワードの変更などを行う画面を表示する。

開発チーム単位では、例えば、検査対象となるＵＲＬの一覧、スキャン結果の一覧などの画面を表示する。開発チームに係る各種の設定や、チームに所属するメンバーの管理を行う画面を表示してもよい。また、対象の開発チームについてのテスト状況等を示すダッシュボード画面を表示してもよい。

図７は、本発明の一実施の形態におけるブラウザ２０に表示される画面の例について概要を示した図である。図７では、検査対象のＵＲＬの一覧表示の例を示している。例えば、検査対象のＵＲＬの一覧からユーザにより選択されたＵＲＬについて、右側に表示されたサイドパネルにより詳細情報をシームレスに表示する。サイドパネルに表示する詳細情報としては、図示するものの他に、例えば、ＵＲＬの詳細（ＵＲＬの名称やカテゴリ等）、リクエスト／レスポンス（ＵＲＬのリクエスト／レスポンスのパラメータ一覧）、当該ＵＲＬに到達するための遷移シナリオ（例えば、図３の例に示したような図）、関連ＵＲＬ（検査対象のＵＲＬからリンクされているＵＲＬの一覧）などが含まれる。

図８は、本発明の一実施の形態におけるブラウザ２０に表示される画面の他の例について概要を示した図である。図８では、脆弱性検査（スキャン）の結果一覧の例を示している。例えば、検知された脆弱性の一覧からユーザにより選択された脆弱性について、右側に表示されたサイドパネルにより詳細情報をシームレスに表示する。サイドパネルに表示する詳細情報としては、図示するように、例えば、脆弱性の情報（脆弱性の説明や対応方法）、検知の詳細内容（実際に検査を行った際のリクエスト／レスポンス）、トリアージの内容（過去の検知結果や精査の判定結果、コメント等）などが含まれる。

サブＵＩでは、例えば、ユーザがブラウザ２０上で開いている画面に関連した情報を、ユーザが使用中の開発者ツール（例えば、Ｇｏｏｇｌｅ Ｃｈｒｏｍｅの場合はＤｅｖＴｏｏｌｓ）上に表示する。これにより、当該ユーザは対象アプリケーション４の開発中にシームレスにこれらの情報にアクセスしたり操作したりすることができ、生産性を向上させることができる。サブＵＩで表示する内容は、サブＵＩ（ブラウザ拡張機能）に固有の機能である画面遷移のレコード機能に係る内容以外は、基本的に上述したメインＵＩにおいてサイドパネルに表示する内容と同様である。したがって、例えば、表示に係る各パーツをコンポーネントとして構成することで、メインＵＩ（ＳＰＡ）とサブＵＩ（ブラウザ拡張機能）とで可能な限りパーツを共用することが望ましい。

なお、サブＵＩ（ブラウザ拡張機能）に固有の機能である画面遷移のレコード機能に係る内容を除き、他のユーザインタフェースに係る構成については、上述した構成に限られず、要件や制約等に応じて適宜の構成とすることができる。例えば、本実施の形態では、メインＵＩをＳＰＡとして実装するものとしているが、他の実装方式であってもよい。

以上に説明したように、本発明の一実施の形態であるセキュリティテストシステム１によれば、「セキュリティテスト」を開発工程に容易に組み込んで、開発者や開発チームが独自に行うことが可能となる。具体的には、各開発者が行ったスキャンの結果を統合・マージして一元的に管理するため、各開発者がそれぞれ一部の小さい単位のスキャンのみを行っていたとしても、全体の検査結果の一覧を見ることで、自身が行ったスキャンの結果も含めて全体の状況を把握することが可能となる。

また、画面遷移のシナリオの登録に際して、各開発者がブラウザ２０上で行った操作と画面遷移を、ブラウザ２０の拡張機能として実装される遷移記録部２１により記録し、有向グラフとして管理する。これにより、他の開発者が登録したものも含む既存の画面遷移を再利用することが可能となり、画面遷移の任意の箇所から柔軟に画面遷移を記録することができるとともに、スキャンについても一部の小さい単位に絞り込んで繰り返しスキャンするということが可能となる。すなわち、対象アプリケーション４のうち必要な部分だけを必要なタイミングで対応可能な開発者がテストする等、効率的でスピーディーなテスト実施と管理が可能となる。

以上、本発明者によってなされた発明を実施の形態に基づき具体的に説明したが、本発明は上記の実施の形態に限定されるものではなく、その要旨を逸脱しない範囲で種々変更可能であることはいうまでもない。

なお、上記の実施の形態は本発明を分かりやすく説明するために詳細に説明したものであり、必ずしも説明した全ての構成を備えるものに限定されるものではない。また、上記の実施の形態の構成の一部について、他の構成の追加・削除・置換をすることが可能である。

例えば、、図７の例の検査対象のＵＲＬの一覧や、図８の例の脆弱性検査（スキャン）の結果一覧において、各ＵＲＬに対して、ユーザがスキャンを実行する前、又は、実行してスキャン結果を参照した際などに、対象ＵＲＬに開発バージョン番号（開発内容を特定する番号）を入力し、各ＵＲＬのスキャン結果と開発バージョン番号を関連付けて記録するような構成としてもよい。これにより、ユーザは、開発バージョン番号から、各スキャン結果や対象ＵＲＬを検索して表示することも可能となる。

また、本実施の形態では、画面遷移の情報を有向グラフとして保持するものとしているが、同様の機能を実現できる他の方式により保持するものであってもよい。

また、上記の各構成、機能、処理部、処理手段等は、それらの一部または全部を、例えば、集積回路で設計する等によりハードウェアで実現してもよい。また、上記の各構成、機能等は、プロセッサがそれぞれの機能を実現するプログラムを解釈し、実行することによりソフトウェアで実現してもよい。各機能を実現するプログラム、テーブル、ファイル等の情報は、メモリやハードディスク、ＳＳＤ（Solid State Drive）等の記録装置、またはＩＣカード、ＳＤカード、ＤＶＤ等の記録媒体に置くことができる。

また、上記の各図において、制御線や情報線は説明上必要と考えられるものを示しており、必ずしも実装上の全ての制御線や情報線を示しているとは限らない。実際にはほとんど全ての構成が相互に接続されていると考えてもよい。

本発明は、アプリケーションの脆弱性を検査するセキュリティテストシステムに利用可能である。

１…セキュリティテストシステム、２…ユーザ端末、３…セキュリティテストサーバ、４…対象アプリケーション、
２０…ブラウザ、２１…遷移記録部、
３１…ＵＩ処理部、３２…基盤機能部、３３…シナリオ管理部、３４…遷移再現部、３５…診断処理部、３６…テナント管理部、３７…グラフＤＢ、３８…診断データＤＢ、３９…ユーザＤＢ

Claims (4)

1. アプリケーションにおけるセキュリティの脆弱性の有無を検査するセキュリティテストシステムであって、
   ユーザによるブラウザ上での前記アプリケーションに対する操作により発生するリクエスト／レスポンスの情報を含む画面遷移の情報を記録する遷移記録部と、
   複数のユーザによりそれぞれ記録された前記画面遷移の情報をマージした遷移グラフをグラフ記録部に遷移シナリオとして記録するシナリオ管理部と、
   前記遷移シナリオの内容に従って前記アプリケーションに対してリクエストを送信する遷移再現部と、
   前記遷移再現部により送信されたリクエストを取得して、指定された脆弱性の検査パターンに従って当該リクエストの内容を改変して前記アプリケーションに対して送信し、前記アプリケーションから受信したレスポンスの内容に基づいて前記指定された脆弱性の有無を検査する診断処理部と、を有し、
   前記診断処理部は、
   検査結果に対してユーザから指定されたコメントを当該検査結果に関連付けて記録し、
   同一の検査対象の画面に対する複数のユーザによる検査結果について、リクエストにおけるパラメータの内容と、検知された脆弱性の組み合わせの単位で、検査結果の状況の遷移に基づいて、検査結果を１つにマージし、診断データ記録部に記録する、セキュリティテストシステム。
2. 請求項１に記載のセキュリティテストシステムにおいて、
   前記シナリオ管理部は、前記遷移グラフ中においてユーザに指定された、画面遷移の中途のものも含む検査対象の画面に対して、前記遷移グラフ上での前記検査対象の画面に至る最適経路に基づいて生成した画面遷移の情報を遷移シナリオとして出力する、セキュリティテストシステム。
3. 請求項１又は２に記載のセキュリティテストシステムにおいて、
   前記診断処理部は、
   同一の検査対象の画面に対する複数の検査結果のうち、最初の第１の検査結果において、前記指定された脆弱性が検知された場合に、検査結果を前記指定された脆弱性が検知された旨を示す第１の状況とし、その後の第２の検査結果において前記指定された脆弱性が検知されなかった場合に、検査結果を前記指定された脆弱性が解消したか否かを確認中である旨を示す第２の状況とし、その後の第３の検査結果において前記指定された脆弱性が検知されず、解消したことが確認された旨の指定がされている場合に、検査結果を前記指定された脆弱性に対する対応が完了した旨を示す第３の状況とする、セキュリティテストシステム。
4. 請求項１ないし３のいずれか１項に記載のセキュリティテストシステムにおいて、
   前記遷移記録部は、
   前記ブラウザの拡張機能として構成される、セキュリティテストシステム。

Images