JP2022153237A - security test system - Google Patents

Abstract

PROBLEM TO BE SOLVED: To enable verification of security of an application as "a security test" incorporated by a developer as one process in development processes.

SOLUTION: A security test system includes a transition recording section 21 for recording information of screen transition by an operation to an object application 4 on a browser 20, a scenario management section 33 for recording a transition graph formed by merging a plurality of pieces of screen transition information on a graph DB 37 as a transition scenario, a transition reproduction section 34 for transmitting a request to the object application 4 according to contents of the transition scenario, and a diagnostic processing section 35 for acquiring the request transmitted by the transition reproduction section 34, modifying the contents according to a specified vulnerability inspection pattern, transmitting it to the object application 4, and inspecting whether or not to have vulnerability based on the content of the received response.

SELECTED DRAWING: Figure 1

COPYRIGHT: (C)2023,JPO&INPIT

Description

The present invention relates to application development technology, and more particularly to technology effectively applied to a security test system that inspects application vulnerabilities.

Recent applications and systems are almost premised on the use of networks, and security management is an important requirement.

As a technology for security management in applications and systems, for example, Japanese Patent Application Laid-Open No. 2005-134995 (Patent Document 1) discloses that a setting file that defines the correspondence between parameter names and inspection items is stored, and parameters to be inspected are stored. is specified, it is possible for the system administrator to grasp the status of security measures at the program level by identifying the corresponding inspection items based on the configuration file and executing them for the relevant parameters. It describes a security management system that

On the other hand, in addition to the mechanism to implement or support security management for such applications and systems, it is also necessary to inspect and eliminate security holes and vulnerabilities at the development stage of applications and systems. It has been demanded. In this respect, conventionally, as an activity separated from the application development process (for example, specification formulation → design → implementation → unit test → integration test → comprehensive test), a "security consultant" separate from the developer and development team In the past, it was common to request a specialist such as the above to perform a diagnosis to ensure security.

JP-A-2005-134995

There are the following problems in requesting a specialist such as a "security diagnostician" to perform a security check at the development stage of an application. In other words, the schedule depends on the specialist who performs the diagnosis, an external vendor, etc., and it is difficult to freely control the implementation schedule.

In addition, the overhead cost for ordering and requesting work is large, and it is difficult to flexibly request diagnosis in small units. may be released. Furthermore, since this process is separate from the application development process, there are many cases where security diagnosis is performed after the developer has completed the test process related to the operation of the application, which delays the timing at which problems are detected. This increases the risk and cost of rework.

Therefore, the purpose of the present invention is to ensure security at the development stage of an application, not by a specialist such as a "security consultant" as an activity separate from the application development process, but by a developer or a development team. To provide a security test system that can be implemented as a "security test" incorporated as one step in a series of development steps.

The above and other objects and novel features of the present invention will become apparent from the description of the specification and the accompanying drawings.

A brief outline of typical inventions disclosed in the present application is as follows.

A security test system, which is a representative embodiment of the present invention, is a security test system that inspects the presence or absence of security vulnerabilities in an application. a transition recording unit for recording screen transition information including the information of; a scenario management unit for recording a transition graph obtained by merging a plurality of screen transition information as a transition scenario in the graph recording unit; a transition reproducing unit that transmits a request to an application; and a request transmitted by the transition reproducing unit that is obtained, modifies the contents of the request according to a specified vulnerability inspection pattern, and transmits the request to the application. and a diagnostic processing unit that inspects the presence or absence of the specified vulnerability based on the content of the response received from the application.

Among the inventions disclosed in the present application, the effects obtained by representative ones are briefly described below.

That is, according to the representative embodiment of the present invention, the security guarantee at the application development stage is implemented as a "security test" incorporated as one step in a series of development processes by developers and development teams. It becomes possible to

1 is a diagram showing an overview of a configuration example of a security test system that is an embodiment of the present invention; FIG. 1 is a diagram showing an overview of an example of a security test use case according to an embodiment of the present invention; FIG. FIG. 4 is a diagram showing an overview of an example of transition scenario management in one embodiment of the present invention; FIG. 4 is a sequence diagram showing an overview of an example of a transition scenario recording technique according to an embodiment of the present invention; It is the figure which showed the outline|summary about the example which integrates the vulnerability test result in one embodiment of this invention. FIG. 4 is a diagram showing an overview of an example of rules when integrating vulnerability inspection results according to an embodiment of the present invention; FIG. 4 is a diagram showing an overview of an example of a screen displayed on a browser according to one embodiment of the present invention; FIG. FIG. 5 is a diagram showing an overview of another example of a screen displayed on a browser according to one embodiment of the present invention;

BEST MODE FOR CARRYING OUT THE INVENTION Hereinafter, embodiments of the present invention will be described in detail with reference to the drawings. In principle, the same parts are denoted by the same reference numerals throughout the drawings for describing the embodiments, and repeated descriptions thereof will be omitted. On the other hand, parts that have been described with reference numerals in one drawing may be referred to with the same reference numerals, although they are not shown again in the description of other drawings.

<Overview>
The security test system, which is one embodiment of the present invention, enables developers and development teams to independently conduct "security tests" as one step in the development process of applications and systems. It is an information processing system that

As a result, for example, it can be implemented as one of the tests in the development team, so there is no need to match the convenience of external vendors, etc., and it is possible to adjust the schedule according to the progress of development and test at any time. Become. In addition, since it is implemented as an internal process in development, there is no overhead cost for ordering or requesting work, so it can be implemented in flexible and detailed units according to the unit of development and release, and security is not checked. It is possible to prevent a release in the (not completed) state from being done. Furthermore, since it becomes possible to implement a security test for each individual module at the timing when functional communication between modules becomes possible, it is possible to carry out the test at an early stage and identify problems. In addition, since reconfirmation after correction can be performed immediately, it is possible to efficiently rotate the cycle of problem discovery → correction to strengthen security.

Even if security testing is incorporated into the application development process, for example, there are no engineers with security knowledge in the development team, or even if some tools are used that have never worked on security in the first place. Usually, it is difficult to easily incorporate tools, such as the development team not being able to master them and the tools being expensive.

Therefore, in this embodiment, the security test system is designed not for engineers with security knowledge, but for "developers", so that it can be easily incorporated into the development process. Specifically, for example, by implementing it as a cloud service, without the need to set up server equipment, etc., developers can perform everything from registering test scenarios to executing them and checking results using a browser. . Each developer should be able to flexibly register test scenarios (screen transitions) and execute tests for each part of the screen transitions, and share scenario and test result information with the development team. This enables efficient and speedy test execution and management, such as having developers who can handle only the necessary parts test at the necessary timing.

<System configuration>
FIG. 1 is a diagram showing an overview of a configuration example of a security test system that is an embodiment of the present invention. The security test system 1 includes, for example, a security test server 3 configured as a server system by a server device, a virtual server built on a cloud computing service, etc., and a personal computer (PC) or the like used by each developer. User terminals 2, which are information processing terminals, are connected to each other via a network such as the Internet, a VPN (Virtual Private Network), or a LAN (Local Area Network) (not shown).

Then, the user terminal 2 and the security test server 3 can each access a development server system (not shown) and execute the application or system under development, that is, the target application 4 that is the target of the security test. .

The user terminal 2 has, for example, a browser 20, and can execute the target application 4 via the browser 20 based on instructions and operations from the developer. In addition, by accessing the security test server 3, it is possible to perform security tests related to the target application 4, register test scenarios, and check test results. As the browser 20, any commonly used web browser can be appropriately used as long as it has an interface such as an API (Application Programming Interface) that allows the user to implement extended functions and add-ons. In the following description, it is assumed that Google Chrome (registered trademark, hereinafter the same) is used as the browser 20 unless otherwise specified.

The browser 20 has a transition recording unit 21 implemented as an extended function or add-on (Extensions in the case of Google Chrome). The transition recording unit 21 records user operations and screen transitions by recording combinations of requests sent by the browser 20 and responses received when the user executes and operates the target application 4 on the browser 20. have a function. The recorded information is sent to the security test server 3, which will be described later, and based on this, a transition scenario is generated and registered. It should be noted that the technique of recording screen transitions based on the requests and responses exchanged between the web browser and the application, and then modifying the contents of the recorded requests to change the screen transitions and operation details is not a common technique. Since it is widely used in various web application testing tools, a detailed description will not be given.

The security test server 3 uses a CPU (Central Processing Unit) (not shown) to develop an OS (Operating System) on a memory from a recording device such as a HDD (Hard Disk Drive), middleware such as a Web server, and runs on it. Executing the software implements various functions described below related to security testing by the development team. In this embodiment, the security test server 3 is assumed to be implemented by a virtual server built on a cloud computing service.

The security test server 3 has units such as a UI processing unit 31, a basic function unit 32, a scenario management unit 33, a transition reproduction unit 34, a diagnosis processing unit 35, and a tenant management unit 36 implemented by software. It also has various data stores such as a graph database (DB) 37, a diagnostic data DB 38, and a user DB 39, which are implemented by databases, files, and the like.

For example, the UI processing unit 31 receives a request from the browser 20 on the user terminal 2 via a Web server program (not shown), and displays various management screens related to security tests, screens related to test execution, etc., which will be described later. It has a function of displaying on the browser 20 . The base function unit 32 has a function of providing various base functions commonly used by each unit during various processes in the security test server 3 . The base functions include, for example, a so-called CI/CD (continuous integration/continuous delivery) environment, a security function of the system itself, a log management function, and the like.

For example, the scenario management unit 33 expresses the structure of the screen transitions of the target application 4 as a directed graph (transition graph) based on the information about the screen transitions recorded by the browser 20, as will be described later. It has a function of holding in the graph DB 37 . It also has a function of generating and outputting an optimal path (transition scenario) to a URL (Uniform Resource Locator) to be inspected designated by a user based on a transition graph.

The transition reproduction unit 34 has a function of reproducing screen transitions by, for example, generating a request related to the transition scenario generated by the scenario management unit 33 and transmitting the request to the target application 4 . For example, when performing a security test, the diagnostic processing unit 35 intercepts the request sent by the transition reproducing unit 34 to the target application 4 and extracts one or more signatures specified by the user. It has a function of diagnosing the presence or absence of security holes and vulnerabilities by rewriting parameters according to an inspection pattern for each vulnerability) and judging the response, and recording the diagnosis result in the diagnosis data DB 38 .

The tenant management unit 36 has, for example, a function of managing teams and tenants (contractors) so that a plurality of developers can perform security tests jointly or sharedly. Information on developers, teams, and tenants is registered in the user DB 39 .

<Use case>
FIG. 2 is a diagram outlining an example of a security test use case according to an embodiment of the present invention. In order to perform a security test on the screen (URL) to be inspected, it is necessary to actually transition to the screen to be inspected. In this embodiment, first, the user records (records) operations on the browser 20 up to the screen to be inspected using the transition recording unit 21, which is an extended function of the browser 20. Register information (S1). Once registered, transition information can be reused repeatedly, including by other users.

Thereafter, the user selects a screen (URL) to be inspected and a signature (inspection pattern), and executes scanning (vulnerability inspection) (S2). Here, the transition reproducing unit 34 and the diagnostic processing unit 35 of the security test server 3 access the target URL on the development server and continue to issue rewritten requests.

After the scan is performed, the user (it may be the person who performed the target test, or the person in charge of the development team, the person in charge, or the approval authority such as the superior) will be notified of the detected vulnerabilities. performs triage (scrutinization of test results) (S3). That is, it determines whether or not the detected vulnerability is caused by false detection, and determines whether or not countermeasures are necessary for the vulnerability. As for the inspection results, the scan results performed by multiple users are integrated and merged and managed centrally. By looking at the list of results, you can grasp the overall situation, including the results of the scans you have performed. Since a certain level of knowledge and experience is required to perform triage, accompanying information such as commentary on the vulnerability, log information at the time of detection, and comments at the time of past triage are important. It is desirable to be able to manage and present them in association with each other.

The developer fixes the detected vulnerability (S4). After correction, in order to confirm that the vulnerability has been resolved, the process returns to step S2 and repeats the series of steps after the scan until the vulnerability is resolved. In this embodiment, as described above, the URL and signature to be inspected can be specified at the time of scanning, and scanning can be performed in small units. It is possible to check efficiently by

<Transition scenario management>
FIG. 3 is a diagram showing an overview of an example of transition scenario management in one embodiment of the present invention. Regarding the screen transition information recorded by the transition recording unit 21 of the browser 20 in step S1 of FIG. , is represented as a directed graph (transition graph) with edges representing transitions between screens, and is registered and held in the graph DB 37 . At this time, for example, "1" in the path transition of "1"→"2"→"3"→"4" and the path transition of "1"→"2"→"5"→"4", Like nodes "2" and "4", screens common to a plurality of record results are represented by merging them into the same node. As a result, the links (routes) on the transition graph are traced for transitioned screens, and the screens are added (recorded) as nodes, thereby increasing the link network and increasing the reachable URLs to be inspected. become.

When the user designates a URL to be inspected, the scenario management section 33 of the security test server 3 generates an optimum route from the transition graph. For example, in the transition graph shown on the left side of FIG. ”→“9”. Note that this optimum route does not necessarily have to be the shortest route. The generated route becomes a transition scenario as shown in the diagram on the right side of FIG. 3, and scanning (vulnerability inspection) is performed according to this transition.

In addition to the screen transition path, the transition scenario also includes, for example, information in which screen operations (actions) required to generate transitions between screens are recorded. For example, in order to make the transition from screen "1" to screen "6", it is necessary to click "details" and then click the "user information" button. These pieces of information can be expressed, for example, as DOM (Document Object Model) events generated by the browser 20, or locator information of the relevant screen acquired by XPath (XML Path Language) or the like.

FIG. 4 is a sequence diagram outlining an example of a transition scenario recording method according to an embodiment of the present invention. First, the user operates the browser 20 up to the target screen (URL), and the transition recording unit 21 of the extended function of the browser 20 records the transition up to the target screen (1 in the figure). . The transition recording unit 21 confirms with the scenario management unit 33 whether or not the recorded transition is registered in the graph DB 37 (2 in the figure). The scenario management unit 33 generates and returns a transition scenario of the optimum route to reach the target URL (3 in the figure).

After that, the user tests whether or not the screen transition can be reproduced based on the returned transition scenario in the local environment on the browser 20 (4 in the figure). The screen transition is officially registered with the scenario management unit 33 (5 in the figure). The scenario management unit 33 officially registers the transition scenario in the graph DB 37, and then transmits it to the transition reproduction unit 34 (6 in the figure). Then, the transition reproduction unit 34 transmits a request to the target application 4 based on the acquired transition scenario, and tests whether or not the screen transition can be reproduced (7 in the figure). If the test is OK, the scenario management unit 33 registers the target transition scenario in the graph DB 37 as being scannable (8 in the figure).

After that, the user selects a URL to be inspected from the list of scannable URLs displayed in the browser 20 via the scenario management unit 33, designates a signature, and instructs execution of scanning (9 in the figure). ). The scenario management unit 33 generates a transition scenario related to the specified URL based on the transition graph registered in the graph DB 37, and the transition reproduction unit 34 reproduces the screen transition according to the transition scenario on the target application 4. At the same time, the diagnostic processing unit 35 intercepts the request and rewrites the parameters, thereby executing the vulnerability test for the specified signature (10 in the figure).

<Integration of vulnerability inspection results>
In this embodiment, for the results of multiple scans individually performed by multiple users, even if there are similar results in units of combinations of target URLs, specified parameters, and detected vulnerabilities, By merging these, centrally managed. As a result, even if each user repeats scans in small units, each user can grasp the status of the inspection results of the entire development team, including the results of the scans performed by the user himself/herself.

FIG. 5 is a diagram showing an overview of an example of integrating vulnerability inspection results according to one embodiment of the present invention. On the left side of the figure, vulnerabilities are detected when "parameter A", "parameter B", and "parameter C" are specified as a result of "scan 1" for the target URL. As a result of another "scan 2", a vulnerability similar to "scan 1" is detected when "parameter A" is specified, and a vulnerability is detected when "parameter B" and "parameter C" are specified. is not detected.

In the present embodiment, the inspection results of these "scan 1" and "scan 2" are unified (merged). The right side of the figure shows an example of the merged inspection results. Since the same vulnerability was detected in both scans for "parameter A" for the target URL, the inspection result is set to "detected." indicates that

Also, for "parameter B", although a vulnerability was detected in "scan 1", it was not detected in the subsequent "scan 2", and corrective measures were taken during that time (for example, for one of the scan results Such comments were left, etc.), indicating that the inspection result is set as "solved". In addition, if a vulnerability was detected in "Scan 1" for "Parameter C", but it was determined to be a false positive, even if a vulnerability was detected again in "Scan 2", the inspection result is automatically set as a "false positive", indicating that there is no need to scrutinize the detection results again.

FIG. 6 is a diagram outlining an example of rules for integrating vulnerability inspection results according to an embodiment of the present invention. Here is an example of how to set the vulnerability detection status when merging one result with the other for the results of two vulnerability tests performed with the same parameters for the same URL. is shown. If there are three or more test results, for example, all the test results can be finally merged by merging the past test results one by one in chronological order.

As shown in the figure, in the present embodiment, five detection state transitions of "detected", "accepted", "erroneous detection", "waiting for confirmation", and "handled" are managed. In general, "detection" is the situation in which a vulnerability is detected, "acceptance" is the situation in which the existence of the vulnerability is accepted, and "false positive" is the situation in which the vulnerability that was detected was a false positive. "Waiting for Confirmation" indicates that the detected vulnerability has been corrected and is no longer detected, and that it is currently being confirmed whether or not the vulnerability has actually been resolved. This indicates that it has been confirmed that the problem has been resolved.

In order to merge multiple inspection results, each URL must be the same, and the sameness of the URL is a problem. Sometimes there is. Therefore, rules and conditions for merging substantially identical URLs may be set.

<User interface>
In the present embodiment, a screen (UI) displayed on the browser 20 by the UI processing unit 31 of the security test server 3 is implemented as an SPA (Single Page Application), mainly displaying a list of multiple pieces of information, It has a main UI that displays a screen for performing various settings, and a sub UI that displays detailed information on individual items mainly selected from a list and details related to recording of screen transitions using the extended functions of the browser 20. .

The main UI displays, for example, information for each tenant (contract), information for each development team, and information for each individual within the team. For each tenant, for example, screens related to development team management within a tenant (team creation, deletion, archiving, etc.) and tenant settings (billing/accounting management, common settings within a tenant, etc.) are displayed. In addition, on an individual basis, for example, a screen for personal setting (change of display name, icon, etc.) and password change is displayed.

For each development team, for example, screens such as a list of URLs to be inspected and a list of scan results are displayed. A screen for managing various settings related to the development team and members belonging to the team may be displayed. Also, a dashboard screen may be displayed that shows the test status of the target development team.

FIG. 7 is a diagram showing an overview of an example of a screen displayed on the browser 20 according to one embodiment of the invention. FIG. 7 shows an example of a list display of URLs to be inspected. For example, for a URL selected by the user from a list of URLs to be inspected, detailed information is seamlessly displayed on the side panel displayed on the right side. In addition to the detailed information displayed on the side panel, for example, URL details (URL name, category, etc.), request/response (URL request/response parameter list), transition scenario (for example, a diagram as shown in the example of FIG. 3), related URLs (a list of URLs linked from the URL to be inspected), and the like.

FIG. 8 is a diagram outlining another example of the screen displayed on the browser 20 according to one embodiment of the present invention. FIG. 8 shows an example of a vulnerability check (scan) result list. For example, for vulnerabilities selected by the user from a list of detected vulnerabilities, the side panel displayed on the right seamlessly displays detailed information. Detailed information displayed on the side panel includes, as shown in the diagram, vulnerability information (vulnerability description and countermeasures), detection details (requests/responses when actually inspected), triage content (past detection results, judgment results of scrutiny, comments, etc.).

In the sub UI, for example, information related to the screen that the user has opened on the browser 20 is displayed on the developer tools that the user is using (eg, DevTools in the case of Google Chrome). This allows the user to seamlessly access and operate this information during development of the target application 4, thereby improving productivity. The content displayed on the sub UI is basically the same as the content displayed on the side panel of the main UI described above, except for the content related to the screen transition recording function, which is a function unique to the sub UI (browser extension function). . Therefore, for example, it is desirable to share parts as much as possible between the main UI (SPA) and the sub UI (browser extension) by configuring each part related to display as a component.

In addition, except for the content related to the screen transition recording function, which is a function specific to the sub UI (browser extension function), the configuration related to other user interfaces is not limited to the configuration described above, and may be changed according to requirements, restrictions, etc. It can be configured as appropriate. For example, in the present embodiment, the main UI is implemented as SPA, but other implementation methods may be used.

As described above, according to the security test system 1 according to one embodiment of the present invention, the "security test" can be easily incorporated into the development process so that the developer and the development team can independently perform it. Become. Specifically, since the results of scans performed by each developer are integrated and merged and centrally managed, even if each developer has only performed a small unit of scan, the entire inspection can be performed. By looking at the list of results, it is possible to grasp the overall situation, including the results of the scans performed by the user himself/herself.

Further, when registering screen transition scenarios, the operations and screen transitions performed by each developer on the browser 20 are recorded by the transition recording unit 21 implemented as an extended function of the browser 20 and managed as a directed graph. This makes it possible to reuse existing screen transitions, including those registered by other developers. It is possible to narrow down to smaller units and scan repeatedly. In other words, efficient and speedy test execution and management are possible, such as testing of only the necessary portions of the target application 4 by a developer capable of responding at the necessary timing.

Although the invention made by the present inventor has been specifically described above based on the embodiments, the present invention is not limited to the above embodiments, and can be variously modified without departing from the scope of the invention. Needless to say.

It should be noted that the above embodiment has been described in detail in order to explain the present invention in an easy-to-understand manner, and is not necessarily limited to those having all the described configurations. Moreover, it is possible to add, delete, or replace some of the configurations of the above-described embodiments with other configurations.

For example, in the list of URLs to be inspected in the example of FIG. 7 and the result list of vulnerability inspection (scan) in the example of FIG. It is also possible to input a development version number (a number specifying the content of development) to the target URL when referring to the scan result, and record the scan result of each URL and the development version number in association with each other. This enables the user to search and display each scan result or target URL from the development version number.

In addition, in the present embodiment, screen transition information is held as a directed graph, but it may be held by another method that can realize a similar function.

Further, each of the above configurations, functions, processing units, processing means, and the like may be realized by hardware, for example, by designing a part or all of them using an integrated circuit. Moreover, each of the above configurations, functions, etc. may be realized by software by a processor interpreting and executing a program for realizing each function. Information such as programs, tables, and files that implement each function can be stored in recording devices such as memories, hard disks, SSDs (Solid State Drives), or recording media such as IC cards, SD cards, and DVDs.

Further, in each of the above drawings, control lines and information lines are those considered to be necessary for explanation, and not all control lines and information lines for implementation are necessarily shown. In fact, it may be considered that almost all configurations are interconnected.

INDUSTRIAL APPLICABILITY The present invention can be used for a security test system that inspects application vulnerabilities.

1 -- security test system, 2 -- user terminal, 3 -- security test server, 4 -- target application,
20... browser, 21... transition recording unit,
31 UI processing unit 32 base function unit 33 scenario management unit 34 transition reproduction unit 35 diagnosis processing unit 36 tenant management unit 37 graph DB 38 diagnosis data DB 39 user database

Claims (1)

A security testing system for checking for security vulnerabilities in an application,
a transition recording unit that records screen transition information including request/response information generated by a user's operation of the application on a browser;
a scenario management unit for recording, in a graph recording unit, a transition graph obtained by merging a plurality of pieces of screen transition information respectively recorded by computers of a plurality of users, as a transition scenario;
a transition reproducing unit that transmits a request to the application according to the contents of the transition scenario;
acquiring the request transmitted by the transition reproducing unit, modifying the contents of the request according to the specified vulnerability inspection pattern and transmitting the request to the application, and based on the contents of the response received from the application a diagnostic processing unit that inspects the presence or absence of the specified vulnerability;
A security test system that records a comment specified by a user's computer on an inspection result in association with the inspection result, and presents the recorded comment to the user's computer.

Images