特許 7580005 セキュリティテストシステム

(19)【発行国】日本国特許庁(JP)

(12)【公報種別】特許公報(B1)

(11)【特許番号】

(24)【登録日】2024-10-30

(45)【発行日】2024-11-08

(54)【発明の名称】セキュリティテストシステム

(51)【国際特許分類】

   G06F 21/57 20130101AFI20241031BHJP

【ＦＩ】

G06F21/57 370

【請求項の数】 4

(21)【出願番号】P 2024096407

(22)【出願日】2024-06-14

【審査請求日】2024-06-17

【早期審査対象出願】

(73)【特許権者】

【識別番号】308020663

【氏名又は名称】株式会社ユービーセキュア

(74)【代理人】

【識別番号】100216677

【弁理士】

【氏名又は名称】坂次 哲也

(72)【発明者】

【氏名】山口 聖

(72)【発明者】

【氏名】岡島 未来

(72)【発明者】

【氏名】筧 賢太

【審査官】青木 重徳

(56)【参考文献】

【文献】特許第７４８８９７６（ＪＰ，Ｂ１）

【文献】特許第７４６４８０４（ＪＰ，Ｂ１）

【文献】特開２０１２－０７８８７７（ＪＰ，Ａ）

【文献】特開平０８－３３９２５０（ＪＰ，Ａ）

【文献】中国特許出願公開第１０６６５３０１１（ＣＮ，Ａ）

【文献】大規模言語モデル（ＬＬＭ）とは？ 仕組み・種類・活用サービスをわかりやすく解説，Ismiley ［オンライン］，2024年05月30日，（２０２４年 ７月 ２日 検索）、インターネット，<URL: https://aismiley.co.jp/ai_news/what-is-large-language-models/>

(58)【調査した分野】(Int.Cl.，ＤＢ名)

Ｇ０６Ｆ ２１／５７

(57)【特許請求の範囲】

【請求項1】

Ｗｅｂアプリケーションにおけるセキュリティの脆弱性の有無を検査するセキュリティテストシステムであって、
検査対象の前記Ｗｅｂアプリケーション内の巡回対象のＷｅｂページを取得して解析し、取得した前記Ｗｅｂページの内容に係る情報をプロンプトに設定してＬＬＭ（大規模言語モデル）に入力して、前記Ｗｅｂページに係る第１の操作手順情報を作成させ、
前記第１の操作手順情報に従って前記Ｗｅｂページに係る操作をシミュレートして、前記Ｗｅｂページ内のリンクに係るＵＲＬを取得して巡回対象ページリストに登録し、
前記巡回対象ページリストに登録された各Ｗｅｂページを巡回して作成されたページリストに登録された各ＷｅｂページついてＤＡＳＴ（Dynamic Application Security Testing）の手法による脆弱性の検査を実施する、セキュリティテストシステム。

【請求項2】

請求項１に記載のセキュリティテストシステムにおいて、
前記Ｗｅｂページにおける過去の巡回時の結果と、対象の巡回時の内容をプロンプトに設定して前記ＬＬＭに入力して、前記Ｗｅｂページの挙動に変化が生じると推測されるか否かについて判定し、
前記Ｗｅｂページの挙動に変化があると推測される場合、前記対象の巡回の操作に係る前記Ｗｅｂページを前記巡回対象ページリストに登録する、セキュリティテストシステム。

【請求項3】

請求項１に記載のセキュリティテストシステムにおいて、
前記ＬＬＭにより作成させた前記第１の操作手順情報に加えて、
前記Ｗｅｂページに係る解析結果から、所定のルールに基づいて、前記Ｗｅｂページに係る第２の操作手順情報を作成し、
前記第２の操作手順情報に従って前記Ｗｅｂページに係る操作をシミュレートして、前記Ｗｅｂページ内のリンクに係るＵＲＬを取得して前記巡回対象ページリストに登録する、セキュリティテストシステム。

【請求項4】

Ｗｅｂアプリケーションにおけるセキュリティの脆弱性の有無を検査するセキュリティテストシステムであって、
検査対象の前記Ｗｅｂアプリケーション内の巡回対象のＷｅｂページを取得して解析し、取得した前記Ｗｅｂページの内容に係る情報をプロンプトに設定してＬＬＭ（大規模言語モデル）に入力して、前記Ｗｅｂページに係る第１の操作手順情報を作成させ、
前記第１の操作手順情報に従って前記Ｗｅｂページに係る操作をシミュレートして、当該シミュレートの結果を前記ＬＬＭに入力して前記第１の操作手順情報を修正させ、
前記修正させた第１の操作手順情報に従って前記Ｗｅｂページに係る操作をシミュレートして、前記Ｗｅｂページ内のリンクに係るＵＲＬを取得して巡回対象ページリストに登録し、
前記巡回対象ページリストに登録された各Ｗｅｂページを巡回して作成されたページリストに登録された各ＷｅｂページついてＤＡＳＴ（Dynamic Application Security Testing）の手法による脆弱性の検査を実施する、セキュリティテストシステム。

【発明の詳細な説明】

【技術分野】

【0001】

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

【背景技術】

【0002】

Ｗｅｂアプリケーションはネットワークの利用が前提であり、セキュリティの観点から脆弱性の有無を検査・テストすることは非常に重要である。Ｗｅｂアプリケーションの脆弱性の有無を検査するツールやサービスは各種のものが利用可能であり、検討・開発も日々行われている。

【0003】

Ｗｅｂアプリケーションのセキュリティテストの手法は、大きくＳＡＳＴ（Static Application Security Testing）と、ＤＡＳＴ（Dynamic Application Security Testing）に分けられる。ソースコード等を静的に分析するＳＡＳＴに対して、ＤＡＳＴでは、稼働しているアプリケーションに対して、攻撃者の視点を踏まえて疑似的な攻撃（検査）リクエストを送信し、アプリケーションの挙動の変化から脆弱性があるかどうかを判定する。したがって、ＤＡＳＴによるセキュリティテストの仕組みでは、Ｗｅｂアプリケーションにおいて攻撃（検査）の対象とするページを特定する必要があり、そのために対象のＷｅｂアプリケーション（Ｗｅｂサイト）を自動もしくは手動により巡回してリンク等の構成を解析して、ページの情報を収集することが行われる。

【0004】

このようなＷｅｂサイトの自動巡回に関する技術として、例えば、特許第７３２０２１１号公報（特許文献１）には、Ｗｅｂサイトの脆弱性検査において、Ｗｅｂサイトを自動巡回する際に、ＡＩ（Artificial Intelligence）を利用し、脆弱性の検査が必要な検査必要機能を判定し、Ｗｅｂページにおいて実行可能な複数の実行可能操作と検査必要機能との関連度を判定して、関連度が高いものとして特定された操作を優先して実行することが記載されている。

【先行技術文献】

【特許文献】

【0005】

【文献】特許第７３２０２１１号公報

【発明の概要】

【発明が解決しようとする課題】

【0006】

上記の従来技術によれば、Ｗｅｂサイトの自動巡回の際、各Ｗｅｂページにおいて実行可能な複数の操作のうち、優先度の高い操作から実行して巡回することができるため、例えば、自動巡回するＷｅｂページの数や階層数、経過時間等により上限が設定されているような場合でも、重要な機能の検査漏れを抑制することができるとされている。

【0007】

しかしながら、Ｗｅｂサイトには、特定の操作を実施した後でなければ次の操作を行うことができないというように、順序性がある操作を含むケースがある。例えば、ＥＣ（Electronic Commerce）サイトにおいて、注文者の住所を入力しなければ注文画面に遷移できないケースや、カートに商品を追加しなければ注文画面に遷移できないケース等があり、このようなケースでは適切な手順で操作しなければ通信が発生しない。したがって、各Ｗｅｂページにおいて実行可能な操作を漏れなく把握するためには、Ｗｅｂサイトの機能を正しく理解し、適切な手順で操作をシミュレートすることが必要となる。

【0008】

この点につき、例えば、どのような場合にどのような順序で操作を行う必要があるかのパターンを全て網羅して事前にルールとして定めておくことは難しい。一方で、形式上取り得るすべての操作を総当たり的に試せば、理論上は適切な操作手順を把握することが可能である。しかしながら、Ｗｅｂページの規模や複雑さによっては試さなければならない操作手順の組合せが膨大な数になってしまい、現実的な時間で操作をシミュレートすることは困難となる。

【0009】

そこで本発明の目的は、順序性がある操作を含むＷｅｂサイトに対して適切な操作手順を把握して効率的・効果的に自動巡回を行うセキュリティテストシステムを提供することにある。

【0010】

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

【課題を解決するための手段】

【0011】

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

【0012】

本発明の代表的な実施の形態であるセキュリティテストシステムは、Ｗｅｂアプリケーションにおけるセキュリティの脆弱性の有無を検査するセキュリティテストシステムであって、検査対象の前記Ｗｅｂアプリケーション内の巡回対象のＷｅｂページを取得して解析し、取得した前記Ｗｅｂページの内容に係る情報をプロンプトに設定してＬＬＭ（大規模言語モデル）に入力して、前記Ｗｅｂページに係る第１の操作手順情報を作成させ、前記第１の操作手順情報に従って前記Ｗｅｂページに係る操作をシミュレートして、前記Ｗｅｂページ内のリンクに係るＵＲＬを取得して巡回対象ページリストに登録するものである。

【発明の効果】

【0013】

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

【0014】

すなわち、本発明の代表的な実施の形態によれば、Ｗｅｂサイトの脆弱性の検査の仕組みにおいて、順序性がある操作を含むＷｅｂサイトに対して適切な操作手順を把握して効率的・効果的に自動巡回を行うことが可能となる。

【図面の簡単な説明】

【0015】

【図1】本発明の一実施の形態であるセキュリティテストシステムの構成例について概要を示した図である。

【図2】本発明の一実施の形態における自動巡回処理の流れの例について概要を示したフローチャートである。

【図3】本発明の一実施の形態における巡回対象ページリストの具体的な例について概要を示した図である。

【図4】本発明の一実施の形態におけるＷｅｂページの例について概要を示した図である。

【図5】本発明の一実施の形態におけるＷｅｂページの他の例について概要を示した図である。

【図6】本発明の一実施の形態におけるＬＬＭを利用した操作手順書の作成の例について概要を示した図である。

【図7】本発明の一実施の形態における巡回対象ページリストの他の具体的な例について概要を示した図である。

【図8】本発明の一実施の形態におけるＬＬＭを利用した再巡回が必要なＷｅｂページの判定の例について概要を示した図である。

【図9】本発明の一実施の形態におけるＬＬＭを利用した再巡回が必要なＷｅｂページの判定の例について概要を示した図である。

【図10】本発明の一実施の形態における巡回対象ページリストのデータ構成の例について概要を示した図である。

【発明を実施するための形態】

【0016】

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

【0017】

＜概要＞
ＤＡＳＴによるＷｅｂサイトのセキュリティテストでは、対象Ｗｅｂサイトの巡回により、公開されているＵＲＬ（Uniform Resource Locator）（すなわち検査対象のＵＲＬ）を全て見つけ出す必要がある（なお、より正確には、発生する通信の全てではなく、入出力部分の処理が共通しているＵＲＬについては、各ＵＲＬをそれぞれ検査しても結果が変わらないため、少なくとも１つのＵＲＬを検査（巡回）できればよく、入出力部分の処理が異なるＵＲＬの全てということになる）。

【0018】

ＵＲＬを見つけ出すには、ＷｅｂサイトのＨＴＭＬ（HyperText Markup Language）を解析する静的な手法や、Ｗｅｂサイトでの実際の操作をシミュレートして発生した通信を収集する動的な手法がある。後者の手法をとる場合、上述したように、Ｗｅｂサイトには、順序性のある操作を含み、特定の操作を実施した後でなければ次の操作を行うことができず、適切な手順で操作しなければ通信が発生しないというケースがある。したがって、実際の操作をシミュレートするには、Ｗｅｂサイトの機能を正しく理解し、適切な手順で操作をシミュレートすることが必要となる。

【0019】

この点につき、例えば、どのような場合にどのような順序で操作を行う必要があるかのパターンを全て網羅して事前にルールとして定めておくことは難しい。一方で、形式上取り得るすべての操作を総当たり的に試せば、理論上は適切な操作手順を把握することが可能である。しかしながら、Ｗｅｂページの規模や複雑さによっては試さなければならない操作手順の組合せが膨大な数になってしまい、現実的な時間で操作をシミュレートすることは困難となる。

【0020】

ここで、上述したような順序性のある操作を含むＷｅｂサイトには、Ｗｅｂページ内で複数の操作を適切な順序で行う必要があるものと、複数Ｗｅｂページを跨いで適切な順序で操作を行う必要があるものの２つのタイプのＷｅｂページが含まれ得る。

【0021】

Ｗｅｂページ内で複数の操作を適切な順序で行う必要があるタイプとしては、例えば、ＥＣサイトでの商品の届け先住所を登録する画面において、名前や住所の欄に入力せずに「登録」ボタンを押下しても、名前や住所を入力させる旨のエラーが発生して、登録完了画面に遷移できない（登録完了画面に遷移するためには、「登録」ボタンを押下する前に名前や住所を入力する操作をしなければならない）というようなケースがある。

【0022】

また、複数Ｗｅｂページを跨いで適切な順序で操作を行う必要があるタイプとしては、例えば、ＥＣサイトでカートに商品を追加する前にカート画面に移動した場合には、カートが空であるため「レジに進む」ボタンが表示されず、注文画面に進むことができないが、商品をカートに追加してからカート画面に移動すると、カートに商品があるため「レジに進む」ボタンを押下して注文画面に進むことができるというようなケースがある。

【0023】

本発明の一実施の形態であるセキュリティテストシステムでは、前者のＷｅｂページ内で複数の操作を適切な順序で行う必要があるタイプのＷｅｂページへの対応として、どのような場合にどのような順序で操作を行うかを予め定めておいたルールに基づいて適切な操作手順を得る手法（従来の手法）に加えて、もしくはこれに代えて、ＣｈａｔＧＰＴ（登録商標）等の生成ＡＩ・大規模言語モデル（Large Language Models）（以下「ＬＬＭ」と総称する場合がある）を利用して、人間が操作した場合の内容に近い操作手順を得る手法を用いて、適切な操作手順（操作手順書）を作成する。

【0024】

また、後者の複数Ｗｅｂページを跨いで適切な順序で操作を行う必要があるタイプのＷｅｂページへの対応として、対象のＷｅｂページについて過去に巡回したときと現在再度巡回したときとの間で挙動に変化が生じると推測されるか否かをＬＬＭによって判定し、変化が生じると推測された場合には同じＵＲＬでも操作手順が異なるとして個別に巡回（検査）の対象とする。なお、後述するように、本実施の形態では、異なるＵＲＬであるが実質的に同一であるＷｅｂページをグルーピングして取り扱うことで、巡回対象のＷｅｂページを実質的に削減し、巡回や検査の処理の効率化を図っているが、同一のＵＲＬでも過去の巡回時と挙動に変化があるとして個別に巡回対象とすると判断されたＷｅｂページについてはグルーピングの対象から外して再巡回の対象とする。

【0025】

＜システム構成＞
図１は、本発明の一実施の形態であるセキュリティテストシステムの構成例について概要を示した図である。セキュリティテストシステム１は、例えば、サーバ機器やクラウドコンピューティングサービス上に構築された仮想サーバ等により構成され、これにユーザが使用するＰＣ（Personal Computer）等のユーザ端末２が、図示しないインターネットやＶＰＮ（Virtual Private Network）、ＬＡＮ（Local Area Network）などのネットワークを介して、図示しないＷｅｂブラウザや専用のアプリケーション等を利用してアクセスする構成を有する。

【0026】

セキュリティテストシステム１は、例えば、図示しないＣＰＵ（Central Processing Unit）により、ＨＤＤ（Hard Disk Drive）やＳＳＤ（Solid State Drive）等の記録装置からメモリ上に展開したＯＳ（Operating System）やＤＢＭＳ（DataBase Management System）、Ｗｅｂサーバプログラム等のミドルウェアや、その上で稼働するソフトウェアを実行することで、セキュリティテストの実施に係る各種機能を実現する。このセキュリティテストシステム１は、例えば、ソフトウェアにより実装された検査管理部１１、巡回処理部１２、および検査実施部１３などの各部を有する。また、データベースやファイルテーブル等により実装された巡回対象ページリスト１４、操作手順書作成ルール１５、ページリスト１６、検査結果１７などの各データストアを有する。

【0027】

検査管理部１１は、例えば、ユーザ端末２を介して検査対象となる対象Ｗｅｂサイト３に係る情報の入力や設定をユーザから受け付けたり、検査の実施に係る各種の設定や指示等の入力を受け付けたり、検査の実施結果である検査結果１７に基づいてレポートを作成してユーザ端末２を介してユーザに提示したり等、脆弱性検査に係る管理機能やユーザインタフェースの機能を有する。

【0028】

巡回処理部１２は、例えば、ユーザから指定された対象Ｗｅｂサイト３について自動で巡回し、検出したＷｅｂページについて巡回対象ページリスト１４に登録するとともに、最終的に検査対象となるＷｅｂページを含むページリスト１６を作成する機能を有する。その際、上述したように、対象Ｗｅｂサイト３に含まれる順序性のある操作を含むＷｅｂページについて、操作手順書作成ルール１５やＬＬＭ４を利用して適切な操作手順を把握して、対象のＷｅｂページについての操作手順書を作成する。巡回処理部１２の処理内容の詳細については後述する。

【0029】

検査実施部１３は、例えば、ページリスト１６に登録されている各Ｗｅｂページについて、ＤＡＳＴの手法による脆弱性の検査を実施する機能を有する。すなわち、対象の各Ｗｅｂページについて、対象Ｗｅｂサイト３にリクエストを送信する際にフォームに不正な値を入力する等により擬似的な攻撃リクエストとして送信する。そして、対象Ｗｅｂサイト３からのレスポンスについて通常と異なる応答であるか否かを解析して脆弱性の有無を判定するとともに、判定結果を検査結果１７に記録する。

【0030】

＜処理の流れ＞
図２は、本発明の一実施の形態における巡回処理部１２による自動巡回処理の流れの例について概要を示したフローチャートである。自動巡回処理を開始すると、巡回処理部１２では、まず、ユーザから指定された対象Ｗｅｂサイト３の開始ページを取得して巡回対象ページリスト１４に登録する（Ｓ０１）。そして、自動巡回の終了条件に該当するか否かを判定する（Ｓ０２）。例えば、巡回対象ページリスト１４が空であるか、もしくは巡回したページ数が予め設定された上限値に到達したか、もしくは巡回開始からの経過時間が予め設定されたタイムアウト時間に到達したかのいずれかに該当した場合に、終了条件に該当したものと判定し（ステップＳ０２でＹｅｓ）、自動巡回処理を終了する。

【0031】

終了条件に該当していない場合（ステップＳ０２でＮｏ）、巡回対象ページリスト１４に基づいて、未巡回のものの中から巡回対象のＷｅｂページ（ＵＲＬ）を決定し（Ｓ０３）、対象Ｗｅｂサイト３の当該ページにアクセスし、当該ページを解析する（Ｓ０４）。

【0032】

図３は、本発明の一実施の形態における巡回対象ページリスト１４の具体的な例について概要を示した図である。リスト中のＵＲＬのうち、巡回ステータスが「巡回済み」のものについては、すでに巡回しているため巡回対象外となる。また、巡回ステータスが「○○と類似ＵＲＬ」のものについては、「巡回済み」のＵＲＬと類似するため巡回対象外となる（上述したように、本実施の形態では、異なるＵＲＬであるが実質的に同一であるＷｅｂページをグルーピングして取り扱うことで、巡回対象のＷｅｂページの削減を図っている）。図３の例で、次に巡回対象となるＵＲＬは、例えば、巡回ステータスが「未巡回」のもののうち先に見つかったものとして、「Ｎｏ．６」のＵＲＬとなる。

【0033】

図２に戻り、対象のＷｅｂページを静的に解析した上で（Ｓ０４）、適切な操作手順についてルールベースでの操作手順書を作成する（Ｓ０５）。本実施の形態において、操作手順書とは、対象のＷｅｂページ（ＵＲＬ）における１つ以上の操作内容の情報を含んで構成されるデータを示す（便宜上「操作手順『書』」としているが実体はデータ（操作手順情報）である）。操作手順書は、１つのＷｅｂページに対して複数存在する場合があり、シミュレーション時に操作手順書間で操作内容が干渉しないよう、１つの操作手順書の操作内容の実行を完了すると、次の操作手順書の操作の実行に移る前に対象のＷｅｂページを再読み込みする。

【0034】

ルールベースでの操作手順書の作成方法は、例えば、以下のとおりである。まず、図２のステップＳ０４において対象のＷｅｂページのＨＴＭＬを解析することで、要素に登録されているイベントリスナー等に基づいて、実行可能な操作を把握する。このとき、例えば、ＨＴＭＬのＦｏｒｍタグで囲まれた要素など、一度に操作すべき要素に対する操作をグルーピングする。

【0035】

なお、ここでの「一度に操作すべき要素」とは、Ｆｏｒｍタグ内の要素に限らず、例えば、クリックするとドロップダウンメニューが表示される要素や、ドラッグ＆ドロップなど、複数回に渡る操作が必要な要素が対象となる。したがって、１つの要素に対する複数の操作だけでなく、異なる複数の要素に対する操作が１つにグルーピングされる場合も生じ得る。なお、これらのルールは操作手順書作成ルール１５に登録しておく
その後、各要素について具体的な操作内容（選択値や入力内容等）を決定して、操作手順書を作成する。

【0036】

図４は、本発明の一実施の形態におけるＷｅｂページの例について概要を示した図である。ここでは、「トップ」画面の下位の「住所登録」画面において、Ｆｏｒｍタグに囲まれた「郵便番号」、「都道府県」、「市区町村」、「戻る」、および「登録」の各要素が配置されていることを示している。この画面において実行可能な操作は、例えば、「トップ」はａタグなのでクリックが可能であり、「郵便番号」はｉｎｐｕｔタグなので入力が可能、「都道府県」はｓｅｌｅｃｔタグなので選択値を変更可能、「市区町村」はｉｎｐｕｔタグなので入力が可能、「戻る」および「登録」ボタンはそれぞれｃｌｉｃｋイベントが設定されているのでクリックが可能、というように把握することができる。

【0037】

そして、これらの要素のうち「トップ」と「戻る」に係る操作はグルーピングの対象としない一方で、Ｆｏｒｍタグ内の要素である「郵便番号」、「都道府県」、「市区町村」、「登録」に係る操作は１つにグルーピングする。なお、「戻る」についてはＦｏｒｍタグ内の操作ではあるが、画面遷移が発生する操作となるので、操作手順書としては分離するものとする。

【0038】

その後、各要素について具体的な操作内容を決定して操作手順書を作成する。図４の例では、例えば、「トップ」リンクをクリックするという内容で「操作手順書１」を作成する。また、「郵便番号」に「１２３－４５６７」を入力し、「都道府県」として「東京都」を選択し、「市区町村」に「中央区」を入力し、「登録」ボタンをクリックするという内容で「操作手順書２」を作成する。また、「戻る」ボタンをクリックするという内容で「操作手順書３」を作成する。なお、具体的な設定値等については、例えば、操作手順書作成ルール１５にパターンを登録しておくなどの適宜の方法により決定することができる。

【0039】

図２に戻り、ルールベースでの操作手順書の作成（Ｓ０５）に加えて、本実施の形態では、ＬＬＭ４を利用して人間が操作した場合の内容に近い操作手順書を作成する（Ｓ０６）。

【0040】

図５は、本発明の一実施の形態におけるＷｅｂページの他の例について概要を示した図である。ここでは、ＥＣサイトにおいて配送先住所を登録する画面の例を示しており、予め名前、住所、電話番号の必須欄（※印）を入力しなければ配送先住所を登録することができない仕様となっている。なお、ここではＦｏｒｍタグは使用していない。

【0041】

ここで、図２のステップＳ０５のルールベースでの操作手順書の作成では、Ｆｏｒｍタグ内の要素など「一度に操作すべき要素」として操作手順書作成ルール１５に設定されているルールに該当する複数の操作については、上述したように１つの操作手順書にグルーピングすることができる。

【0042】

一方で、Ｗｅｂサイトによっては、図５の例のように、ＨＴＭＬ標準のＦｏｒｍタグを使用せず、独自タグで実装しているようなケースがあり、「一度に操作すべき要素」を正しく認識することができず、操作手順書が分離してしまうことがある。例えば、図５のＷｅｂページの例に対して図２のステップＳ０５のルールベースでの操作手順書の作成によると、例えば、「お名前」の「姓」に「○○」を入力するという内容で「操作手順書１」を作成し、「お名前」の「名」に「△△」を入力するという内容で「操作手順書２」を作成し、「お名前（カナ）」の「セイ」に「●●」を入力するという内容で「操作手順書３」を作成し、…（中略）…、「登録する」ボタンをクリックするという内容で「操作手順書Ｘ」を作成する、というように操作手順書が分離する。

【0043】

操作手順書が分離された結果、例えば、「操作手順書１」で「お名前」の「姓」を入力しても、「操作手順書２」を実行する前に対象のＷｅｂページが再読み込みされるため、「姓」が入力されていない状態に戻って「名」を入力する操作が開始されてしまい、一度に操作すべき内容（図５の例では必須欄への入力）が正しく行えないという問題が生じる。

【0044】

これに対し、ステップＳ０６のＬＬＭ４を利用した操作手順書の作成では、独自タグでＦｏｒｍタグ相当の機能を実装している場合や、ステップＳ０５のルールベースでの操作手順書の作成では「一度に操作すべき要素」について適切な操作手順を作成できないような複雑な操作を必要とする場合などで、人間が操作した場合の内容に近い操作手順書を作成する。これにより、例えば、必須欄である「お名前」の「姓」に「○○」を入力し、「名」に「△△」を入力し、「お名前（カナ）」の「セイ」に「●●」を入力し、…（中略）…、「登録する」ボタンをクリックする、という内容で「操作手順書１」を作成することが可能である。

【0045】

図６は、本発明の一実施の形態におけるＬＬＭ４を利用した操作手順書の作成（図２のステップＳ０６）の例について概要を示した図である。ここでは、図５の例のような画面のＨＴＭＬの内容をプロンプトのテンプレートに設定することで、図６の上段の図に示すような、ＬＬＭ４に操作手順書を作成させるためのプロンプトを得る。なお、図６の例では対象のページのＨＴＭＬの情報を入力しているが、画面キャプチャによって得た情報を用いることもできる。また、ＨＴＭＬは必ずしも全文を入力する必要はなく、不要な情報を取り除くトリミング処理を行った上で入力してもよい。

【0046】

上段の図に示すような操作手順書作成プロンプトをＬＬＭ４に入力することで、下段の図に示すような操作手順書（ＪＳＯＮ（JavaScript Object Notation）形式等の操作手順情報）を得ることができる。そして、得られた操作手順書により操作をシミュレートすることで、例えば、ルールベースで得られた操作手順書による操作のシミュレーションでは見つけられなかったリクエスト（例えば、図５の画面例では住所の新規登録リクエスト等）を見つけられる可能性が高くなる。

【0047】

なお、本実施の形態では、従来のルールベースでの操作手順書の作成（図２のステップＳ０５）と、ＬＬＭ４を利用した操作手順書の作成（図２のステップＳ０６）の両者を行うことで、操作手順書における操作の網羅性を効率よく向上させているが、ＬＬＭ４を利用した操作手順書の作成のみであってもよい。また、図２の例では、ルールベースでの操作手順書の作成→ＬＬＭ４を利用した操作手順書の作成の順で実行するように記載されているが、逆の順でもよいし並列的に行うようにしてもよい。

【0048】

図２に戻り、その後、ステップＳ０５、Ｓ０６で作成された操作手順書に従って対象のＷｅｂページの画面操作をシミュレートする（Ｓ０７）。そして、操作の影響で画面表示が変化したか否かを判定する（Ｓ０８）。画面が変化している場合（ステップＳ０８でＹｅｓ）、変化した画面の情報（例えば、ＤＯＭ（Document Object Model）や画面キャプチャ等）を使用して、ステップＳ０５に戻って操作手順書（ルールベースおよびＬＬＭ４によるもの）の作成と、作成された操作手順書による画面操作のシミュレートを繰り返す。

【0049】

一方、操作の影響による画面表示の変化がなくなった場合（ステップＳ０８でＮｏ）は、対象のＷｅｂページ内で見つかったＵＲＬの一覧から巡回対象ページリスト１４を作成する（Ｓ０９）。このとき、対象のＷｅｂページがすでに巡回済みであれば、当該Ｗｅｂページを再巡回しても見つかるＵＲＬが同じになる可能性が高い。そこで、本実施の形態では、不要な巡回を減らすために、見つかったＵＲＬが過去に巡回済みの既存のＷｅｂページと重複する（実質的に同一である）か否かをルールベースにより判定し、重複するものはグルーピングして巡回対象外とする（Ｓ１０）。

【0050】

しかしながら、過去に巡回済みの既存のＷｅｂページと実質的に同一であるＵＲＬであっても、当該ＵＲＬに辿り着くまでの前提条件（実施した操作）が異なる場合は、対象のＷｅｂページにおける挙動が変化する可能性があり、その場合は改めて巡回する必要がある。そこで、本実施の形態では、ＬＬＭ４を利用して、対象のＷｅｂページについて過去の巡回時と挙動に変化が生じると推測されるか否かを判定し、変化が生じると推測される場合にはグルーピングの対象から外して再巡回の対象とする（Ｓ１１）。

【0051】

図７は、本発明の一実施の形態における巡回対象ページリスト１４の他の具体的な例について概要を示した図である。図７の例において、「Ｎｏ．」の欄は各ＵＲＬが見つかった順を示しており、「親」の欄は対象のＵＲＬのリンクが見つかった親の画面のＮｏ．を示している。すなわち、図２のステップＳ０９において「Ｎｏ．１」のトップ画面を解析したことで「Ｎｏ．２」のカート画面と「Ｎｏ．３」の商品一覧画面が見つかったことを示している。そして、「Ｎｏ．３」の画面を解析したことで「Ｎｏ．４」の商品をカートに追加する画面が見つかり、「Ｎｏ．４」の画面を解析したことで「Ｎｏ．５」のカート画面が見つかったことを示している。

【0052】

このとき、図２のステップＳ１０の処理では、「Ｎｏ．５」のカート画面が「Ｎｏ．２」のカート画面と類似（実質的に同一）であり、すでに巡回済みであることから、「Ｎｏ．２」の画面とグルーピングされ巡回不要と判断される。しかしながら、「Ｎｏ．２」のカート画面は初期状態のカートを示しており、カートに商品が追加されておらず空であることから、レジ画面に進むことができないが、「Ｎｏ．５」のカート画面では、「Ｎｏ．４」の画面でカートに商品が追加された後に遷移していることから、再巡回することによりレジに進む操作（ＵＲＬ）を新たに見つけ出すことが期待される（すなわち、これらのＷｅｂページには複数のＷｅｂページを跨いで順序性のある操作が含まれていることになる）。

【0053】

そこで本実施の形態では、図２のステップＳ１１の処理により、ステップＳ１０でルールベースによりグルーピングしたＵＲＬのリストのうち、対象のＵＲＬに辿り着くための前提条件（操作）を踏まえて、過去に巡回したとき（「Ｎｏ．２」の画面）と現在の巡回（「Ｎｏ．５」の画面）とでＷｅｂページの挙動に変化が生じると推測されるか否か、すなわち再巡回が必要か否かをＬＬＭ４を利用して判断する。

【0054】

図８、図９は、本発明の一実施の形態におけるＬＬＭ４を利用した再巡回が必要なＷｅｂページの判定（図２のステップＳ１１）の例について概要を示した図である。ここでは、図７の例のような巡回対象ページリスト１４の内容において、すでに見つかっている（巡回済みの）ＵＲＬと、今回の巡回で見つかったＵＲＬをプロンプトのテンプレートに設定することで、図８に示すような、ＬＬＭ４に再巡回が必要なＵＲＬを判定させるためのプロンプトを得る。

【0055】

ここで、巡回済みのＵＲＬのデータにおいて、画面のＩＤ（"id"）や親ＩＤ（"parentId"）のプロパティに加えて、概要（"summary"）プロパティに操作の概要を示す文章が含まれているが、今回の巡回で実施した操作の概要だけでなく、巡回を開始してから実行した全ての操作が含まれるようにしてもよい。これは、例えば、上記の図７の例では、「Ｎｏ．４」の画面で商品をカートに追加した後、直接「Ｎｏ．５」のカート画面に異動しているが、商品をカートに追加した後に一度「Ｎｏ．１」のトップ画面に戻らなければカート画面に移動できないような構造のＷｅｂサイトであった場合には、トップ画面に異動した経緯を遡らなければ「Ｎｏ．５」のカート画面の再巡回が必要か否かを適切に判断できないためである。

【0056】

図８の例に示すようなプロンプトをＬＬＭ４に入力することで、図９に示すような出力を得ることができる。この出力には、再巡回が必要なＵＲＬの情報が含まれる。なお、本実施の形態では、再巡回が必要か否かを上記のようにＬＬＭ４を利用して判定しているが、判定対象のＵＲＬの数が多い場合などでは、効率化を図るため、その一部または全部について、ＬＬＭ４での判定に代えてルールベースにより判定してもよい。

【0057】

図２に戻り、ステップＳ１１において再巡回が必要と判断されたＵＲＬを、巡回対象ページリスト１４に登録（もしくは、対象のＵＲＬがすでに巡回対象ページリスト１４に登録されている場合は、その巡回ステータスを変更）する（Ｓ１２）。そして、ステップＳ０２に戻って、自動巡回の終了条件に該当するまで（ステップＳ０２でＹｅｓ）、以降の処理を繰り返す。

【0058】

＜データ構成＞
図１０は、本発明の一実施の形態における巡回対象ページリスト１４のデータ構成の例について概要を示した図である。巡回対象ページリスト１４は、自動巡回の対象となる（もしくは巡回した）ページ（ＵＲＬ）のリストを保持するテーブルであり、例えば、巡回対象ページＩＤ、親ページＩＤ、巡回リクエストＩＤ、ＵＲＬ、ＵＲＬ概要、メソッド、リクエスト、レスポンス、キャプチャ、ページ巡回ステータス、操作内容、および操作概要などの各項目を有する。

【0059】

巡回対象ページＩＤの項目は、巡回対象のページを一意に特定するＩＤの情報を保持する。親ページＩＤの項目は、巡回対象のページが見つかった親のページを特定するＩＤの情報を保持する。また、巡回リクエストＩＤの項目は、対象のページが含まれる対象Ｗｅｂサイト３に対する巡回のリクエストを一意に特定するＩＤの情報を保持する。巡回のリクエスト毎に個別に特定可能とすることで、例えば、巡回毎にそれぞれの全体としてのステータス（巡回待ち、巡回中、巡回完了等）の情報を図示しない管理テーブル等により別途管理することができる。

【0060】

ＵＲＬの項目は、対象のページのＵＲＬの情報を保持する。また、ＵＲＬ概要の項目は、対象のページに対する解析の結果得られた、対象のページが何のページであるかの概要を示す文章（例えば、「トップ画面」や「商品をカートに追加」等）を保持する。メソッド、リクエスト、レスポンス、キャプチャの各項目は、それぞれ、対象のページのメソッド（ＧＥＴ、ＰＯＳＴ、ＰＵＴ等）、対象のページに対するリクエストとこれに対するレスポンスの情報、対象のページを画面キャプチャした情報を保持する。また、ページ巡回ステータスの項目は、対象のページに対する巡回のステータス（巡回待ち、巡回中、巡回完了等）の情報を保持する。

【0061】

操作内容の項目は、対象のページのＵＲＬに到達するために必要な具体的な操作の内容（例えば、[{"name":"open","url":"https://example.com/top/"},{"name":"clickAt","target":"//a[.='リンク']"}]等）を保持する。また、操作概要の項目は、上記の操作内容の概要を示す文章（例えば、「トップ画面を開き、［リンク］をクリックする」等）を保持する。

【0062】

以上に説明したように、本発明の一実施の形態であるセキュリティテストシステム１によれば、Ｗｅｂページ内で複数の操作を適切な順序で行う必要があるタイプのＷｅｂページへの対応として、どのような場合にどのような順序で操作を行うかを予め定めておいたルールに基づいて適切な操作手順を得る従来の手法に加えて、ＬＬＭ４を利用して、人間が操作した場合の内容に近い操作手順を得る手法を用いて、適切な操作手順書を作成して画面操作をシミュレートすることができる。

【0063】

また、複数Ｗｅｂページを跨いで適切な順序で操作を行う必要があるタイプのＷｅｂページへの対応として、対象のＷｅｂページについて過去に巡回したときと現在再度巡回したときとの間で挙動に変化が生じると推測されるか否かをＬＬＭ４によって判定し、変化が生じると推測された場合には同じＵＲＬでも操作手順が異なるとして、グルーピングの対象から外して再巡回の対象とする。これらにより、順序性がある操作を含む対象Ｗｅｂサイト３に対して適切な操作手順を把握して効率的・効果的に自動巡回を行うことができる。

【0064】

以上、本発明者によってなされた発明を実施の形態に基づき具体的に説明したが、本発明は上記の実施の形態に限定されるものではなく、その要旨を逸脱しない範囲で種々変更可能であることはいうまでもない。また、上記の実施の形態は本発明を分かりやすく説明するために詳細に説明したものであり、必ずしも説明した全ての構成を備えるものに限定されるものではない。また、上記の実施の形態の構成の一部について、他の構成の追加・削除・置換をすることが可能である。

【0065】

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

【0066】

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

【産業上の利用可能性】

【0067】

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

【符号の説明】

【0068】

１…セキュリティテストシステム、２…ユーザ端末、３…対象Ｗｅｂサイト、４…ＬＬＭ、
１１…検査管理部、１２…巡回処理部、１３…検査実施部、１４…巡回対象ページリスト、１５…操作手順書作成ルール、１６…ページリスト、１７…検査結果

【要約】

【課題】順序性がある操作を含むＷｅｂサイトに対して適切な操作手順を把握して効率的・効果的に自動巡回を行う。
【解決手段】Ｗｅｂアプリケーションにおけるセキュリティの脆弱性の有無を検査するセキュリティテストシステム１であって、対象Ｗｅｂサイト３内の巡回対象のＷｅｂページを取得して解析し、取得したＷｅｂページの内容に係る情報をプロンプトに設定してＬＬＭ４に入力して、Ｗｅｂページに係る操作手順情報を作成させ、操作手順情報に従ってＷｅｂページに係る操作をシミュレートして、Ｗｅｂページ内のリンクに係るＵＲＬを取得して巡回対象ページリスト１４に登録する。
【選択図】図１

【図1】

【図2】

【図3】

【図4】

【図5】

【図6】

【図7】

【図8】

【図9】

【図10】