Security testing system

Abstract

We provide a security testing system that uses the DAST (Dynamic Application Security Testing) method to check for security vulnerabilities in web applications. [Solution] The security system 1 includes an inspection unit 11 that sends an original request and / or a modified inspection request to the target website 3, and obtains the original response and / or inspection response received in response to each, and records them as inspection results 13. Based on the contents of one or more of the original request, inspection request, original response, and inspection response, or based on the presence or absence of a difference between the original response and the inspection response, the system has the LLM (Large-Scale Language Model) 4 determine the presence or absence of a predetermined event used to determine the presence or absence of a predetermined vulnerability, and determines the presence or absence of a predetermined vulnerability based on this.

Description

Technical Field

[0001] The present invention relates to application testing technology, and particularly to a technology effective when applied to a security testing system for inspecting the presence or absence of vulnerabilities in a web application.

Background Art

[0002] Web applications are premised on network usage, and it is very important to inspect and test for vulnerabilities from a security perspective. Various tools and services for inspecting the presence or absence of vulnerabilities in web applications are available, and research and development are being carried out every day.

[0003] The security testing methods for web applications are roughly divided into SAST (Static Application Security Testing) and DAST (Dynamic Application Security Testing). In contrast to SAST, which statically analyzes source code and the like, in DAST, for a running application, a pseudo attack (inspection) request is sent from the outside from the perspective of an attacker, and it is determined whether there are vulnerabilities based on changes in the behavior (response) of the application.

[0004] As a technology related to security testing using such a method, for example, in Japanese Patent No. 7440150 (Patent Document 1), based on the page information of each of a plurality of web pages included in a website, the type of parameters in the web page is determined, a learning model is used to identify parameters of a predetermined type from among a plurality of parameters in the web page, and the vulnerability of the website is inspected through a predetermined operation involving a change in the value of the parameter.

Prior Art Documents

Patent Documents

[0005] [Patent Document 1] Patent No. 7440150 [Overview of the Initiative] [Problems that the invention aims to solve]

[0006] According to conventional technology, the DAST method can be used to scan for vulnerabilities in web applications, allowing for the examination of various vulnerabilities depending on the meaning, purpose, and function of the website, web page, or parameters, in addition to simple defects caused by invalid input values.

[0007] On the other hand, when performing automated security testing using the DAST method, including the conventional techniques mentioned above, simply comparing the contents of requests and responses as strings when determining the behavior of a web application can lead to many errors in the judgment results. It is known that the majority of errors in vulnerability assessment results by automated security testing tools are due to such errors in judging the contents of requests and responses.

[0008] Therefore, the objective of the present invention is to provide a security testing system for web applications using the DAST method that, instead of simply comparing strings related to requests and responses, or in addition to doing so, makes judgments about behavior after considering the content and meaning of these strings.

[0009] The aforementioned and other objectives and novel features of the present invention will become apparent from this specification and the accompanying drawings. [Means for solving the problem]

[0010] A brief overview of some of the representative inventions disclosed in this application is as follows:

[0011] A security testing system, which is a typical embodiment of the present invention, is a security testing system that tests for the presence or absence of security vulnerabilities in a web application using the DAST method, and comprises: an inspection execution unit that sends an original request and / or an inspection request which is a modified version of the original request to the web application, obtains the original response and / or inspection response in response from the web application for each, and records the request and response as inspection results; and a vulnerability determination unit that, based on the contents of one or more of the original request, the inspection request, the original response, and the inspection response, or based on the presence or absence of a difference between the original response and the inspection response, causes an LLM (Large-Scale Language Model) to determine the presence or absence of a predetermined event used to determine the presence or absence of a predetermined vulnerability, determines the presence or absence of the predetermined vulnerability based on the information including the presence or absence of the predetermined event, and outputs the determination result. [Effects of the Invention]

[0012] The effects obtained by some of the representative inventions disclosed in this application can be briefly explained as follows:

[0013] In other words, according to a typical embodiment of the present invention, in a security testing mechanism for web applications using the DAST method, it becomes possible to make a judgment about the behavior by considering the content and meaning of requests and responses, instead of simply comparing strings related to those strings, or in addition to doing so. [Brief explanation of the drawing]

[0014] [Figure 1] This figure outlines an example configuration of a security test system, which is one embodiment of the present invention. [Figure 2] This figure outlines an example of a website that may misjudge the presence or absence of vulnerabilities according to one embodiment of the present invention. [Figure 3]This is a diagram showing an overview of an example of the concept of a signature in one embodiment of the present invention. [Figure 4] This is a flowchart showing an overview of an example of the process flow of vulnerability testing in one embodiment of the present invention. [Figure 5] This is a diagram showing an overview of an example of vulnerability testing in one embodiment of the present invention. [Figure 6] This is a diagram showing an overview of an example of a response in one embodiment of the present invention. [Figure 7] This is a diagram showing an overview of an example of a prompt for causing an LLM to determine a location where parameters in one embodiment of the present invention are considered to be reflected. [Figure 8] This is a diagram showing an overview of an example of a regular expression output by an LLM in one embodiment of the present invention. [Figure 9] (a) and (b) are diagrams showing an overview of an example of a vulnerability testing pattern in one embodiment of the present invention. [Figure 10] This is a diagram showing an overview of an example of a prompt for causing an LLM to determine the presence or absence of a predetermined event used for determining whether to be a test target in one embodiment of the present invention. [Figure 11] (a) and (b) are diagrams showing an overview of other examples of determination results by an LLM in one embodiment of the present invention. [Figure 12] This is a diagram showing an overview of another example of a prompt for causing an LLM to determine the presence or absence of a predetermined event used for determining whether to be a test target in one embodiment of the present invention. [Figure 13] (a) and (b) are diagrams showing an overview of other examples of determination results by an LLM in one embodiment of the present invention. [Figure 14] This is a diagram showing an overview of another example of a prompt for causing an LLM to determine the presence or absence of a predetermined event used for determining whether to be a test target in one embodiment of the present invention. [Figure 15](a)(b) is a diagram showing an overview of another example of the determination result by the LLM in one embodiment of the present invention. [Figure 16] (a)(b) is a diagram showing an overview of an example of a confirmation processing screen in a web application. [Figure 17] It is a diagram showing an overview of another example of a prompt for causing an LLM to determine the presence or absence of a predetermined event used for determining whether or not to be an inspection target in one embodiment of the present invention. [Figure 18] It is a diagram showing an overview of an example of the determination result by the LLM in one embodiment of the present invention. [Figure 19] It is a diagram showing an overview of an example of the determination result by the LLM in one embodiment of the present invention. [Figure 20] It is a diagram showing an overview of an example of a prompt for causing an LLM to determine the presence or absence of a predetermined event used for determining the presence or absence of vulnerability in one embodiment of the present invention. [Figure 21] It is a diagram showing an overview of an example of the determination result by the LLM in one embodiment of the present invention. [Figure 22] It is a diagram showing an overview of an example of the determination result by the LLM in one embodiment of the present invention. [Figure 23] It is a diagram showing an overview of another example of a prompt for causing an LLM to determine the presence or absence of a predetermined event used for determining the presence or absence of vulnerability in one embodiment of the present invention. [Figure 24] It is a diagram showing an overview of an example of an original response and an inspection response in one embodiment of the present invention. [Figure 25] It is a diagram showing an overview of another example of the determination result by the LLM in one embodiment of the present invention. [Figure 26] (a)(b) is a diagram showing an overview of an example of a screen after login in a web application. [Figure 27] It is a diagram showing an overview of another example of a prompt for causing an LLM to determine the presence or absence of a predetermined event used for determining the presence or absence of vulnerability in one embodiment of the present invention. [Figure 28] This figure outlines an example of a determination result by LLM in one embodiment of the present invention. [Figure 29] This figure outlines an example of a determination result by LLM in one embodiment of the present invention. [Figure 30] This figure outlines an example of the data structure of inspection results in one embodiment of the present invention. [Figure 31] This figure outlines an example of the data structure of a vulnerability master in one embodiment of the present invention. [Modes for carrying out the invention]

[0015] Embodiments of the present invention will be described in detail below with reference to the drawings. In principle, the same parts will be denoted by the same reference numerals in all the drawings used to describe the embodiments, and repeated descriptions will be omitted. On the other hand, a part that is denoted by a reference numeral and described in one drawing may be referred to again in the description of another drawing, although it will not be shown again.

[0016] <Overview> In DAST (Data Absorbent Testing) security testing of web applications (websites, web servers), vulnerabilities are typically determined by performing unusual operations, such as tampering with or resending HTTP (Hypertext Transfer Protocol) requests, and then analyzing the changes in the web application's behavior (response). Examples of web application behavior include: • The process completed successfully. An error occurred. • A difference was observed in the response compared to when the request was not tampered with. • The header parameters have deprecated settings. These are some examples, but the term is not limited to these; it includes all events that can be inferred from the content of requests and responses (including supplementary information such as response time).

[0017] As mentioned above, when performing automated security testing using the DAST method, simply comparing the content of requests and responses as strings can lead to many errors in determining the behavior of a web application. For example, it may excessively identify differences in parts of an e-commerce site, such as the "recommended products" section, where the framework and structure of the web page remain the same but the content constantly changes.

[0018] Figure 2 is an overview of an example of a website where the presence or absence of vulnerabilities may be misidentified. Both the upper and lower screen examples show web pages that display "recommended products" on an e-commerce site. The overall framework and structure of the web pages are the same in both cases, but the breakdown of products displayed in "recommended products" (content enclosed in a dotted line frame) is different (this content may vary each time).

[0019] If these screens were to represent the screen displayed when the request is not tampered with (the original request) and the screen displayed when the request is tampered with, then it should be determined that there is no (substantial) difference between these screens. However, because the breakdown of products displayed in "Recommended Products" is different, it is possible to mistakenly determine that there is a difference. (Note that if an error screen is displayed when the request is tampered with, it is easy to determine that there is a difference between the two screens.)

[0020] When determining the content of requests and responses, it is possible to improve the accuracy of the determination by defining various rules. However, website structures vary widely, making it difficult to cover all patterns through rule definitions. Furthermore, increasing the number of rules necessitates sending numerous requests in a single check, increasing processing time. Therefore, to efficiently and effectively determine the presence or absence of vulnerabilities, it is necessary to understand and grasp the content and meaning of requests and responses before making a determination.

[0021] Furthermore, when determining the presence or absence of vulnerabilities, there are cases where, for example, deprecated settings in the request and response header parameters may not be detected by general rule-based analysis. For example, if the header parameters in an HTTP response are, HTTP / 1.1 200 OK Content-Type: text / html; charset=UTF-8 Set-Cookie: sessionid=123456789 In a case like that, it's easy to determine, even using a rule-based approach, that "123456789" is the session ID between the website and the user.

[0022] On the other hand, for example, HTTP / 1.1 200 OK Content-Type: text / html; charset=UTF-8 Set-Cookie: cakephp=123456789 When a session ID is set using a parameter name unique to the framework (in this case, the open-source web application framework CakePHP) ("cakephp"), it is possible to determine this by incorporating it into the rule base. However, regularly investigating the unique session IDs of all frameworks and continuously modifying the rules is a heavy burden.

[0023] Also, for example, HTTP / 1.1 200 OK Content-Type: text / html; charset=UTF-8 Set-Cookie: s_=123456789 If the session ID is set with a deprecated parameter name such as ("s_"), rule-based determination may not be possible, and attempting to determine it using rule-based determination is likely to result in over-determining, as well as placing a heavy burden on setting and modifying rules.

[0024] Similarly, for example, header parameters in an HTTP request, POST / complete HTTP / 2 Accept-Language: ja,en-US;q=0.9,en;q=0.8 user_id=user1&password=596359635963 If the content is like that, it is easy to determine, even using a rule-based approach, that "596359635963" is the password.

[0025] On the other hand, for example, POST / complete HTTP / 2 Accept-Language: ja,en-US;q=0.9,en;q=0.8 u=user1&p=596359635963 If a password is set with a deprecated parameter name such as "p", the rule-based approach may not be able to find a match and therefore cannot determine the password. Attempting to determine the password using the rule-based approach is likely to result in over-matching, and it also places a heavy burden on setting up and modifying the rules.

[0026] Similarly, for example, header parameters in an HTTP request, POST / complete HTTP / 2 Accept-Language: ja,en-US;q=0.9,en;q=0.8 CSRF-Token: 123456789 In a case like this, it is easy to determine, even using rules, that "123456789" is a CSRF token (a value that cannot be guessed by an attacker) used as a countermeasure against so-called CSRF (Cross-Site Request Forgeries) attacks.

[0027] On the other hand, for example, POST / complete HTTP / 2 Accept-Language: ja,en-US;q=0.9,en;q=0.8 XSRF-Token: 123456789 While it is possible to detect framework-specific CSRF tokens ("XSRF-Tokens") by incorporating them into the rule base, regularly investigating all frameworks and continuously modifying the rules is a significant burden.

[0028] Also, for example, POST / complete HTTP / 2 Accept-Language: ja,en-US;q=0.9,en;q=0.8 t_=596359635963 When a CSRF token is set with a deprecated parameter name such as ("t_"), rule-based detection may not be able to match or determine the vulnerability. Attempting to detect vulnerabilities using rule-based detection is likely to result in over-detection, and the burden of setting and modifying rules is also significant. To efficiently and effectively determine the presence or absence of vulnerabilities in such parameters, it is necessary to understand the contents of the request and response, as well as the names and values ​​of the parameters and headers, before making a determination.

[0029] One embodiment of the present invention is a security testing system that performs security testing using the DAST method, which involves sending a request related to a simulated attack from an external source to a running web application and determining the presence or absence of vulnerabilities based on the response received from the application.

[0030] In this process, based on one or more requests and responses, the presence or absence of changes in the behavior of the web application, such as the occurrence of errors or changes in screen content, is determined by a Generative AI (Artificial Intelligence) and an LLM (Large Language Model) (hereinafter sometimes collectively referred to as "LLM"), and the presence or absence of vulnerabilities is determined based on the determination result. In other words, the LLM is made to interpret the meaning of the requests and responses and determines whether the changes or differences in behavior are normal and constant, or whether they are due to tampering. This makes it possible to narrow down the determination of the presence or absence of vulnerabilities to changes or differences in areas directly affected by tampering, thereby improving accuracy and processing efficiency.

[0031] In such a scenario, if, for example, all websites and web pages were to be included in the inspection, and if every difference in the response from the inspected items were to be determined by LLM to determine whether it is normal or consistent, the number of LLM checks required could become enormous depending on the scale of the web application, leading to increased time and economic costs.

[0032] Therefore, in this embodiment, the websites and web pages to be inspected are determined and narrowed down in advance, and during the test, sections where the content of parameters that have been tampered with as a simulated attack is thought to be reflected are extracted, and the inspection target is narrowed down to those sections to determine whether or not there is a vulnerability.

[0033] <System Configuration> Figure 1 is a diagram illustrating an example configuration of a security test system, which is one embodiment of the present invention. The security test system 1 is composed of, for example, one or more server devices or virtual servers built on a cloud computing service, and a user terminal 2, such as a PC (Personal Computer) used by the user, accesses it via a network (not shown) such as the Internet, VPN (Virtual Private Network), or LAN (Local Area Network), using a web browser or dedicated application (not shown).

[0034] The security test system 1 implements various functions related to security testing by executing middleware such as an OS (Operating System), DBMS (Database Management System), and web server programs, as well as software running on them, which are loaded into memory from a storage device such as an HDD (Hard Disk Drive) or SSD (Solid State Drive), for example, using a CPU (Central Processing Unit) (not shown). This security test system 1 has various parts, such as a test execution unit 11 and a vulnerability determination unit 12, which are implemented by software. It also has various data stores, such as a test results unit 13 and a vulnerability master unit 14, which are implemented by databases and file tables.

[0035] The inspection unit 11 has the function of performing an inspection using the DAST method for each web page within the target website 3. Specifically, for each target web page, it sends a pseudo-attack request (inspection request) to the target website 3 by entering malicious values ​​into a form, and obtains the response (inspection response) from the target website 3 and records it in the inspection result 13. It also sends a normal request (original request) for comparison and obtains the response (original response) to it, and records it in the inspection result 13. The number of requests sent for each target web page may vary depending on the type of vulnerability being inspected.

[0036] The vulnerability determination unit 12 analyzes the differences between the inspection request and inspection response recorded in the inspection result 13 and the original request and original response, and determines the presence or absence of a vulnerability based on, for example, the percentage and content of the response difference (difference from the expected behavior depending on the type of vulnerability being inspected), error messages, etc., and records the determination result in the inspection result 13. In this embodiment, as described above, in determining the presence or absence of a vulnerability based on the request and response, an external or internal LLM4 is used to perform the determination considering the meaning and content of the request and response. In order to improve the efficiency and speed of processing, a configuration may be used that combines determination by LLM4 with an existing method of string comparison.

[0037] Figure 3 is a diagram illustrating an example of the signature concept in one embodiment of the present invention. In this embodiment, the inspection pattern for each vulnerability to be inspected, that is, how to modify the original request to create an inspection request, and how to consider the meaning of the request and response when making a determination, is handled using the concept (unit) of a signature. In practice, for example, each signature is implemented as a class.

[0038] In the example in Figure 3, a signature is implemented for each vulnerability being tested (SQL (Structured Query Language) injection in the example in the figure), and each signature includes processes such as determining whether or not to include the vulnerability in the test, creating and sending a test request by modifying the original request, and determining the presence or absence of the vulnerability based on the content of the modified test request and the obtained test response.

[0039] In the process of determining whether or not to include a signature in the inspection, LLM4 is used to determine whether the original request and response contain the aforementioned session ID, password, CSRF token, and other parameters. In the process of determining whether or not a vulnerability exists, LLM4 is used to make a judgment that takes into account the meaning and content of the inspection request and inspection response. However, processes that are common to other signatures (such as "Inspection Target Determination 1," "Inspection Target Determination 2," etc., and "Semantic Consideration Determination 1," "Semantic Consideration Determination 2," etc. in the example in the diagram) can be implemented as components in one or more classes ("LLM Utilization Class" in the example in the diagram) and called as appropriate from each signature.

[0040] Furthermore, as shown in the example in Figure 3, processes that utilize LLM4 can be grouped into a single class, or the processes for determining the object to be inspected can be grouped into a single class, or the processes for determining the semantic considerations can be grouped into a single class. In addition, processes other than those that utilize LLM4 can be implemented by grouping common elements across signatures into one or more classes.

[0041] <Processing flow> Figure 4 is a flowchart outlining an example of the vulnerability testing process in one embodiment of the present invention. In vulnerability testing, the testing unit 11 first starts a first loop process that is repeated for all URLs (Uniform Resource Locators) to be tested on the target website 3 (S01). The URLs to be tested are obtained and listed in advance, for example, by automatically crawling the target website 3 and analyzing the links within each web page. In the first loop process, a test scenario is played back in which an original request is sent to the URLs to be tested before tampering (S02), and the request (original request) and response (original response) are obtained and recorded in the testing result 13 (S03).

[0042] Figure 5 is a diagram illustrating an example of vulnerability testing in one embodiment of the present invention. Here, from the list of URLs to be tested shown in the upper figure, an original request as shown in the lower figure is sent via HTTP to the URLs enclosed by the dashed line, representing the original scenario before tampering, and an original response as shown is obtained.

[0043] Returning to Figure 4, after obtaining the original request and response, the vulnerability assessment unit 12 uses LLM4 to determine the locations in the original response where parameters are thought to be used or reflected (S04). For example, the assessment is performed for each parameter to be inspected, such as "user_id". If LLM4 determines that it is necessary during the assessment, it may change the parameter value to another normal value or tamper with it to an abnormal value and obtain the response again.

[0044] Figure 6 is a diagram illustrating an example of a response in one embodiment of the present invention. The top figure shows an example of the original response's HTML (HyperText Markup Language), indicating that it includes user attribute information. The middle figure shows an example of another response when the value of the parameter to be inspected (e.g., "user_id") is changed to another normal value, indicating that the user attribute information has changed. The bottom figure shows an example of a response when an abnormal value is specified for the parameter, indicating an abnormal state where the user attribute information is not included. Based on these responses, the parts where the parameter is thought to be reflected are determined.

[0045] Figure 7 is a diagram illustrating an example of a prompt that causes LLM4 to determine where a parameter is thought to be reflected in one embodiment of the present invention. The example in Figure 7 is a prompt that causes LLM4 to determine where a parameter is thought to be used in a given response and to create a regular expression to extract that part from the response. In addition to the role and tasks of LLM4, it shows that the output content in JSON (JavaScript Object Notation) format and instructions for the conditions and various constraints of the regular expression are included.

[0046] Furthermore, if the amount of information (number of tokens) to be entered via a prompt is large, including other prompts described later, the token limit of the prompt can be avoided by, for example, trimming unnecessary parts or splitting the information before input. Also, the response entered into LLM4 is not limited to HTML as shown in the example in Figure 6; response information from a web page, such as the response header or the response itself, or screen capture data may also be entered. In addition, the output content is not limited to JSON format; it may be output in multiple formats such as XML (eXtensible Markup Language) or HTML.

[0047] Figure 8 is a diagram illustrating an example of a regular expression output by LLM4 in one embodiment of the present invention. Here, we show an example of a regular expression output by LLM4 and the reason for its creation when the prompt in the example of Figure 7 is input to LLM4 and the response shown in the example of Figure 6 is input.

[0048] In this embodiment, LLM4 outputs a regular expression to obtain the parts of the response that are thought to reflect the parameters, but program code with a similar function may be output instead of a regular expression. Also, in this embodiment, the parts that are thought to reflect each parameter to be inspected are determined in advance, but the determination may be made only when certain conditions are met, such as when the difference between the original response and the response when the parameters are changed or tampered with, or when the difference between the original response and the response at the time of inspection in the processing described later is below a predetermined threshold.

[0049] Returning to Figure 4, a second loop process is initiated, repeating for all pre-configured test patterns (signatures) (S05). In the second loop process, the vulnerability determination unit 12 first uses LLM4, based on the original request and response, to determine whether or not an event used to determine whether or not to include the target test pattern in the test, taking into account their meaning and content (S06), and then determines whether or not to include it in the test based on the determination result (S07). If it is determined not to include it in the test (No in step S07), the process moves on to the next test pattern (S12). The details of the determination process in step S06 regarding whether or not to include it in the test will be described later.

[0050] If it is determined that the target inspection pattern should be the target of inspection (Yes in step S07), a test scenario is played back in which a modified request (inspection request) corresponding to the target inspection pattern is sent to the target URL (S08), and the inspection request and the response (inspection response) received from the web page related to the target URL are obtained and recorded in inspection result 13 (S09).

[0051] Then, the vulnerability determination unit 12 uses LLM4 to determine whether a predetermined event used to determine the presence or absence of a vulnerability is present, taking into account the meaning and content of the original request, response, and inspection request and response (S10). At this time, for the response, the determination is made based on the portion obtained by the regular expression (or program code) acquired in step S04, thereby improving the accuracy of the determination and streamlining the determination process. Based on this determination result, the system determines whether or not a vulnerability related to the target inspection pattern (signature) has been detected, records the determination result in inspection result 13 (S11), and proceeds to the processing of the next inspection pattern (S12). The details of the vulnerability determination process in steps S10 and S11 will be described later.

[0052] After the second loop process is completed by performing steps S08 to S11 for all test patterns, the first loop process moves on to processing the next target URL (S13). Then, after the first loop process is completed by performing steps S02 to S12 for all target URLs, the vulnerability test process is terminated. The contents of the test results 13 may be organized and processed and output by displaying them on the screen of the user terminal 2, etc.

[0053] <Determining the presence or absence of vulnerabilities> Figure 9 is a diagram illustrating an example of a vulnerability testing pattern in one embodiment of the present invention. Figure 9(a) shows an example of a tampered test request and its corresponding test response in one of the test patterns for testing SQL injection. SQL injection is tampered with by embedding malicious SQL statements in the request. In the example in Figure 9(a), the area enclosed by the dashed line in the test request indicates the part that has been tampered with from the original request shown in the example in Figure 5 above.

[0054] In the example in Figure 9(a), it is shown that the content of the inspection response to the inspection request is the same as the original response shown in the example in Figure 5 above. In this inspection pattern, if it is determined that there is no difference between the original response to the original request and the inspection response to the inspection request, it is determined that an SQL injection vulnerability has been detected.

[0055] On the other hand, Figure 9(b) shows an example of a tampered inspection request and its corresponding inspection response in one of the inspection patterns used to detect cross-site scripting. In cross-site scripting, a request is tampered with to embed a malicious script into the target website 3, which is then executed when accessed by a third party. In the example in Figure 9(b), the area enclosed by the dashed line in the inspection request indicates the part that has been tampered with from the original request shown in the example in Figure 5 above.

[0056] In the example in Figure 9(b), the content of the response to the inspection request differs from the original response shown in the example in Figure 5 above, as indicated by the dashed lines. Note that in the case of this inspection pattern, as shown in the example in the figure, for example, the inspection request is embedded <script>タグが検査レスポンスにも反射された場合に、クロスサイトスクリプティングの脆弱性を検知したと判断する。

[0057] このように、検査パターンによって、オリジナルリクエストおよびレスポンスと、攻撃に係る検査リクエストおよびレスポンスとの間に差分がない場合に脆弱性を検知したとする場合もあれば、差分がある場合に脆弱性ありと検知する場合もある。また、差分の有無に関わらず検査レスポンスの内容に基づいて判断する場合もある。このように、検査パターン(脆弱性)毎に着目すべき情報が異なることから、本実施の形態では、検査パターン毎、すなわちシグネチャ毎にどのような観点で脆弱性の有無の判定のために必要な所定の事象の有無(例えば、オリジナルレスポンスと検査レスポンスとの差分の有無)を判定するのかをLLM4に指示するためのプロンプトを予め用意しておく。

[0058] <検査対象とするか否かの判定>図4のステップS06、S07では、ステップS03で取得したオリジナルのリクエスト、レスポンスにつき、その意味や内容を考慮した形で、処理対象の検査パターンについて検査対象とするか否かを判定する。本実施の形態では、オリジナルリクエストやレスポンスにセッションIDやパスワード、CSRFトークンが含まれているか否かや、レスポンスに係るWebページがWebアプリケーションにおける処理(例えば、注文や送金等)の確定を示す画面であるか否かなどの事象の有無に基づいて判定する。

[0059] 例えば、オリジナルリクエストやレスポンスにセッションIDやパスワード、CSRFトークンが含まれている場合は、これらが正しく検証されているかを見るために検査対象とする(値を改ざんした検査リクエストを送信する対象とする)と判定する。一方で、オリジナルレスポンスにCSRFトークンが含まれていない場合であっても、当該オリジナルレスポンスが確定処理画面である場合には脆弱性がある(CSRF対策がされていない)可能性が高いとして検査対象とすると判定する。

[0060] 図10は、本発明の一実施の形態における検査対象とするか否かの判定に用いる所定の事象の有無をLLM4に判定させるプロンプトの例について概要を示した図である。図10の例は、与えられたリクエストやレスポンスにセッションIDが存在するか否かをLLM4に判定させるプロンプトであり、LLM4の役割とタスクに加えて、JSON形式での出力内容、および各種の制約条件の指示が含まれていることを示している。

[0061] 図11は、本発明の一実施の形態におけるLLM4による判定結果の他の例について概要を示した図である。図11(a)、(b)ともに、上段にオリジナルレスポンスのヘッダ·パラメータの例を示しており、下段にLLM4によるセッションIDの有無の判定結果の例を示している。図11(a)では、レスポンスに"s_"のようなルールベースでは判別が困難なパラメータ名によりセッションIDが設定されていた場合であっても、LLM4によりセッションIDであると適切に判定できたことを示している。また、図11(b)では、"user_id"というパラメータ名で設定されているものがセッションIDではないと適切に判定できたことを示している。

[0062] 図12は、本発明の一実施の形態における検査対象とするか否かの判定に用いる所定の事象の有無をLLM4に判定させるプロンプトの他の例について概要を示した図である。図12の例は、与えられたリクエストやレスポンスにパスワードが存在するか否かをLLM4に判定させるプロンプトであり、上述の図10などのプロンプトと同様に、LLM4の役割とタスクに加えて、JSON形式での出力内容、および各種の制約条件の指示が含まれていることを示している。

[0063] 図13は、本発明の一実施の形態におけるLLM4による判定結果の他の例について概要を示した図である。図13(a)、(b)ともに、上段にリクエストのヘッダ·パラメータの例を示しており、下段にLLM4によるパスワードの有無の判定結果の例を示している。図13(a)では、リクエストに"p"のようなルールベースでは判別が困難なパラメータ名によりパスワードが設定されていた場合であっても、同時に設定されている"u"というパラメータ名で設定された内容がユーザ名を表している可能性が高いことから、"p"はパスワードを表している可能性が高いとLLM4により判定できたことを示している。また、図13(b)では、"token"というパラメータ名で設定された文字列について、パスワードを意味するものではなく、他にパスワードに関連しそうなパラメータ等はないと適切に判定できたことを示している。

[0064] 図14は、本発明の一実施の形態における検査対象とするか否かの判定に用いる所定の事象の有無をLLM4に判定させるプロンプトの他の例について概要を示した図である。図14の例は、与えられたリクエストやレスポンスにCSRFトークンが存在するか否かをLLM4に判定させるプロンプトであり、上述の図10などのプロンプトと同様に、LLM4の役割とタスクに加えて、JSON形式での出力内容、および各種の制約条件の指示が含まれていることを示している。

[0065] 図15は、本発明の一実施の形態におけるLLM4による判定結果の他の例について概要を示した図である。図15(a)、(b)ともに、上段にリクエストのヘッダ·パラメータの例を示しており、下段にLLM4によるCSRFトークンの有無の判定結果の例を示している。図15(a)では、リクエストに"XSRF-Token"のようなフレームワーク独自のCSRFトークンが設定されていた場合であっても、CSRFトークンであるとLLM4により判定できたことを示している。また、図15(b)では、リクエストに"t_"のようなルールベースでは判別が困難なパラメータ名によりCSRFトークンが設定されていた場合であっても、その値の内容からCSRFトークンである可能性が高いとLLM4により判定できたことを示している。

[0066] 図16は、Webアプリケーションにおける確定処理画面の例について概要を示した図である。図16(a)、(b)いずれも、Webアプリケーション(図中の例ではオンラインショッピングアプリケーション)において商品の購入処理が完了した後に表示される画面の例を示している。図16(a)の例では、"発送までしばらくお待ち下さい”として購入処理が完了した旨の文言が表示されていることから、処理が確定した画面であることは正規表現を用いたルールベースでも判定することができるが、"完了しました”"実行できました”などの文言でも同様に判定することができ、ルールベースですべてを網羅することは困難である。"注文番号”が表示されていることをもって処理確定と判定することも可能であるが、「過去の注文ページ一覧」など処理が確定していない別の画面を誤判定してしまう可能性がある。

[0067] 一方、図16(b)の例では、ミャンマー(ビルマ)語で「支払いが完了しました」と書かれていることを示しているが、ルールベースではこのように多数の言語に広く対応した形で確定処理画面であるか否かを判定することは困難である。

[0068] 図17は、本発明の一実施の形態における検査対象とするか否かの判定に用いる所定の事象の有無をLLM4に判定させるプロンプトの他の例について概要を示した図である。図17の例は、与えられたレスポンスが確定処理画面か否かをLLM4に判定させるプロンプトであり、上述の図10などのプロンプトと同様に、LLM4の役割とタスクに加えて、JSON形式での出力内容、および各種の制約条件の指示が含まれていることを示している。

[0069] 図18、図19は、本発明の一実施の形態におけるLLM4による判定結果の例について概要を示した図である。図18の例では、上述の図17の例のプロンプトをLLM4に入力した上で、レスポンスとして上段の図に示すような処理画面のHTMLを入力した場合にLLM4により出力される判定結果の例を下段の図に示している。なお、LLM4に入力する処理画面は、図18の例に示したようなHTMLに限らず、図19の例の上段の図に示すような画面キャプチャのデータを入力してもよい。このような入力であっても図19の例の下段の図に示すようにLLM4により確定処理画面であるか否かの判定をすることができる。

[0070] <意味を考慮した脆弱性の有無の判定>図4のステップS10では、ステップS03で取得したオリジナルリクエスト、レスポンスと、ステップS09で取得した検査リクエスト、レスポンスに基づいて、その意味や内容を考慮した形で、脆弱性の有無の判定に用いる所定の事象の有無を判定する。本実施の形態では、ステップS06で判定したセッションIDやパスワードの有無等の各事象に加えて、検査レスポンスに係るWebページがエラー画面であるか否か、オリジナルレスポンスと検査レスポンスに差異が合った場合であっても実質的に同一ページであるか否か、レスポンスに係るWebページがログイン後の画面であるか否かなどの事象の有無を判定する。

[0071] 例えば、改ざんした検査リクエストに対する検査レスポンスがエラー画面の場合、不正なリクエストを正しく検証しているとして脆弱性なしと判断される一方で、オリジナルレスポンスと検査レスポンスが実質的に同一ページである場合は、不正なリクエストを検証できていないとして脆弱性ありと判断される可能性が高い。

[0072] また、例えば、検査リクエストにおいてセッションIDを書き換えたにも関わらずログインが失敗せず成功し、検査レスポンスにより「ログイン後画面」が表示された場合は脆弱性ありと判断することができる。また、検査レスポンスがログイン失敗の画面であった場合に、当該画面に「ログイン失敗」などの明白な文字列が存在する場合や、オリジナルレスポンスのログイン成功の画面との間の差異が大きい場合などでは、脆弱性なしと判断することができるが、差異が少なく判定が難しい場合などでは検査レスポンスが「ログイン後画面」であるかを判定し、「ログイン後画面」である場合は脆弱性ありの可能性があるとすることで脆弱性有無の検査精度の向上を図る。

[0073] 図20は、本発明の一実施の形態における脆弱性の有無の判定に用いる所定の事象の有無をLLM4に判定させるプロンプトの例について概要を示した図である。図20の例は、与えられたレスポンス(検査レスポンス)がエラー画面か否かをLLM4に判定させるプロンプトであり、LLM4の役割とタスクに加えて、JSON形式での出力内容、および各種の制約条件の指示が含まれていることを示している。

[0074] 図21、図22は、本発明の一実施の形態におけるLLM4による判定結果の例について概要を示した図である。図21の例では、上述の図20の例のプロンプトをLLM4に入力した上で、検査レスポンスとして上段の図に示すようなエラー画面のHTMLを入力した場合にLLM4により出力される判定結果の例を下段の図に示している。なお、LLM4に入力するエラー画面は、図21の例に示したようなHTMLに限らず、図22の例の上段の図に示すような画面キャプチャのデータを入力してもよい。このような入力であっても図22の例の下段の図に示すようにLLM4によりエラー画面の判定をすることができる。

[0075] 図23は、本発明の一実施の形態における脆弱性の有無の判定に用いる所定の事象の有無をLLM4に判定させるプロンプトの他の例について概要を示した図である。図23の例は、与えられた2つのレスポンス(オリジナルレスポンスと検査レスポンス)が(実質的に)同一のページか否かをLLM4に判定させるプロンプトであり、上述の図20のプロンプトの例と同様に、LLM4の役割とタスクに加えて、JSON形式での出力内容、および各種の制約条件の指示が含まれていることを示している。

[0076] 図24は、本発明の一実施の形態におけるオリジナルレスポンスと検査レスポンスの例について概要を示した図である。ここでは、上述の図2における上段の画面例がオリジナルレスポンスに係るものであり、下段の画面例が検査レスポンスに係るものであった場合の両レスポンスのHTMLを抜粋したものの例を示している。上述したように、この例では、両レスポンスにおいて「おすすめ商品」の内訳が相違しているが、その他の構成等はHTMLとしても同じであることを示している。

[0077] 図25は、本発明の一実施の形態におけるLLM4による判定結果の他の例について概要を示した図である。ここでは、上述の図23の例のプロンプトをLLM4に入力した上で、オリジナルレスポンスおよび検査レスポンスとして上述の図24の例に示すようなレスポンスを入力した場合にLLM4により出力される判定結果の例を示している。両ページにエラーは発生しておらず、「おすすめ商品」の内訳は異なるものの商品件数は一致しており、レイアウトや構造も同一であることから、これらは(実質的に)同一のページであると判断したことを示している。

[0078] 図26は、Webアプリケーションにおけるログイン後の画面の例について概要を示した図である。図26(a)、(b)いずれも、Webアプリケーション(図中の例ではブログアプリケーション)においてユーザがログインした後に表示されるブログのダッシュボード画面の例を示している。図26(a)の例では、画面右上部に"Currently logged in as USER01"としてユーザがログイン中である旨が表示されていることから、ログインした後の画面であることはルールベースでも容易に判定することができる。一方、図26(b)の例では、ログイン中である旨の表示がないことから、ルールベースではログイン後の画面であると判断することは容易ではない。

[0079] 図27は、本発明の一実施の形態における脆弱性の有無の判定に用いる所定の事象の有無をLLM4に判定させるプロンプトの他の例について概要を示した図である。図27の例は、与えられたレスポンスがログイン後の画面か否かをLLM4に判定させるプロンプトであり、上述の図20などのプロンプトと同様に、LLM4の役割とタスクに加えて、JSON形式での出力内容、および各種の制約条件の指示が含まれていることを示している。

[0080] 図28、図29は、本発明の一実施の形態におけるLLM4による判定結果の例について概要を示した図である。図28の例では、上述の図27の例のプロンプトをLLM4に入力した上で、検査レスポンスとして上段の図に示すようなログイン後画面のHTMLを入力した場合にLLM4により出力される判定結果の例を下段の図に示している。なお、LLM4に入力するエラー画面は、図28の例に示したようなHTMLに限らず、図29の例の上段の図に示すような画面キャプチャのデータを入力してもよい。このような入力であっても図29の例の下段の図に示すようにLLM4によりログイン後画面の判定をすることができる。

[0081] 上述した例では、検査対象とするか否かの判定に用いる事象として、セッションIDが存在するか否か、パスワードが存在するか否か、CSRFトークンが存在するか否か、および確定処理画面であるか否かをそれぞれ判定し、また、脆弱性の有無の判定に用いる所定の事象として、エラー画面か否か、同一ページか否か、およびログイン後の画面か否かをそれぞれ判定する例について示したが、これらはあくまで一例であり、他の事象について判定するようにしてもよい。検査対象とするか否か、および脆弱性の有無の判定のために他の事象の有無についてLLM4による判定が必要となる場合は、例えば、上述の図3の例に示したようなLLM利用クラスに適宜判定処理を追加してシグネチャから呼び出すなどにより拡張することができる。

[0082] <データ構成>図30は、本発明の一実施の形態における検査結果13のデータ構成の例について概要を示した図である。検査結果13は、検査実施部11による対象Webサイト3に対する検査毎に結果に係る情報を保持するテーブルであり、例えば、検査に係る項目として、検査ID、URLパラメータID、検査パターンID、検知ステータス、および挙動判定結果などの各項目を有し、検査対象URLパラメータに係る項目として、URLパラメータID、URL、およびパラメータなどの各項目を有する。また、リクエストに係る項目として、リクエストID、URLパラメータID、オリジナルフラグ、検知脆弱性ID、改ざん値、リクエストヘッダ、およびリクエストボディなどの各項目を有し、レスポンスに係る項目として、レスポンスID、リクエストID、レスポンスヘッダ、およびレスポンスボディなどの各項目を有する。

[0083] 検査に係る項目において、検査IDの項目は、対象の検査を一意に特定するIDの情報を保持する。URLパラメータIDおよび検査パターンIDの各項目は、それぞれ、対象の検査において用いられたURLパラメータおよび検査パターンを一意に特定するIDの情報を保持する。検知ステータスの項目は、対象の検査において脆弱性が検知されたか否かを示す情報を保持する。挙動判定結果の項目は、LLM4により対象のURLにおける挙動の判定を行った結果について説明するテキスト等の情報を保持する。

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

[0085] リクエストに係る項目において、リクエストIDおよびURLパラメータIDの各項目は、それぞれ、対象の検査におけるリクエストおよび用いられたURLパラメータを一意に特定するIDの情報を保持する。オリジナルフラグの項目は、対象のリクエストが改ざんしていないオリジナルのものか否かを示すフラグ(オリジナルの場合True)の情報を保持する。検知脆弱性IDおよび改ざん値の各項目は、いずれも上記のオリジナルフラグの値がFalse(改ざんしたリクエスト)の場合にのみ値が設定される項目であり、それぞれ、対象の検査において検知された脆弱性を一意に特定するIDの情報および対象のリクエストにおいて改ざんした値の情報を保持する。リクエストヘッダおよびリクエストボディの各項目は、それぞれ、対象のリクエストにおけるヘッダおよびボディの内容に係る情報を保持する。

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

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

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

[0089] 検査パターンに係る項目において、検査パターンIDおよび脆弱性IDの各項目は、それぞれ、対象の脆弱性を検査するための検査パターンおよび対象の脆弱性を一意に特定するIDの情報を保持する。挙動判定フラグの項目は、対象の脆弱性を検査するためにLLM4による挙動の判定を実施するか否かを示すフラグ(実施する場合True)の情報を保持する。検知理由の項目は、対象の検査パターンにより対象の脆弱性を検知した場合の検知理由を説明するテキスト等の情報を保持する。

[0090] 以上に説明したように、本発明の一実施の形態であるセキュリティテストシステム1によれば、DASTの手法によりセキュリティテストを行う際に、1つ以上のリクエストやレスポンスに基づいて、エラーの発生や画面内容の変化など、Webアプリケーションの挙動の変化の有無をLLM4により判定し、判定結果に基づいて脆弱性の有無を判断する。LLM4によりWebアプリケーションの挙動の判定を行うことで、単純な文字列の比較ではなく、人間が行う判断と同様に、リクエストやレスポンスの意味を考慮した判定を行うことが可能である。

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

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

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

産業上の利用可能性

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

符号の説明

[0095] 1…セキュリティテストシステム、2…ユーザ端末、3…対象Webサイト、4…LLM、11…検査実施部、12…脆弱性判定部、13…検査結果、14…脆弱性マスタ< / script>

Claims

1. A security testing system that uses the DAST (Dynamic Application Security Testing) method to check for security vulnerabilities in web applications, An inspection unit sends an original request and / or an inspection request that is a modified version of the original request to the aforementioned Web application, obtains the original response and / or inspection response received from the Web application for each, and records the request and response as inspection results. The system includes a vulnerability determination unit that, based on the contents of one or more of the original request, the inspection request, the original response, and the inspection response, or based on the presence or absence of a difference between the original response and the inspection response, causes the Large-Scale Language Model (LLM) to determine the presence or absence of a predetermined event used to determine the presence or absence of a predetermined vulnerability, determines the presence or absence of the predetermined vulnerability based on the information including the presence or absence of the predetermined event, and outputs the determination result. The vulnerability determination unit causes the LLM to determine the locations in the original response and / or the test response where the contents of the parameters in the original request and / or the test request are expected to be reflected, creates a regular expression or program code to obtain the locations from the original response and / or the test response, and determines whether or not the predetermined event exists for the locations obtained by the regular expression or program code, in a security test system.

2. In the security test system described in claim 1, A security test system in which the predetermined event is whether the original response or the test response is an error screen of the web application.

3. In the security test system described in claim 1, A security test system in which the predetermined event is whether or not the original response and the test response are substantially identical.

4. In the security test system described in claim 1, A security test system in which the predetermined event is whether or not a session ID exists between the original request, the original response, the inspection request, and the inspection response and the web application.

5. In the security test system described in claim 1, A security test system in which the predetermined event is whether or not a password for accessing the web application exists in one or more of the original request, the original response, the inspection request, and the inspection response.

6. In the security test system described in claim 1, A security test system in which the predetermined event is whether or not a CSRF token exists in the Web application in the original request or the inspection request.

7. In the security test system described in claim 1, A security test system in which the predetermined event is whether the original response or the test response is a screen after logging into the web application.

8. In the security test system described in claim 1, A security test system in which the predetermined event is whether or not the original response or the test response is a screen indicating that a predetermined process in the web application has been confirmed.

Images