Detection device

Abstract

This detection device (100) identifies a location including an instruction to be executed by an input which is from the outside and included in the source code. The detection device (100) constructs a constraint expression corresponding to a character string operation performed for a location including an instruction to be executed by an input from the specified outside. In addition, the detection device (100) determines the presence / absence of vulnerability pertaining to Injection in the source code on the basis of the pattern of the character string that satisfies the constraint based on the constructed constraint expression and the regular expression pertaining to the pattern of the prescribed character string input.

Description

Detection device

[0001] The present invention relates to a detection device.

[0002] The vulnerability related to Injection is a vulnerability that causes an unintended operation of a web application by exploiting external inputs and string operations (hereinafter sometimes simply referred to as "external inputs") performed on the web application or the like. When there is a vulnerability related to Injection in a web application, malicious attackers may exploit the vulnerability, leading to various security incidents such as information leakage and redirection to malicious external websites.

[0003] Therefore, the above-mentioned vulnerability related to Injection is recognized as a significant threat in modern society where web applications are widely popular, and research on its detection technology is actively carried out. For example, as a prior art, a technology related to the automatic generation of test inputs for detecting bugs and vulnerabilities from the source code of web applications and the like is known (see, for example, Non-Patent Document 1).

[0004] Gary Wassermann, Zhendong Su, Sound and Precise Analysis of Web Applications for Injection Vulnerabilities, PLDI '07: Proceedings of the 28th ACM SIGPLAN Conference on Programming Language Design and Implementation, June 2007Pages 32-41.<URL:https: / / dl.acm.org / doi / 10.1145 / 1250734.<1250739>、<URL:https: / / www.cs.ucdavis.edu / ~su / publications / pldi07.pdf>

[0005] However, the above-mentioned conventional techniques have a problem in that it is difficult to efficiently detect injection vulnerabilities. For example, the conventional techniques represent string operations as finite state transducers. However, if integer operations, such as operations that handle string subscripts in string operations, are treated as finite state transducers, the number of states becomes large, and the processing may not be performed efficiently.

[0006] Therefore, in order to solve the above-mentioned problems and achieve the object, the detection device of the present invention is characterized by having an identification unit that identifies a location in source code that includes an instruction that is executed by external input; a construction unit that constructs a constraint expression corresponding to a string operation performed on the location identified by the identification unit that includes an instruction that is executed by external input; and a determination unit that determines whether or not the source code has an injection vulnerability based on a string pattern that satisfies the constraint of the constraint expression constructed by the construction unit and a regular expression related to a predetermined string input pattern.

[0007] The present invention has the effect of enabling efficient detection of injection-related vulnerabilities.

[0008] FIG. 1 is a diagram illustrating an overall image of processing by a detection device according to this embodiment. FIG. 2 is a diagram illustrating an example of a string constraint according to this embodiment. FIG. 3 is a diagram illustrating an example of a regular expression according to this embodiment. FIG. 4 is a diagram illustrating an example of the configuration of a detection device according to this embodiment. FIG. 5 is a table diagram illustrating an example of a command list according to this embodiment. FIG. 6 is a diagram illustrating an example of a specification process according to this embodiment. FIG. 7 is a diagram illustrating an example of a constraint equation construction process according to this embodiment. FIG. 8 is a diagram illustrating an example of a process for detecting vulnerabilities related to injection according to this embodiment. FIG. 9 is a flowchart illustrating an example of a process procedure for detecting vulnerabilities related to injection according to this embodiment. FIG. 10 is a diagram illustrating an example of a computer that executes detection processing according to this embodiment.

[0009] DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS Hereinafter, embodiments of the present invention will be described with reference to the accompanying drawings. Note that the embodiments are not limited to the following description.

[0010] <Explanation of Overall Picture of Processing by Detection Device> Fig. 1 is a diagram illustrating an overall picture of processing by a detection device 100 according to this embodiment. The detection device 100 shown in Fig. 1 is an example of a computer that provides a technology for identifying a portion of source code that may be affected by an attack by a malicious attacker because it includes an instruction executed by an external input or string manipulation (hereinafter simply referred to as an "external input-affected portion"), and determining whether or not an external input exists for the identified external input-affected portion that satisfies predetermined constraints.

[0011] As described above, an injection vulnerability is a vulnerability that allows an attacker to relay malicious code to another system through an application. For example, SQL injection and cross-site scripting (hereinafter sometimes referred to as "XSS") are known as injection vulnerabilities. SQL injection is a vulnerability that allows an attacker to input a malicious SQL query in an application that creates an SQL query based on external input, such as an external input or string manipulation, and then executes the SQL query, thereby generating output that is not intended by the developer. Furthermore, XSS is a vulnerability that allows an attacker to input a malicious string (e.g., an HTML tag) in an application that reflects external input on a screen, etc., thereby generating output that is not intended by the developer.

[0012] In recent years, such injection vulnerabilities have been considered a threat, and reference techniques for detecting such injection vulnerabilities are known. For example, a technique is known in which operations related to strings that appear in source code obtained from a web application are expressed as string constraints to detect injection vulnerabilities (first reference technique). Also, a technique is known for automatically generating test inputs based on finite state transducers or the like to verify the presence or absence of attacks to detect bugs and vulnerabilities in web applications (second reference technique).

[0013] (Regarding Character Count Constraints) Here, the above-mentioned character string constraints will be explained. FIG. 2 is a diagram showing an example of a character string constraint according to this embodiment. A character string constraint is a constraint made up of variables that store character strings, etc. For example, it is expressed using a logical formula such as that shown in (1) of FIG. 2.

[0014] Here, "x" means a variable of a string. For example, "|x|=3" is a constraint that means that the length of the string that goes into x is "3". On the other hand, "x∈L([a-z] ＊ ) where x is the regular expression "[a-z] ＊ This constraint means that a string belonging to the language represented by "x=abc" (a regular expression representing a string of zero or more consecutive characters from a to z)" is to be recorded. For example, assignments that satisfy the above constraint include "x=abc" and "x=ddd".

[0015] Various String Constraint Solvers (hereinafter sometimes referred to as "SCS") are known as programs for solving the above-mentioned string constraints. These SCSs receive string constraints written in accordance with a syntax defined by a known SMT-LIB or the like. For example, if the string constraint shown in FIG. 2(1) is written in the SMT-LIB format, it will be expressed in a format such as that shown in FIG. 2(2). Note that known SCS technologies include, for example, Z3 Solver, CVC5, and OSTRICH.

[0016] (Regular Expressions) Next, the above-mentioned regular expressions will be described. FIG. 3 is a diagram showing an example of a regular expression according to this embodiment. A regular language is expressed using a regular expression. For example, as shown in FIG. 3, the regular expression r follows a syntax defined using Backus-Naur form (BNF).

[0017] In this embodiment, the meaning of a regular expression may be one that is generally defined. That is, the language L(r) of regular expression r may be one defined as shown in FIG. 3. In addition to the definition shown in FIG. 3, range characters [C] and [^C] may also be used. Here, C is a set of characters, and L([C]) = C, L([^C]) = Σ\C. Here, "Σ" represents the set of all characters, and "\" represents the difference set.

[0018] (Regarding the First Reference Technology) The reference technology will now be further described. The first reference technology described above targets source code obtained from a web application and determines whether or not an injection vulnerability exists by expressing operations related to strings appearing in the source code as string constraints.

[0019] For example, a technique for detecting parameter tampering attacks is known as a related technique for detecting vulnerabilities by solving constraint equations related to character strings. This detection technique extracts string conditions related to parameters from HTML forms as string constraints, and attempts to detect malicious input using the string constraints.

[0020] However, the first reference technology detects vulnerabilities by solving constraint equations related to character strings, but because it is a technology specialized in detecting parameter tampering attacks, it has a problem in that it does not perform detection using regular expressions (hereinafter, may be referred to as "Attack String specifications") that express a set of character strings that may be vulnerable to attacks if they match character strings expressed in a regular language.

[0021] (Regarding the Second Reference Technology) The above-mentioned second reference technology is a technology related to the automatic generation of test inputs for detecting bugs and vulnerabilities in web applications. For example, the second reference technology automatically generates inputs for verifying the presence or absence of attacks by expressing possible values ​​of a string variable to be inspected as a context-free grammar, expressing string operations using finite-state transducers, and taking the intersection of the grammar obtained as a result of the operations with an attack string expressed in a regular language.

[0022] However, the second reference technology has problems such as the fact that when processing integers, such as processing that handles subscripts of strings, is handled as a finite state transducer in string operations, the number of states becomes large, processing is not performed efficiently, and processing speed decreases.

[0023] Therefore, the detection device 100 according to this embodiment determines whether or not the source code contains an injection vulnerability by using the specifications of the input attack string and a constraint expression corresponding to a character string that can be input for an instruction included in the input source code.

[0024] 1, a series of steps in the vulnerability detection process performed by the detection device 100 according to this embodiment will now be described. For example, as shown in (1) of Fig. 1, the detection device 100 identifies an affected area of ​​an external input, which is an area containing an instruction that can evaluate malicious code contained in source code, such as an instruction to receive and execute character string data contained in input source code.

[0025] The detection device 100 constructs a constraint equation corresponding to an external input, such as a malicious string input or string manipulation, performed on the identified affected portion of the external input, as shown in (2) of Fig. 1. For example, the detection device 100 constructs a constraint equation including a constraint on an argument (a value suspected of being malicious code) to be passed to the instruction included in the identified portion in (1) of Fig. 1.

[0026] Then, as shown in (3) of Fig. 1, the detection device 100 determines whether or not the source code has an injection vulnerability based on a string pattern that satisfies the constraints of the constructed constraint expression and a regular expression (attack string specification) related to a predetermined string input pattern. For example, the detection device 100 determines that the source code has an injection vulnerability if the constraints of the constructed constraint expression are satisfied and the attack string specification includes a value (argument) that is suspected of being malicious code. At this time, the detection device 100 can output the result of the determination regarding the presence or absence of an injection vulnerability as information about the injection vulnerability.

[0027] In this way, the detection device 100 according to this embodiment determines whether or not there is a malicious string that can be input from the outside and that satisfies the constraint formula constructed so as to correspond to the affected portion of the external input identified from the source code and the attack string specifications, thereby enabling efficient detection of injection vulnerabilities.

[0028] <Description of Detection Apparatus> Next, the configuration of the detection apparatus 100 will be described. FIG. 4 is a diagram showing an example of the configuration of the detection apparatus 100 according to this embodiment. As shown in FIG. 4, the detection apparatus 100 has a communication unit 110, a storage unit 120, and a control unit 130. Although not shown in FIG. 4, the detection apparatus 100 may also include an input unit such as a keyboard or a mouse for receiving input such as operations by a user or the like. Furthermore, the detection apparatus 100 may also include a display unit such as a display for displaying information about injection-related vulnerabilities to a user or the like.

[0029] (Communication Unit 110) The communication unit 110 performs data communication related to input of application source code, attack string specifications, etc., and output of a determination result (information on injection-related vulnerabilities) by a determination unit 134 (described later).

[0030] The communication unit 110 is realized by a network interface card (NIC) or the like, and controls communication via a telecommunication line such as a local area network (LAN) or the Internet. The communication unit 110 is connected to a network via a wired or wireless connection as necessary, and can transmit and receive information bidirectionally.

[0031] (Storage Unit 120) The storage unit 120 stores data and programs used for various processes by the control unit 130, as well as various data acquired through the operation of the control unit 130. The storage unit 120 is realized by a semiconductor memory element such as a random access memory (RAM) or a flash memory, or a storage device such as a hard disk or an optical disk. As shown in FIG. 4 , the storage unit 120 also has an instruction list DB 121. The storage unit 120 also stores a location that calls an instruction acquired from the source code by the identification unit 132, which will be described later.

[0032] (Instruction List DB 121) The instruction list DB 121 is a database that stores instructions that receive and execute character string data and are used to identify instructions that may be malicious code from input source code. Specifically, the instruction list DB 121 stores an identification number that identifies the stored instruction, in association with the instruction.

[0033] Here, an example of an instruction stored in the instruction list DB 121 will be described. FIG. 5 is a table diagram showing an example of an instruction list according to this embodiment. As shown in FIG. 5, the instruction list DB 121 stores instructions that receive and execute character string data, in association with an identification number "No." that identifies the stored instruction. For example, the instruction list DB 121 stores "document.write" as an instruction, in association with No. "1."

[0034] (Control Unit 130) The control unit 130 has an internal memory for temporarily storing programs defining various processing procedures and the like of the detection device 100 and processing data, and is realized by electronic circuits such as a CPU (Central Processing Unit) and an MPU (Micro Processing Unit), and integrated circuits such as an ASIC (Application Specific Integrated Circuit) and an FPGA (Field Programmable Gate Array). As shown in FIG. 4 , the control unit 130 has a reception unit 131, an identification unit 132, a construction unit 133, a determination unit 134, and an output unit 135.

[0035] (Reception Unit 131) The reception unit 131 receives source code of a web application or the like and the specifications of an Attack String. The reception unit 131 can receive the source code and the specifications of an Attack String via an input unit such as a keyboard or a touch panel, or the communication unit 110 that performs data communication with other information processing devices, etc.

[0036] (Identification unit 132) The identification unit 132 identifies locations affected by an external input that are included in source code of a web application or the like. Specifically, the identification unit 132 identifies locations in the source code that include instructions that match instructions for receiving and executing string-type data that are stored in advance in the instruction list DB 121 as locations affected by the external input. For example, the identification unit 132 scans a predetermined program to obtain locations that call specific instructions included in the instruction list stored in the instruction list DB 121. The identification unit 132 then stores the obtained locations in the storage unit 120.

[0037] Here, an example of the identification process performed by the identification unit 132 will be described. FIG. 6 is a diagram showing an example of the identification process according to this embodiment. As shown in FIG. 6, the identification unit 132 uses the instruction list stored in the instruction list DB 121 to identify an instruction (an instruction that receives and executes character string data) that can evaluate malicious code from source code such as Javascript (registered trademark) accepted by the acceptance unit 131. Then, the identification unit 132 identifies a location that includes the instruction as a location affected by the external input.

[0038] For example, the identification unit 132 identifies an instruction in the source code, "innerHTML ((2) in FIG. 6)," that matches an instruction in the instruction list, "innerHTML ((1) in FIG. 6)." Then, the identification unit 132 identifies the location containing the identified matching "innerHTML" as the location affected by the external input.

[0039] (Construction unit 133) The construction unit 133 constructs a constraint equation corresponding to a string operation performed on the affected part of the external input identified by the identification unit 132. Specifically, the construction unit 133 constructs a constraint equation by converting, using a function that converts into a logical expression, a predetermined expression to be substituted for an argument that is suspected of being malicious code related to an instruction that receives and executes string-type data, which is present in the affected part of the external input.

[0040] Here, an example of the constraint equation construction process performed by the construction unit 133 will be described. Fig. 7 is a diagram showing an example of the constraint equation construction process according to this embodiment. The construction unit 133 constructs a constraint equation that constrains a passed argument ("X" in the following equation), which is a value suspected of being malicious code, for each instruction present in an affected portion of an external input identified by the identification unit 132.

[0041] For example, the construction unit 133 converts the instructions (program) into an SSA (Static Single Assignment) format as shown in Fig. 7. Next, the construction unit 133 identifies an expression e to be substituted into X from the SSA format program.

[0042] The construction unit 133 applies a function F that converts an expression into a logical expression to add X = F(e) to the constraint expression. For example, when a subexpression of e includes variables x1, x2, ..., the construction unit 133 adds x1 = F(e1), x2 = F(e2), ... to the constraint expression. Note that e1 and e2 here represent expressions substituted for x1 and x2 in the SSA format program.

[0043] Here, the function F that converts an expression of an SSA format program into a constraint expression will be described, taking as an example a case where the expression e is defined in BNF notation. The expression e is expressed in BNF notation as the following mathematical expression (1).

[0044]

[0045] In the above-mentioned formula (1), "x" represents a variable, "c" represents a constant, and "m (e-overline)" represents a string manipulation function call. Note that "e-overline" is actually written as a single character with an overline written on the "e", but in this text it will be written as "e-overline". Furthermore, "e-overline" represents the following formula (2).

[0046]

[0047] In addition, in an SSA program, the subexpression "e" becomes the variable "x." The function F is then defined as follows:

[0048]

[0049] Furthermore, the following equation (6) is added to the constraint equation for equation (5): Note that "m'" is an operation related to a character string provided in the SMT solver. For example, if m is "replace", then m' becomes "str.Replace_re".

[0050]

[0051] It is assumed that the SSA format program contains the following formulas (7) and (8).

[0052]

[0053] Next, a specific flow of the process of constructing a constraint equation will be further explained. As shown in Fig. 7, the constructor 133 analyzes a program included in the source code and constructs a constraint equation that constrains a character string to be input into "innerHTML=X" included in the program. Specifically, the constructor 133 converts the program included in the source code into a program in SSA format, and analyzes the converted SSA format program by working backward from the bottom of the source code according to the procedure described below, thereby constructing the above-mentioned constraint equation.

[0054] The construction unit 133 converts the statement "X=v4;" shown in (1-1) of Figure 7, which means that "v4" is substituted for "X" contained in "innerHTML=X;", into the formula shown in (2-1) of Figure 7 using the function F.

[0055] The constructing unit 133 converts the description "v4=replace(v6, v7, v11);" shown in (1-2) of FIG. 7 into the formula shown in (2-2) of FIG. 7 using the function F.

[0056] The construction unit 133 converts the descriptions "V7=\<!-(.*?)--\>);" and "v11=;" shown in (1-3) of Fig. 7 into the formula shown in (2-3) of Fig. 7. Then, the construction unit 133 further converts the formula in (2-3) of Fig. 7 into the formula shown in (2-4) of Fig. 7.

[0057] By performing the above-described processing, the construction unit 133 converts the program in the SSA format into constraint expressions as shown in (2-5) of FIG.

[0058] (Determination Unit 134) Now, returning to Fig. 4 , the description will be continued. The determination unit 134 determines whether or not there is an injection vulnerability in the source code, based on a string pattern that satisfies the constraints of the constraint expressions constructed by the construction unit 133 and the specifications of an Attack String, which expresses, as a regular expression, a string that may be a malicious external input. Specifically, the determination unit 134 determines that there is an injection vulnerability in the source code of the web application when there is a string pattern that satisfies the string constraints of the constraint expressions constructed by the construction unit 133 and a regular expression, which expresses, in a regular language, a string input pattern that is input by malicious string manipulation from outside.

[0059] For example, the determination unit 134 uses SCS to determine whether "φ ∧ (X∈L)" is satisfiable for a constraint φ related to a value X suspected of being malicious code constructed by the construction unit 133. If the constraint is satisfiable, the determination unit 134 determines that the analyzed source code contains an injection vulnerability. On the other hand, if the constraint is not satisfiable, the determination unit 134 determines that the corresponding location does not contain an injection vulnerability. Note that the determination unit 134 can use CVC5, Z3, OSTRICH, etc. when performing the above-mentioned determination process.

[0060] (Output unit 135) The output unit 135 outputs information about injection vulnerabilities based on the determination result by the determination unit 134. For example, when the determination unit 134 determines that an injection vulnerability is included, the output unit 135 outputs information such as "There is an injection vulnerability" or a counterexample obtained for the above-mentioned constraint equation using a constraint solving technique such as an SMT solver. Furthermore, when the determination unit 134 determines that there is no injection vulnerability, the output unit 135 outputs information such as "There is no injection vulnerability."

[0061] The output unit 135 can output the detection results to the user via a display unit such as a display provided in the detection device 100 or a communication unit 110 that performs data communication with other information processing devices.

[0062] (Example of Injection-Related Vulnerability Detection Processing) Hereinafter, an example of injection-related vulnerability detection processing by the detection device 100 according to this embodiment will be described. Fig. 8 is a diagram showing an example of injection-related vulnerability detection processing according to this embodiment.

[0063] The detection device 100 constructs the constraint equation shown in Fig. 8(2) based on the description of the source code shown in Fig. 8(1). Note that the description of Fig. 8(1-1) in the source code of Fig. 8(1) is "X １ " and the description of (1-2) in Figure 8 is "X ２ " and the description of (1-3) in Figure 8 is "X ３ "

[0064] Here, the description in (1-2) of FIG. 8 indicates that the description in (1-1) of FIG. 8 is replaced with "<!--(.*?)--￥>)." The detection device 100 then replaces "X ２ " into the constraint equation shown in (2-1) of FIG. 8. Also, the description in (1-3) of FIG. 8 indicates that the contents of (1-2) of FIG. 8 are displayed. The detection device 100 converts "X ３ " is converted into the constraint equation shown in FIG. 8 (2-2).

[0065] The detection device 100 constructs the logical expression shown in (4) of Fig. 8 based on the constructed constraint expression shown in (2) of Fig. 8 and the input regular expression (attack string specification) shown in (3) of Fig. 8. The detection device 100 then determines whether the input source code has an injection vulnerability based on whether the constructed logical expression ((4) of Fig. 8) is satisfiable. That is, if the constructed logical expression ((4) of Fig. 8) is satisfiable, the detection device 100 determines that there is an injection vulnerability, and if it is not satisfiable, the detection device 100 determines that there is no injection vulnerability.

[0066] (Procedure for Injection-Related Vulnerability Detection Processing) Hereinafter, a procedure for injection-related vulnerability detection processing implemented by the detection device 100 according to this embodiment will be described. Fig. 9 is a flowchart showing an example of the injection-related vulnerability detection processing procedure according to this embodiment.

[0067] The receiving unit 131 receives the source code and the specification of the attack string (S101).

[0068] The identifying unit 132 identifies the affected part of the external input from the received source code (S102). The constructing unit 133 constructs a constraint expression (S103). The determining unit 134 determines whether or not there is an external input that satisfies the constraint expression and the attack string specifications (S104).

[0069] If a corresponding external input exists (Yes in S105) and all of the received source code has been determined (Yes in S106), the output unit 135 outputs the result (S107).Then, the detection apparatus 100 ends the process.

[0070] On the other hand, if there is no corresponding external input (No in S105) or if all of the received source code has not been determined (No in S106), the detection apparatus 100 returns to the previous step and continues the process.

[0071] (Effects) Next, the effects achieved by the detection device 100 according to this embodiment will be described. The identification unit 132 of the detection device 100 according to this embodiment identifies a location affected by an external input included in source code. The construction unit 133 of the detection device 100 constructs a constraint expression corresponding to a string operation performed on the location affected by the external input identified by the identification unit 132. The determination unit 134 of the detection device 100 then determines whether or not there is an injection vulnerability in the source code, based on a string pattern that satisfies the constraints imposed by the constraint expression constructed by the construction unit 133 and the attack string specifications. Therefore, the detection device 100 according to this embodiment has the effect of being able to efficiently detect injection vulnerabilities.

[0072] The identification unit 132 identifies, as an affected area of ​​the external input, a location in the source code that includes an instruction that matches an instruction for receiving and executing pre-stored string-type data. In this way, the detection device 100 determines whether an instruction included in the source code is likely to be vulnerable to attack based on whether the instruction matches a pre-registered list. In this way, the detection device 100 achieves the effect of efficiently identifying areas that may have injection vulnerabilities based on the above-described determination results.

[0073] The construction unit 133 constructs a constraint equation by using a function that converts a predetermined expression substituted for an argument suspected of being malicious code related to an instruction that receives and executes string-type data, which is present in an affected area of ​​an external input, into a logical expression. In this way, the detection device 100 constructs a constraint equation corresponding to a string operation that may be performed on the affected area of ​​the identified external input. Then, the detection device 100 uses the constructed constraint equation to efficiently identify areas that may have injection vulnerabilities.

[0074] The determination unit 134 determines that an injection vulnerability exists in the source code of the web application when a string pattern exists that satisfies the string constraints imposed by the constraint expression constructed by the construction unit 133 and the attack string specifications. In this way, the detection device 100 determines whether an injection vulnerability exists in the input source code by determining whether an external input exists that satisfies the input attack string specifications and the constraint expression. Therefore, the detection device 100 has the effect of being able to efficiently identify locations that may have injection vulnerabilities.

[0075] As described above, the detection device 100 according to this embodiment makes it easy to detect injection vulnerabilities, and by using this, it is possible to eliminate the threat of injection vulnerabilities in web applications.

[0076] Furthermore, the detection device 100 according to this embodiment detects injection vulnerabilities using constraint expressions corresponding to the specifications of an attack string expressed as a regular language and string operations, thereby making it possible to reduce the amount of computer processing required for vulnerability detection compared to conventional vulnerability detection techniques based on finite state transducers or the like.

[0077] <Modifications> Modifications realized by the detection device 100 according to this embodiment will be described below.

[0078] (Data, etc.) The string constraints, regular expressions, constraint expressions, command lists, functions related to logical expression conversion, names of functional parts of the detection device 100, steps, processes, names of steps or processes, etc. used in the description of the above embodiments are merely examples and can be changed as desired.

[0079] For example, the command list DB 121 stores commands for receiving and executing string-type data in the source code of a web application, but the content shown in FIG. 5 is merely an example of a command in XSS and is not limited to this.

[0080] (Flowcharts, etc.) The steps in a flowchart, etc. may be interchanged and performed as long as there is no contradiction, and some steps may not be performed. In addition, conjunctions such as "next," "continue," "further," "at this time," and "on this occasion" used in the description of a flowchart do not limit the order or timing of performing the processes in the flowchart.

[0081] (System) The information including the processing procedures, control procedures, specific names, various data and parameters shown in the above documents and drawings can be changed as desired unless otherwise specified.

[0082] Furthermore, the components of each device shown in the figure are conceptual functional components and do not necessarily have to be physically configured as shown. In other words, the specific form of distribution and integration of each device is not limited to that shown. In other words, all or part of the devices can be functionally or physically distributed or integrated in any unit depending on various loads, usage conditions, etc.

[0083] <Hardware Configuration> The components of each device shown in the figure are conceptual functional components and do not necessarily have to be physically configured as shown. In other words, the specific form of distribution and integration of each device is not limited to that shown, and all or part of them can be functionally or physically distributed and integrated in any unit depending on various loads, usage conditions, etc. Furthermore, all or any part of the processing functions performed by each device can be realized by a CPU and a program analyzed and executed by the CPU, or can be realized as hardware using wired logic.

[0084] Furthermore, among the processes described in this embodiment, all or part of the processes described as being performed automatically can also be performed manually using known methods. In addition, the information including the processing procedures, control procedures, specific names, various data, and parameters shown in the drawings can be changed as desired unless otherwise specified.

[0085] <Program> In one embodiment, the various devices constituting the detection device 100 can be implemented by installing a detection program as package software or online software on a desired computer. For example, by executing the detection program on an information processing device, the various devices constituting the detection device 100 can function. The information processing device referred to here includes desktop and notebook personal computers. In addition, the information processing device also includes mobile communication terminals such as smartphones and mobile phones, and slate terminals such as PDAs (Personal Digital Assistants).

[0086] 10 is a diagram showing an example of a computer that executes the detection process according to this embodiment. The computer 1000 includes, for example, a memory 1010 and a CPU 1020. The computer 1000 also includes a hard disk drive interface 1030, a disk drive interface 1040, a serial port interface 1050, a video adapter 1060, and a network interface 1070. These components are connected by a bus 1080.

[0087] The memory 1010 includes a ROM (Read Only Memory) 1011 and a RAM 1012. The ROM 1011 stores a boot program such as a BIOS (Basic Input Output System). The hard disk drive interface 1030 is connected to a hard disk drive 1090. The disk drive interface 1040 is connected to a disk drive 1100. A removable storage medium such as a magnetic disk or optical disk is inserted into the disk drive 1100. The serial port interface 1050 is connected to a mouse 1110 and a keyboard 1120, for example. The video adapter 1060 is connected to a display 1130, for example.

[0088] The hard disk drive 1090 stores, for example, an OS 1091, an application program 1092, a program module 1093, and program data 1094. That is, a program that defines each process of the various devices that make up the detection device 100 is implemented as a program module 1093 in which computer-executable code is written. The program module 1093 is stored, for example, in the hard disk drive 1090. For example, a program module 1093 for executing processes similar to those of the functional configurations of the various devices that make up the detection device 100 is stored in the hard disk drive 1090. Note that the hard disk drive 1090 may be replaced with an SSD (Solid State Drive).

[0089] Furthermore, setting data used in the processing of the above-described embodiment is stored as program data 1094, for example, in the memory 1010 or the hard disk drive 1090. Then, the CPU 1020 reads the program module 1093 or the program data 1094 stored in the memory 1010 or the hard disk drive 1090 into the RAM 1012 as necessary, and executes the processing of the above-described embodiment.

[0090] The program module 1093 and program data 1094 are not limited to being stored in the hard disk drive 1090, but may also be stored in, for example, a removable storage medium and read by the CPU 1020 via the disk drive 1100 or the like. Alternatively, the program module 1093 and program data 1094 may be stored in another computer connected via a network (such as a LAN or a WAN (Wide Area Network)). The program module 1093 and program data 1094 may then be read by the CPU 1020 from the other computer via the network interface 1070.

[0091] Although the present embodiment has been described above, the present embodiment is not limited by the descriptions and drawings that form a part of the disclosure. In other words, other embodiments, examples, operational techniques, etc. that are made by those skilled in the art based on the present embodiment are all included in the scope of the present embodiment.

[0092] REFERENCE SIGNS LIST 100 Detection device 110 Communication unit 120 Storage unit 121 Command list DB 130 Control unit 131 Reception unit 132 Identification unit 133 Construction unit 134 Determination unit 135 Output unit

Claims

1. A detection device comprising: an identification unit that identifies a location in source code that includes an instruction to be executed by an external input; a construction unit that constructs a constraint equation corresponding to a string operation performed on the location identified by the identification unit that includes the instruction to be executed by the external input; and a determination unit that determines whether or not the source code has an injection vulnerability based on a string pattern that satisfies the constraints imposed by the constraint equation constructed by the construction unit and a regular expression related to a predetermined string input pattern.

2. The detection device described in claim 1, characterized in that the identification unit identifies a location in the source code that contains an instruction that matches an instruction to receive and execute pre-stored string-type data as a location that contains an instruction to be executed by the external input.

3. The detection device described in claim 1, characterized in that the construction unit constructs the constraint equation by converting a specified expression that is substituted for an argument suspected of being malicious code related to an instruction to receive and execute string-type data, which is present in a location including an instruction to be executed by external input, using a function that converts into a logical expression.

4. The detection device described in claim 1, characterized in that the determination unit determines that there is an injection vulnerability in the source code of the web application when there is a string pattern that satisfies the string constraint based on the constraint expression constructed by the construction unit and the regular expression that expresses in a regular language the pattern of the string input input by malicious string manipulation from outside.

Images