TPSQLi: Test Prioritization for SQL Injection Vulnerability Detection in Web Applications

Abstract

The rapid proliferation of network applications has led to a significant increase in network attacks. According to the OWASP Top 10 Projects report released in 2021, injection attacks rank among the top three vulnerabilities in software projects. This growing threat landscape has increased the complexity and workload of software testing, necessitating advanced tools to support agile development cycles. This paper introduces a novel test prioritization method for SQL injection vulnerabilities to enhance testing efficiency. By leveraging previous test outcomes, our method adjusts defense strength vectors for subsequent tests, optimizing the testing workflow and tailoring defense mechanisms to specific software needs. This approach aims to improve the effectiveness and efficiency of vulnerability detection and mitigation through a flexible framework that incorporates dynamic adjustments and considers the temporal aspects of vulnerability exposure.

1. Introduction

This section provides an overview of the paper’s background, motivation, contributions, and organization.

1.1. Background

Over the past two decades, the integration of network technology into daily life has significantly increased, marking a notable trend [1]. With the growing dependence on the web, web applications have become indispensable for modern data management and processing. This evolution allows developers to efficiently design, maintain, and secure applications by modifying existing code rather than building entire programs from scratch. This streamlined approach not only enhances the protection of valuable business assets, but also transforms the Internet into a vast repository of information. Despite these advancements, web applications remain susceptible to numerous security threats, including Structured Query Language (SQL) injection, cross-site scripting (XSS), and cross-site request forgery (CSRF) [2,3].

Exploiting these vulnerabilities enables attackers to compromise user information and damage organizational reputations by breaching security policies. The primary objective of cybersecurity is to protect networks and resources from unauthorized access, ensuring the principles of integrity, availability, and confidentiality are upheld.

Recent reports, such as the OWASP Top 10 project published in 2021 [4], indicate that injection attacks rank among the top three common vulnerabilities in software projects. SQL injection attacks, in particular, exploit inadequate input validation and poor website management, allowing attackers to inject malicious SQL statements into queries generated by web applications. This can lead to unauthorized access to backend databases and exposure to sensitive information, such as usernames, passwords, email addresses, phone numbers, and credit card details. Additionally, attackers can alter database schemas and content, exacerbating the potential damage.

Various types of SQL injection attacks have been identified [5], and numerous methods for detecting and preventing them have been proposed. However, existing solutions often have limitations and may not fully address the evolving nature of these attacks. As new attack vectors emerge, it is crucial to identify and understand current technologies to develop more effective countermeasures.

1.2. Motivation

Software testing is a crucial and costly industry activity, often accounting for over 50% of the total software development cost [6]. To address this challenge in testing SQL injection for agile software development, we propose a software testing tool for automatic testing, activated upon the tester’s submission of the software version and relevant information. This tool customizes defense functions tailored to the specific software under test, enhancing the testing process’s efficiency. Following the completion of testing, the tool adjusts the defense strength vector to optimize subsequent tests.

Upon receiving the version information, the tool tests the failed cases in the previous round and further designs a choice based on common tester practices. Prioritizing previously failed test cases allows testers to obtain real-time information about iterative versions promptly. After testing, adjustments to the test process are made to facilitate future tests, thus improving overall testing efficiency.

To demonstrate the impact of test prioritization on time and cost, we conducted a pre-test to measure the time differences using various prioritization methods to identify the first SQL injection vulnerabilities. For instance, in target1 (powerhr), the time difference between the TEUQSB and BUSQET prioritization orders was up to 64 s, as shown in Figure 1. Similar differences were observed for target2 (dcstcs) and target3 (healthy), with time differences exceeding 15 s, as illustrated in Figure 1. This substantial variance underscores the importance of optimizing test prioritization strategies. Each letter in the sequences BUSQET represents a different type of SQL injection, detailed in

Table 1. Abbreviation and complete name mapping.

Complete Name	Abbreviation
Boolean-based blind SQL injection	B
Union-based SQL injection	U
Stack-based SQL injection	S
Inline Queries SQL injection	Q
Error-based SQL injection	E
Time-based blind SQL injection	T

, with further explanations provided in Section 2.2 SQL Injection.

Additionally, we evaluated the relevant information available in some open-source tools. We found that in ZAP [7], this problem was listed in the TODO section, clearly indicating in the ZAP documentation that this area requires expansion, as shown in Figure 2. Conversely, SQLMAP [8] uses a fixed BEUSTQ order for testing, indicating that SQLMAP does not significantly incorporate test prioritization, as shown in Figure 3. This evidence highlights the need for tools to adopt more dynamic and optimized test prioritization strategies to enhance testing efficiency and effectiveness.

1.3. Contribution

In this subsection, we outline the critical contributions of our work:

• We proposed a new algorithm to prioritize SQL Injection vulnerability test cases. This algorithm is part of a comprehensive framework (TPSQLi) that includes the design of weight functions, dynamic adjustments, and evaluation methods to ensure efficient and effective prioritization.
• We enhanced the testing process in SQLMAP by prioritizing test cases that failed in previous rounds, thereby improving the efficiency and effectiveness of the testing cycle.
• Our framework (TPSQLi) is designed to adapt to immediate feedback and evolving security threats, ensuring continuous adjustments to testing priorities. This adaptability significantly enhances the efficiency of security testing, particularly for regression testing, ensuring that testing remains relevant and effective in addressing the ever-changing landscape of web application security.
• Our framework (TPSQLi) performs better than ART4SQLi [9], the current state-of-the-art (SOTA) test prioritization framework, by designing more efficient and adaptable prioritization mechanisms.

1.4. Organization

The rest of this paper is organized as follows: Section 2 introduces the preliminary knowledge essential for our study, providing the foundational background. Section 3 offers a comprehensive review of related research, establishing the context and significance of our research. Section 4 presents the TPSQLi penetration testing framework and the test prioritization algorithm unit, detailing the conceptual design and implementation processes with insights into practical applications. Section 5 discusses the evaluation results, presenting a comparative analysis with the state-of-the-art ART4SQLi [9] across 10 test cases. Finally, Section 6 concludes the paper by summarizing the main findings and their implications.

2. Preliminaries

This section will introduce the fundamental concepts of software testing, test prioritization, and SQL injection, which are essential to understanding our proposed methodology.

2.1. Software Testing

Software testing encompasses any activity aimed at evaluating an attribute or capability of a program or system to determine whether it meets its requirements. Despite its critical role in ensuring software quality and its widespread use by programmers and testers, software testing remains largely an art due to the limited understanding of fundamental software principles. The inherent complexity of software makes comprehensive testing of even moderately complex programs infeasible. Testing extends beyond debugging; it serves various purposes, including quality assurance, verification and validation, and reliability assessment. Additionally, testing can function as a generic metric. Correctness testing and reliability testing represent two primary focus areas within software testing. Ultimately, software testing involves a trade-off between budget, time, and quality, necessitating carefully balancing these factors to achieve optimal results [10,11,12].

2.2. Test Prioritization

In order to reduce software testing costs, testers can prioritize test cases to ensure that the most critical ones are executed early in the testing process. This prioritization becomes particularly important during the maintenance and evolution phases, which are the stages where updates and changes are made to the software, of the software development life cycle, where regression testing is essential to confirm that recent changes have not adversely affected previous software versions, and that the new version remains backward compatible. Testing typically accounts for nearly half the total software development cost, making it a time-intensive and costly endeavor [10].

As sources [13,14,15] indicated, the regression testing process can be optimized through three primary methods: Test Case Selection, Test Suite Minimization, and Test Case Prioritization.

• Test Case Selection: This method selects test cases based on specific criteria, focusing only on the updated areas of the software.
• Test Suite Minimization: This approach reduces the overall test suite by eliminating redundant or obsolete test cases, optimizing testing resources, and minimizing the testing effort required.
• Test Case Prioritization: This technique involves ordering test cases based on specific attributes, ensuring that higher-priority test cases, which are those that cover critical functionalities or have a high likelihood of failure, are executed first [12,14,16,17].

Unlike Test Case Selection and Test Suite Minimization, which alter the original test suite by removing cases, Test Case Prioritization only reorders the test cases without eliminating any. This distinction is crucial because some test cases, though unnecessary for specific releases, may be valuable in future versions. As a result, prioritizing test cases instead of permanently removing them is often a safer strategy, providing a sense of security in the testing process. Therefore, Test Case Prioritization is considered a secure, reliable, and cost-effective approach to regression testing [18].

2.3. SQL Injection

SQL Injection is a prevalent network attack method [4,19]. It involves embedding malicious instructions within input strings to manipulate SQL syntax logic, aiming to unlawfully disrupt and infiltrate database servers. Such attacks can lead to the theft of confidential user information, account details, and passwords. We collected common SQL injection attack types from [19,20,21,22,23,24], detailed below:

• Boolean-based Blind SQL Injection: This method is one of the most common and dangerous types of SQL injection. It injects conditional SQL statements that force the SQL command to constantly evaluate as true, such as (‘1’ = ‘1’). This technique is primarily used to bypass authentication processes, allowing unauthorized access to the database.
• Union-based SQL Injection: In a union query attack, the attacker inserts an additional statement into the original SQL string. This injection is achieved by appending a UNION query string or a similar statement to a web form input. The result is that the database returns a dataset that combines the original query and the injected query results, thereby exposing additional data.
• Time-based Blind SQL Injection: This technique sends SQL queries that force the database to pause for a specified duration before responding. An attacker can infer information about the database by observing these delays, exploiting timing delays to gather data without direct feedback.
• Error-based SQL Injection: This attack depends on the error messages generated by the database server. These messages often reveal information about the database’s structure, which can be used to craft further attacks.
• Stack-based SQL Injection: This involves injecting multiple SQL statements in a single query, separated by a delimiter such as a semicolon. The database executes these statements sequentially, allowing attackers to perform several actions with one injection.
• Inline Queries SQL Injection: Inline queries involve embedding malicious sub-queries within the main SQL query. These sub-queries can manipulate the database operation, often leading to unauthorized data access or manipulation.

3. Related Work

SQL injection (SQLi) remains a significant threat to the security of web applications, prompting the development of various detection and testing methodologies [21]. In 2019, Zhang et al. proposed ART4SQLi, an adaptive random testing method based on SQLMAP that prioritizes test cases to efficiently identify SQLi vulnerabilities, reducing the number of attempts needed by over 26% [9]. Unlike static order test prioritization, which calculates the distance between payloads, our tool employs a dynamic adjustment mechanism, enhancing detection efficiency.

Furthermore, most research needs to address the test prioritization of SQL injection. Al Wahaibi et al. introduced SQIRL in 2023, which utilizes deep reinforcement learning with grey-box feedback to intelligently fuzz input fields, generating diverse payloads, discovering more vulnerabilities with fewer attempts, and achieving zero false positives [22]. However, this method does not include test prioritization. Similarly, Erdődi et al. (2021) simulated SQLi attacks using Q-learning agents within a reinforcement learning framework, modeling SQLi as a security capture-the-flag challenge, enabling agents to learn generalizable attack strategies [25]. In the same year, Kasim developed an ensemble classification-based method that detects and classifies SQLi attacks as simple, unified, or lateral, utilizing features from the OWASP dataset to achieve high detection and classification accuracy [26]. Additionally, in 2023, Ravindran et al. created a Chrome extension to detect and prevent SQLi and XSS attacks by analyzing incoming data for suspicious patterns, thus enhancing web application security [2]. In 2024, Arasteh et al. presented a machine learning-based detection method using binary Gray-Wolf optimization for feature selection, which enhances detection efficiency by focusing on the most compelling features, achieving high accuracy and precision [23].

In test prioritization, Chen et al. investigated various techniques to optimize regression testing time in 2018. Based on test distribution analysis, their predictive test prioritization (PTP) method accurately predicts the optimal prioritization technique, significantly improving fault detection and reducing testing costs [27]. Haghighatkhah et al. studied the combination of diversity-based and history-based test prioritization (DBTP and HBTP) in continuous integration environments, finding that leveraging previous failure knowledge (HBTP) is highly effective. At the same time, DBTP is beneficial during early stages or when combined with HBTP [28]. Alptekin et al. introduced a method to prioritize security test executions based on web page similarities, hypothesizing that similar pages have similar vulnerabilities. This approach achieved high accuracy in predicting vulnerabilities, speeding up vulnerability assessments, and improving testing efficiency [29]. In 2023, Medeiros et al. proposed a clustering-based approach to categorize and prioritize code units based on security trustworthiness models. This method helps developers improve code security early in development by identifying code units prone to vulnerabilities, reducing potential vulnerabilities and associated costs [30].

These studies collectively advance the fields of SQL injection detection and test prioritization, providing robust methodologies to enhance web application security and optimize testing processes. However, to our knowledge, only ART4SQLi uses test prioritization to boost SQL injection testing.

4. Methodology and Implementation

The purpose of this section is to outline the methodology and steps undertaken in our research on testing prioritization for SQL injection vulnerabilities. The first section provides a succinct introduction to our penetration testing process and the associated framework. Subsequently, we detail the test prioritization algorithm in the following sections. Finally, the subsection introduces the profiling defense update function, elucidating its role in enhancing security measures.

4.1. TPSQLi Framework of Penetration Testing

Before initiating the detection module, various submodules targeting specific vulnerabilities are loaded. Figure 4 shows the workflow of our model.

In this penetration framework, the initial step involves the user entering the URL to be tested. Subsequently, a web crawler is employed to identify additional test targets, with the crawling depth determined by user-defined settings. The next phase involves launching the SQL Injection Attack Detection Model, which encompasses four main components: the Parameter Testing Panel, Test Prioritization Panel, Exploit Panel, and Report Panel. In the Parameter Testing Panel, parameters can be transmitted using the GET or POST method. For GET requests, parameters are extracted directly from the web pages. HTML code is analyzed for POST requests to locate “form” tags. The subsequent Test Prioritization Panel calculates an appropriate testing sequence for the Exploit Panel, utilizing a test prioritization algorithm detailed in the following chapter. Once the parameters are extracted, they are tested based on the prioritization determined in the previous panel. The test results are then fed into the test prioritization algorithm unit to refine future testing sequences. Finally, the Report Panel displays the results of the detection process, provides relevant information, and offers recommended solutions.

4.2. Parameter Testing Panel

The Parameter Testing Panel involves extracting parameters for analysis using GET and POST, as referenced in [31]. The GET method extracts parameters following the “?” in the URL, while the POST method identifies parameters within form input tags for testing. This differentiation allows for a comprehensive analysis of all possible entry points for SQL injection vulnerabilities.

4.3. Test Prioritization Panel

Upon acquiring the test parameters, the Test Prioritization Panel employs a prioritization algorithm to determine the sequence of tests. The unit of the Test Prioritization Algorithm is shown in Figure 5. The calculated prioritization dictates the order in which tests are conducted. During the injection phase, the system dynamically adjusts the test prioritization using the profiling defense update function. Post-injection, feedback in feedback.json file is utilized to update the weight scores, ensuring the algorithm adapts to the testing environment. This iterative process refines the prioritization for subsequent tests, continuously optimizing the testing strategy.

4.4. Test Prioritization Algorithm

This subsection presents the test prioritization algorithm for SQL injection vulnerability detection in web applications.

4.4.1. Pseudocode

Algorithm 1 outlines the test prioritization algorithm for SQL injection vulnerability detection in web applications. The algorithm takes as input an $n$-dimensional Strength–Weakness (SW) vector, where $n$ represents different techniques, and a payload for each technique.

The process of our algorithm is detailed below:

• Initialization (Set Initial Variables):
  • Strength–Weakness Vector (‘SW_Vector’): Initialize a fundamental score for each technique using a function discussed in the subsequent subsection. This vector quantifies each SQL injection technique’s relative strengths or weaknesses based on historical data or predefined metrics.
  • Exploit Time (‘exploit_time’): Initialize this variable to record the fastest exploit time for each technique. For instance, if technique A exploits a vulnerability in 2 s, while technique A takes 5 s, this would influence the prioritization of these techniques.
  • Is Exploit (‘is_exploit’): Initialize this boolean variable to record the success status of each technique. If a technique fails, it will be marked as False, affecting its priority in future tests.
• Execution Loop:
  • Payload Selection: For each payload that failed in the previous round (higher risk payloads), determine whether it can be successfully exploited. If not, reduce its risk and select the payload with the highest fundamental score for testing.
  • Execution: Start the execution loop by recording the start time to establish a baseline duration. Execute the selected payload, performing the specific task assigned by the system. After the payload execution, record the end time to calculate the total execution time, which is critical for performance analysis and optimization.
  • Outcome Evaluation: Determine whether the exploit was successful. There are two possible outcomes:
    • Failure Case:
    • If ‘is_exploit’ for the technique is False, add the execution time and subtract one point from the fundamental score.
    • If ‘is_exploit’ is True, only subtract one point from the fundamental score without adding the execution time.
    • Success Case:
    • Set the payload’s risk to high.
    • If ‘is_exploit’ for the technique is False, add the execution time and set ‘is_exploit’ to True.
• Iteration and Update:
  • Iterate: Continue testing the next payload until all payloads have been executed.
  • Update: After executing all payloads, update the SW-vector based on the recorded exploit time and the ‘is_exploit’ status.

Our proposed algorithm ensures that the payloads with higher risks are prioritized and the execution times are minimized by continuously updating and adapting the strength–weakness vector based on the performance of each technique. For an example of the algorithm in action, please refer to Section 4.4.4.

Algorithm 1. Test Prioritization Algorithm
Input:
Strength–Weakness Vector SW_vector[0, …, n − 1],
Payloads payloads = {0 : […], 1 : […], …, n − 1 : […]}
Output:
Updated Strength–Weakness Vector SW_vector[0, …, n − 1]
1.	Initialize Basic Scores BS[0, …, n − 1] based on SW_vector
2.	Initialize exploit_time[0, …, n − 1] to zero
3.	Initialize is_exploit[0, …, n − 1] to False
4.	while there exists an unused payload with risk level 3 do
5.	Select payload p with the maximum BS[t] where risk(p) = 3 and t ∈ [0, …, n − 1]
6.	if p fails to exploit then
7.	Set risk(p) ← 1
8.	end if
9.	end while
10.	while there are unused payloads remaining do
11.	Select payload p with the maximum BS[t] where t ∈ [0, …, n − 1]
12.	Record current time as start_time
13.	Execute payload p
14.	Record current time as end_time
15.	if p fails to exploit then
16.	if is_exploit[t] = False then
17.	exploit_time[t] ← exploit_time[t] + (end_time − start_time)
18.	BS[t] ← BS[t] − 1
19.	else
20.	Set risk(p) ← 3
21.	if is_exploit[t] = False then
22.	exploit_time[t] ← exploit_time[t] + (end_time − start_time)
23.	Set is_exploit[t] ← True
24.	end if
25.	end if
26.	end if
27.	end while
28.	Update SW_vector based on exploit_time[0, …, n − 1] and is_exploit[0, …, n − 1]
Return Strength–Weakness Vector SW_vector[0, …, n − 1]

4.4.2. Mathematical Formulation of Test Prioritization Algorithm

In this subsection, we introduce the algorithm for test prioritization of various SQL injection vulnerability detection techniques. We define two sets: one representing all current detection techniques and the other representing the set of test targets. As technology evolves, new techniques may emerge. We assume there are currently $n$ detection techniques and $m$ test targets for this discussion.

For each test target, we conduct $n$ attacks and record the duration of these attacks, resulting in $n\times m$ different results, which are then used to calculate the weight scores. We establish three rules to construct this test prioritization model:

• Rule 1: If a technique fails to exploit a vulnerability successfully, it receives zero points in the weight score calculation.
• Rule 2: The total score for the same test target is n, with faster exploits earning higher scores.
• Rule 3: The score calculation considers the difference in exploit time using the reciprocal ratio of these times.

Moreover, we use the following mathematical formulas to express the model:

• Techniques: n.
• Successful exploits: $a$.
• Failed exploits: $n-a$.
• Success exploit time: $S_1,S_2, \dots , S_a$.
• Fail exploit time: $F_1,F_2, \dots , F_a$.
• Weights (Both $W_{F_i}, W_{S_i}, W_i$ set to zero in the initial process):

$$W_{F_i}=0, \forall i=1,2,\dots ,n-a$$

(1)

$$W_{S_i}={\displaystyle \frac{1}{S_i}}·n· {\displaystyle \frac{1}{{\sum }_{k=1}^a\frac{1}{S_k}}},\forall i=1,2,\dots ,a$$

(2)

$$W_i=\mathrm{m}\mathrm{a}\mathrm{x}(W_{S_i}, W_{F_i}), \forall i=1,2,\dots ,a$$

(3)

For a deeper understanding of our algorithm, please refer to Section 4.4.4 for a simple example.

4.4.3. Profiling Defense-Update Function

In addition to adjusting the order of the basic technique through the previously mentioned algorithm, we have incorporated an update mechanism within the dynamic segment. This mechanism aims to facilitate the dynamic adjustment of test prioritization. Specifically, after each technique is employed with an injected payload, if no vulnerabilities are detected, the priority of this technique will be progressively reduced in subsequent tests. Concurrently, we also prioritize the implementation of high-weighted techniques.

The precise methodology involves leveraging the fundamental score calculated by the preceding algorithm. When a test is conducted, and no weaknesses are identified, the technique score is decremented. This decrement continues until the score falls below that of other techniques or until the technique is deemed ineffective. This adaptive scoring and prioritization process ensures that the focus gradually shifts towards techniques more likely to uncover vulnerabilities, thereby optimizing the efficiency and effectiveness of the testing procedure.

4.4.4. Simple Example for Test Prioritization Algorithm

To better understand our algorithm, consider a simplified scenario involving three SQL injection techniques: Technique A1, Technique A2, and Technique A3. If, in the first round, Technique A1 has an exploit time of 2 s, Technique A2 fails, and Technique A3 has an exploit time of 4 s, the weight calculations would be as follows:

• Technique A1: $W_i=2$
• Technique A2: $W_i=0$
• Technique A3: $W_i=1$

Given these weights, Technique A1 has the highest priority. Therefore, our method will adjust the profiling defense-update function to prioritize testing Technique A1 first, followed by Technique A3, and finally Technique A2.

4.5. Exploit Panel

As shown in Figure 6, the Exploit Panel initiates by calculating a fundamental score using a strength–weakness vector. Two variables are initialized: ‘exploit_time’ to record the fastest exploit time for each technique and ‘is_exploit’ to track the success of each technique. The panel first re-tests previously failed payloads, adjusting their risk levels dynamically based on success or failure. Successful exploits prompt the setting of the payload’s risk to high and update the technique’s status.

For failed payloads, the system subtracts points from their fundamental score and re-tests the next payload. If a payload is successfully exploited, its execution time is recorded, and the strength–weakness vector is updated accordingly. This process continues until all payloads are tested, ensuring comprehensive coverage of potential vulnerabilities.

4.6. Report Panel

Upon completing all tests, the system generates a comprehensive report, concluding the penetration testing process. The described implementation ensures a systematic and thorough approach to detecting SQL injection vulnerabilities in web applications.

5. Evaluation

The experimental setup included a Windows 10 machine from ASUS, model P2520LA, which was produced in China. The machine equipped with 12 GB of RAM and an Intel(R) Core(TM) i5-5200U CPU, operating at 2.2 GHz with four cores. The penetration testing framework, as outlined in Section 4, was implemented using Python 3.9.7. Our study focused on two specific targets, DVWA SQL-blind and DVWA SQL, along with eight real-world cases, including login pages, blogs, business websites, and eCommerce sites. Our framework was first evaluated on an open-source software project, with the specific test targets depicted in

Table 2. TPSQLi test target.

Type	Test Target	Topic
Open Source	DVWA (SQL-blind)	Test Environment
	DVWA (SQL)	Test Environment
Real-world Case	R1	Login page
	R2	Wiki/database
	R3	Blogs/news
	R4	Business website
	R5	Service provider
	R6	eCommerce website
	R7	Portfolio
	R8	Business website

.

5.1. Collecting Time Data from Various Techniques

This flowchart in Figure 7 is designed to collect time data for various SQL injection detection techniques. The process begins by inputting a URL as the test target and testing each technique over multiple rounds ($n$ rounds). The technique type is recorded at the outset, followed by the start time for each technique test. The exploit is then executed, and upon completion, the end time is recorded regardless of the test’s success. The log file is subsequently deleted to ensure it does not affect subsequent tests. This procedure is repeated for all techniques, ensuring a comprehensive time data collection for each method.

5.2. Weights for Test

We evaluated TPSQLi on two open-source projects and eight websites with publicly disclosed SQL injection vulnerabilities submitted to HITCON ZeroDay [32]. The types and themes of these test websites are detailed in Table 2.

We performed five rounds of testing, recording the results and calculating the weights using Equations (1) and (2). The compiled scores are presented in

Table 3. Weights of the test target.

	Boolean-Based	Error- Based	Union-Based	Stack- Based	Time- Based	Inline Queries
DVWA (SQL-blind)	5.46	0	0	0.25	0.29	0
DVWA (SQL)	2.34	0.94	2.57	0.09	0.06	0
R1	0	0	0	0	6	0
R2	2.32	0	2.55	0	1.13	0
R3	0	0	0	0	6	0
R4	6	0	0	0	0	0
R5	4.59	0	0	0.43	0.98	0
R6	3.60	1.23	0.75	0	0.42	0
R7	2.71	0	2.54	0	0.74	0
R8	2.74	0.69	2.16	0	0.40	0

. These scores informed the development of new testing priorities, transitioning from the existing BEUSTQ to a new order based on the calculated weights. Detailed timing information for each round is available in Appendix A.

5.3. Comparing with ART4SQLi

To evaluate the effectiveness of our proposed test prioritization approach, we conducted a comparative analysis against ART4SQLi, a widely used tool for SQL injection detection.

5.3.1. Coverage-Based Visual Comparison

We plotted the data obtained from both the original test prioritization and our new test prioritization approach on a single chart for visual comparison. In each chart in Figure 8, the horizontal axis represents time, while the vertical axis denotes the number of detected vulnerabilities. The blue area illustrates the results from the original test order, whereas the yellow area represents the outcomes generated by our TPSQLi framework. Our research demonstrates that the test priorities determined by the TPSQLi framework consistently outperform or match the original test order. In scenarios where the test priority differs from the original order, our approach achieves faster and more remarkable coverage improvement, leading to earlier attainment of 100% coverage.

5.3.2. Statistical Analysis of Test Execution Time

The maximum time $T_{max}$, minimum time $T_{min}$, average time $T_{mean}$, and standard deviation of the time for exposing the last vulnerabilities $T_{std}$ of both the ART4SQLi and the proposed TPSQLi for the ten test targets are presented in

Table 4. Comparisons between ART4SQLi and TPSQLi.

Test Target	Method	${\mathit{T}}_{\mathit{m}\mathit{a}\mathit{x}}$	${\mathit{T}}_{\mathit{m}\mathit{i}\mathit{n}}$	${\mathit{T}}_{\mathit{m}\mathit{e}\mathit{a}\mathit{n}}$	${\mathit{T}}_{\mathit{s}\mathit{t}\mathit{d}}$	$\left|\mathit{Z}\right|$
DVWA (SQL-blind)	ART4SQLi [9]	405.80	349.90	369.11	20.37	1.68
	TPSQLi	359.9	307.06	331.26	14.47
DVWA (SQL)	ART4SQLi [9]	913.55	834.79	862.39	31.95	0.059
	TPSQLi	898.65	836.08	859.97	25.52
R1	ART4SQLi [9]	68.48	64.26	65.82	1.69	17.04
	TPSQLi	32.42	29.28	30.44	1.21
R2	ART4SQLi [9]	157.61	141.22	146.07	6.76	5.50
	TPSQLi	109.82	99.45	102.73	4.07
R3	ART4SQLi [9]	94.11	87.41	90.68	2.65	20.66
	TPSQLi	35.69	34.67	35.15	0.46
R4	ART4SQLi [9]	22.63	20.10	21.00	0.99	0.04
	TPSQLi	22.47	20.32	21.06	0.85
R5	ART4SQLi [9]	395.77	351.55	368.99	16.29	5.86
	TPSQLi	275.34	259.71	267.65	5.83
R6	ART4SQLi [9]	128.62	121.16	124.49	3.10	2.67
	TPSQLi	116.81	109.65	113.21	2.88
R7	ART4SQLi [9]	332.98	319.94	325.47	5.69	9.49
	TPSQLi	256.94	244.99	250.87	5.43
R8	ART4SQLi [9]	79.27	78.18	78.72	0.44	32.16
	TPSQLi	61.90	61.15	61.63	0.30

.

The last column in Table 4, labeled $\left|Z\right|$, displays the values obtained from the statistical $Z$-$test$, calculated using the mean ($T_{mean})$ and standard deviation ($T_{std})$, specified in Equation (4). This column is intended to determine whether there is a statistically significant difference between the results of the two approaches (ART4SQLi and TPSQLi) across the ten test cases, with a confidence level of 95%, i.e., $Z_{0.95}=1.645$.

$$Z={\displaystyle \frac{T_{mean, \mathrm{T}\mathrm{P}\mathrm{S}\mathrm{Q}\mathrm{L}\mathrm{i}}-T_{mean,\mathrm{A}\mathrm{R}\mathrm{T}4\mathrm{S}\mathrm{Q}\mathrm{L}\mathrm{i}}}{\sqrt{T_{std,\mathrm{T}\mathrm{P}\mathrm{S}\mathrm{Q}\mathrm{L}\mathrm{i}}^2+T_{std,\mathrm{A}\mathrm{R}\mathrm{T}4\mathrm{S}\mathrm{Q}\mathrm{L}\mathrm{i}}^2}}}$$

(4)

As shown in Table 4, TPSQLi outperformed ART4SQLi across all metrics, with the exception of $T_{mean}$ for R4. Notably, the test prioritization did not alter the order for R4 and DVWA (SQL), resulting in the same order as observed in ART4SQLi. The $\left|Z\right|$ values, except for those corresponding to DVWA (SQL) and R4, exceeded the critical value $Z_{0.95}=1.645$, as indicated in the rightmost column. This suggests that the $Z$-$test$ confirms a significant reduction in execution time between ART4SQLi and TPSQLi for the 10 test cases.

5.3.3. Discussion of Effectiveness

Like ART4SQLi [9], we discuss the effectiveness of our test prioritization process and compare it with ART4SQLi. In TPSQLi, when a payload successfully exposes a vulnerability in the web application, it is considered valid and treated as a true positive. If the payload detects the final vulnerability, TPSQLi halts, marking the payload as valid. All payloads tested before this last successful one, which did not lead to exploiting a vulnerability, are considered false positives (they are flagged as suspicious but ultimately invalid).

If TPSQLi stops after the $p^{th}$ payload (where $p\ge 1$ and the payload is valid), and the number of the valid payloads before $p^{th}$ is $v$, the $p-v-1$ payloads are categorized as false positives. In contrast, the $v+1$ payloads are considered as true positive. Since TPSQLi terminates once the last valid payload is detected, neither true nor false negatives are accounted for in this analysis.

We designed a new metric, the False Positive Measure ($FPM$), to systematically compare the false positives. This metric is defined as:

$$FPM={\displaystyle \frac{Total Executed Payloads}{False Positive}}$$

(5)

A higher $FPM$ indicates a more effective process, implying fewer false positives than the number of executed payloads. To further quantify the improvement of TPSQLi over ART4SQLi, we also introduce an Improved Rate ($IR$), calculated as:

$$IR={\displaystyle \frac{{FPM}_{\mathrm{T}\mathrm{P}\mathrm{S}\mathrm{Q}\mathrm{L}\mathrm{i}}-{FPM}_{\mathrm{A}\mathrm{R}\mathrm{T}4\mathrm{S}\mathrm{Q}\mathrm{L}\mathrm{i}}}{{FPM}_{\mathrm{A}\mathrm{R}\mathrm{T}\mathrm{4}\mathrm{S}\mathrm{Q}\mathrm{L}\mathrm{i}}}}\times 100\%$$

(6)

The $IR$ expresses the percentage improvement offered by TPSQLi over ART4SQLi. As shown in

Table 5. Comparison of TPSQLi and ART4SQLi Based on False Positive Measure ($FPM$) and Improved Rate ($IR$) Across Various Test Targets.

Test Target	Method	FPM	IR	Average IR
DVWA (SQL-blind)	ART4SQLi [9]	1.0028	3.37%	4.65%
	TPSQLi	1.0366
DVWA (SQL)	ART4SQLi [9]	1.0057	0.00%
	TPSQLi	1.0057
R1	ART4SQLi [9]	1.0004	19.95%
	TPSQLi	1.2000
R2	ART4SQLi [9]	1.0018	2.17%
	TPSQLi	1.0236
R3	ART4SQLi [9]	1.0004	16.62%
	TPSQLi	1.1667
R4	ART4SQLi [9]	1.0004	0.00%
	TPSQLi	1.0004
R5	ART4SQLi [9]	1.0009	0.71%
	TPSQLi	1.0080
R6	ART4SQLi [9]	1.0031	1.09%
	TPSQLi	1.0140
R7	ART4SQLi [9]	1.0018	1.70%
	TPSQLi	1.0189
R8	ART4SQLi [9]	1.0030	0.92%
	TPSQLi	1.0123

, TPSQLi delivers significant enhancements, particularly for test targets R1 and R3, with $IR$ values of 19.95% and 16.62%, respectively. On average, TPSQLi demonstrates a 4.65% overall improvement, indicating consistent efficiency gains across different web applications. Notably, no improvement was observed on test targets DVWA(SQL) and R4, as the original order in both cases was optimal, resulting in identical $FPM$ values for both TPSQLi and ART4SQLi.

This analysis highlights that our test prioritization method effectively reduces false positives and improves the accuracy of SQL injection detection. The increase in $FPM$ values and positive IR percentages confirm that TPSQLi is superior to ART4SQLi, particularly in handling test execution time and precision.

6. Conclusions

In this research, we propose a comprehensive framework for regression testing of SQLi, focused on optimizing test prioritization through the design of weight functions and evaluation methods. The proposed module for calculating test prioritization is flexible, accommodating various technologies and targets, and includes dynamic adjustment capabilities. The weight calculation method accounts for the time differential in the exposure of weaknesses and considers the probability of successful exploitation by different technologies. Our findings demonstrate that the time to expose the first weakness is significantly reduced, and the overall exposure time is faster than the original test order. TPSQLi effectively accelerates the testing process, as evidenced by statistical $Z$-$test$ calculations confirming significant differences compared to the ART4SQLi. We also discuss the false positive to check the effectiveness of TPSQLi and compare it with ART4SQLi. Moreover, future work will explore machine learning methods, such as large language models for feature extraction and reinforcement learning for dynamically adjusting test prioritization, to enhance test prioritization further, aiming to improve the efficiency of SQL Injection testing.