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

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

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

(11)【特許番号】

(24)【登録日】2024-05-14

(45)【発行日】2024-05-22

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

(51)【国際特許分類】

   G06F 21/57 20130101AFI20240515BHJP

   G06N 3/0475 20230101ALI20240515BHJP

【ＦＩ】

G06F21/57 370

G06N3/0475

【請求項の数】 6

(21)【出願番号】P 2024013436

(22)【出願日】2024-01-31

【審査請求日】2024-01-31

【早期審査対象出願】

(73)【特許権者】

【識別番号】308020663

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

(74)【代理人】

【識別番号】100216677

【弁理士】

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

(72)【発明者】

【氏名】岡島 未来

(72)【発明者】

【氏名】筧 賢太

【審査官】中里 裕正

(56)【参考文献】

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

【文献】国際公開第２０１８／１３９４５８（ＷＯ，Ａ１）

【文献】国際公開第２０２２／１７２４３７（ＷＯ，Ａ１）

【文献】国際公開第２０２２／２１９７９２（ＷＯ，Ａ１）

【文献】米国特許出願公開第２０２３／０３０６１１８（ＵＳ，Ａ１）

【文献】米国特許出願公開第２０２３／０３１５８５６（ＵＳ，Ａ１）

【文献】PEARCE, H. et al.，Examining Zero-Shot Vulnerability Repair with Large Language Models，2023 IEEE Symposium on Security and Privacy (SP)，2023年，pp.2339-2356

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

Ｇ０６Ｆ ２１／５７

Ｇ０６Ｎ ３／０４７５

ＪＳＴＰｌｕｓ／ＪＭＥＤＰｌｕｓ／ＪＳＴ７５８０（ＪＤｒｅａｍＩＩＩ）

ＩＥＥＥ Ｘｐｌｏｒｅ

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

【請求項1】

Ｗｅｂアプリケーションにおけるセキュリティの脆弱性の有無を検査するセキュリティテストシステムであって、
前記Ｗｅｂアプリケーションの脆弱性の有無を検査し、検知された脆弱性に係る情報を検査結果として記録してユーザに提示する検査実施部と、
前記検査結果においてユーザから指定された対象脆弱性に係る質問を受け付けて、ＬＬＭ（大規模言語モデル）により回答を作成して回答する対話処理部と、を有し、
前記対話処理部は、前記対象脆弱性に係る詳細情報を前記ＬＬＭに対して入力する、セキュリティテストシステム。

【請求項2】

請求項１に記載のセキュリティテストシステムにおいて、
前記対話処理部は、前記対象脆弱性に係る前記詳細情報を含む第１のプロンプトを前記ＬＬＭに対して入力し、ユーザからの前記質問に対して回答するために必要となる回答必要情報を判断させる第２のプロンプトを前記ＬＬＭに入力し、前記ＬＬＭから出力された前記回答必要情報に係る内容を前記検査結果から取得して、ユーザからの前記質問に対して回答させる第３のプロンプトを前記ＬＬＭに入力して、前記ＬＬＭから出力された内容を回答としてユーザに提示する、セキュリティテストシステム。

【請求項3】

請求項１に記載のセキュリティテストシステムにおいて、
前記対話処理部は、前記対象脆弱性に係る前記詳細情報を、既知の脆弱性に係る詳細情報を予め蓄積した脆弱性マスタから取得する、セキュリティテストシステム。

【請求項4】

請求項２に記載のセキュリティテストシステムにおいて、
前記第１のプロンプトには、前記対象脆弱性に係る前記詳細情報として、少なくとも、前記対象脆弱性の名称、前記対象脆弱性の概要の説明情報、前記対象脆弱性を検知するためのロジック、および前記対象脆弱性の検知が誤検知か否かを判断するための方法に係る情報が含まれる、セキュリティテストシステム。

【請求項5】

請求項２に記載のセキュリティテストシステムにおいて、
前記回答必要情報には、前記Ｗｅｂアプリケーションに対するリクエストと当該リクエストに対するレスポンス、前記Ｗｅｂアプリケーションに対する改ざんしたリクエストと当該リクエストに対するレスポンス、および前記改ざんの値のうち、少なくとも１つ以上が含まれる、セキュリティテストシステム。

【請求項6】

請求項１に記載のセキュリティテストシステムにおいて、
前記対話処理部は、予め設定した質問のテンプレートからユーザにより選択されたものに基づいて前記質問を受け付ける、セキュリティテストシステム。

【発明の詳細な説明】

【技術分野】

【0001】

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

【背景技術】

【0002】

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

【0003】

Ｗｅｂアプリケーションのセキュリティテストの手法は、大きくＳＡＳＴ（Static Application Security Testing：静的アプリケーションセキュリティテスト）と、ＤＡＳＴ（Dynamic Application Security Testing：動的アプリケーションセキュリティテスト）に分けられる。ソースコード等を静的に分析するＳＡＳＴに対して、ＤＡＳＴでは、稼働しているアプリケーションに対して、攻撃者の視点を踏まえて外部から疑似的な攻撃（検査）リクエストを送信し、アプリケーションの挙動（レスポンス）の変化から脆弱性があるかどうかを判定する。

【0004】

このような手法を用いたセキュリティテストに関連する技術として、例えば、特表２０２３－５４５６２５号公報（特許文献１）には、ＳＡＳＴやＤＡＳＴなどの手法を用いてソフトウェアをスキャンして潜在的脆弱性問題を検出し、これらをリストする電子文書報告を生成して、電子文書報告から各潜在的脆弱性問題についての特徴を抽出し、抽出された特徴と、潜在的脆弱性問題のソースコードに基づいて決定したトークンに基づいてベクトルを決定し、ベクトルに基づいて脆弱性スコア付け方法を選択して脆弱性精度スコアを決定することで、ソフトウェアの脆弱性のトリアージを行うことが記載されている。

【先行技術文献】

【特許文献】

【0005】

【文献】特表２０２３－５４５６２５号公報

【発明の概要】

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

【0006】

従来技術によれば、ＳＡＳＴやＤＡＳＴなどの手法によりソフトウェアの脆弱性をスキャンして、脆弱性の程度（攻撃の可能性）を数値化することで、最も関連性の高い脆弱性を明らかにし、解決策を提案することが可能であると言える。

【0007】

一方で、セキュリティテストの手法としてＤＡＳＴを用いる場合、ＤＡＳＴが稼働中のアプリケーションに対して外部から擬似的な攻撃を行って脆弱性の有無を判定するというブラックボックス的な手法であることから、攻撃時におけるアプリケーションの内部の処理を１００％把握することが難しく、脆弱性の検知に誤りが生じ得る。特に、セキュリティテストシステム等、自動的に検査・診断を行うような仕組みの場合、手動での検査・診断に比べて誤検知の可能性が高くなる。したがって、自動的に検知された脆弱性については、正しい検知（True Positive）なのか誤検知（False Positive）なのかをユーザが手動で精査する必要がある。

【0008】

このとき、アプリケーションの脆弱性について知見のあるユーザであれば、自動的に検知された脆弱性に係る詳細情報から、適切な情報に着目して高い精度で精査することができる。一方で、脆弱性について知見のないユーザの場合、どこに着目して判断すべきかが分からず、精査を適切に行えない事態が生じ得る。また、正しく検知された脆弱性への対応策についても、例えば、ソースコードを具体的にどう修正すべきか等の判断ができない場合が生じ得る。

【0009】

そこで本発明の目的は、ＤＡＳＴ等の手法により自動的に検知されたアプリケーションの脆弱性について、正しい検知か誤検知かのユーザによる手動での精査とユーザへの対応策の提示を支援するセキュリティテストシステムを提供することにある。

【0010】

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

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

【0011】

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

【0012】

本発明の代表的な実施の形態であるセキュリティテストシステムは、Ｗｅｂアプリケーションにおけるセキュリティの脆弱性の有無を検査するセキュリティテストシステムであって、前記Ｗｅｂアプリケーションの脆弱性の有無を検査し、検知された脆弱性に係る情報を検査結果として記録してユーザに提示する検査実施部と、前記検査結果においてユーザから指定された対象脆弱性に係る質問を受け付けて、ＬＬＭ（大規模言語モデル）により回答を作成して回答する対話処理部と、を有し、前記対話処理部は、前記対象脆弱性に係る詳細情報を前記ＬＬＭに対して入力する。

【発明の効果】

【0013】

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

【0014】

すなわち、本発明の代表的な実施の形態によれば、Ｗｅｂサイトの脆弱性の検査の仕組みにおいて、ＤＡＳＴ等の手法により自動的に検知された脆弱性について、正しい検知か誤検知かのユーザによる手動での精査とユーザへの対応策の提示を支援することが可能となる。

【図面の簡単な説明】

【0015】

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

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

【図3】本発明の一実施の形態における脆弱性検査の例について概要を示した図である。

【図4】（ａ）（ｂ）は、本発明の一実施の形態における脆弱性検査のパターンの例について概要を示した図である。

【図5】本発明の一実施の形態における脆弱性の詳細情報をＬＬＭに入力するプロンプトの例について概要を示した図である。

【図6】本発明の一実施の形態における回答に必要な情報をＬＬＭに判断させるためのプロンプトの例について概要を示した図である。

【図7】本発明の一実施の形態における回答をＬＬＭに作成させるプロンプトの例について概要を示した図である。

【図8】（ａ）～（ｃ）は、本発明の一実施の形態におけるチャット画面での回答の例について概要を示した図である。

【図9】本発明の一実施の形態における検査結果のデータ構成の例について概要を示した図である。

【図10】本発明の一実施の形態における脆弱性マスタのデータ構成の例について概要を示した図である。

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

【0016】

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

【0017】

＜概要＞
上述したように、ＤＡＳＴによるＷｅｂサイトのセキュリティテストは、稼働中のアプリケーションに対して外部から擬似的な攻撃に係るリクエストを送信し、これに対してアプリケーションから応答されたレスポンスに基づいて脆弱性の有無を判定するというブラックボックス的な手法であることから、攻撃時におけるアプリケーションの内部の処理を１００％把握することが難しく、脆弱性の検知に誤りが生じ得る。特に、セキュリティテストシステム等、自動的に検査・診断を行うような仕組みの場合、手動での検査・診断に比べて誤検知の可能性が高くなる。したがって、自動的に検知された脆弱性については、正しい検知（True Positive）なのか誤検知（False Positive）なのかをユーザが手動で精査する必要がある。

【0018】

精査に際しては、後述するように、脆弱性の種別や検査パターンによって着目すべき情報が異なる。例えば、アプリケーションに対するオリジナル（改ざん前）のリクエストに着目すべき場合もあれば、改ざん後のリクエストに対するレスポンスに着目すべき場合もある。また、オリジナルのリクエストに対するレスポンスと改ざん後のリクエストに対するレスポンスの差分に着目すべき場合もある。このとき、脆弱性について知見のあるユーザであれば、自動的に検知された脆弱性に係る詳細情報から、適切な情報に着目して高い精度で精査することができる。一方で、脆弱性について知見のないユーザの場合、どこに着目して判断すべきかが分からず、精査を適切に行えない事態が生じ得る。また、正しく検知された脆弱性への対応策についても、例えば、ソースコードを具体的にどう修正すべきか等の判断ができない場合が生じ得る。

【0019】

そして、ＤＡＳＴはあくまでアプリケーションに対するブラックボックス的な検査手法であり、アプリケーションの内部構造を理解した上での検査手法ではない。したがって、ユーザによる精査にあたり、アプリケーションを構成している各種の技術要素（例えば、ソースコードやフレームワーク設定等）についての知見が提供されることで、誤検知か否かの判定の精度を向上させることができる。しかし、セキュリティテストシステム等、自動的に検査・診断を行うような仕組みの場合、アプリケーションの外部からは精査の際の参考となる内部の情報を知ることができない。したがって、これらの情報は当該アプリケーションの管理者や開発者等から別途提供してもらう必要がある。

【0020】

そこで本発明の一実施の形態であるセキュリティテストシステムは、対象のアプリケーションについてＤＡＳＴ等の手法により自動的に検知した脆弱性について、これに対する精査や対応策についてのユーザからの質問を、チャットボット形式で対話的に受け付けて回答する。そして、回答に際し、回答のために必要な情報を事前に判断し、これらの情報についてユーザから提供を受けた内容に基づいて回答することで、回答の精度を向上させる。さらに、上記のような情報の収集や質問への回答に生成ＡＩ（Artificial Intelligence）・ＬＬＭ（Large Language Models：大規模言語モデル）（以下ではこれらを「ＬＬＭ」と総称する場合がある）を利用することで、脆弱性について知見のあるユーザと同等の判断を実現する。

【0021】

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

【0022】

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

【0023】

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

【0024】

対話処理部１２は、検査実施部１１により検知された脆弱性について、これに対する精査や対応策についてのユーザからの質問を、ユーザ端末２を介してチャットボット形式で対話的に受け付けて回答する機能を有する。本実施の形態ではチャットボット形式で対話的に質問を受け付けて回答する構成としているが、質問・回答のユーザインタフェースはこれに限られない。回答に際し、回答のために必要な情報を外部もしくは内部のＬＬＭ４を利用して判断し、これらの情報についてユーザから提供を受けた内容に基づいて、ＬＬＭ４により回答を生成する。対話処理部１２での処理の詳細については後述する。

【0025】

＜処理の流れ＞
図２は、本発明の一実施の形態における脆弱性検査の処理の流れの例について概要を示したフローチャートである。まず、検査実施部１１により対象Ｗｅｂサイト３に対するＤＡＳＴによる脆弱性の検査を行う。検査ではまず、対象Ｗｅｂサイト３における検査対象のすべてのＵＲＬ（Uniform Resource Locator）について繰り返す第１のループ処理を開始する（Ｓ０１）。検査対象のＵＲＬは、例えば、事前に対象Ｗｅｂサイト３を自動巡回して各Ｗｅｂページ内のリンクを解析する等により取得してリスト化する。第１のループ処理では、処理対象のＵＲＬに対してオリジナル（改ざん前）のリクエストを送信するシナリオを再生する（Ｓ０２）。

【0026】

図３は、本発明の一実施の形態における脆弱性検査の例について概要を示した図である。ここでは、上段の図に示されているような検査対象のＵＲＬのリストのうち、破線で囲まれた処理対象のＵＲＬに対して、オリジナル（改ざん前）のシナリオとして、下段の図に示されているようなリクエストをＨＴＴＰ（Hyper Text Transfer Protocol）により送信し、図示するようなレスポンスを得たことを示している。

【0027】

図２に戻り、その後、予め設定されたすべての検査パターンについて繰り返す第２のループ処理を開始する（Ｓ０３）。第２のループ処理では、処理対象の検査パターンに応じて改ざんされたリクエストを処理対象のＵＲＬに対して送信するシナリオを再生する（Ｓ０４）。そして、処理対象のＵＲＬに係るＷｅｂページから応答されたレスポンスに基づいて、脆弱性の検知の有無を判定し（Ｓ０５）、次の検査パターンの処理に移る（Ｓ０６）。

【0028】

図４は、本発明の一実施の形態における脆弱性検査のパターンの例について概要を示した図である。図４（ａ）では、ＳＱＬ（Structured Query Language）インジェクションを検査するための検査パターンの１つにおける改ざんしたリクエストと、これに対するレスポンスの例を示している。ＳＱＬインジェクションでは、不正なＳＱＬ文をリクエストに埋め込むことで改ざんする。図４（ａ）の例では、リクエストにおける破線で囲まれた箇所を、上述の図３の例に示したオリジナルのリクエストから改ざんしていることを示すとともに、このリクエストに対するレスポンスの内容が、上述の図３の例に示したレスポンスとの間で差分がないことを示している。この検査パターンの場合は、オリジナルのリクエストに対するレスポンスと、改ざんしたリクエストに対するレスポンスに差分がない場合に、ＳＱＬインジェクションの脆弱性を検知したと判定する。

【0029】

一方、図４（ｂ）では、検査パターンがクロスサイトスクリプティングを検査するための検査パターンの１つにおける改ざんしたリクエストと、これに対するレスポンスの例を示している。クロスサイトスクリプティングでは、リクエストを改ざんして悪意のあるスクリプトを対象Ｗｅｂサイト３に埋め込むことで、後に第三者によりアクセスされた際にこれを実行させる。図４（ｂ）の例では、リクエストにおける破線で囲まれた箇所を、上述の図３の例に示したオリジナルのリクエストから改ざんしていることを示すとともに、このリクエストに対するレスポンスの内容に、上述の図３の例に示したレスポンスとの間で、破線で囲まれた箇所の差分があることを示している。この検査パターンの場合は、図中の例のように、例えばリクエストに埋め込んだ＜ｓｃｒｉｐｔ＞タグがレスポンスにも反射された場合に、クロスサイトスクリプティングの脆弱性を検知したと判断する。

【0030】

このように、検査パターンによって、オリジナルのリクエストおよびレスポンスと、攻撃に係るリクエストおよびレスポンスとの間に差分がない場合に脆弱性を検知したとする場合もあれば、差分がある場合に脆弱性ありと検知する場合もある。また、差分の有無に関わらずレスポンスの内容に基づいて判断する場合もある。このように、検査パターン毎に着目すべき情報が異なることから、本実施の形態では、後述するように、検査パターン（脆弱性）毎にどのようなロジックで脆弱性の有無を検知・判断するのかに係る情報を事前にＬＬＭ４に入力しておく。

【0031】

図２に戻り、すべての検査パターンについてステップＳ０４～Ｓ０５の処理を行って第２のループ処理が終了すると、第１のループ処理において次の検査対象のＵＲＬの処理に移る（Ｓ０７）。そして、すべての検査対象のＵＲＬについてステップＳ０２～Ｓ０６の処理を行って第１のループ処理が終了すると、対象Ｗｅｂサイト３に係る検査結果を対話処理部１２によりユーザ端末２に表示する（Ｓ０８）。例えば、検知した各脆弱性をリスト表示し、リストからユーザにより選択された脆弱性について、詳細画面にて検査パターン、ＵＲＬ、Ｗｅｂページ内のパラメータ等を表示する。さらに、詳細画面に、例えば「相談する」等のボタンを表示し、ユーザがこれを押下することで、チャット画面を介して対象の脆弱性についての質問を受け付けることができるようにする。

【0032】

その後、ユーザが「相談する」等のボタンを押下してチャット画面を起動したか否かを判定する（Ｓ０９）。チャット画面が起動されずに検査結果の画面がユーザによりクローズされる等した場合は（ステップＳ０９でＮｏ）、検査処理を終了する。一方、ユーザによりチャット画面が起動された場合は（ステップＳ０９でＹｅｓ）、まず、対話処理部１２により、対象の脆弱性についての詳細情報をＬＬＭ４に入力・指示する（Ｓ１０）。

【0033】

図５は、本発明の一実施の形態における脆弱性の詳細情報をＬＬＭ４に入力するプロンプトの例について概要を示した図である。ここでは、図示するような脆弱性詳細情報入力プロンプトを生成してＬＬＭ４に入力することで、対象の脆弱性（図５の例ではＳＱＬインジェクション）について、脆弱性の概要、どのようなロジックで検知するのか、誤検知か否かの判定を行う方法等、必要な情報を脆弱性マスタ１４から取得して予めＬＬＭ４にインプットしておく。なお、図５の例に示された情報の項目は必要最低限のものであり、これらの他に脆弱性毎に必要な情報の項目が追加され得ることは言うまでもない。この脆弱性詳細情報入力プロンプトでは、応答を出力しないよう指示することで、そのまま次の処理に移る。

【0034】

図２に戻り、次の処理では、チャット画面を介してユーザからの質問の入力を受け付ける（Ｓ１１）。質問の入力を受け付けると、対話処理部１２では、当該質問に回答するために必要な情報をＬＬＭ４に判断させ（Ｓ１２）、必要と判断された情報に基づいて、質問に対する回答をＬＬＭ４に作成させ（Ｓ１３）、得られた回答をチャット画面においてシステムからの回答としてユーザに表示する（Ｓ１４）。

【0035】

図６は、本発明の一実施の形態におけるステップＳ１２で回答に必要な情報をＬＬＭに判断させるためのプロンプトの例について概要を示した図である。ここでは、上段の図に示すような回答必要情報判断プロンプトを生成してＬＬＭ４に入力することで、ＬＬＭ４からの出力として、下段の図に示すような、ユーザからの質問に回答するために必要な情報を得る。

【0036】

図６の例に示す回答必要情報判断プロンプトでは、対象の脆弱性とユーザからの質問の内容に加えて、回答のために入手可能な情報のキー（図６の例では、改ざん値（tamperedValue）、オリジナルのリクエスト（originalRequest）、オリジナルのレスポンス（originalResponse）、改ざん時のリクエスト（tamperedRequest）、改ざん時のレスポンス（tamperedResponse）の５種類）と、ＪＳＯＮ（JavaScript Object Notation）形式で出力される回答に含まれるデータ項目を指示している。このプロンプトに対し、図６の例では、ＬＬＭ４からのＪＳＯＮ形式の出力において、質問への回答に必要な情報（required）として、上記の５種類のキーすべてが必要であるという出力がされたことを示している。

【0037】

なお、図６の例に示す回答必要情報判断プロンプトでは、回答のために入手可能な情報におけるリクエストとレスポンスとして、それぞれ、オリジナル（正常通信時）と改ざん時（攻撃時）の２種類を指定しているが、脆弱性によっては、１つの攻撃で複数の改ざんを行う場合があるため、改ざん時については２種類以上のリクエストとレスポンスが指定される場合もある。また、図６の例に示された回答のために入手可能な情報は一例であり、これらの他に入手可能な情報の項目が追加され得ることは言うまでもない。

【0038】

図７は、本発明の一実施の形態におけるステップＳ１３で回答をＬＬＭ４に作成させるプロンプトの例について概要を示した図である。ここでは、上段の図に示すような回答作成プロンプトを生成してＬＬＭ４に入力することで、ＬＬＭ４からの出力として、下段の図に示すようなユーザからの質問に対する回答を得る。

【0039】

図７の例に示す回答作成プロンプトでは、対象の脆弱性とユーザからの質問の内容に加えて、ステップＳ１２で取得した回答のために必要な情報（図７の例では、改ざん値、オリジナルのリクエスト、オリジナルのレスポンス、改ざん時のリクエスト、および改ざん時のレスポンスそれぞれの実際の内容）と、ＪＳＯＮ形式での出力に含める項目を指示している。回答のために必要な情報の実際の内容は、例えば、検査結果１３から取得することができる。なお、ＬＬＭ４に入力することができる情報量（トークン数）には上限があるため、入力する情報量が多くなる場合は、例えば、入力するリクエストとレスポンスの実際の内容について、不要な部分を切り詰めたり、分割して入力したりすることで、ＬＬＭ４の制限を回避する。

【0040】

図８は、本発明の一実施の形態におけるステップＳ１４でのチャット画面での回答の例について概要を示した図である。図８（ａ）は、１回のやり取りで終了する場合の例を示している。ここでは、検知された脆弱性が誤検知かどうか教えてほしいというユーザからの質問に対して、ＬＬＭ４がステップＳ１３で作成した誤検知の可能性が高いとの終局的な回答を提示してやり取りを終了していることを示している。

【0041】

一方、図８（ｂ）は、ユーザからの追加の情報提供が必要な場合の例を示している。ここでは、図８（ａ）と同様に、検知された脆弱性が誤検知かどうかというユーザからの質問に対して、ＬＬＭ４がステップＳ１３で回答を作成したものの、誤検知か否かを判定するためにはさらに追加の情報が必要であるとしてユーザに確認を求めている。そして、ユーザから入力された追加情報に基づいて誤検知の可能性が高いとの終局的な回答を提示していることを示している。このように、ＬＬＭ４を利用することで、対話的にやり取りを重ねてユーザから追加の情報を取得しながら、質問に対して回答していくことができる。

【0042】

また、図８（ｃ）は、検知された脆弱性に対して、ユーザに対象Ｗｅｂサイト３のコードの修正方法を提示する場合の例を示している。ここでは、どのようにコードを修正すべきか、というユーザからの質問に対して、回答するためにはさらに追加の情報（図中の例では現在のソースコードや技術情報）が必要であるとしてユーザに入力を求めている。そして、ユーザから入力された追加情報に基づいて、どのようにコードを修正すべきかを回答していることを示している。

【0043】

なお、ユーザからの質問としては、例えば、「この脆弱性を検知した理由を説明してください」「この脆弱性が誤検知かどうか確認してください」「この脆弱性が存在するかを確認するには何をすべきか教えてください」などのように、検知された脆弱性の精査に係る質問が想定される。この場合、対話処理部１３およびＬＬＭ４では、例えば、上述のステップＳ１０で入力した脆弱性の詳細情報や、脆弱性マスタ１４に蓄積されている情報に基づいて回答を作成することができる。

【0044】

また、例えば、「ＳＱＬインジェクションについて説明してください」「クロスサイトスクリプティングを放置するとどのような危険性があるか教えてください」などのように、脆弱性一般についての質問も想定される。この場合、対話処理部１３およびＬＬＭ４では、例えば、脆弱性マスタ１４に蓄積されている情報に基づいて回答を作成することができる。

【0045】

また、例えば、「どのようにコードを修正すべきか教えてください」などのように、対象Ｗｅｂサイト３の修正方法についての質問も想定される。この場合、対話処理部１３およびＬＬＭ４では、例えば上述したように、ユーザに対して該当箇所のソースコードや技術情報（利用言語やライブラリ等）の入力を求め、入力された情報と脆弱性マスタ１４に蓄積されている情報に基づいて回答を作成することができる。

【0046】

なお、ユーザからの質問については、例えば、上記のような質問内容をユーザがチャット画面を通して自由に入力できるようにしてもよいし、想定される質問を予めテンプレートとして用意しておき、その中からユーザが選択して質問するようにしてもよい。

【0047】

図２に戻り、対話処理部１３では、図８の例に示したようなチャット画面でのユーザとのやり取りが終了したか否か（例えば、ユーザがチャット画面をクローズしたか否か）を判定し（Ｓ１５）、終了していない場合は（ステップＳ１５でＮｏ）、ステップＳ１１に戻って、チャット画面でのユーザからの入力の受け付けを継続する。一方、チャット画面でのユーザとのやり取りが終了した場合は（ステップＳ１５でＹｅｓ）、検査処理を終了する。

【0048】

なお、図２の例に示した一連の処理において、網掛けがされている処理（ステップＳ１０、Ｓ１２、Ｓ１３）は、ＬＬＭ４を利用した処理であることを示している。

【0049】

＜データ構成＞
図９は、本発明の一実施の形態における検査結果１３のデータ構成の例について概要を示した図である。検査結果１３は、検査実施部１１による対象Ｗｅｂサイト３に対する検査毎に結果に係る情報を保持するテーブルであり、例えば、検査に係る項目として、検査ＩＤ、ＵＲＬパラメータＩＤ、検査パターンＩＤ、および検査ステータスなどの各項目を有し、検査対象ＵＲＬパラメータに係る項目として、ＵＲＬパラメータＩＤ、ＵＲＬ、およびパラメータなどの各項目を有する。また、リクエストに係る項目として、リクエストＩＤ、ＵＲＬパラメータＩＤ、オリジナルフラグ、検知脆弱性ＩＤ、改ざん値、リクエストヘッダ、およびリクエストボディなどの各項目を有し、レスポンスに係る項目として、レスポンスＩＤ、リクエストＩＤ、レスポンスヘッダ、およびレスポンスボディなどの各項目を有する。

【0050】

検査に係る項目において、検査ＩＤの項目は、対象の検査を一意に特定するＩＤの情報を保持する。ＵＲＬパラメータＩＤおよび検査パターンＩＤの各項目は、それぞれ、対象の検査において用いられたＵＲＬパラメータおよび検査パターンを一意に特定するＩＤの情報を保持する。検知ステータスの項目は、対象の検査において脆弱性が検知されたか否かを示す情報を保持する。

【0051】

検査対象ＵＲＬパラメータに係る項目において、ＵＲＬパラメータＩＤの項目は、対象の検査において用いられたＵＲＬパラメータを一意に特定するＩＤの情報を保持する。ＵＲＬおよびパラメータの各項目は、それぞれ、検査の対象のＵＲＬの情報および指定するパラメータの情報を保持する。

【0052】

リクエストに係る項目において、リクエストＩＤおよびＵＲＬパラメータＩＤの各項目は、それぞれ、対象の検査におけるリクエストおよび用いられたＵＲＬパラメータを一意に特定するＩＤの情報を保持する。オリジナルフラグの項目は、対象のリクエストが改ざんしていないオリジナルのものか否かを示すフラグ（オリジナルの場合Ｔｒｕｅ）の情報を保持する。検知脆弱性ＩＤおよび改ざん値の各項目は、いずれも上記のオリジナルフラグの値がＦａｌｓｅ（改ざんしたリクエスト）の場合にのみ値が設定される項目であり、それぞれ、対象の検査において検知された脆弱性を一意に特定するＩＤの情報および対象のリクエストにおいて改ざんした値の情報を保持する。リクエストヘッダおよびリクエストボディの各項目は、それぞれ、対象のリクエストにおけるヘッダおよびボディの内容に係る情報を保持する。

【0053】

レスポンスに係る項目において、レスポンスＩＤおよびリクエストＩＤの各項目は、それぞれ、対象の検査におけるレスポンスおよびリクエストを一意に特定するＩＤの情報を保持する。レスポンスヘッダおよびレスポンスボディの各項目は、それぞれ、対象のレスポンスにおけるヘッダおよびボディの内容に係る情報を保持する。

【0054】

図１０は、本発明の一実施の形態における脆弱性マスタ１４のデータ構成の例について概要を示した図である。脆弱性マスタ１４は、既知の脆弱性に係るマスタ情報を保持するテーブルであり、例えば、脆弱性に係る項目として、脆弱性ＩＤ、脆弱性名、詳細解説、リスク解説、精査方法解説、および検知内部ロジックなどの各項目を有し、検査パターンに係る項目として、検査パターンＩＤ、脆弱性ＩＤ、および検知理由などの各項目を有する。

【0055】

脆弱性に係る項目において、脆弱性ＩＤの項目は、対象の脆弱性を一意に特定するＩＤの情報を保持する。脆弱性名の項目は、対象の脆弱性の名称の情報を保持する。詳細解説、リスク解説、および精査方法解説の各項目は、それぞれ、対象の脆弱性の詳細内容、想定されるリスク、および対象の脆弱性に真に該当するか否かを精査する方法について説明するテキスト等の情報を保持する。検知内部ロジックの項目は、対象の脆弱性を検知するために用いる内部ロジックの内容に係る情報を保持する。

【0056】

検査パターンに係る項目において、検査パターンＩＤおよび脆弱性ＩＤの各項目は、それぞれ、対象の脆弱性を検査するための検査パターンおよび対象の脆弱性を一意に特定するＩＤの情報を保持する。検知理由の項目は、対象の検査パターンにより対象の脆弱性を検知した場合の検知理由を説明するテキスト等の情報を保持する。

【0057】

以上に説明したように、本発明の一実施の形態であるセキュリティテストシステム１によれば、対象Ｗｅｂサイト３についてＤＡＳＴ等の手法により自動的に検知した脆弱性について、これに対する精査や対応策についてのユーザからの質問を、チャットボット形式で対話的に受け付けて回答することができる。そして、回答に際し、回答のために必要な情報を事前に判断し、これらの情報についてユーザから提供を受けた内容に基づいて回答することで、回答の精度を向上させることができる。さらに、上記のような情報の収集や質問への回答にＬＬＭ４を利用することで、脆弱性について知見のあるユーザと同等の判断を実現することができる。

【0058】

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

【0059】

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

【0060】

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

【産業上の利用可能性】

【0061】

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

【符号の説明】

【0062】

１…セキュリティテストシステム、２…ユーザ端末、３…対象Ｗｅｂサイト、４…ＬＬＭ、
１１…検査実施部、１２…対話処理部、１３…検査結果、１４…脆弱性マスタ

【要約】

【課題】ＤＡＳＴ等の手法により自動的に検知されたアプリケーションの脆弱性について、正しい検知か誤検知かのユーザによる手動での精査と対応策の提示を支援する。
【解決手段】対象Ｗｅｂサイト３の脆弱性の有無を検査し、検知された脆弱性に係る情報を検査結果１３として記録してユーザに提示する検査実施部１１と、ユーザから指定された対象脆弱性に係る質問を受け付けて、ＬＬＭ４により回答を作成して回答する対話処理部１２を有し、対話処理部１２は、対象脆弱性に係る詳細情報をＬＬＭ４に対して入力する。
【選択図】図１

【図1】

【図2】

【図3】

【図4】

【図5】

【図6】

【図7】

【図8】

【図9】

【図10】