An automatic mining method of PHP second-order vulnerabilities based on semantic state diagram

Abstract

The application discloses a kind of based on semantic state diagram PHP second-order vulnerability's automation mining method, including based on dynamic log and taint analysis semantic state diagram model and based on semantic state diagram automation vulnerability mining method.Construction semantic state diagram contains two parts, one side is through crawler and builds runtime monitoring program, using coarse-grained dynamic taint analysis to model persistent storage, set server state node on semantic state diagram;The other side is through static analysis method to discover fragile function, and the parameter of fragile function is backtracked, and source code semantic node is set on semantic state diagram.Automated mining method is first solved in semantic state diagram in suspected second-order vulnerability path, according to attack vector library and based on fuzzy test method verifies the existence of second-order vulnerability.Using the above method, the automation mining of second-order vulnerability can quickly locate the position of suspected second-order vulnerability, obtain the correlation between requests, and automatically complete the verification of suspected second-order vulnerability.Through the method, the mining efficiency of second-order vulnerability can be improved, and the comprehensiveness of second-order vulnerability mining is improved.

Description

Technical Field

[0001] This invention relates to the field of vulnerability discovery technology for second-order PHP vulnerabilities, and more particularly, to an automated method for discovering second-order PHP vulnerabilities based on semantic state graphs. Background Technology

[0002] With the rapid development of web applications, a significant portion of critical business operations now rely on them, making web applications an indispensable part of modern society. Currently, most websites use PHP (Hypertext Preprocessor) as their backend development language.

[0003] Second-order vulnerabilities (SOVs) occur when user-input data (corrupted data) is not directly sent to the vulnerability point, but is first stored in persistent storage. When the corrupted data is retrieved from the persistent data store (PDS) and enters the vulnerability trigger point without proper sanitization, it leads to a vulnerability. Based on the form (explicit or implicit) of second-order vulnerabilities in PHP web applications, they can be divided into second-order cross-site scripting vulnerabilities (SOXSSVs) and second-order remote code execution vulnerabilities (SORCEVs).

[0004] With the improvement of vulnerability analysis and intrusion detection technologies, attacks triggered by single-step requests have been effectively mitigated. To conceal their attacks, attackers are pursuing increasingly covert methods and have shifted their focus to PDS (Programmable Threads). The data stream that triggers SOV (Service-Oriented Vulnerability) flows through the PDS; traditional streaming detection methods struggle to analyze intermittent data streams, making this attack method highly stealthy. The data stream that triggers SOV is permanently stored in the PDS, causing persistent impacts on web applications. Most developers are unaware that the data stored in the database is insecure and therefore do not perform any filtering, making SOV highly offensive. Due to the high stealth and offensive nature of SOV, application security and user privacy protection issues arise. A series of security problems, such as user session hijacking, user credential theft, and unauthorized operation execution, pose significant threats to the execution security of web applications and the information security of users. Addressing and resolving SOV detection in web applications is becoming increasingly urgent. However, SOV detection faces many different and severe challenges, and automated detection is one of the most challenging design problems. How to design and implement an automated SOV detection method suitable for PHP web applications has become an urgent problem to solve.

[0005] Static analysis techniques are methods for analyzing vulnerabilities in source code, guided by human-defined vulnerability models. Taint analysis techniques are the most prevalent among these. The basic idea behind this technique is to construct an Abstract Syntax Tree (AST) of the code, trace the path of user-input data (Source) within the code, and determine the presence of sensitive data sinks, such as database queries, system calls, and file operations. Simultaneously, this technique also determines whether effective filtering or validation of user input data exists to uncover vulnerabilities in the program.

[0006] Dynamic analysis techniques record the execution trajectory of a target program, allowing analysis of runtime memory read / write operations, function call relationships, and memory allocation / release information. These techniques primarily include web scraping, log monitoring, and fuzzing. Web scraping simulates user behavior, automatically discovering and crawling links on websites, supports JavaScript rendering, and can crawl dynamic websites. XDEBUG is an open-source extension for PHP debugging and analysis, providing stack tracing, code coverage analysis, performance analysis, and remote debugging capabilities. Fuzzing, based on black-box or gray-box testing principles, uses a large amount of semi-valid data as program input to monitor for anomalies during program execution and records the input data that caused these anomalies. This allows for further localization of defects in the program, thereby discovering potential security vulnerabilities.

[0007] Dynamic and static analysis techniques fully utilize the comprehensiveness of static analysis techniques and the accuracy of dynamic analysis techniques. By using dynamic analysis methods to verify the results of static analysis, more accurate results can be obtained while reducing the false alarm rate.

[0008] In SOV mining, automated detection methods are required to model the data flow through the PDS (Product Data Store), necessitating taint analysis to be able to perform analysis across the PDS. Traditional static and dynamic-static combined analysis methods primarily employ static data flow analysis, constructing a complete data flow by modeling the database's metadata. However, these methods struggle to handle the dynamic nature of modern web applications and generate numerous false positives and false negatives based on the judgment conditions of filtering functions. Traditional dynamic analysis methods utilize dynamic crawling and fuzzing techniques, constructing data dependencies between different pages by populating all fields on the page. However, these methods can only detect SOVs that display information on the page and cannot detect vulnerabilities like SORCEV that execute commands in the background.

[0009] In summary, traditional SOV mining solutions are difficult to automate the discovery of second-order vulnerabilities in PHP web applications, and some solutions rely on extensive traversal to achieve discovery, resulting in low overall efficiency.

[0010] To overcome the shortcomings of the aforementioned automated methods for discovering second-order vulnerabilities in PHP web applications, this invention proposes an automated method for discovering PHP second-order vulnerabilities based on semantic state graphs. This method enables developers to inspect their web applications and discover PHP second-order vulnerabilities in advance, thereby enhancing the security of PHP web applications and protecting user privacy. This invention designs a semantic state graph (SSG) model based on dynamic logs and static taint analysis, and designs, constructs, and solves this model to achieve automated vulnerability discovery for PHP second-order vulnerabilities. This method can quickly locate paths to suspected second-order vulnerabilities, construct relationships between different requests, and automatically verify suspected second-order vulnerabilities. This method not only improves the efficiency of second-order vulnerability discovery in PHP web applications but also enhances the comprehensiveness of second-order vulnerability discovery.

[0011] The present invention provides a method for constructing a semantic state graph model based on dynamic logs and static taint analysis, which includes the following construction steps:

[0012] Step 1: Initialize the SSG model;

[0013] The semantic state graph constructed by combining dynamic runtime logs and static taint analysis is referred to as the SSG model.

[0014] Initially, the SSG model is an empty set;

[0015] The mathematical model of the SSG model is represented as SSG = {DV, DE, DT, DR};

[0016] Step two: Build the PHP web application structure;

[0017] Step 201: Obtain the PHP Web application source code and deploy the PHP Web application, denoted as TSC;

[0018] In this step, the environment for deploying the PHP web application can be a Linux system, using Nginx as the web server, MySQL as the database support, and PHP as the code interpreter.

[0019] Step 202: Register a PHP web application account;

[0020] In this step, registering an account allows the web crawler to crawl more web pages;

[0021] Step 203: Start the crawler and set the PHP web application entry address, username, password, and optional cookies to be crawled;

[0022] Step 204: Output the crawler result, denoted as crawler_result, where crawler_result = {r i |r i = (url, method, header, data)}; where any element r i url represents the request address, method represents the request method, header represents the request header, and data represents the request content;

[0023] In this step, each element r i Each corresponds to an HTTP request, r i The data contained therein can reconstruct the corresponding HTTP request for the webpage, which can access the web application and cause a state transition in the web application.

[0024] Step 3: Construct the dynamic PDS subgraph;

[0025] Step 301: Initialize XDEBUG and enable dynamic logging.

[0026] This step can be done using the PHP debugging tool XDEBUG, which can record the backend code running for each HTTP request;

[0027] Step 302, set the log tracing function;

[0028] Using a MySQL database as an example for PDS, the function reserved words and regular expressions are tracked;

[0029] Step 303: Introduce the crawler result `crawler_result` from step 204, and record the log set MLOG = {LOG1, LOG2, ..., LOG...} corresponding to all requests. i ,…,LOG n}, construct the request layer and PHP file layer nodes and their relationships;

[0030] In this step, first read crawler_result, and then loop through all r values ​​in crawler_result. i For each r i Reconstruct the HTTP request and send it to the web server, and build the request layer node V with this HTTP request. i REQ According to r i The header determines the specific redirection relationship of the request layer. inside FORM inside or JavaScript inside At the same time, the log triggered by this HTTP request is recorded as LOG.i ;

[0031] When constructing an HTTP request, a variable named XDEBUG_TRACE needs to be added to the parameters of the GET or POST request to trigger XDEBUG's logging function.

[0032] Step 304, Read the log. i Add nodes and relationships to the semantic state graph PHP file layer, function layer, and PDS structure layer;

[0033] In this step, the line number of the log containing the tracking function is matched using the regular expression matching function in step 302, and the content of that line is extracted to obtain (path, line), which is then used to construct the PHP file layer node V. j PHPFILE ;

[0034] By splitting the tracing function, obtaining the database operation fields and database table fields, and constructing the function layer node V, i FUNC =(in), construct PDS structure layer node V i BASE =(guestbook); Record the read file and the line number of the code, denoted as select_result={sr|sr=(path,line)}; Finally, construct the inter-layer relationship according to the data flow direction;

[0035] Step 305, Read the log. i Add internal relationships to the semantic state graph PHP file layer;

[0036] In this step, a monotonic stack data structure is used to read the log files sequentially from top to bottom. i By using keywords to determine file inclusion relationships, the layer level of each processed PHP file is guaranteed not to be higher than the node level in the stack, thus ensuring the inclusion relationship between different files. This is achieved through INCLUDE. inside Relationships connect them;

[0037] Step 306: Repeat steps 304 and 305 until MLOG has been traversed.

[0038] Step four: Construct a static fragile function subgraph;

[0039] Step 401: Initialize the fragile function dictionary, read the source code, and load the select_result obtained in step 304;

[0040] In this step, a dictionary of vulnerable functions for second-order vulnerabilities is set up: dict = {echo,print,eval,assert,system,exec,passthru}.

[0041] Step 402: Based on the dictionary of vulnerable functions, perform full-text regular expression matching in the source code to obtain the file and line number of the vulnerable function;

[0042] Step 403: Convert the source code of the file into an abstract syntax tree, backtrack all parameters in the fragile functions, and add internal relations to the semantic state graph FUNC layer; until the initial variable is found or any position sr in select_result is reached. i If the match is found at the position sr in select_result i Then add nodes to the semantic state graph function layer. via PROPAGATE inside Build With sr i corresponding The relationship.

[0043] Compared with existing technologies, the advantages of the PHP second-order vulnerability automated discovery method based on semantic state graphs in this invention are:

[0044] ①The SSG model designed in this invention can establish the association between requests and PHP files, and can combine the accuracy of dynamic analysis with the comprehensiveness of static analysis.

[0045] ② In the process of constructing SSG, this invention solves the problem that static analysis methods are difficult to analyze the data flow of PDS through dynamic analysis; by introducing static analysis on the basis of dynamic analysis, it can discover second-order vulnerabilities that are not displayed on the page, and can more comprehensively discover the trigger points of second-order vulnerabilities.

[0046] ③ The PHP second-order vulnerability automated mining method based on the SSG model designed in this invention adopts an incremental solution method to search the path of SSG, which can quickly determine the injection point and trigger point of suspected second-order vulnerabilities, avoiding the disadvantage of large amount of computation caused by the use of a large number of backtracking methods in traditional methods.

[0047] ④ In the process of automating the discovery of second-order vulnerabilities in PHP, this invention uses a dynamic pollution tracking method to search for dynamic suspected second-order vulnerabilities, a static vulnerable function association method to search for static suspected second-order vulnerabilities, constructs the association relationship between the PHP file containing the second-order vulnerability and its injection and triggering requests, and finally verifies the second-order vulnerability based on fuzz testing, thus enabling automated discovery of second-order vulnerabilities.

[0048] ⑤ The present invention combines the SSG model with the automated second-order vulnerability mining method to achieve the goal of automatically mining second-order vulnerabilities in PHP Web, improving mining efficiency and achieving a higher detection rate. Attached Figure Description

[0049] Figure 1 This is a flowchart of the process of constructing the SSG model according to the present invention.

[0050] Figure 2 It is a structure diagram of a semantic state diagram.

[0051] Figure 3 It is a flowchart for constructing a semantic state graph based on dynamic logs and static taint analysis.

[0052] Figure 4 This is a screenshot of the log.

[0053] Figure 5 This is a technical roadmap for automated discovery of second-order vulnerabilities. Detailed Implementation

[0054] The present invention will now be described in further detail with reference to the accompanying drawings and embodiments.

[0055] Part 1: A Semantic State Graph Model Based on Dynamic Logs and Static Tag Analysis, namely the SSG model.

[0056] See Figure 1 As shown, this invention employs a semantic state graph, or SSG model, constructed by combining dynamic runtime logs and static taint analysis. The SSG model can fully represent the triggering process of a PHP second-order vulnerability and automatically verify its existence.

[0057] like Figure 1 , Figure 2 As shown, the constructed SSG model has a four-layer structure: request layer, PHP file layer, function layer, and PDS structure layer. (1) Request layer: This layer models dynamic requests and can represent all interfaces of the PHP Web application that interact with the user. It can also represent the relationship diagram of the page and the navigation structure of the front-end state of the PHP Web application. (2) PHP file layer: This layer is the connecting layer. Based on the strong correlation between the results of dynamic analysis and the relevant code of the executed PHP file, the semantics of the lower-level code can be linked to the request layer through this layer. (3) Function layer: This layer represents the ability to aggregate read and write functions and fragile functions for persistent storage to determine the direction of data flow. (4) PDS structure layer: This layer represents the logical information of the database table and associates the relationships between requests based on this information.

[0058] In this invention, the mathematical model of the SSG model is represented as SSG = {DV, DE, DT, DR}.

[0059] DV represents a set of nodes, and DV = {V1, V2, ..., V} a ,…,V b ,…,V X}, where the subscript 'a' represents the node identifier and the subscript 'X' represents the total number of nodes. V1 represents the first node, V2 represents the second node, and V a V represents the a-th node (also called any node). b V represents the b-th node (also known as any other node). X This indicates the last node.

[0060] DE represents the set of edges formed by connecting nodes.

[0061] DT represents the node identity type, and DT = {REQ,PHPFILE,FUNC,BASE}.

[0062] REQ is a request-type identity node. The REQ node includes: a unique page state ID, a request URL, a request method, a request content data, and identity information role, i.e., REQ = (id, url, method, data, role).

[0063] PHPFILE is a PHP file class identity node. The PHPFILE contains the path to the PHP file, denoted as path.

[0064] FUNC is a function-class identity node. The function node FUNC includes: the PDS write function in, the PDS read function out, and the fragile function sink, that is, FUNC = (in, out, sink).

[0065] BASE is the identity node of the PDS structure layer. The BASE contains the name of the PDS structure layer, denoted as `name`. In this invention, `name` corresponds to the database table name of the PHP web application.

[0066] The

[0067] DR represents the hierarchical relationship between nodes. In this invention, the hierarchical relationship is divided into the internal relationship (inside) and the inter-layer relationship (outside), i.e., DR = [inside, outside].

[0068] The inner layer relationship "inside" includes the jump relationship "LINK". inside Form redirection relationshipinside Script navigation relationships in JavaScript inside Inclusion relation INCLUDE inside PROPAGATE and data propagation relationship inside ,Right now The relationships located within the request layer are LINK. inside FORM inside and JavaScript inside The INCLUDE keyword, located within the PHP file layer, represents a specific relationship. inside The PROPAGATE relation is located within the function layer. inside .

[0069] The "outside" layer relationship includes the "CALL" call relationship. outside Containment function relationship CONTAIN outside Input relation IN outside Output relationship OUT outside That is, outside = {CALL outside CONTAIN outside IN outside ,OUT outside}

[0070] The

[0071] The

[0072] In constructing the SSG model, a dynamic analysis-based approach, supplemented by static analysis, was used to model second-order vulnerabilities. The technical solution is as follows: Figure 3 As shown. In the semantic state graph construction process based on dynamic logs and static taint analysis of this invention, on the one hand, by crawling and building a runtime monitoring program, coarse-grained dynamic taint analysis is used to model persistent storage, which can better represent the dynamic state of the server; on the other hand, by using static analysis methods to discover vulnerable functions and backtracking the parameters of vulnerable functions, semantics can be extracted from the source code of the PHP web application, which can more comprehensively discover second-order vulnerabilities.

[0073] Step 1: Initialize the SSG model;

[0074] Initially, the SSG model is an empty set.

[0075] The mathematical model of the SSG model is represented as SSG = {DV, DE, DT, DR}.

[0076] DV represents a set of nodes.

[0077] DE represents the set of edges formed by connecting nodes.

[0078] DT represents the node identity type.

[0079] DR represents the hierarchical relationship between nodes.

[0080] Step two: Build the PHP web application structure;

[0081] Step 201: Obtain the PHP Web application source code and deploy the PHP Web application, denoted as TSC;

[0082] In this step, the environment for deploying the PHP web application can be a Linux system, using Nginx as the web server, MySQL as the database, and PHP as the code interpreter.

[0083] Step 202: Register a PHP web application account;

[0084] Registering an account in this step allows the web crawler to access more web pages.

[0085] Step 203: Start the crawler and set the PHP web application entry address, username, password, and optional cookies to be crawled;

[0086] This step first requires setting up the crawler environment. This includes disabling browser options that affect page rendering to speed up the crawler without compromising page rendering. Simultaneously, you need to configure the browser's User Agent (UA), enable request interception, and inject initialization hook code. This can be done using the open-source tool crawlergo. The download address for crawlergo is: https: / / github.com / Qianlitp / crawlergo.

[0087] Step 204: Output the crawler result, denoted as crawler_result, where crawler_result = {r i |r i = (url, method, header, data)}; where any element r i url represents the request address, method represents the request method, header represents the request header, and data represents the request content.

[0088] In this step, each element r i Each corresponds to an HTTP request, r i The contained data content can reconstruct the corresponding HTTP request for the webpage, which can access the web application and cause a state transition in the web application.

[0089] In this invention, the input obtained after the second construction step is the application source code TSC, and the output is the crawler result crawler_result.

[0090] Step 3: Construct the dynamic PDS subgraph;

[0091] Step 301: Initialize XDEBUG and enable dynamic logging.

[0092] This step can be done using the PHP debugging tool XDEBUG, which can log the backend code for each HTTP request. To reduce overhead, a keyword-triggered logging pattern is used. For setup instructions, refer to https: / / xdebug.org / docs / profiler.

[0093] Step 302, set the log tracing function;

[0094] This invention uses a MySQL database as an example of a PDS to track function reserved words and regular expressions.

[0095] For example: the database write function: INSERT, corresponding to INSERT\s+INTO\s+[\d\w\.]+.

[0096] For example, the database update function is UPDATE, which corresponds to UPDATE\s+[\d\w\.]+\s+SET.

[0097] For example, the database update function REPLACE corresponds to INSERT\s+INTO\s+[\d\w\.]+.

[0098] For example, the database read function SELECT corresponds to SELECT.+FROM\s+[\d\w\.]+.

[0099] Step 303 introduces the crawler_result from step 204, recording the logs corresponding to all requests, as well as the relationship between the nodes used to construct the request layer and the PHP file layer;

[0100] In this invention, the log set corresponding to the request is denoted as MLOG, and MLOG = {LOG1, LOG2, ..., LOG}. i ,...,LOG n The log file contains LOG1 for the first request, LOG2 for the second request, and LOG3 for the i-th request. i Log for the nth request n .

[0101] In this step, first read crawler_result, and then loop through all r values ​​in crawler_result. i For each r i Reconstruct the HTTP request and send it to the web server, and build the request layer node V with this HTTP request. i REQ According to r i The header determines the specific redirection relationship of the request layer. inside FORM inside or JavaScript inside At the same time, the log triggered by this HTTP request is recorded as LOG. i .

[0102] When constructing an HTTP request, a variable named XDEBUG_TRACE needs to be added to the parameters of the GET or POST request to trigger XDEBUG's logging function. The log content is as follows: Figure 4 As shown, the log is recorded line by line, and the log result is represented as LOG. i = {l|l=(time,func,path,line)}, where l represents the log line number, including time (time), func (function called), path (PHP file path), and line (line of executed code).

[0103] Then, according to LOG i Line 2 (each LOG) i Both exist and contain the keyword "main"), constructing the PHP layer node V. i PHPFILE Path is the last field, such as Figure 4 The file is located at / srv / http / dvwa / vulnerabilities / xss_s / index.php. Then, a CALL is used. outside Building V i REQ and V i PHPFILE The relationship.

[0104] Step 304, Read the log. i Add nodes and relationships to the semantic state graph PHP file layer, function layer, and PDS structure layer;

[0105] In this step, the line number of the log containing the tracking function is matched using the regular expression matching function in step 302, and the content of that line is extracted to obtain (path, line), which is then used to construct the PHP file layer node V. j PHPFILE .like Figure 3 As shown, the tracked location is highlighted in blue, and the corresponding path and line are: / srv / http / dvwa / vulnerabilities / xss_s / index.php and "19" respectively.

[0106] Decompose the tracing function to obtain the database operation fields and database table fields. For example, if the database operation field is INSERT and the table name is guestbook, construct the function layer node V. i FUNC =(in), construct PDS structure layer node V i BASE =(guestbook). Note that the read function requires additional processing to record the read file and the line number of the code, denoted as select_result={sr|sr=(path,line)}. Finally, based on the data flow direction, the inter-layer relationships are constructed, as in this example, through IN outside Building V i FUNC and V i BASE The relationship, through CONTAIN outside Build and V i FUNC The relationship.

[0107] Step 305, Read the log. i Add internal relationships to the semantic state graph PHP file layer.

[0108] This step establishes the inclusion relationship between the PHP file nodes in step 304 and the PHP file nodes in step 303. For example... Figure 2 The relationship between F1 and F3 in PHP file layers: F1 contains F2, and F2 contains F3.

[0109] This step uses a monotonic stack data structure to read the log files sequentially from top to bottom. i The inclusion relationship between files is determined by the keyword "->". The hierarchy of each processed PHP file is guaranteed not to be higher than the node hierarchy in the stack, thus ensuring the inclusion relationship between different files. This is achieved through INCLUDE. inside Relationships connect us.

[0110] Step 306: Repeat steps 304 and 305 until MLOG has been traversed.

[0111] Step four: Construct a static fragile function subgraph;

[0112] Step 401: Initialize the fragile function dictionary, read the source code, and load the select_result obtained in step 304;

[0113] In this step, a dictionary of vulnerable functions for second-order vulnerabilities is set up: dict = {echo, print, eval, assert, system, exec, passthru}.

[0114] Step 402: Based on the dictionary of fragile functions, perform full-text regular expression matching in the source code to obtain the file and line number of the fragile function.

[0115] Step 403: Convert the source code of the file into an abstract syntax tree, backtrack all parameters in the fragile functions, and add internal relationships to the semantic state graph FUNC layer. Next, extract the parameters from the fragile functions and start a variable analysis function for each parameter. The variable analysis function searches for assignment statements in the abstract syntax tree, recursively analyzing the rvalues ​​in the assignment statements as new variables until the initial variable is found or any position `sr` in `select_result` is reached. i If the match is found at the position sr in select_result. i Then add nodes to the semantic state graph function layer. via PROPAGATE inside Build With sr i corresponding The relationship.

[0116] In this invention, the abstract syntax tree is referenced from the "Research on Static Automatic Testing Method of Code Based on Abstract Syntax Tree" in the Journal of Beijing University of Chemical Technology, Vol. 34, Supplement I, 2007, authored by Gao Chuanping, which describes the conversion of source code into an abstract syntax tree.

[0117] In this invention, the input obtained through steps three and four is the source code TSC and the crawler result crawler_result, and the output is a semantic state graph.

[0118] Part Two: Automated Discovery of Second-Order PHP Vulnerabilities Using the SSG Model

[0119] In this invention, the SSG model is applied to represent the runtime information and source code information of a web application. Then, the SSG model is solved to automatically verify the existence of second-order vulnerabilities. The automated second-order vulnerability discovery method of this invention is as follows: Figure 5 As shown, this method first solves for suspected second-order vulnerability paths in the semantic state graph, and then verifies the triggerability of suspected second-order vulnerabilities based on an attack vector library and a fuzz-based method. An incremental solution approach is used to improve the efficiency of vulnerability discovery.

[0120] Step 1: Construct a semantic state graph and collect dynamic runtime logs and source code information from the PHP web application;

[0121] In this step, according to the first part of the present invention, SSG is first initialized, the Web application environment is initialized, and XDEBUG is initialized.

[0122] Then obtain the PHP web application source code, deploy the PHP web application, and denote it as TSC.

[0123] Register as a user, start the crawler, and set the PHP web application entry address, username, password, and optional cookies to be crawled;

[0124] Record the crawler results (crawler_result) 当前 Replay the crawler results (crawler_result) 当前 Record the current log set MLOG for all requests. 当前 Establish the relationship between nodes in the request layer and the PHP file layer;

[0125] Loop through the logs (LOG) i Add nodes and relationships to the semantic state graph PHP file layer, function layer, and PDS structure layer.

[0126] Read the source code, perform full-text regular expression matching in the source code according to the fragile function dictionary, obtain the file and line number of the fragile function, convert the source code of the file into an abstract syntax tree, backtrack all parameters in the fragile function, and add internal relations to the semantic state graph FUNC layer.

[0127] Step 2: Based on pattern matching methods, discover the suspected second-order vulnerability path suspath=(REQ 注入 REQ 触发 );

[0128] REQ 注入 This indicates a request to inject data into the PDS.

[0129] REQ 触发 This indicates a request that can trigger malicious code in the PDS.

[0130] Step 2A: Read the PDS structure layer nodes in the semantic state graph and search for nodes whose attribute is IN. outside For all nodes, a forward search request list of injection points is denoted as list_in, and

[0131] The search connection for this node has the attribute OUT. outsideFor all nodes, request a list of subsequent search trigger points, denoted as list_out, and

[0132] A global search request list for vulnerable functions is denoted as list_sink, and And determine the relationship with BASE.

[0133] In this step, the PDS structure layer node acts as an intermediate node, which can search for the database table name (table), write function (in), PDS read function (out), and vulnerable function (sink) in the semantic state graph, and can associate requests, files, and functions.

[0134] Step 2B, static suspected path solving;

[0135] In this step, if the sink function's related data is empty, the static suspected path solving stage is skipped. If the sink function's related data is not empty, all requests in the in function's related data (list_in) and all requests in the sink function's related data (list_sink) are associated. This association includes associating all requests and their parameters, and then adding them to the suspath set.

[0136] Step 2C, dynamic suspected path solving;

[0137] In this step, dynamic pollution tracking is used to associate injection requests and read requests. First, all request list_in in the data related to the in function is analyzed. If a request can inject information into the table, all fields of the request are identified, and a unique token is submitted to the corresponding field. After that, all request list_out in the data related to the out function is accessed. If a unique token is found in the response, the injection request and the response request are added to the suspath set.

[0138] Step 3: Based on the fuzzing method, verify the suspected second-order vulnerability path and output the vulnerability report result;

[0139] Step 3A: Read the attack vector database, read the suspected second-order vulnerability path suspath obtained in step four, and start the web monitoring device;

[0140] In this step, the attack vector library can be found on GitHub, for example:

[0141] https: / / github.com / payloadbox / xss-payload-list.

[0142] https: / / github.com / payloadbox / command-injection-payload-list.

[0143] The webpage monitor is implemented using Python. It determines whether the webpage response contains a script that pops up a dialog box, which is used to verify whether the attack vector has successfully triggered the vulnerability.

[0144] Step 3B, cyclically feed REQ 注入 Inject attack vectors and monitor REQ. 触发 The response results will be used to output a vulnerability report.

[0145] In this step, an attack vector is randomly selected and injected. The success of the attack is determined by the web monitoring system. If successful, a second-order vulnerability report (result) is output and the verification ends. If unsuccessful, a new attack vector is selected until the vulnerability is successfully triggered or the maximum number of attempts is reached.

[0146] Example 1

[0147] The method was deployed in a PHP web application, and its ability to detect second-order vulnerabilities in PHP web applications was compared with that of BLACK WIDOW and Burp Suite Pro. Experiments were conducted on PHP web applications such as DVWA, PIKACHU, and SCARF to verify the method. Experimental results show that the method can effectively detect second-order vulnerabilities and discover more vulnerabilities in a shorter time compared to other tools. The time cost and number of vulnerabilities are shown in the table below.

[0148] Table 1 Comparison of Detection Capabilities

[0149]

[0150] Table 2 Comparison of Time Costs

[0151]

[0152] In the comparative experiment on detection capabilities, the method of this invention introduces static analysis while monitoring runtime state, enabling a more comprehensive identification of vulnerable functions in PHP web applications compared to BlackWidow and Burp Suite Pro. As shown in Table 1, the method of this invention can find more vulnerabilities. In the comparative experiment on detection time overhead, the method of this invention not only monitors the page content but also includes dynamically generated logs. Through the hierarchical structure of the semantic state graph, different types of requests are associated through the PDS structure, greatly reducing the search space for second-order vulnerabilities. In contrast, BlackWidow and Burp Suite Pro only monitor page content, resulting in a large amount of traversal analysis. As shown in Table 2, the method of this invention can significantly reduce the time overhead for second-order vulnerabilities.

Claims

1. A method for constructing a semantic state graph model based on dynamic logs and static taint analysis, characterized in that... The following are the construction steps: Step 1: Initialize the SSG model; The semantic state graph constructed by combining dynamic runtime logs and static taint analysis is referred to as the SSG model. Initially, the SSG model is an empty set; The mathematical model of the SSG model is represented as SSG = {DV, DE, DT, DR}; Step two: Build the PHP web application structure; Step 201: Obtain the PHP Web application source code and deploy the PHP Web application, denoted as TSC; In this step, the environment for deploying the PHP web application can be a Linux system, using Nginx as the web server, MySQL as the database support, and PHP as the code interpreter. Step 202: Register a PHP web application account; In this step, registering an account allows the web crawler to crawl more web pages; Step 203: Start the crawler and set the PHP web application entry address, username, password, and optional cookies to be crawled; Step 204: Output the crawler result, denoted as crawler_result, where crawler_result = {r i |r i = (url, method, header, data)}; where any element r i url represents the request address, method represents the request method, header represents the request header, and data represents the request content; In this step, each element r i Each corresponds to an HTTP request, r i The data contained therein can reconstruct the corresponding HTTP request for the webpage, which can access the web application and cause a state transition in the web application. Step 3: Construct the dynamic PDS subgraph; Step 301: Initialize XDEBUG and enable dynamic logging. This step can be done using the PHP debugging tool XDEBUG, which can record the backend code running for each HTTP request; Step 302, set the log tracing function; Using a MySQL database as an example for PDS, the function reserved words and regular expressions are tracked; Step 303: Introduce the crawler result `crawler_result` from step 204, and record the log set MLOG = {LOG1, LOG2, ..., LOG...} corresponding to all requests. i ,...,LOG n }, construct the request layer and PHP file layer nodes and their relationships; In this step, first read crawler_result, and then loop through all r values ​​in crawler_result. i For each r i Reconstruct the HTTP request and send it to the web server, and build the request layer node V with this HTTP request. i REQ According to r i The header determines the specific redirection relationship of the request layer. inside FORM inside or JavaScript inside At the same time, the log triggered by this HTTP request is recorded as LOG. i ; When constructing an HTTP request, a variable named XDEBUG_TRACE needs to be added to the parameters of the GET or POST request to trigger XDEBUG's logging function. Step 304, Read the log. i Add nodes and relationships to the semantic state graph PHP file layer, function layer, and PDS structure layer; In this step, the line number of the log containing the tracking function is matched using the regular expression matching function in step 302, and the content of that line is extracted to obtain (path, line), which is then used to construct the PHP file layer node. By splitting the tracing function, obtaining the database operation fields and database table fields, and constructing the function layer node V, i FUNC =(in), construct PDS structure layer node V i BASE =(guestbook); Record the read file and the line number of the code, denoted as select_result={sr|sr=(path,line)}; Finally, construct the inter-layer relationship according to the data flow direction; Step 305, Read the log. i Add internal relationships to the semantic state graph PHP file layer; In this step, a monotonic stack data structure is used to read the log files sequentially from top to bottom. i By using keywords to determine file inclusion relationships, the layer level of each processed PHP file is guaranteed not to be higher than the node level in the stack, thus ensuring the inclusion relationship between different files. This is achieved through INCLUDE. inside Relationships connect them; Step 306: Repeat steps 304 and 305 until MLOG has been traversed. Step four: Construct a static fragile function subgraph; Step 401: Initialize the fragile function dictionary, read the source code, and load the select_result obtained in step 304; In this step, a dictionary of vulnerable functions for second-order vulnerabilities is set up: dict = {echo,print,eval,assert,system,exec,passthru}. Step 402: Based on the dictionary of vulnerable functions, perform full-text regular expression matching in the source code to obtain the file and line number of the vulnerable function; Step 403: Convert the source code of the file into an abstract syntax tree, backtrack all parameters in the fragile functions, and add internal relations to the semantic state graph FUNC layer; until the initial variable is found or any position sr in select_result is reached. i If the match is found at the position sr in select_result i Then add nodes to the semantic state graph function layer. via PROPAGATE inside Build With sr i corresponding The relationship.

2. A method for automated discovery of second-order PHP vulnerabilities using the SSG model of claim 1, characterized in that... The excavation process includes the following steps: Step 1: Construct a semantic state graph and collect dynamic runtime logs and source code information from the PHP web application; First, initialize SSG, initialize the Web application environment, and initialize XDEBUG; Then obtain the PHP web application source code, deploy the PHP web application, and denote it as TSC; Register as a user, start the crawler, and set the PHP web application entry address, username, password, and optional cookies to be crawled; Record the crawler results (crawler_result) 当前 Replay the crawler results (crawler_result) 当前 Record the current log set corresponding to all requests. 当前 Construct the nodes and relationships of the request layer and PHP file layer; Loop through the logs (LOG) i Add nodes and relationships to the semantic state graph PHP file layer, function layer, and PDS structure layer; Read the source code, perform full-text regular expression matching in the source code according to the fragile function dictionary, obtain the file and line number of the fragile function, convert the source code of the file into an abstract syntax tree, backtrack all parameters in the fragile function, and add internal relations to the semantic state graph FUNC layer. Step 2: Based on pattern matching methods, discover the suspected second-order vulnerability path suspath=(REQ 注入 REQ 触发 ); Step 2A: Read the PDS structure layer nodes in the semantic state graph and search for nodes whose attribute is IN. outside For all nodes, the forward search injection point request list is list_in; The search connection for this node has the attribute OUT. outside For all nodes, the list of backward search trigger points is list_out; The global search for vulnerable function requests is set to list_sink, and its relationship with BASE is determined. In this step, the PDS structure layer node acts as an intermediate node, searching for the database table name (table), write function (in), PDS read function (out), and vulnerable function (sink) in the semantic state graph, which enables the association of requests, files, and functions. Step 2B, static suspected path solving; In this step, if the sink function related data is empty, the static suspected path solving stage is skipped; if the sink function related data is not empty, all requests in the in function related data list_in and all requests in the sink function related data list_sink are associated. The association includes associating all requests and their parameters and adding them to the suspath set. Step 2C, dynamic suspected path solving; In this step, dynamic pollution tracking is used to associate injection requests and read requests. First, all request list_in in the data related to the in function is analyzed. If a request can inject information into the table, all fields of the request are identified and a unique token is submitted to the field. After that, all request list_out in the data related to the out function is accessed. If a unique token can be found in the response, it is added to the suspath set. Step 3: Based on the fuzzing method, verify the suspected second-order vulnerability path and output the vulnerability report result; Step 3A: Read the attack vector database, read the suspected second-order vulnerability path suspath obtained in step four, and start the web monitoring device; The webpage monitor is implemented using Python. It determines whether the webpage response contains a script that pops up a dialog box, which is used to verify whether the attack vector has successfully triggered the vulnerability. Step 3B: Loop through the REQs for each record in suspath. 注入 Inject attack vectors and monitor REQ. 触发 The response results will be used to output a vulnerability report; In this step, an attack vector is randomly selected and injected. The success of the attack is determined by the web monitoring system. If successful, a second-order vulnerability report (result) is output and the verification ends. If unsuccessful, a new attack vector is selected until the vulnerability is successfully triggered or the maximum number of attempts is reached.

Images