A Static Detection Method for SQL Injection Vulnerability Based on Program Transformation

Abstract

Static analysis is popular for detecting SQL injection vulnerabilities. However, due to the lack of accurate modeling of object-oriented database extensions, current methods fail to accurately detect SQL injection vulnerabilities in applications that use object-oriented database extensions. We propose a program transformation-based SQL injection vulnerability detection method to address this issue. This method consists of two stages: program transformation and vulnerability detection. In the first stage, object-oriented database extensions are automatically transformed into semantically equivalent procedural database extensions through the identification of key statements, call relation verification, and program transformation. In the second stage, application programs are automatically scanned using a combination of control flow graph construction and taint analysis techniques to detect SQL injection vulnerabilities. Based on the proposed method, we have implemented the OODBE-SCAN prototype system and performed experimental analysis on eight modern PHP applications. We compare OODBE-SCAN with two related static analysis tools, RIPS and Seay. The results show that OODBE-SCAN can detect more real-world vulnerabilities and has higher accuracy than existing methods.

1. Introduction

SQL injection vulnerability detection has become a research hot spot in information security [1]. Currently, the mainstream approach is to use static analysis techniques to detect SQL injection vulnerabilities. Static analysis technology refers to analyzing web application code without executing it, mainly relying on syntax and semantic features, such as abstract syntax tree (AST), control flow graph (CFG), and call flow graph, matching according to the characteristics of vulnerabilities to discover them [2]. After a long development, static analysis techniques have become increasingly mature and have been used to automate the detection of SQL injection vulnerabilities with certain results [3,4,5,6,7,8,9,10,11,12]. However, existing static analysis techniques cannot accurately detect SQL injection vulnerabilities in applications that use object-oriented database extension (OODBE).

An OODBE is a type of database that applies an object-oriented programming style. The object-oriented programming style was introduced in PHP 5. The core features of PHP object-oriented programming include class, object, encapsulation, inheritance, and polymorphism, which have strong dynamism and flexibility. In our study, we investigated existing solutions of static analysis tools and identified that their inability to effectively and accurately detect SQL injection vulnerabilities in applications utilizing OODBE is mainly due to their lack of modeling for OODBE or their use of regular expression matching to detect vulnerabilities [3,10,12,13,14,15,16]. As a result, existing techniques fail to accurately determine the object involved in method calls (e.g., $\$obj$ in $\$obj\to f\left(\right)$), leading to false negatives, or they may only match method names (e.g., $f\left(\right)$ in $\$obj\to f\left(\right)$), resulting in false positives.

We propose a program transformation-based SQL injection vulnerability detection technique to address this issue, which consists of two stages: program transformation and vulnerability detection. The first stage is divided into three parts. The first part is to automatically identify the database extension and search for the source points (in our technique, referring to the instantiation of a database extension class into an object) and sink points (in our technique, referring to sensitive operations in the database extension, such as ($\$conn\to query$).

In the second part, data flow analysis is performed to determine the relation of method calls. The third part performs a program transformation to convert the key statements identified in the first two parts from an object-oriented programming style to a procedural programming style, automatically converting an OODBE to a semantically equivalent procedural database extension. The second stage is divided into two parts. The first part constructs a control flow graph to generate basic blocks and function summaries to model the entire application framework. In the second part, taint analysis techniques are applied to automatically scan application programs to detect SQL injection vulnerabilities. A prototype system, OODBE-SCAN, was developed based on the techniques. We conduct a comprehensive evaluation of OODBE-SCAN on a dataset containing eight representative PHP applications. Experimental results demonstrate the capability of OODBE-SCAN to detect SQL injection vulnerabilities in applications using OODBE. We also compare OODBE-SCAN with the existing static analysis tools RIPS [3] and Seay [15], and the experimental results show that OODBE-SCAN can not only detect more SQL injection vulnerabilities but also with higher accuracy.

2. Background

2.1. SQL Injection Vulnerability

SQL injection vulnerability is a common type of web vulnerability that allows an attacker to bypass the authentication and authorization mechanisms of an application by constructing malicious SQL queries to obtain sensitive data or perform unlawful operations on the database. In a normal application, data are typically entered by the user and somehow passed to the back-end database for corresponding queries, updates, and deletions [17]. If the application does not properly filter or evade these user inputs, the attacker can insert malicious SQL statements into the inputs, causing the application to execute unexpected queries or actions, such as deleting tables, inserting data, or leaking sensitive information [17].

2.2. Database Extensions

Database extensions refer to the extension libraries provided by PHP for various types of databases, which enable PHP developers to interact with databases through their programs. A database in PHP may have one or more extensions, both official and third-party. For example, MySQLi commonly uses native MySQL libraries, enhanced MySQL extensions, or PHP Data Objects (PDO) for connectivity and manipulation. Different extensions provide similar basic operational approaches but may have some new features and differences in operational performance. The OODBE connects to and manipulates the database through some key statements, which are all in the object-oriented programming style.

In PHP, there are two main OODBE: MySQLi and PDO. MySQLi is an enhanced version of MySQL that provides an object-oriented interface, prepared statements, and transaction processing.

To connect to a database in an object-oriented manner, a MySQLi object representing the connection to the database needs to be created first. For example $\$conn=newmysqli$$(‘localhost’, ‘username’, ‘password’, ‘mydb’)$. After a successful connection, the methods of the $\$conn$ can be called to operate on the database. For example, the select query statement: $\$result=\$conn\to query\left(\$query\right);\$query=“SELECT\ast FROMmytable”$. Or insert query statement: $\$this\to db\to query(“INSERTINTOsystem\_settingsset”. \$data$). PDO is a lightweight, scalable OODBE that provides a unified API that makes it easy for developers to work with different types of databases. When using a PDO to connect to a database, parameters such as database type, hostname, user name, and password need to be specified. For example $\$pdo=newPDO(“mysql:host=localhost;dbname=mydatabase”,$$“username”,“password”)$. The PDO provides a function for the prepared statement. By using parameterized queries, the risk of SQL injections can be effectively avoided, and the security and reliability of code can be improved. When executing a query, a prepared statement using the prepare() method needs to be created first, and then the bindValue() method to bind parameters is used, and the execute() method is called. For example: $\$stmt=pdo\to prepare(“SELECT\ast FROMuserWHEREid=?”);\$stmt\to$$bindValue(1,1);\$stmt\to execute\left(\right)$.

2.3. Taint Analysis

Taint analysis is a technique to track and analyze the flow of tainted information in a program [18,19]. The object of its analysis is the tainted information flow [20]. In the process, information from outside the program is often considered tainted. The process of taint analysis often consists of several steps: identifying and labeling points in a program where taint information is generated, tracking and analyzing the propagation of taint information through specific rules, and checking whether critical operations at key program points are affected by taint information [21,22]. In general, the point where tainted information is generated is called the source point, and the point where tainted information is examined is called the sink point [23]. The propagation rule for tainted information is called the taint analysis rule [24]. During the analysis process, it is also important to pay attention to whether the taint has been handled by a sanitization function. If the taint is handled by a sanitization function, the spread of the taint is interrupted, and the taint analysis ends here. The sanitization process aims to make data transmission harmless to the information security of the application by means of data encryption or removing harmful operations.We draw on the ideas of taint analysis in our approach. We treat sensitive operations in database extensions as sink points and instantiations of database extension classes as objects as source points. In the data flow analysis process, we focus on the variable state information and also formulate the taint analysis rules based on whether the property information has changed or not.

3. Motivating Example

In this section, we analyze the limitations of the current technique through specific examples, as shown in the Figure 1. OODBE primarily utilizes an object-oriented programming style. In Figure 1b, the mysqli database extension class is instantiated as an object and assigned to the variable $\$conn$ (line 2). Subsequently, database operations are performed by directly invoking methods on this object variable. By calling the query method of $\$conn$, various operations on the database can be performed (in this example, we have chosen the most common select operation for injection attacks), and the result is assigned to the variable $\$user$ (line 4). Process ➀ depicts this process. In Figure 1c, the application encapsulates the mysqli database extension within a new class called DBConnection (line 2). Within this class, an attribute $\$conn$ is defined (line 3), and the instantiated mysqli database extension object is assigned to the $\$conn$ attribute (line 6). Finally, the methods of the $\$conn$ attribute are invoked to execute database query operations (line 8). Process ➁ represents this process. Figure 1 illustrates an example of an SQL injection attack on a web application that utilizes OODBE. In Figure 1a, an attacker sends malicious input through a text box on the website (via the $‘id’$ parameter). As shown in Figure 1b, the server-side program is vulnerable to the attack because it directly passes the input to the invoked method $\$conn\to query\left(\right)$, which executes the injected command (line 4). Process ➂ depicts this process. Similarly, Figure 1c demonstrates another susceptible code segment with the same vulnerability principle. Process ➃ represents the attack process.

Due to the lack of comprehensive and accurate modeling of OODBE [3,10,12], existing static analysis techniques are unable to effectively detect SQL injection vulnerabilities in this class of extensions. Taking the classic static analysis tool RIPS as an example, its vulnerability detection process is based on tracing parameters backward from sink functions. However, in applications using mysqli and PDO database extensions, sink functions often appear in an object-oriented encoding form. For example, $\$conn=newmysqli\left(\right);\$conn\to query\left(\right)$, where $\$conn$ is an object instantiated from the mysqli class, and query() is a method within the $\$conn$ object. By calling methods within an object to perform various operations, such as select, insert, and update, etc. Since RIPS does not model this type of data, it cannot identify $\$conn\to query\left(\right)$. Without finding the sink function, the static analysis cannot proceed, resulting in a significant number of false negatives. Some static analysis techniques may already model object-oriented data types, but their lack of precision greatly affects the efficiency of discovering SQL injection vulnerabilities [13,14,15]. For example, the static analysis tool Seay employs a regular expression matching strategy to find the sink function [25]. In the case of $\$conn\to query\left(\right)$, although the method $\$conn\to query\left(\right)$ is matched, it fails to determine which class the object $\$conn$ is instantiated from. This strategy leads to contamination propagation and a large number of false positives. In summary, the limitations of current static analysis techniques boil down to two main points:

• Existing static analysis techniques do not model object-oriented data types, which leads to the inability to find sink points in web applications that utilize OODBE. As a result, static analysis cannot proceed properly, leading to a significant number of false negatives;
• A few static analysis techniques have modeled object-oriented data types, but they use regular expression matching to find sink functions. They only match the object and the called method (e.g., $obj\to f\left(\right)$) without determining which class instantiated the object, causing contamination propagation and resulting in numerous false positives.

In this work, we aim to propose a static analysis technique that can detect SQL injection vulnerabilities in PHP applications that utilize an OODBE.

4. Design

OODBE-SCAN is divided into two main parts, the first of which is the program transformation, which we call DBE-converter. In the first part, the PHP parser first parses the source code of the application into an AST, which is passed to the core part of the DBE-converter. The core section is divided into three phases. In the first phase, the key statements of the database expansion and the locations of the source and sink points are automatically identified. In the second phase, the method call relations are determined by data flow analysis. The third phase is the program transformation, which transforms the key statements identified in the previous two parts from an object-oriented programming style to a process-oriented programming style. In this part, an OODBE database is automatically transformed into semantically equivalent process-oriented database extensions. The second part is the vulnerability scanner, which is divided into two phases. In the first phase, the CFG is constructed, and basic block summaries and function summaries are generated to enable the modeling of the entire application framework. The generated CFG, basic blocks, and function summaries are passed to the second phase as input data. In the second phase, a taint analysis is applied to backtrack the parameters of the sink. If the sink parameters successfully reach the source, a context-sensitive data flow analysis is performed on the source to determine the vulnerability. Finally, the vulnerability information is output. The architecture of OODBE-SCAN is depicted in Figure 2.

4.1. DBE-Converter

The core part of DBE-converter is divided into three parts, including key statement identification, call relation verification, and program transformation. It can automatically convert OODBE into semantically equivalent program-oriented database extensions.

4.1.1. Key Statement Identification

First, the DBE-converter needs to identify the database extension used by the application program and find the object variables instantiated by the database extension class as source points. In this paper, we focus on the analysis of MySQLi and PDO, which are currently the most widely used types of database extensions. Application programs may directly use these two types of database extensions. Then, all potential sink points are identified.

In terms of design details, PHP-parser is used to parse the application source code into an AST, and all AST nodes in the project are traversed in depth. First, nodes with all class labels are filtered out. Then, these nodes are analyzed: (1) If the “name” attribute in the tag is MySQLi or PDO, backward analysis is performed to see if the previous node is a tag with the keyword “new”. If so, this indicates that the application program directly uses both types of database extensions; (2) If the “extends” attribute in the tag is MySQLi (PDO cannot be inherited), forward analysis is performed from this tag. If there is a “new” node after the class tag, it indicates that the application program creates a new class that inherits MySQLi; (3) If MySQLi or PDO is wrapped, the object instantiated with MySQLi or PDO will be assigned to a property of the new class, such as $\$this\to conn=newmysqli\left(\right)$, as long as the label to the left of the equal sign is calling an object property, to the right is the label to instantiate MySQLi. The objects instantiated by the database extension class are the source points.

Then, we traverse the AST nodes and use regular expression matching to find all statements in the source code that call sensitive operation methods (e.g., “→query()”) as potential sink points and perform backward analysis on them. The algorithm implementation is shown in Algorithm 1. In the process of finding source points, we use a depth-first traversal algorithm and perform backward tracing for nodes that partially meet the judgment conditions at most twice, so the algorithm complexity is O(n). In the process of finding sink points, we use regular expression matching based on traversing all nodes, so the algorithm complexity is also O(n). Overall, the algorithm complexity of Algorithm 1 is O(n). The implementation algorithm is shown in Algorithm 1.

Algorithm 1: key statement identification

4.1.2. Call Relation Verification

We draw on the ideas of taint analysis in our approach to monitor the state of variables and capture changes in variable properties during transmission through data flow analysis techniques [26].

In the first PART, we used regular expression matching to match the object’s methods $“\to query”$ in the source program, and mark their positions. We regarded the object variable instantiated by the database extension class as the source point (e.g., $\$conn=newmysqli\left(\right)$). Then, we performed backward data flow analysis on each sink point, starting from the $“x\to query”$ node (since we did not know the state of $“x”$ at this time, we used $“x”$ to represent it). We monitor the change in the state of the variables during data transmission based on the taint propagation rule and stop until the source point is encountered. If the object variable instantiated by the database extension class is transmitted to $“x”$, it indicates that $“x”$ is also an object, and its state equals the state of the object instantiated by the database extension class, then $“x\to query”$ is a true sink point. The implementation algorithm is shown in Algorithm 2.

Algorithm 2: data flow analysis

4.1.3. Program Transformation

After the call relations are determined, we mark the key statements. Key statements include the statements for instantiating the database extension class (which we call source points) and calling methods in the object (which we call sink points). We will transform the object-oriented programming style of key statements into a procedural programming style. Typically, we transform the source point: “$\$conn$ = $newmysqli(“localhost”, “username”, “password”, “database”)”$ into “$\$link=mysqli\_connect(“localhost”, “username”, “password”,$$“database”)”$. Then, various operations of the sink points will also be translated into corresponding procedural statements. The select query statement: “$\$result=\$conn\to query(“SELECT\ast FROMusers”)$” will be transformed into “$result=mysqli\_query$$(\$link,$$“SELECT\ast FROMusers”)$”; the insert query statement: “$\$save=\$this\to db\to query$$(“INSERTINTOordersset\$date”)$” will be transformed into “$query=“INSERT$ $INTO$ $ordersset\$data”;\$save=mysqli\_query(\$link,\$query)$”. The remaining transformation operations are similar, and we will not go into further details here.

4.2. Vulnerability Scanner

The source code converted by the DBE-converter will be fed into the vulnerability scanner section to detect SQL injection vulnerabilities. This process consists of two main phases. The first stage is to construct the CFG; the second stage is a taint analysis based on CFG.

4.2.1. Build Control Flow Graph

In the first stage, the AST is first divided into a main AST and a custom function AST. CFG is constructed based on the main AST. When a skip node is encountered, a new basic block is created, and the data flow analysis is performed within the basic block to form a summary of the basic block. When a call node for a custom function is encountered, a new CFG is constructed based on the AST of the custom function, and a function summary is similarly formed using data flow analysis.

In terms of the specific implementation, CFGBuilder first creates a new BasicBlock and stores it as the current block. It then loops through all the root nodes of the AST and adds all non-statement nodes to the list of current block nodes. If a jump statement (JSTMT) is detected, a new CFGBuilder is started, and the new current block is linked to the previous current block. CFGBuilder stops parsing nodes when it encounters a stop node. Finally, when all statements are resolved, and all children are added to the base block, the resolution is concluded.

During the CFG construction, whenever a statement splits the control flow into new basic blocks, the analysis of a basic block is initiated. Within the base block, the data flow analysis is performed, and the summary of the base block is formed. We traverse all nodes within the base block and analyze assignments, function calls, returns, exits, and other operations.

When encountering a node calling a custom function, we create a new CFG to form the function summary. Creating this summary requires a summary of all the basic blocks in the CFG. We initiate a depth-first search for the basic block summaries. If a basic block has no outgoing edges, it either has a return statement or an exit statement, or it is the last block in the CFG. When the search reaches these stopping blocks, it concludes. After the summary of a custom function is completed, its call effect is evaluated by performing an inter-procedural data flow analysis based on its preconditions and postconditions.

By constructing the CFG, we obtain all call relations and data streams in the application. By constructing basic blocks and custom function summaries, we achieve efficient backward taint analysis.

4.2.2. Taint Analysis

In the second stage, we will perform a backward taint analysis. We trace back each parameter flow to the sink. If the parameter comes from user input, we then perform a context-sensitive data flow analysis on it to check if it has been filtered by a sanitization function. If not, a vulnerability will be reported. In our design, the sanitization function exists in the form of a blacklist. We collect all functions that can block the further spread of taint as a list of sanitization functions. When conducting taint analysis, we check the functions against this list. For example, the addslashes function is used to escape predefined characters by adding backslashes, thereby achieving the effect of quoting. If the single quotes in an SQL statement are quoted, it becomes difficult to perform SQL injection. Once a parameter enters such a function, we consider it to be sanitized and no longer as taint, and the taint analysis is interrupted. The main steps are as follows:

• Perform backward data flow analysis on the parameters of the sink point. Specifically, we traverse all the base blocks to find those whose summaries match the parameters and have not been sanitized. We collect all the information related to the parameters in the block summary and continue the backward trace through the entry links of the blocks. During the data flow analysis, we collect the results of the processing of the parameters in each base block and summarize them, including their sanitization status;
• Context-sensitive data flow analysis is performed at the source point. When a parameter arrives at a source point through the data flow analysis, we perform a context-sensitive data flow analysis on it. This is mainly to achieve two goals: to identify the vulnerability type and to check if the sanitization function has processed the parameter. Depending on the vulnerability type, a different analyzer is invoked to identify the context in the tag. Based on the context, specific vulnerability flags are identified.

5. Evaluation

In this section, we aim to answer the following research questions through the evaluation of OODBE-SCAN:

RQ1. Can OODBE-SCAN detect more SQL injection vulnerabilities in web applications with OODBE than traditional static analysis techniques (Section 5.2)?

RQ2. Are dataflow analysis techniques really effective in improving accuracy (Section 5.3)?

5.1. Setup

We selected eight open-source web applications as our evaluation dataset. We chose these eight PHP applications for three reasons: first, these applications all employ OODBE, such as PDO and mysqli, and encapsulate both types of extensions, which is more in line with our experimental goals. Second, the eight applications are all commercial ones, freely available from source code websites and widely used. Third, many of the vulnerabilities in these applications have already been submitted to CVEs, and these known vulnerabilities allow us to manually verify their exploitability, which facilitates our analysis of false positives and false negatives. The eight web applications contain a total of 50 known vulnerabilities. We try to select the most recent and latest versions of the application for evaluation so that the evaluation results are more realistic. Since newer applications are more likely to be downloaded and used by users, the value of detecting a 0-day vulnerability is higher. However, unfortunately, no 0-day vulnerabilities were found in our experiments. Eight web applications of this evaluation are summarized in

Table 1. Overview of the main characteristics of the applications.

Application	Size	Version	Release Date	Language (S)	Lines of Code	Numbers (Files)	Numbers (Vulnerabilities)	Known Vulnerabilities
Best POS Management System	40 MB	1.0	2023.02	PHP/XML	155259	2057	6	CVE-2023-3617CVE-2023-27205 CVE-2023-27204CVE-2023-27203 CVE-2023-27202CVE-2023-0946
Online Food Ordering System	37.8 MB	2.0	2023.01	PHP/XML	131173	1810	6	CVE-2023-24197CVE-2023-0332 CVE-2023-0305CVE-2023-0304 CVE-2023-0303CVE-2023-0256
Raffle Draw system	149 KB	1.0	2022.12	PHP	770	18	4	CVE-2023-24201CVE-2023-24200 CVE-2023-24199CVE-2023-24198
Pizza Ordering System	24 MB	1.0	2023.02	PHP/XML	131413	1812	8	CVE-2023-30092CVE-2023-27210 CVE-2023-27207CVE-2023-1455 CVE-2023-1365CVE-2023-1364 CVE-2023-0910CVE-2023-0883
Online Traffic Offense Management System	67.3 MB	1.0	2023.02	PHP/JS/XML	546033	1967	3	CVE-2023-2075CVE-2023-2074 CVE-2023-2073
Vehicle Service Management System	64.6 MB	1.0	2021.09	PHP/JS/XML	545768	1976	8	CVE-2023-2097CVE-2023-2096 CVE-2023-2095CVE-2023-2094 CVE-2023-2093CVE-2023-2092 CVE-2023-0913CVE-2023-37806
Eduauth	24.7 MB	1.0	2023.02	PHP/XML	139159	1248	3	CVE-2023-27214CVE-2023-27213 CVE-2023-1099
Judging Management System	4.17 MB	1.0	2022.12	PHP	48570	109	12	CVE-2023-24643CVE-2023-24642 CVE-2023-24641CVE-2023-2108 CVE-2023-1556CVE-2023-46623 CVE-2023-30018CVE-2023-30076 CVE-2023-30077CVE-2023-30203 CVE-2023-30204CVE-2023-37682

using the detailed information. This includes size, version, release date, number of lines of code, number of files included, number of known vulnerabilities, and a specific CVE number.

We compared OODBE-SCAN with the latest open-source versions of RIPS and Seay, both static analysis tools for detecting vulnerabilities in web applications. Among them, we selected the open-source version of the latest version of RIPS 0.55, and there is also a commercial version of RIPS 2.9.0, but we cannot apply the commercial version of RIPS because it is not open source. Seay currently has only one version and is open source. RIPS and OODBE-SCAN are websites, and when we set them up, we selected Apache2.4 for the server, PHP7.3 for the language, and MySQL5.7 for the database. Seay can be used directly after being installed locally. We cannot compare with other static analysis tools because they are not open source [27] or the code is incomplete [6]. All the experiments were done on a machine with Intel Core i7-9700k 3.6Ghz, 16GB RAM, and 64-bit Windows 10. For a fair comparison, we applied the same source point, sink point, and sanitization rule definitions for OODBE-SCAN, RIPS, and Seay.

In our evaluation, we will use precision (P) and R as our evaluation criteria, where P refers to the ratio of detected true positives ($TP$) to all vulnerabilities detected by the tool (including $TP$ and false positives ($FP$)):

$$P=\frac{TP}{TP+FP}$$

(1)

R is the ratio of the number of $TP$ detected to the actual number of vulnerabilities (which is the sum of $TP$ and false negatives ($FN$) that were not detected):

$$R=\frac{TP}{TP+FN}$$

(2)

5.2. Comparison with RIPS

To validate RQ1, we choose to compare OODBE-SCAN with RIPS. There are two main reasons for this choice: firstly, RIPS is an open-source static analysis tool commonly used as a benchmark in related research papers; Second, RIPS does not accurately model object-oriented properties, and our tool is an improvement over RIPS by incorporating program transformation components. Therefore, we conducted a comparison experiment between OODBE-SCAN and RIPS in order to objectively evaluate the results and provide meaningful references. These evaluations aim to determine if our technique can detect more SQL injection vulnerabilities in specific environments compared to traditional static analysis methods. To ensure a fair comparison, we made modifications to the source code of RIPS by adding the method name “query” to its sink list before conducting the comparative experiments.

The experimental results show that OODBE-SCAN detected 41 true vulnerabilities and 52 false positives, with a P of 0.44 and an R of 0.82. On the other hand, RIPS generates a large number of false positives during detection. It found a total of 237 vulnerabilities, out of which only 8 were true vulnerabilities, resulting in 217 false positives. The P was only 0.04, and the R was merely 0.16. The experimental results indicate that, compared to traditional static analysis techniques, OODBE-SCAN not only detects more SQL injection vulnerabilities in web applications with OODBE but also leads to fewer false positives. We conduct a thorough analysis to understand why RIPS generates so many false positives. By examining the false positive cases and studying the source code of the dataset, it was found that most of the false positives occurred due to misidentifying sink points. Taking one false positive as an example, when scanning the source code of the application $“BestPOSManagementSystem1.0”$, RIPS reported 33 vulnerability findings, but they were all false positives. Further investigation revealed that for the $“BestPOSManagementSystem1.0”$, most of the false positives reported by RIPS were within a single class file. In the $“admin\_class.php”$ file, there is a class called $“Action”$ that instantiates an object from the database extension library and assigns the query method of that object to a method in the class. However, this is not a sink point.

From the theoretical analysis, the vulnerability detection procedure in RIPS starts from the sink function and traces back the parameters. However, in applications using these two types of databases, sink functions often appear in an object-oriented coding style. For example, $“\$conn=newmysqli\left(\right);\$conn\to query\left(\right)”$. Since RIPS does not accurately model object-oriented properties but instead adopts regular expression matching, it only matches the $“query\left(\right)”$ method in $“\$conn\to query\left(\right)”$, without considering the calling object $“conn”$. This strategy results in a diffusion of contamination and leads to a large number of false positives.

In contrast, OODBE-SCAN comprehensively models OODBE and performs program transformations. Specifically, it first identifies all relevant statements using regular expression matching, then uses data flow analysis to determine method call relationships, and finally converts the identified statements from an object-oriented programming style to a procedural programming style. This sequence of operations automatically transforms OODBE into semantically equivalent procedural database extensions. This is the core reason for the ability of OODBE-SCAN to detect vulnerabilities and its improvement over traditional static analysis techniques.

Based on the experimental results (which are listed in

Table 2. Evaluation results of vulnerability detection.

	OODBE-SCAN				RIPS				Seay
application	TP	FP	P	R	TP	FP	P	R	TP	FP	P	R
Best POS Management System	5	7	0.42	0.83	0	33	0	0	1	23	0.04	0.17
Online Food Ordering System	5	8	0.38	0.83	1	26	0.04	0.17	2	20	0.09	0.33
Raffle Draw system	4	2	0.67	1	0	0	0	0	3	1	0.75	0.75
Pizza Ordering System	7	9	0.44	0.88	2	26	0.07	0.25	2	21	0.09	0.25
Traffic offense	2	3	0.4	0.67	1	58	0.02	0.33	2	14	0.13	0.67
Vehicle service	7	12	0.37	0.88	4	74	0.05	0.5	5	17	0.23	0.63
Eduauth	3	2	0.6	0.67	0	0	0	0	1	0	1	0.33
Judging Management System	8	9	0.47	0.67	0	0	0	0	8	20	0.29	0.67
TOTAL	41	52	0.44	0.82	8	217	0.04	0.16	24	116	0.17	0.48

) and our analysis work, the answer to RQ1 is obvious. Compared with traditional static analysis techniques, OODBE-SCAN can indeed detect more SQL injection vulnerabilities in web applications utilizing OODBE.

5.3. Comparison with Seay

To validate the RQ2, we chose to compare OODBE-SCAN with Seay. There are two main reasons for this choice: firstly, Seay is a mature and open-source static analysis tool that is suitable for comparison. It has been frequently used as a benchmark in previous research works; secondly, Seay models object-oriented properties, similar to our work, but the difference lies in the application of data flow analysis.

From the experimental results, Seay detected more true vulnerabilities than RIPS but also produced a large number of false positives. It found a total of 150 vulnerabilities, out of which only 24 were true vulnerabilities, resulting in 116 false positives. The P was only 0.17, and the R was 0.48. Moreover, we observe that most of the types of false positives reported by Seay are similar to those in the RIPS experiment. Taking the example of the $“BestPOSManagementSystem1.0”$ application, Seay reported a significant number of false positives originating from the $“Action”$ class in the $“admin\_class.php”$ file. After the analysis, we found that while Seay supports object-oriented properties, it does not perform data flow analysis specifically for object-oriented types. The $“admin\_class.php”$ file primarily serves the purpose of implementing various functionalities by defining a class for convenient instantiation in other files, and therefore, it is not a sink point.

From a theoretical point of view, Seay is prone to contamination diffusion during static analysis. This is because Seay does not perform precise data flow analysis but instead relies on regular expression matching. For example, in $“\$conn\to query\left(\right)”$, it only matches the $“query\left(\right)”$ method without considering the calling object $“conn”$. This strategy leads to contamination diffusion and results in a large number of false positives. Only through accurate data flow analysis and call relationship analysis can such functions be excluded. Additionally, Seay seems to have inadequate modeling of sanitization functions. In the $“Master”$ file of the $“traffic\_offense1.0”$ application, during the propagation process, the $“\$v”$ variable is sanitized by the $“addslashes”$ function before entering the sink point.

Based on the experimental results(which is listed in Table 2) and our analysis work, the answer to RQ2 is also certain. Compared with Seay, OODBE-SCAN reports significantly fewer false positives. The application of data flow analysis technology enables OODBE-SCAN to accurately locate the called objects of methods, avoiding the spread of contamination and improving the accuracy of vulnerability detection.

In addition to presenting the experimental data of the two experiments in Table 2, we used Figure 3 and Figure 4 to display the comparison of the TP and FP discovered by three tools in the same dataset, respectively, to make the results more clear.

OODBE-SCAN reported a total of 52 false positives, and the main reason for these false positives is that our tool is based on the implementation of RIPS, which has inherent design flaws. The improvements we made mainly focused on the program transformation part, and we did not make significant changes to the vulnerability scanning logic of RIPS. In summary, there are three main reasons for the false positives:

• Path-insensitive data flow analysis;
• Sanitization through database whitelist
• Wrong content-type

For example, in the application $“BestPOSManagementSystem”$, there is the following code segment:

The user-defined function sanitizes the first argument based on the value of the second argument. Due to RIPS’s path-insensitive data flow analysis and function summary-based approach, it mistakenly incorporates two possible return values into the function summary, resulting in always returning the same result regardless of the value of the second parameter.

6. Discussion

OODBE-SCAN is a static analysis tool that automatically transforms OODBE into semantically equivalent procedural database extensions. It scans the transformed programs to detect SQL injection vulnerabilities. Compared to other static analysis tools, OODBE-SCAN not only detects more vulnerabilities but also achieves higher accuracy.

6.1. Cost-Effectiveness and Scalability

Our strategy ensures that our technique is highly cost-effectiveness. When performing program transformation, we prioritize the identification of source points and sink points, which are directly related to vulnerabilities. Our algorithm primarily involves deep traversal and regular matching, resulting in a complexity of O(n). Through program transformation technology, our tool can discover a large number of SQL injection vulnerabilities that RIPS and Seay cannot find. Within the same time, OODBE-SCAN discovered 41 real vulnerabilities, while RIPS only discovered 8 and Seay only discovered 24. Our technique exhibits high scalability. Firstly, we incorporated program transformation techniques into RIPS, which have a low algorithmic complexity of O(n). The overhead is minimal. Additionally, RIPS itself is applicable to large-scale real-world programs, which means our approach is also suitable for such programs. Secondly, our technology focuses on database extensions, so any scale of real-world application, as long as it applies object-oriented database extensions, we can process it.

6.2. Limitation

1. To some extent, program transformation technique serve as auxiliary method for vulnerability detection. The effectiveness of our technique in detecting SQL injection vulnerabilities heavily relies on the SQL injection detection capabilities of existing static analysis techniques. Because the fundamental purpose of proposing program transformation technique is to automatically transform object-oriented database extensions into semantically equivalent procedural database extensions. This transformation helps existing static analysis techniques accurately detect SQL injection vulnerabilities in applications that utilize object-oriented databases.

2. Our program transformation technique currently relies heavily on the knowledge of researchers. If complex semantic code is encountered, the automatic transformation may not access ideal results, which can affect the final vulnerability detection.

6.3. Future Work

1. Although OODBE-SCAN has performed well in evaluations, we have identified potential improvements. Currently, our program transformation technique relies heavily on the knowledge of the researcher. In terms of understanding code semantics, the large language models(LLMs) have shown impressive performance. Some aspects of our work are entirely dependent on LLMs and they have even helped optimize our work. If we encounter complex semantics, leveraging LLMs for understanding may access better results.

2. Our technique not only enables vulnerability discovery but also has the potential to be combined with other security techniques to enhance the vulnerability detection process. For example, it can be integrated with fuzzing.

6.4. Related Work

In recent years, extensive research has been conducted by scholars worldwide on detecting SQL injection vulnerabilities [3,4,5,15,27,28,29,30,31,32,33,34,35,36,37,38,39,40]. This research primarily focuses on two approaches: vulnerability mining techniques based on static analysis and vulnerability mining techniques based on dynamic analysis. Static analysis-based vulnerability mining techniques involve analyzing the code without running the web application. On the other hand, dynamic analysis-based vulnerability mining techniques require constructing an appropriate code execution environment for the web application and conducting analysis under the prerequisite of successful execution. In the following discussion, we will explore the relevant works and their notable limitations.

Static analysis methods refer to the analysis of web application code without executing it, primarily leveraging code syntax and semantic features such as AST, CFG, and call flow graphs to match vulnerability patterns and discover vulnerabilities.

PhpSAFE [5] is specifically designed to analyze security vulnerabilities in plugins developed for PHP-based content management systems (CMS) and can detect SQL injection vulnerabilities in these plugins. However, PhpSAFE is highly customized for detecting vulnerabilities specific to CMS plugins, which may limit its utility for analyzing other types of PHP projects.

PIXY [4] is an open-source tool specifically designed for statically detecting tainted vulnerabilities in PHP programs, thus having the capability to detect SQL injection vulnerabilities. However, it has limited capabilities as it only supports PHP 4 and earlier versions and cannot analyze object-oriented programming features introduced in subsequent language versions. This means that PIXY produces a significant number of false negatives, rendering its analysis results unreliable.

RIPS [3] is a static analysis tool specifically designed for detecting security vulnerabilities in PHP code. It can analyze all types of vulnerabilities in PHP code, including SQL injection vulnerabilities. RIPS uses the PHP Zend engine syntax parser to obtain token flow information from the source code, based on which it generates corresponding AST and CFG. However, RIPS does not support the analysis of object-oriented programming PHP code; therefore, it cannot detect SQL injection vulnerabilities in applications that utilize object-oriented database extensions.

Seay [15] can detect common web application vulnerabilities, including SQL injection vulnerabilities, and generate detailed reports to help users identify and fix these security issues. Moreover, Seay supports customizable rules and plugins, allowing for flexible configuration and extension based on user requirements. It also provides command-line and web interfaces, supporting interactive operations and scanning. However, Seay performs poorly in supporting object-oriented features and often generates a significant number of false positives during vulnerability detection.

Dynamic analysis techniques require the actual execution of the program. After setting up the program’s runtime environment, debugging, fuzz testing, and simulating attacks are performed with the premise of successful program execution. Relevant vulnerabilities are then discovered based on the output results.

Huang et al. [35] proposed a black-box fuzz testing method for automatically testing SQL injection vulnerabilities in real-world scenarios of web applications. They integrated and simulated web browser functionality within their crawler to enable testing of web applications in real-world scenarios. The crawler utilizes a “comprehensive crawling” mechanism to reverse-engineer web applications and identify all data input points. Self-learning is employed to inject knowledge into the knowledge base, and fault injection techniques are used to detect SQL injection vulnerabilities. However, black-box fuzz testing relies on manually managed lists of inputs that trigger vulnerabilities, which significantly reduces the ability of black-box scanners to explore the input space of web applications and may result in false negatives.

Addressing this issue, inspired by gray-box coverage-guided fuzz testing, Trickel et al. [36] proposed a gray-box fuzz testing technique for web applications. It instruments the source code of web applications using instrumentation techniques to collect code coverage information of test cases, which then guides the generation of test cases, thereby increasing the exploration of the web application’s state space.

O. van Rooij et al. [37] also designed and implemented a coverage-based gray-box fuzz testing tool for web applications. They placed code in each basic block of the source code to obtain the current execution location during the fuzz testing process. They also created a code analysis tool for JavaScript to analyze whether an alert function call is generated during each fuzz testing process and determine if an XSS vulnerability is successfully triggered based on this condition. Although this technique currently only supports XSS vulnerability detection, their next step is to include SQL injection vulnerability detection.

In addition to the above, in dynamic analysis techniques, test case generation is a critical issue, and improving the quality of test cases has been a focus of research. Wang et al. [38] proposed an improvement for the problem of test case scarcity by first constructing a test case generation model using augmented attack trees and then using the model to generate test cases in batches. Although this method effectively solves the problem of test case scarcity, the accuracy of these test cases cannot be guaranteed.

Tian et al. [39] proposed an improved approach to enhance the accuracy of test cases. Building on Wang’s method [38], they introduced a model-driven test case generation approach that constructs different models based on different runtime environments. This approach achieves the effect of batch test case generation while maintaining a certain level of accuracy. However, the limitation of this approach is evident as the models are customized based on specific runtime environments and cannot be easily extended.

Chen et al. [40], aiming to address the problem of low detection efficiency due to significant biases in test case generation, divided SQL injection vulnerabilities into different levels. Dynamic analysis techniques can analyze program properties, precisely locate vulnerable code, and have a low false positive rate. However, dynamic analysis cannot inspect the entire source code like static analysis does. Reliance on a single execution path can lead to incomplete path coverage and potential false negatives.

Our work is based on static analysis. Although static analysis techniques have matured in detecting SQL injection vulnerabilities, they currently cannot accurately detect SQL injection vulnerabilities in applications that utilize OODBE due to the lack of precise modeling for such extensions. Our work addresses this issue by leveraging program transformation techniques, effectively enhancing the capability of static analysis techniques in detecting SQL injection vulnerabilities.

7. Conclusions

SQL injection vulnerability detection is essential for web security. The current technique does not accurately detect SQL injection vulnerabilities in applications that apply for object-oriented database extensions. In this paper, we propose a SQL injection vulnerability detection technique based on program transformations. The technique consists of two phases: program transformation and vulnerability detection. In the first stage, object-oriented database extensions are automatically transformed into semantically equivalent program-oriented database extensions. In the second stage, the transformed program is automatically scanned to detect SQL injection vulnerabilities. Based on the above-mentioned techniques, we implemented the OODBE-SCAN prototype system and performed experimental analysis on eight modern PHP applications with this system. Our experimental results show that OODBE-SCAN not only detects more vulnerabilities but also achieves higher accuracy than other static analysis methods.