Intermediate language representation method and system for web injection vulnerabilities

Abstract

The application discloses a method and system for representing WEB injection vulnerability in an intermediate language. When detecting a vulnerability, if a source code is directly analyzed, a large amount of irrelevant information is included, resulting in poor vulnerability detection effect. After the source code is converted by the intermediate language representation of the application, semantic information related to the vulnerability can be extracted, the extracted information does not include noise data irrelevant to the vulnerability, and the logic code directly related to the vulnerability can be more accurately described. Moreover, the intermediate language representation is irrelevant to the actual development language and development environment, and can be regarded as a language for describing the structure of the vulnerability. By using the intermediate language representation as input to train a Bi-LSTM network, a vulnerability detection model can be obtained, and the model can be used to detect vulnerabilities in the source code.

Description

Technical Field

[0001] This invention relates to the field of vulnerability detection in web applications, and more particularly to an intermediate language representation method and system for web injection vulnerabilities, and a method and system for detecting web injection vulnerabilities in PHP based on intermediate language representation. Background Technology

[0002] Since the rise of distributed computing models (such as cyber-physical systems and the Internet of Things), the number of web applications has been growing rapidly, but the number of vulnerabilities has also increased accordingly. Injection attacks are widely considered one of the most destructive threats among all web vulnerabilities. Injection attacks embed scripts into user input, causing relational database management systems running behind the web application to execute malicious SQL statements, or executing malicious scripts within the user's browser. According to the vulnerability distribution data released by the National Information Security Vulnerability Sharing Platform in 2020, web application vulnerabilities accounted for as much as 27.7%, with injection attacks accounting for half of all vulnerability types. Therefore, detecting and preventing injection vulnerabilities is crucial for improving the reliability and trustworthiness of modern web applications. Among the various programming languages ​​used in web applications, PHP is widely used in web development due to its flexibility and fast execution. According to W3Techs statistics, in 2021, PHP accounted for 78.8% of the programming languages ​​used in web servers, still holding a high proportion. Therefore, web vulnerability detection targeting PHP remains a current research hotspot.

[0003] Generally, there are two methods for detecting PHP injection vulnerabilities. One is dynamic testing, which involves simulating hacker attacks on web applications. Specifically, this involves designing various attack vectors, using these vectors to attack the system, and analyzing whether the attack was successful. For example, Liu M et al. believed that malicious SQL statements possess unique semantics, thus semantic knowledge could be used to generate semantically identical test cases. These generated test cases could more comprehensively detect SQLi vulnerabilities, leading to the design of DeepSQLi. DeepSQLi utilizes neural language models to mutate given test cases or normal user input, thereby generating more diverse test cases. However, because it is essentially black-box testing, it cannot perform complete and thorough input testing. Detection failures may occur due to semantic deficiencies in the test cases, which may prevent coverage of all execution paths.

[0004] Another approach is static testing, which essentially involves offline analysis of dependencies between variables using lexical and syntactic analysis to detect whether tainted data can propagate from its source to its endpoint. This process neither runs the target program nor requires code modification. Static testing also falls into two categories: rule-based static testing and learning-based static testing. Rule-based static testing, such as Son et al., combined taint analysis and control flow graphs to discover semantic vulnerabilities like lost authorization issues and denial-of-service attacks. However, its high false positive rate makes it unusable directly and requires manual review. Wasef et al. proposed a PHP web application detection method based on genetic algorithms and static analysis, which reduces the false positive rate by eliminating infeasible paths in the control flow graph. Russell et al. and Nguyen et al. emphasized the disadvantages of static and dynamic analysis, which can lead to a high proportion of errors and false positives when detecting software vulnerabilities. Seokmo et al. also highlighted the low accuracy of static analysis techniques for vulnerability detection. The other approach is learning-based static testing, which avoids manually designing rule bases and can detect novel vulnerabilities. The main idea is to use static analysis to analyze or preprocess the source code, and then train a neural network to achieve vulnerability detection. For example, Medeiros et al. used data mining techniques to replace manual review, thereby reducing false positives. Furthermore, Zheng et al. compared and evaluated traditional machine learning and deep learning methods in software vulnerability detection, confirming that deep learning methods do indeed perform better in detecting software vulnerabilities compared to traditional machine methods.

[0005] Traditional static vulnerability detection methods suffer from a high rate of false positives, making the integration of machine learning a current trend in vulnerability detection. Using machine learning for vulnerability detection requires preprocessing the source code to locate vulnerabilities and extract their features. However, existing feature extraction methods often lack vulnerability-related information, such as source code text, AST features, opcodes, and php-tokens. Source code text is the result of removing meaningless markers from the source code. AST features represent source code information using an AST, removing special markers. Opcodes are intermediate code executed by the Zend engine in PHP. Source code can be represented in opcode form, and vulnerabilities can be characterized using these opcodes. php-tokens utilize the built-in PHP function `token_get_all` to segment the source code according to PHP markers, obtaining a PHP token sequence, which is then used as the vulnerability feature representation in the source code.

[0006] However, all of the above intermediate representations have their problems, specifically: source code text and ASTs used as vulnerability features contain a large amount of irrelevant information, leading to inaccurate vulnerability detection; Fidalgo et al. use opcodes for feature extraction, but opcodes cannot represent too much semantic information, resulting in missing vulnerability semantics; Fang et al. redesigned php-token, retaining function names in the source code. Therefore, when this method escapes, function parameters are discarded, but some functions have different effects depending on the parameters, leading to the loss of vulnerability-related information. Furthermore, this representation has poor readability and contains a lot of redundant information.

[0007] To address the aforementioned issues, this invention proposes an intermediate language for vulnerability feature extraction, specifically targeting SQL injection, cross-site scripting (XSS), and command injection vulnerabilities in PHP-based web applications. A vulnerability detection tool is designed based on this intermediate language. This intermediate language can extract semantic information relevant only to the vulnerability from the source code and provide an abstract representation of the vulnerability. This abstract representation preserves both the semantic information and readability. Compared to the representation methods mentioned above, the intermediate language representation of this invention is specifically designed for vulnerability feature representation, more accurately describing the semantic information of the vulnerability, eliminating irrelevant code, and preserving code readability. Furthermore, this invention uses this intermediate language representation as input to train a Bi-LSTM network, resulting in a vulnerability detection model that can be used to detect vulnerabilities in source code. Summary of the Invention

[0008] This invention discloses an intermediate language representation for web injection vulnerabilities. This representation can be used to accurately describe vulnerability information in code, and based on this intermediate representation, this invention discloses a web injection vulnerability detection method for PHP. This intermediate language representation can accurately extract information directly related to the vulnerability, avoid introducing too much noise data, and the vulnerability detection method using this intermediate language also has high accuracy.

[0009] According to one aspect of the present invention, an intermediate language representation method for web injection vulnerabilities is provided, the method being used to represent a categorized language of various variables and functions; the method comprising:

[0010] When escaping source code, it is categorized according to the semantics of the code, including string operations, sensitive functions, and...

[0011] During the escaping process, each line is escaped, and after escaping, they are combined according to a specific syntax to form an intermediate representation of the target code.

[0012] Preferably, different code semantics are classified as follows:

[0013] Sensitive functions, cleanup functions, variables, comparison operators, strings, string manipulation, whitelists, type validation, conditional statements, and loop statements;

[0014] Among them, sensitive functions are functions used to trigger SQL injection, XSS, and command injection; clean functions are functions used to perform formal validation on user input; variables include contaminated and uncontaminated variables; type validation includes numeric validation, numeric conversion, string validation, and string conversion; string operations include string concatenation, addition, and replacement; and the results of each category are represented by specific keywords.

[0015] Preferably, each statement in the source code is categorized and escaped, rather than each word in the source code being categorized to obtain an intermediate language representation of the vulnerability. When escaping source code into an intermediate language representation, statements are used as the smallest escaping objects, and escaping is performed according to the semantics of each statement in the source code. The escaping process is context-dependent, and targeted escaping is performed according to the propagation path of the pollution source. Parts unrelated to the vulnerability will not be escaped, and the escaping of a code statement is a combination of multiple keywords.

[0016] Preferably, the target program is preprocessed before escaping to extract the code containing the vulnerability. This preprocessing first analyzes and extracts the vulnerable parts of the code, and marks these parts with information as code to be escaped. The marked information includes the vulnerability type, the file in which it is located, and the line of code in which it is located.

[0017] Preferably, the keywords are combined according to a specific syntax; the combination method is determined by the position and semantics of the keywords in the source code, and specific modifications are made according to the semantics; the modifications include the string length and the position of the variable in the string.

[0018] Preferably, the combination of keywords includes the combination of a code statement and the combination of the entire source code; the escape result of a statement may contain multiple keywords, and each keyword will be combined according to specific rules; after all statements in the source code have been escaped, they will be combined according to the context of the statements and their semantic features to indicate vulnerabilities in the code.

[0019] Preferably, the position of the keyword in the source code determines how it is combined after escaping; the keywords after escaping in each line of code are stored in the execution order of the source code, and when combined, the keywords are rearranged and combined according to the calling relationship, and the specific information of the vulnerability is added after combination, including the file where the vulnerability is located, the line where the sensitive function is located, and the line where the pollution source is located.

[0020] Preferably, this intermediate representation can directly represent web injection vulnerabilities, regardless of the language used in the source code; for projects using different programming languages, this intermediate language can be used to uniformly represent different types of vulnerabilities, rather than specific vulnerabilities for specific programming languages.

[0021] According to another aspect of the present invention, an intermediate language representation system for web injection vulnerabilities is provided, the system being used to represent a categorized language of various variables and functions; the system comprising:

[0022] A representation device used to categorize and represent source code according to its semantics when escaping it, including string operations, sensitive functions; and

[0023] The processing unit is used to escape each line during the escaping process, and then combine them according to a specific syntax to form an intermediate representation of the target code.

[0024] According to another aspect of the present invention, a method for detecting web injection vulnerabilities in PHP based on intermediate language representation is provided, comprising the following steps:

[0025] S1: Obtain the source code, analyze it, and divide it into different code pieces, each of which is treated as an independent piece of code;

[0026] S2: Escape code snippets according to their context and semantics, and combine the escaped keywords according to a specific syntax to obtain an intermediate language representation of the code snippets;

[0027] S3: Vectorize the escape result of each code snippet and input it into Bi-LSTM as training data to train the model and obtain the vulnerability detection model.

[0028] Preferably, when the source code is divided into code slices, the parts suspected of having vulnerabilities are retained, while all safe parts are discarded; the slicing process treats dangerous functions as program entry points, and performs reverse analysis based on these functions to determine the initial definition position of function variables, and extracts the code between the definition position and the dangerous function as a code slice.

[0029] Preferably, the code between the defined location and the dangerous function is obtained based on the data flow and control flow, rather than based on the line positions of the two statements.

[0030] Preferably, during the source code escaping process, the relationships between variables are analyzed, the pollution paths of variables are recorded, the polluted statements are escaped, the escaping results of each code statement are stored in the order of code execution, and after all code slices are escaped, they are combined according to a specific syntax to serve as the intermediate language representation of the code slices.

[0031] Preferably, the escaping result of each code snippet is not independent and can be used by other code snippets; there may be repeated function calls in the source code. If the function has been escaped, the escaping result of the first time will be directly inserted into the escaping result of this time according to a specific rule during the next escaping.

[0032] Preferably, the escape result of each slice is vectorized, the vectorized result is aligned and used as the input of Bi-LSTM, and an attention mechanism is added to Bi-LSTM, and the softmax activation function is used to classify the input.

[0033] According to another aspect of the present invention, a detection system for web injection vulnerabilities in PHP based on intermediate language representation is provided, the system comprising:

[0034] The acquisition device is used to acquire source code, analyze it, and divide it into different code pieces, each of which is regarded as an independent piece of code.

[0035] Escape mechanisms are used to escape code snippets. They escape code snippets based on the context and semantics of the code, and combine the escaped keywords according to a specific syntax to obtain an intermediate language representation of the code snippet.

[0036] The representation device is used to vectorize the escape result of each code piece and input it into Bi-LSTM as training data to train the model and obtain the vulnerability detection model.

[0037] According to another aspect of the present invention, a computer-readable storage medium is provided, the storage medium storing a computer program for performing the methods described in any of the above embodiments.

[0038] According to another aspect of the present invention, an electronic device is provided, comprising:

[0039] processor;

[0040] Memory used to store the processor's executable instructions;

[0041] The processor is configured to read the executable instructions from the memory and execute the instructions to implement the method described in any of the above embodiments.

[0042] Based on another aspect of the present invention, a computer program product is provided, including computer-readable code. When the computer-readable code is executed on a device, a processor in the device executes the method described in any of the above embodiments. The intermediate language representation for web injection vulnerabilities provided by the present invention specifically includes the following points:

[0043] 1. Intermediate Language Representation (ILR) for Web Injection Vulnerabilities is a categorized language used to represent various variables and functions. When escaping source code, it categorizes the code according to its semantics, including string manipulations and sensitive functions. Furthermore, the escaping process is performed line by line, and the escaped data is combined according to a specific syntax.

[0044] 2. Intermediate language representations for web injection vulnerabilities are categorized based on code semantics into the following types: sensitive functions (functions that could trigger SQL injection, XSS, and command injection vulnerabilities), cleanup functions (functions that perform formal validation of user input), variables, comparison operators, strings, string manipulation, whitelists, type validation, conditional statements, and loop statements. Variables include both polluted and unpolluted variables; type validation includes numeric validation, numeric conversion, string validation, and string conversion; and string manipulation includes string concatenation, addition, and replacement. The results of each category are represented using specific keywords.

[0045] 3. After escaping the source code into an intermediate language representation, it will be combined according to a specific syntax. The combination method will be determined by the position and semantics of keywords in the source code, and specific modifications will be made according to the semantics, including string length, variable position in the string, etc.

[0046] The implementation solution provided by this invention is specifically a web injection vulnerability detection method for PHP based on intermediate representation, comprising the following steps:

[0047] S1: Obtain the source code, analyze it, and divide it into different code pieces, each of which is treated as an independent piece of code;

[0048] S2: Escape code snippets. This process involves escaping code snippets based on their context and semantics, and combining the escaped keywords according to a specific syntax to obtain an intermediate language representation of the code snippets.

[0049] S3: Vectorize the escape result of each code snippet and input it into Bi-LSTM as training data to train the model and obtain the vulnerability detection model.

[0050] Program slicing is a program decomposition technique that primarily involves identifying and breaking down a program by identifying its internal characteristics, then analyzing the resulting program slices. In vulnerability detection, program slicing can extract code segments containing vulnerabilities for analysis. When slicing a program to target a vulnerability, dangerous functions are considered program entry points. Based on these functions, reverse analysis is performed to determine the initial definition location of function variables. The code between the definition location and the dangerous function is extracted as a code slice; this code handles the entry point or depends on it. Slicing involves both intra- and inter-process analysis because it traces the entry point and its dependencies along the source code, traversing different files and functions. The analysis is also context-sensitive because it considers the results of function calls.

[0051] The escaping of code slices is analyzed based on the statement to be analyzed and its context. First, it checks whether the variable in the statement to be analyzed exists in the list of polluted variables. If it does not exist, no escaping is performed. If it exists, it is analyzed according to its specific operation, such as assignment statements, branching statements, etc. Different escaping is performed according to different operations. After escaping, if there are new polluted variables, the list of polluted variables is updated. After escaping a slice, the result must be recorded. If the slice is a class, the escaped intermediate language must be stored in a special location.

[0052] The escaped intermediate language representation is stored as a string, a format that the model cannot directly recognize, and therefore cannot be used as an input variable. This invention uses word2vector to vectorize the string-based intermediate language representation, obtaining word vectors binData usable by the model. Because the length of the training data needs to be consistent, binData is padded with zeros or truncated. If the binData length is less than a specified threshold w (w = 200 in this paper), zeros are padded at the end; if the binData length is greater than the threshold w, it is truncated. Finally, the processed vectors are stored in the training dataset, and this dataset is used to train the model to obtain the vulnerability detection model.

[0053] This invention provides a web injection vulnerability detection method for PHP based on intermediate representation. This method utilizes intermediate language representation to accurately describe vulnerability information in the source code. This intermediate language representation can extract semantic information related to the vulnerability, and the extracted information does not contain noise data unrelated to the vulnerability, thus providing a more accurate description of information directly related to the vulnerability. Replacing traditional static detection methods with this intermediate representation-based web injection vulnerability detection method can improve the accuracy of vulnerability detection and reduce the false positive rate.

[0054] It should be understood that the above general description and the following detailed description are exemplary and explanatory only, and do not limit the disclosure of the present invention. Attached Figure Description

[0055] The accompanying drawings, which are incorporated in and form part of this specification, illustrate embodiments consistent with the invention and, together with the description, serve to explain the principles of the invention.

[0056] To more clearly illustrate the technical solutions in the embodiments of the present invention or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, for those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0057] Figure 1 Syntax rules for intermediate language representation provided in the embodiments of the present invention;

[0058] Figure 2 Example diagram of the program slicing process provided in the embodiments of the present invention;

[0059] Figure 3 Example diagram of the code slice escaping process provided in the embodiments of the present invention;

[0060] Figure 4 This invention provides a vulnerability code analysis process based on intermediate language representation, as disclosed in the embodiments of the present invention.

[0061] Figure 5 This is a flowchart of an intermediate language representation method for web injection vulnerabilities according to an embodiment of the present invention;

[0062] Figure 6 This is a schematic diagram of the structure of an intermediate language representation system for web injection vulnerabilities according to an embodiment of the present invention;

[0063] Figure 7 This is a flowchart of a method for detecting web injection vulnerabilities in PHP based on intermediate language representation, according to an embodiment of the present invention.

[0064] Figure 8 This is a schematic diagram of the structure of a web injection vulnerability detection system for PHP based on intermediate language representation, according to an embodiment of the present invention. Detailed Implementation

[0065] Exemplary embodiments will now be described in detail, examples of which are illustrated in the accompanying drawings. The embodiments described below do not represent all embodiments consistent with the present invention. Rather, they are merely examples of systems consistent with some aspects of the invention as detailed in the appended claims.

[0066] To design keywords for the intermediate language, this invention investigated which code elements can manipulate entry points and are associated with or prevent vulnerabilities (e.g., functions that perform cleanup or replace characters in a string). Furthermore, numerous code segments (containing or not containing vulnerabilities) were examined to define these code elements. Code elements representing PHP functions were also studied to understand which of their parameters are relevant to vulnerability detection. Some code elements are represented by multiple tags; for example, concatenating an unclosed string, such as "cat"."$tainted", would be represented as conc_char0.

[0067] Table 1 shows all the keywords proposed in this application. The first column describes the keywords in the intermediate language of this application, which are used to represent various vulnerability-related information such as pollution type, cleanup function, and string operations. The second column explains the function of each keyword, and the third column provides examples. In addition to the examples in the list, there are some other keywords used in conjunction with the keywords, but these keywords do not exist alone; they serve as supplementary explanations to the keywords in the table. For example, the string concatenation operation "find / size'".$tainted."'" will be specifically explained according to the position of the pollution source and the form of the strings before and after it. Such an example operation should be represented as conc_m_char5, where conc represents the concatenation operation, 'm' represents the middle position of the pollution source in the string concatenation, and char5 represents the length of the string that closes the pollution source is greater than 0 and less than 5.

[0068] Table 1

[0069]

[0070]

[0071] Figure 1 This paper describes the syntax rules of the intermediate language proposed in this application. These syntax rules enable the conversion of a code slice into the intermediate language proposed in this application. The code slice can be converted into the intermediate language according to the syntax, and the conversion process is as follows: Figure 3The left side shows a sliced ​​code, and the right side shows the escaping results for each line. The first line is identified as a contaminant and escaped as `tainted_var`. The second line is the conditional part of a branch statement, which is escaped as intermediate language starting with `cond`. This conditional statement uses the `filter_var` function to validate the input format and is escaped as `format_v`, so the second line is escaped as `condformat_v`. The third line is an assignment statement when the condition is true; essentially, it aliases the contaminant variable and doesn't need escaping because all contaminant variables are identified as `tainted_var` in the intermediate language. The fourth and fifth lines can be escaped together; they are assignment statements when the condition is false. This assignment statement reassigns the contaminant variable with a constant and can be escaped as `assign`, so the fourth and fifth lines are escaped as `else assign`. The sixth line is a string concatenation operation, and the length of the string closing the contaminant variable `$tainted` is 1, so it is escaped as `addstr_char5`. If the length of the closing string is 0, it is escaped as `addstr_char0`. The last line is a sensitive function and a command injection vulnerability, so it's escaped as `sink_ci`. After all statements are escaped, they are assembled into an intermediate language representation of the code slice. For example, the code slice in this example would be escaped as "sink_ci addstr_char5 cond format_v else assign tainted_var". After escaping, the lines containing the tainted source and the sensitive function, along with their corresponding files, are added as comments to the end, such as "sink_ci addstr_char5 cond format_velse assign tainted_var / / tainted.php 5 and tainted.php 15".

[0072] In summary, the intermediate language representation for web injection vulnerabilities provided by this invention specifically includes the following points:

[0073] 1. Intermediate Language Representation (ILR) for Web Injection Vulnerabilities is a categorized language used to represent various variables and functions. When escaping source code, it categorizes the code according to its semantics, including string manipulations, sensitive functions, etc. Furthermore, the escaping process involves escaping each line individually, and then combining them according to a specific syntax.

[0074] 2. Intermediate language representations for web injection vulnerabilities are categorized based on code semantics into the following types: sensitive functions (functions that could trigger SQL injection, XSS, and command injection vulnerabilities), cleanup functions (functions that perform formal validation of user input), variables, comparison operators, strings, string manipulation, whitelists, type validation, conditional statements, and loop statements. Each of these categories contains further subcategories.

[0075] 3. After escaping the source code into an intermediate language representation, it will be combined according to a specific syntax. The combination method will be determined by the position and semantics of keywords in the source code, and specific modifications will be made according to the semantics, including string length, variable position in the string, etc.

[0076] Furthermore, traditional static vulnerability detection methods suffer from a large number of false positives, making the integration of machine learning into vulnerability detection a current trend. However, using machine learning for vulnerability detection requires preprocessing the source code to locate the vulnerability and extract its features. Existing feature extraction methods often lack vulnerability-related information. Therefore, this implementation provides a method for detecting web injection vulnerabilities in PHP based on intermediate representations, including:

[0077] S1: Obtain the source code, analyze it, and divide it into different code pieces, each of which is treated as an independent piece of code;

[0078] S2: Escape code snippets. This process involves escaping code snippets based on their context and semantics, and combining the escaped keywords according to a specific syntax to obtain an intermediate language representation of the code snippets.

[0079] S3: Vectorize the escape result of each code snippet and input it into Bi-LSTM as training data to train the model and obtain the vulnerability detection model.

[0080] Program slicing is a program decomposition technique that primarily involves identifying relevant internal characteristics of a program, breaking it down into smaller segments, and then analyzing and studying these segments. The program slicing process is as follows: Figure 2 As shown, the code slicing operation first extracts the vulnerable portion of the code. This operation is based on the location of the contaminant and the sensitive function, segmenting the source code accordingly. In the example code shown, the contaminant is the user input `$_POST["Submit"]`, and the sensitive function is `mysql_query`, so the code between these two is extracted. Finally, comments and other characters are removed. After slicing the source code, many code slices are obtained, each potentially containing an exploitable vulnerability. Each slice is then escaped; this escaping further extracts key information, and the escaping result is used to determine if a vulnerability exists.

[0081] Code slice escaping is analyzed based on the statement to be analyzed and its context. It can be broken down into the following steps: First, it checks if the variable in the statement to be analyzed exists in the polluted variable list. If not, no escaping is performed. If it exists, it is analyzed based on the specific operation, such as assignment statements, branching statements, etc. Different escaping is performed according to different operations. After escaping, if new polluted variables are added, the polluted variable list is updated. After escaping a slice, the result is recorded. If the slice is a class, the escaped intermediate language is stored in a special location. The specific escaping process is as follows: Figure 3 As shown.

[0082] The escaped intermediate language representation is stored as a string. This format of feature representation cannot be directly recognized by the model and therefore cannot be used as an input variable. This invention uses word2vector to vectorize the string-based intermediate language representation, obtaining word vectors binData usable by the model. Because the length of the training data needs to be consistent, binData is padded with zeros or truncated. If the binData length is less than a specified threshold w (w = 200 in this paper), zeros are padded at the end; if the binData length is greater than the threshold w, it is truncated. Finally, the processed vectors are stored in the training dataset, and this dataset is used to train the model to obtain the vulnerability detection model. The specific training process is as follows... Figure 4 As shown.

[0083] To demonstrate the effectiveness of this model in vulnerability detection, this application tested the model using data from the SARD (Software Assurance Reference Dataset). CWE-78, CWE-79, and CWE-89 vulnerability types were selected for testing, and all datasets were manually checked, with many errors corrected in the PHP test cases. The classification results are summarized in Table 2, and the evaluation metrics are shown in Table 3. Tables 2 and 3 illustrate that the vulnerability detection model using intermediate language representations as input can correctly classify different vulnerabilities, and due to the characteristics of intermediate language representations, the model will not classify a certain type of vulnerability as another type. In conclusion, the vulnerability detection method based on intermediate language representations can effectively detect vulnerabilities.

[0084] Table 2

[0085]

[0086] Table 3

[0087]

[0088] Figure 5 This is a flowchart illustrating an intermediate language representation method for web injection vulnerabilities according to an embodiment of the present invention. Method 500 is used to represent a categorized language for various variables and functions; method 500 includes:

[0089] Step 501: When escaping the source code, it is categorized according to the semantics of the code, including string operations, sensitive functions; and

[0090] Step 502: During the escaping process, each line is escaped, and after escaping, the lines are combined according to a specific syntax to form an intermediate representation of the target code.

[0091] In one embodiment, different code semantics are categorized as follows:

[0092] Sensitive functions, cleanup functions, variables, comparison operators, strings, string manipulation, whitelists, type validation, conditional statements, and loop statements;

[0093] Among them, sensitive functions are functions used to trigger SQL injection, XSS, and command injection; clean functions are functions used to perform formal validation on user input; variables include contaminated and uncontaminated variables; type validation includes numeric validation, numeric conversion, string validation, and string conversion; string operations include string concatenation, addition, and replacement; and the results of each category are represented by specific keywords.

[0094] In one embodiment, each statement in the source code is categorized and escaped, rather than each word in the source code being categorized to obtain an intermediate language representation of the vulnerability. When escaping source code to an intermediate language representation, statements are used as the smallest escaping objects, and escaping is performed according to the semantics of each statement in the source code. The escaping process is context-dependent, and targeted escaping is performed according to the propagation path of the pollution source. Parts unrelated to the vulnerability are not escaped, and the escaping of a code statement is a combination of multiple keywords.

[0095] In one embodiment, the target program is preprocessed before escaping to extract the code containing the vulnerability. This preprocessing first analyzes and extracts the vulnerable parts of the code, and marks these parts with information as code to be escaped. The marked information includes the vulnerability type, the file in which it is located, and the line of code in which it is located.

[0096] In one embodiment, the keywords are combined according to a specific syntax; the combination method is determined by the position and semantics of the keywords in the source code, and specific modifications are made according to the semantics; the modifications include the string length and the position of the variable in the string.

[0097] In one embodiment, the combination of keywords includes the combination of a code statement and the combination of the entire source code; the escape result of a statement may contain multiple keywords, and the keywords are combined according to specific rules; after all statements in the source code have been escaped, they are combined according to the context of the statements and their semantic features to indicate vulnerabilities in the code.

[0098] In one embodiment, the position of a keyword in the source code determines how it is combined after escaping; the escaped keywords of each line of code are stored in the execution order of the source code, and when combined, the keywords are rearranged and combined according to the calling relationship, and the specific information of the vulnerability is added after combination, including the file where the vulnerability is located, the line where the sensitive function is located, and the line where the pollution source is located.

[0099] In one embodiment, this intermediate representation can directly represent a web injection vulnerability, regardless of the language used in the source code; for projects using different programming languages, this intermediate language can be used to uniformly represent different types of vulnerabilities, rather than specific vulnerabilities for specific programming languages.

[0100] Figure 6 This is a schematic diagram of the intermediate language representation system for web injection vulnerabilities according to an embodiment of the present invention. System 600 is used to represent a categorized language for various variables and functions; system 600 includes:

[0101] The representation device 601 is used to classify and represent source code according to its semantics when escaping it, including string operations and sensitive functions; and

[0102] The processing device 602 is used to escape each line during the escaping process and then combine them according to a specific syntax to form an intermediate representation of the target code after the escaping is completed.

[0103] Figure 7 This is a flowchart illustrating a method for detecting web injection vulnerabilities in PHP based on intermediate language representation, according to an embodiment of the present invention. The detection method 700 includes the following steps:

[0104] Step 701: Obtain the source code, analyze it, and divide it into different code pieces, each of which is considered an independent piece of code;

[0105] Step 702: Escape the code snippet according to the context and semantics of the code, and combine the escaped keywords according to a specific syntax to obtain the intermediate language representation of the code snippet;

[0106] Step 703: Vectorize the escape result of each code snippet and input it into Bi-LSTM as training data to train the model and obtain the vulnerability detection model.

[0107] In one embodiment, when the source code is segmented into code slices, the parts suspected of having vulnerabilities are retained, while all safe parts are discarded. The slicing process treats dangerous functions as program entry points and performs reverse analysis based on these functions to determine the initial definition location of function variables, extracting the code between the definition location and the dangerous function as a code slice.

[0108] In one embodiment, the code defining the location between the dangerous function is derived from the data flow and control flow, not from the line positions of the two statements.

[0109] In one embodiment, the source code escaping process analyzes the relationships between variables, records the pollution paths of variables, escapes polluted statements, stores the escaping results of each code statement in the execution order of the code, and after all code snippets are escaped, they are combined according to a specific syntax to form the intermediate language representation of the code snippets.

[0110] In one embodiment, the escaping result of each code snippet is not independent and can be used by other code snippets; there may be repeated function calls in the source code. If the function has been escaped, the escaping result of the first time will be directly inserted into the escaping result of the next time according to a specific rule.

[0111] In one embodiment, the escape result of each slice is vectorized, the vectorized result is aligned and used as the input of Bi-LSTM, and an attention mechanism is added to Bi-LSTM, and the softmax activation function is used to classify the input.

[0112] Figure 8 This is a schematic diagram of the structure of a web injection vulnerability detection system for PHP based on intermediate language representation, according to an embodiment of the present invention. The detection system 800 includes:

[0113] The acquisition device 801 is used to acquire source code, analyze it, and divide it into different code pieces, each of which is regarded as an independent piece of code.

[0114] Escape device 802 is used to escape code snippets, escape them according to the context and semantics of the code, and combine the escaped keywords according to a specific syntax to obtain an intermediate language representation of the code snippets;

[0115] The representation device 803 is used to vectorize the escape result of each code slice and input it into Bi-LSTM as training data for model training to obtain a vulnerability detection model.

[0116] Other embodiments of the invention will readily occur to those skilled in the art upon consideration of the specification and practice of the invention disclosed herein. This application is intended to cover any variations, uses, or adaptations of the invention that follow the general principles of the invention and include common knowledge or customary techniques in the art not disclosed herein. The specification and examples are to be considered exemplary only, and the true scope and spirit of the invention are indicated by the claims.

Claims

1. An intermediate language representation method for web injection vulnerabilities, characterized in that, The method is used to represent a classification language for various variables and functions; the method includes: When escaping source code, it is categorized according to the semantics of the code, including string operations, sensitive functions, and... During the escaping process, each line is escaped, and after escaping, they are combined according to a specific syntax to form an intermediate representation of the target code. Instead of classifying every word in the source code to obtain an intermediate language representation of the vulnerability, the source code is classified and escaped for each statement. When escaping source code to intermediate language representation, statements are used as the smallest escape objects, and escaping is classified according to the semantics of each statement in the source code. The escaping process is context-dependent, and targeted escaping is performed according to the propagation path of the pollution source. Parts unrelated to the vulnerability will not be escaped, and the escaping of a code statement is a combination of multiple keywords. When combining keywords, they are combined according to specific syntax; the combination method is determined by the position and semantics of the keywords in the source code, and specific modifications are made according to the semantics; the modifications include string length and the position of variables in the string.

2. The intermediate language representation method according to claim 1, characterized in that, Different code semantics are categorized as follows: Sensitive functions, cleanup functions, variables, comparison operators, strings, string manipulation, whitelists, type validation, conditional statements, and loop statements; Among them, sensitive functions are functions used to trigger SQL injection, XSS, and command injection; clean functions are functions used to perform formal validation on user input; variables include contaminated and uncontaminated variables; type validation includes numeric validation, numeric conversion, string validation, and string conversion; string operations include string concatenation, addition, and replacement; and the results of each category are represented by specific keywords.

3. The intermediate language representation method according to claim 1, characterized in that, Before escaping, the target program is preprocessed to extract the code containing the vulnerability. This preprocessing first analyzes and extracts the vulnerable parts of the code, and marks these parts with information as code to be escaped. The marked information includes the vulnerability type, the file where it is located, and the line of code where it is located.

4. The intermediate language representation method according to claim 1, characterized in that, Keyword combinations include combinations of a single code statement and combinations of the entire source code; individual keywords are combined according to specific rules; after all statements in the source code have been escaped, they are combined according to the context of the statements and their semantic features to indicate vulnerabilities in the code.

5. The intermediate language representation method according to claim 4, characterized in that, The position of a keyword in the source code determines how it is combined after escaping. The keywords after escaping in each line of code are stored in the execution order of the source code. When combining them, the keywords are rearranged according to the call relationship, and specific information about the vulnerability is added after the combination, including the file where the vulnerability is located, the line where the sensitive function is located, and the line where the pollution source is located.

6. An intermediate language representation system for web injection vulnerabilities, the system being used to represent a categorized language of various variables and functions; the system comprising: A representation device used to categorize and represent source code according to its semantics when escaping it, including string manipulations, sensitive functions; and The processing unit is used to escape each line during the escaping process, and then combine them according to a specific syntax to form an intermediate representation of the target code after escaping. Instead of classifying every word in the source code to obtain an intermediate language representation of the vulnerability, the source code is classified and escaped for each statement. When escaping source code into an intermediate language representation, statements are used as the smallest escape objects, and escaping is performed according to the semantics of each statement in the source code. The escaping process is context-dependent, and targeted escaping is performed according to the propagation path of the pollution source. Parts unrelated to the vulnerability will not be escaped, and the escaping of a code statement is a combination of multiple keywords. When combining keywords, they are combined according to specific syntax; the combination method is determined by the position and semantics of the keywords in the source code, and specific modifications are made according to the semantics; the modifications include string length and the position of variables in the string.

7. A method for detecting web injection vulnerabilities in PHP based on intermediate language representation, characterized in that, Includes the following steps: S1: Obtain the source code, analyze it, and divide it into different code pieces, each of which is treated as an independent piece of code; S2: Escape code snippets according to their context and semantics, and combine the escaped keywords according to a specific syntax to obtain an intermediate language representation of the code snippets; S3: Vectorize the escape result of each code snippet and input it into Bi-LSTM as training data to train the model and obtain the vulnerability detection model; Instead of classifying every word in the source code to obtain an intermediate language representation of the vulnerability, the source code is classified and escaped for each statement. When escaping source code into an intermediate language representation, statements are used as the smallest escape objects, and escaping is performed according to the semantics of each statement in the source code. The escaping process is context-dependent, and targeted escaping is performed according to the propagation path of the pollution source. Parts unrelated to the vulnerability will not be escaped, and the escaping of a code statement is a combination of multiple keywords. When combining keywords, they are combined according to specific syntax; the combination method is determined by the position and semantics of the keywords in the source code, and specific modifications are made according to the semantics; the modifications include string length and the position of variables in the string.

8. A web injection vulnerability detection system for PHP based on intermediate language representation, the system comprising: The acquisition device is used to acquire source code, analyze it, and divide it into different code pieces, each of which is treated as an independent piece of code. Escape mechanisms are used to escape code snippets. They escape code snippets based on the context and semantics of the code, and combine the escaped keywords according to a specific syntax to obtain an intermediate language representation of the code snippet. The representation device is used to vectorize the escape result of each code piece and input it into Bi-LSTM as training data for model training to obtain a vulnerability detection model. Instead of classifying every word in the source code to obtain an intermediate language representation of the vulnerability, the source code is classified and escaped for each statement. When escaping source code into an intermediate language representation, statements are used as the smallest escape objects, and escaping is performed according to the semantics of each statement in the source code. The escaping process is context-dependent, and targeted escaping is performed according to the propagation path of the pollution source. Parts unrelated to the vulnerability will not be escaped, and the escaping of a code statement is a combination of multiple keywords. When combining keywords, they are combined according to specific syntax; the combination method is determined by the position and semantics of the keywords in the source code, and specific modifications are made according to the semantics; the modifications include string length and the position of variables in the string.

Images