# A Static Detection Method for SQL Injection Vulnerability Based on Program Transformation
## 4 Design
### DBE-Converter
#### 4.1.1 Key Statement Identification
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

\begin{table}
\begin{tabular}{c c c c c c c c c} \hline \hline
**Application** & **Size** & **Version** & **Release** & **Language** & **Lines of** & **Numbers** & **Numbers** & **Numbers** \\  & & **Date** & **(S)** & **Code** & **(Files)** & **(Vulnerabilities)** & & **Known Vulnerabilities** \\ \hline Best POS & 40 MB & 1.0 & 2023.02 & PHP/XML & 155259 & 2057 & 6 & CVE-2023-3617 & CVE-2023-327205 \\ Management System & & & & & & & CVE-2023-27204 & CVE-2023-37203 \\ Online Food Ordering & & & & & & & CVE-202



of the application \"_Best POS Management System_ 1.0\", RIPS reported 33 vulnerability findings, but they were all false positives. Further investigation revealed that for the \"_Best POS Management System_ 1.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=new\;\;mysqli();\$conn\to query()\)\". Since RIPS does not accurately model object-oriented properties but instead adopts regular expression matching, it only matches the \"\(query()\)\" method in \"\(\$conn->query()\)\", 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) 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. ### 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 \"_Best POS Management System_ 1.0\" application, Seay reported a significant number of false positives originating from the \"_Action_\" class in the \"_admin_class.php_\" file.