JP4587976B2 - Application vulnerability inspection method and apparatus - Google Patents

Description

  The present invention relates to an application vulnerability inspection apparatus that inspects an application such as a Web application, detects a location where a vulnerability is included in the source code, and provides information that supports a vulnerability correction work of a programmer. Is.

In general, there are two methods for inspecting vulnerabilities included in software (applications): a method for examining software in operation and a method for statically examining a source code of software.
The software inspection method in operation is to input various data into the operating software and determine whether or not a vulnerability is included based on the result.
For example, the inspection using the Manual Intercept plug-in of WebScarab published by OWASP.

On the other hand, the static software inspection method is to inspect the source code and detect the use place of the “dangerous method” included in the standard library of the programming language. A “dangerous method” is a method that creates a vulnerability in software if the programmer is not careful about its use.
The static inspection method is described in detail in Chapter 2 of Non-Patent Document 1 below.

Information processing promotion business association security center: Investigation report about security assurance of open source software Part 2 Investigation of efficient inspection technology of open source software: February 2003

When software processes character string data acquired from outside the software with a "dangerous method", it becomes a vulnerability. Examples of this vulnerability include OS command insertion vulnerability, SQL command insertion vulnerability, and cross-site scripting vulnerability.
When the source code that contains such vulnerabilities is inspected by the conventional static inspection method, it is possible to detect the location where there is a possibility of vulnerability, but specifically, from where the external data is input and through which method There is no technology that provides information about what is passed to a potentially vulnerable method. Therefore, there is a problem that a lot of work man-hours are required when the programmer visually determines whether or not the vulnerability is true or when countermeasures for the vulnerability are taken.
Also, if the vulnerability actually occurs and if it is not a vulnerability but it becomes a vulnerability by changing a code other than the corresponding part a little (potential vulnerability), the same output is made. Therefore, the priority order for taking measures cannot be set. Therefore, there is a problem that effective measures cannot be implemented.

  On the other hand, when the inspection is performed by the conventional dynamic inspection method, the above-described potential vulnerability is not detected. The location of the code that causes the vulnerability in the source code is not pointed out. In addition, since it is not known which value is used in the source code of the Web application among the parameters and header fields included in the request data transmitted to the Web application, all parameters and header fields are simulated. It is necessary to set and inspect a proper attack code.

  The object of the present invention is to provide not only the method call location with a fragile transition to the programmer, but also information on the external input data location and the method through which the data passes, reducing the amount of work required for vulnerability determination and countermeasures And detecting potentially vulnerable areas that are not vulnerable at present but become vulnerable with only minor changes to the code other than the relevant areas, and the vulnerable areas and the latent areas. It is an object of the present invention to provide a vulnerability inspection method and apparatus for an application that can detect and detect a particularly vulnerable portion so that a programmer can effectively take countermeasures in descending order of risk.

  In order to achieve the above object, an application vulnerability inspection method according to the present invention receives an inspection start notification from an application inspection management unit, and inputs data from outside the source code for the source code of the application to be inspected. The location of the code that may be vulnerable and the input position of the data from the outside of the application that causes the vulnerability are checked by analyzing the transition by the value and method referenced by the variable, distinguishing each location And a first step of acquiring information of a method through which the data passes, and a request data for inspection is sent to the inspection target application supplied by the application supply means for the part detected in the first step. , Its response data and pre-registered vulnerability judgment code And by comparing, to determine if it contains a vulnerability, characterized as a brittle, further comprising a second step of outputting to distinguish not.

  In addition, the application vulnerability inspection apparatus according to the present invention receives an inspection start notification from the application inspection management means, and for the source code of the inspection target application, distinguishes data from outside the source code for each input location, Analyzes the values referenced by variables and transitions by methods to check for vulnerabilities, and the location of code that may be vulnerable and the input location of data from the outside of the application and the data pass Request data for inspection is sent to the inspection target application supplied by the application supply means for the first means for acquiring method information and the location detected by the first means, and the response data and Vulnerability by comparing with registered vulnerability judgment code To determine if it contains, it characterized as a brittle, further comprising a second means for the distinguished outputs are not.

According to the present invention, it is possible to provide not only a method call location with a fragile transition to a programmer but also information on an external input data location and a method through which the data passes. The amount of work required can be reduced.
Also, not only vulnerable parts, but also potentially vulnerable parts that are not vulnerable at present but that become vulnerable can be detected just by changing a code other than the relevant parts.
Further, since the vulnerable portion and the potentially vulnerable portion can be detected separately, the programmer can effectively take countermeasures in order from the one with the highest degree of danger.

Hereinafter, embodiments of the present invention will be described in detail with reference to the drawings.
In the following embodiments, an application using the java language will be described as an example. Also, in the following description and drawings, the package name is omitted, java.io.PrintWriter is PrintWriter, java.lang.String is String, javax.servlet.http.HttpServletRequest, HttpServletRequest, javax.servlet.http.HttpServletRequest is HttpServletResponse, javax.servlet.jsp.JspWriter is written as JspWriter.
As a premise, HttpServletRequest.getParameter (String) is a method for acquiring data from the outside.
This is a method for acquiring the value of the parameter having the name specified as the first argument, and the parameter name can be acquired from the first argument value. On the other hand, in the case of source code using the struts framework, external form data is acquired by the form bean setter method, and the parameter name is included in the name of this method. Therefore, the parameter name can be acquired similarly. The parameter name acquired by such a method is registered in the external data DB 12E.

FIG. 1 is a system configuration diagram showing an embodiment of the present invention.
In FIG. 1, a server 1 and a client 2 are connected by a network 3. The server 1 includes a terminal device 11 including a CPU 11A and a memory 11B, source code checking means 12A for checking a vulnerability by analyzing source code, a library method DB 12B for registering a library method in advance, and a programmer definition A programmer-defined method DB12C for managing the selected method, a variable DB12D for managing the value of the variable, an external data DB12E for managing the position where the external data was acquired, and a code that may cause the vulnerability obtained by the inspection An intermediate result report 12F for recording information on the class, a class URL mapping DB 12G in which class names and URLs are associated with each other, an external storage device 12 in which Web application supply means 12H, which is an operating environment of the Web application, is stored, Consists of communication port 13 .

  The client 2 includes a terminal device 21 including a CPU 21A and a memory 21B, a Web application inspection management unit 22A, a Web application execution inspection unit 22B, and a normal application assumed by the Web application developer that is input from the client to the Web application. Stored are a request parameter DB 22C in which parameter values are registered, a response vulnerability determination DB 22D that is a criterion for use by the Web application execution inspection unit 22B, an inspection data DB 22E, and a result report 22F describing the results of the vulnerability inspection. The external storage device 22 and the communication port 23 are configured.

FIG. 2 shows the source code of the inspection target Web application. For the sake of explanation, the line number is shown on the far left. The import statement is omitted. In this source code, data from outside the program is acquired on the 3rd, 4th, and 10th lines.
Calls to the PrintWriter.println (String) method or methods that call it internally are made on lines 6, 7, 8, 9, and 12. Of these, lines 6, 7, 8, and 9 are vulnerable. On the other hand, line 12 is not vulnerable because the contents of the data passed to the first argument are checked by the conditional statement in line 11 before that. However, this 12th line is a potentially vulnerable part where a vulnerability is generated just by changing the code of the conditional statement on the 11th line in a part other than the applicable part.

FIG. 3 is an example of an input page corresponding to the Web application to be inspected.
FIG. 4 is an example of the mapping DB 12G. The DB includes a Web application name, a source code name, a class name, and a URL name. Specify the relative path from the root of the Web application in the URL. If there is no URL, leave it blank.

FIG. 5 is a diagram showing a flow of instructions and data exchanged between the Web application inspection management unit 22A of the client terminal, the Web application execution inspection unit 22B of the server, the source code inspection unit 12A, and the Web application supply unit 12F. It is. It is assumed that the Web application to be inspected is in a state where the service can be provided by the Web application supply unit 12C.
First, the Web application inspection management unit 22A transmits the inspection target application name to the source code inspection unit 12A (step 501).
The source code inspection unit 12A acquires the source code 12I corresponding to the inspection target application registered in the mapping DB 12G, performs the source code inspection (step 502), and uses the result as an intermediate result report for Web application inspection management. It is sent to the means 22A.
At this time, the class URL mapping DB 12G in which the class name is associated with the URL is also sent (step 503).

Next, the Web application inspection management unit 22A sends the intermediate result report 12F and the class URL mapping DB to the Web application execution inspection unit 12B to the Web application execution inspection unit 12B (Step 504).
The Web application execution inspection unit 12B obtains the information of the inspection page URL and the inspection parameter name from these, assembles the request data for inspection by referring to the request parameter DB and the inspection data DB, and combines the request data with the Web application supply unit 12F. (Step 505).
Thereafter, the web application execution inspection unit 12B receives a response from the web application (steps 506 and 507), and determines whether the vulnerability is present by comparing with the vulnerability determination data in the vulnerability determination DB 22D (step 508). Steps 505 to 508 are repeated for each parameter and inspection data value.
Then, the result is notified to the Web application inspection management means 22A (step 509), and finally a result report is generated. At this time, those that are determined to be vulnerable in both the source code inspection and the Web application execution inspection are output as high severity, and those that are determined to be vulnerable only in the source code inspection are output as low severity (step 510).
Finally, the end of inspection is notified to the Web application execution inspection unit 12B and the source code inspection unit 12A (step 511).

FIG. 6 is an example of data stored in the library method DB 12B.
The library method DB 12B is a database in which data transitions such as methods included in the standard library are registered in advance. The first column is a method name, and the second column is a data transition list indicating which value transitions to where. Here, data transition is expressed using “→”, the left of “→” is the transition source, and the right of “→” is the transition destination. The values set in the transition source and transition destination values include the argument number, IN representing external data, R representing the return value, VUL_XSS which is the transition destination that may cause vulnerability, and obj.method () format There is a method caller object flag THIS that points to obj of the method call. One of these is set as the transition destination, and any one or combination thereof is set as the transition source.

FIG. 7 is an example of data stored in the programmer-defined method DB 12C.
In the programmer-defined method DB 12C, data transition information on a method defined by the programmer is registered during source code analysis. The first and second columns of this DB are the same as the library method DB 12B. However, when external data is set as the transition source of the transition value, INi (i = 1,... N) (n is a sufficiently large positive integer) is set instead of IN.
The analyzed flag in the third column is a flag indicating whether or not the analysis of the method definition is completed. The analyzed flag takes a value of 0 or 1, and a method whose analyzed flag is 0 indicates that the analysis from steps 906 to 911 to be described later has not been completed. Indicates that it has finished. The initial value is 0. Hereinafter, the state of the method that has not been analyzed is referred to as unanalyzed.
The weak method name in the fourth column is initially set to null, and the name of the vulnerable method is registered only when the weak method flag VUL_XSS is set in the transition destination of the transition value.

FIG. 8 is an example of data stored in the variable DB 12D.
The first column is an identification number of a variable registered in the variable DB 12D. In the case of a static variable, this variable number is a negative integer value and is assigned in the descending order of −1 and −2. For dummy arguments, a positive integer value that matches the argument number is attached. In the case of local variables, they are assigned in ascending order so as to follow the variable numbers of the formal parameters already registered. If no positive integer value is registered, the numbers are assigned in ascending order from 1.
The second column indicates the type of the variable. When registering a dummy argument, 'A' is stored, 'L' is stored for a local variable, and 'S' is stored for a static variable.
The third column is the variable name.
The fourth column is a value held by the variable, and the initial value is the same value as the variable number. If the value is a constant, use C. Since there is no transition of the array variable in the inspection target source code to be described later, the description is simplified, but it is also possible to cope with data transition to be written to the argument variable by adding the variable dimension to the variable DB 12D.

FIG. 9 is a flowchart showing a processing procedure of the source code vulnerability check apparatus according to the present embodiment.
When the source code checking means 12A is activated, the source code of the Web application to be checked is read, the source code is traced, the found programmer-defined method is registered in the programmer-defined method DB 12C, and the static variable is registered in the variable DB 12D. To do. The variable numbers of static variables are negative integer values and are assigned in descending order from −1 (step 901).
Next, the beginning of the source code is set as the search start position (step 902). If there are multiple source files, the beginning of any file is set as the search start position.
Next, an unanalyzed method definition is searched from the source code (step 903). If there is no unanalyzed method, the process proceeds to step 912 described later (step 903). If the corresponding method is found, next, it is searched whether an unanalyzed method call has been made in the definition of the corresponding method (step 904). If an unanalyzed method call has been made, the search start position is moved to the next method definition position in the source code (step 905), and the process returns to step 903. If an unanalyzed method call has not been made, the method is set as a processing target method, and analysis is started (step 906). If there is a formal argument of the target method, it is registered in the variable DB 12D (step 907). At this time, the variable number of the dummy argument is registered so as to match the argument number. Then, the method definition analysis process (step 908) is performed. This is shown in FIG.

Step 908 is repeated until the end of the target method is reached. When the processing of the target method is completed, the analyzed flag is set to 1 and the process proceeds to step 910 (step 909).
Next, the registration data regarding the dummy argument and the local variable is deleted from the variable DB 12D. Of the values of static variables, values other than INi are initialized (step 911). The process for the target method is finished, and the process returns to Step 903.
In step 912, it is checked whether or not there is a change in the value of the static variable in the variable DB 12D as compared with the previous analysis. If there is a change, the values of the analyzed flag in the programmer-defined method DB 12C are all initialized to 0, and the process returns to step 903. On the other hand, if not, the process is terminated.

Next, a flowchart of the in-method analysis process shown in FIG. 10 will be described.
Here, if the analysis location is not a local variable definition location, the process moves to step 9203 (step 9201). If it is a local variable definition location, the defined variable is registered in the variable DB 12D. Variable numbers are given in ascending order as positive integers (step 9202).
If the analysis location is not a variable access location, the process moves to step 9205 (step 9203). If it is a variable access location, the value of the variable is acquired from the variable DB 12D (step 9204).
If the analysis location is not a method call location, the process ends (step 9205). If it is a method call location, the library method DB 12B and the programmer-defined method DB 12B are searched with the method name, and the transition value of the corresponding method is acquired (step 9206).

If there is no transition value, the process ends (step 9207). If there is a transition value, the first transition value is extracted. When the transition source of the transition is a positive integer (argument number), the following processing is performed after correcting the transition source to an actual argument value corresponding to the argument number.
When the transition source is THIS, the following processing is performed after correcting the value of the method call source variable. Otherwise, the following processing is performed without doing anything (step 9208).
If the transition destination is VUL_XSS and the data transition includes INi in the transition source, the process proceeds to the intermediate output report process in step 9210 in order to output a warning to the corresponding part in the source as the inspection result (step 9209). Step 9210 will be described with reference to FIG. If this procedure is followed, the process moves to step 9206 (step 9210).
If it is an invocation location of an external data acquisition method that is a library method having a transition including IN as a transition source, it is registered in the external data DB in step 9212 and then the process proceeds to step 9213. Otherwise, go to Step 9213. The external data flag name registered in the external data DB 12E is IN1 at the first location, IN2 at the second location, and so on (steps 9211 and 9212).

In step 9213, processing is performed according to the transition destination value of the data transition. If the transition destination is a variable number, the corresponding variable value in the variable DB 12D is updated. If the transition destination is R representing the return value, it is handled in the same way as when the variable having the transition source value is described at the position of the method in the subsequent processing.
If the transition destination is not a variable number, it is added to the programmer-defined method DB 12C.
The assignment statement is also processed in the same manner as the method call as a data transition in which the right side transitions to the left side.

Next, the flowchart of FIG. 11 will be described. This flowchart shows a procedure for outputting one record to the intermediate output report. Duplicate records are not output.
First, a vulnerable method name and a set of positions consisting of a class name and a line number are set in the vulnerable part (step 9301). The external data DB is searched based on the transition source name INi, the input data information of the corresponding record is acquired, and it is set as the input location (step 9302). The initial value of the route method is set to null (step 9303).
If the vulnerable method name is not in the library method DB 12B, the process moves to step 9305. If there is, the process proceeds to Step 9306 (Step 9304). In step 9305, the method is retrieved from the program definition method DB 12C, and the method name of the corresponding record is additionally registered in the via method. In step 9306, the vulnerable part, the input part, and the transit method are output. Then, the process ends.

Next, processing when the processing of FIGS. 9 to 11 is applied to the source code of FIG. 2 will be described.
First, method2 and methodRet without any other programmer-defined method calls are parsed first.
Next, method1 and methoDB1 whose only programmer-defined method is method2 are analyzed, and finally doGet is analyzed. In particular, the doGet method definition process is described here.
FIG. 12 shows a programmer-defined method DB 12C at the end of step 901 for method1, method2, methoDB1, and methodRet.
In FIG. 12, the transition values of method1, method2, and methoDB1 are 1 → VUL_XSS. In method2, PrintWriter.println (String) is called internally, in method1, method2 is called internally, and in methoDB1, both are called in such a way that the value of the first argument is passed to each first argument. Therefore, the vulnerable method name is as shown.

After analysis of method1, method2, methoDB1, and methodRet, it can be seen that the doGet method has not been analyzed, and no unanalyzed method call has been made in the definition (steps 903 and 3404). Therefore, doGet is set as a method to be analyzed (target method) (step 906).
First, a dummy argument and a local variable are registered in the variable DB 12D for the target method doGet (step 907). Since there are external data acquisition methods HttpServletRequest.getParameter (String) method in the third and fourth lines, the data stored in the external data DB 12E is as shown in FIG.

FIG. 14 shows data stored in the variable DB 12D at the end of analysis up to the fifth line for doGet.
Next, data transition processing is performed by calling method method1 on the sixth line (step 908). The transition value of method1 is retrieved from the library method DB 12B and the programmer-defined method DB 12C. Then, 1 → VUL_XSS transition is acquired. 1 of the transition source represents the first argument, and when the value referred to by the variable s given to the first argument is obtained from the variable DB 12D and the transition source is rewritten, IN1 → VUL_XSS, which is a weak transition, Output lines to the intermediate report as vulnerable points. At this time, the input location is acquired from the record whose flag name of the external data DB is IN1, and the via method is acquired from the vulnerable method name of the programmer-defined method DB.

Next, data transition processing is performed by calling method method2 on the seventh line (step 908). The process is almost the same as the process on the sixth line, but the values of the variables given to the first argument are IN1 and IN2. Therefore, two input locations are output in parallel.
Next, data transition processing is performed by calling the method methoDB1 on the eighth line (step 908). Although it is almost the same as the process on the sixth line, since there are two vulnerable method names, two via methods are also output side by side.

Next, data transition processing is performed by calling the method PrintWriter.println (String) on the 9th and 12th lines (step 908). The process is almost the same as the process on the sixth line, but there is no transit method because a weak library method is directly called.
This completes the processing of the target method doGet (step 909). The programmer-defined method DB 12C at the end of step 909 is obtained by changing the doGet analyzed flag in FIG.
Since the corresponding method is not found in the unanalyzed method search (step 903), the process proceeds to step 912.
There are no static variables defined in the source code to be checked. Therefore, the inspection is finished.

FIG. 15 is an example of the intermediate output report 1300.
1301 in the first column is a vulnerable location where a method call with a vulnerable transition is being performed, 1302 in the second column is the input location of the external data that causes it, 1303 in the third column is the vulnerable external data that is the cause It is a passing method that represents the order of passing through the passing method until it is passed to the library method. The contents are as described above.

FIG. 16 shows an example of stored data 1401 in the inspection data DB 22E.
FIG. 17 (a) is an example of data stored in the request parameter DB 22C in which normal request parameter values assumed by the Web application developer are input from the client to the Web application. The URL 1501 of the inspection target page, the parameter name 1502 and a parameter value 1503.

  FIG. 17B is an example of request data corresponding to FIG. In step 505, request data in which only the data value of the parameter to be inspected is changed to the inspection data value among the request data is assembled and transmitted from the Web application execution inspection unit 22B to the Web application inspection management unit 22A.

  FIG. 18 shows an example of data stored in the response vulnerability determination DB 22D, which includes a response vulnerability determination code 1601. When the code registered in the DB 22D is included in the response data, it is determined to be a vulnerability.

FIG. 19 is a diagram showing an example of a result report.
The first column is the severity that indicates the severity of the vulnerability, the second column is the vulnerable location where the method call with the vulnerable transition is performed, the third column is the input location of the external data that causes it, the fourth column Is a passing method that represents the order in which the causal external data is passed to the vulnerable library method.
As a result of the Web application execution inspection, in the intermediate result report of FIG. 15, it is obtained that the four points from the top are vulnerable and the fifth point is not. The result report shown in FIG. 19 is generated in step 510 as a notification of the final inspection result by the Web application inspection management unit 22A.
Those that are determined to be vulnerable in both source code inspection and Web application execution inspection are output as high severity, and those that are determined to be vulnerable only in source code inspection are output as low severity. Although the latter is not a vulnerability, it is a part (potential vulnerability) that becomes a vulnerability just by slightly changing the code other than the corresponding part. Although the priority of vulnerability countermeasures is low in such places, it is better to take countermeasures if the software development man-hours are sufficient when countermeasures for highly serious places are completed.
Via methods are particularly useful when the number of methods is large to some extent and method calls are deep.
In the conventional method in which the transit method is not output, for example, even if an indication is made on the 6th line of the A class, if there is no information on the external data acquisition method, transit method, and vulnerable method, which is the specific reason, it will take time to deal with it. Will be applied. On the other hand, in the method of the present invention, it depends on how the vulnerable method is used, but in the case of the method, it can be understood that method1 should be sanitized at any location described in the via method, and the man-hours required for vulnerability countermeasures are small. That's it.

  In the above embodiment, the application example in which the present invention inspects the Web application has been described. However, the present invention is not limited to this and can be applied to various applications.

1 is a system configuration diagram showing an embodiment of the present invention. It is a figure which shows the example of the source code of a web application to be examined. It is a figure which shows the example of the input page of a web application to be examined. It is a figure which shows the example of the storage data of class name URL mapping DB. It is a sequence diagram which shows operation | movement of the vulnerability test | inspection of this invention. It is a block diagram of the storage data of library method DB. It is a block diagram of the storage data of programmer definition method DB. It is a block diagram of the storage data of variable DB. It is a flowchart showing the process sequence of a source code inspection means. It is a flowchart showing the process sequence of the analysis process in a method definition. It is a flowchart showing the process sequence of an intermediate result output process. It is a figure which shows the example of the storage data of programmer definition method DB. It is a figure which shows the example of the storage data of external data DB. It is a figure which shows the example of the storage data of variable DB. It is a figure which shows the example of an intermediate result report. It is a figure which shows the example of the storage data of test | inspection data DB. It is a figure which shows the example of the storage data and request data of request parameter DB. It is a figure which shows the example of the storage data of response vulnerability determination DB. It is a figure which shows the example of a result report.

Explanation of symbols

  11A, 21A ... CPU, 11B, 21B ... Memory, 13, 23 ... Communication port, 11, 21 ... Terminal device, 12, 22 ... External storage device, 3 ... Network, 12A ... Source code checking means, 12B ... Library method DB , 12C ... Programmer definition method DB, 12D ... Variable DB, 12E ... External data DB, 12F ... Intermediate result report, 12G ... Class URL mapping DB, 12H ... Web application supply means, 12I ... Source code, 22A ... Web application inspection management Means, 22B: Web application execution inspection means, 22C: Request parameter DB, 22D: Response vulnerability determination DB, 22E: Inspection data DB, 22F: Result report.

Claims (2)

By receiving the inspection start notification from the application inspection management means, for the source code of the application to be inspected, the data from outside the source code is distinguished for each input location, and the values referenced by the variables and the transitions by the method are analyzed A first step of inspecting a vulnerability and obtaining information on a position of a code having a potential vulnerability and an input position of data from the outside of the application and a method through which the data passes;
For the location detected in the first step, send request data for inspection to the inspection target application supplied by the application supply means, and compare the response data with the vulnerability determination code registered in advance. The application vulnerability inspection method comprising: a second step of determining whether or not a vulnerability is included, and distinguishing and outputting a vulnerable one. By receiving the inspection start notification from the application inspection management means, for the source code of the application to be inspected, the data from outside the source code is distinguished for each input location, and the values referenced by the variables and the transitions by the method are analyzed A first means for inspecting a vulnerability and obtaining information on a position of a code that may be vulnerable and an input position of data from the outside of the application that causes the vulnerability and a method through which the data passes;
For the location detected by the first means, send request data for inspection to the inspection target application supplied by the application supply means, and compare the response data with the vulnerability determination code registered in advance. The application vulnerability inspection apparatus comprising: a second means for determining whether or not a vulnerability is included, and distinguishing and outputting a vulnerable one.

Images