Comparative Analysis of SQL Injection Defense Mechanisms Based on Three Approaches: PDO, PVT, and ART

Abstract

This study presents a comprehensive examination of the risks associated with SQL Injection attacks, with a particular focus on the Union Select technique. This method is frequently exploited by attackers to retrieve unauthorized data by appending malicious queries to legitimate database calls. We analyzed multiple real-world cases where personal information was leaked through such attacks, underscoring the urgent need for robust countermeasures in modern web applications. To address these threats, we developed and implemented a multi-layered defense strategy. This strategy includes using PHP Data Objects (PDO) with Prepared Statements to safely handling user inputs, rigorous input pattern validation to detect and reject suspicious payloads, and a redirection-based filtering mechanism to disrupt abnormal access attempts. Through controlled experiments, we validated the effectiveness of these techniques in mitigating SQL Injection attacks. The results demonstrate that our approach successfully blocked malicious queries and prevented unauthorized data access or manipulation. These findings represent a significant contribution to enhancing the security, stability, and trustworthiness of web-based systems, especially those handling sensitive user information. Finally, this work is presented as an educational comparative study, not as a proposal of new defense mechanisms, aiming to provide a clear and reproducible evaluation of standard SQL injection countermeasures. The contributions of this work are threefold: (i) it provides a unified comparative evaluation of three representative SQL injection defense methods—PDO, pattern validation, and attacker redirection—under identical experimental conditions; (ii) it analyzes their strengths, weaknesses, and practical applicability in PHP–MySQL environments; and (iii) it serves as an educational reference that bridges theoretical understanding and practical implementation. The study also suggests directions for extending this work through machine-learning-based anomaly detection and runtime self-protection (RASP) frameworks.

1. Introduction

This study aims to explore one of the most critical security vulnerabilities in modern web applications—SQL Injection (SQLi) attacks—and to provide a clear comparative and educational analysis of standard countermeasures. Specifically, the objective of this work is to systematically evaluate three representative SQL Injection defense mechanisms—PHP Data Objects (PDO), Pattern Validation Technique (PVT), and Attacker Redirection Technique (ART)—under identical PHP–MySQL experimental conditions. Rather than proposing novel algorithms, this study focuses on analyzing how existing, widely adopted defensive methods perform in practice, highlighting their strengths, limitations, and applicability in real-world environments. The originality of this work lies in conducting a unified, reproducible comparative evaluation of three well-established SQLi defense mechanisms within the same controlled environment—something rarely addressed in prior studies, which typically assess a single technique in isolation or under differing system settings. By aligning all experiments under consistent PHP–MySQL conditions and attack scenarios, this study provides the first systematic, side-by-side comparison of these core defense methods. Furthermore, the paper integrates practical coding demonstrations, real attack payloads, and structural analysis, thereby bridging the gap between theoretical understanding and hands-on implementation. SQL Injection exploits structural weaknesses in the interaction between web applications and databases. Attackers maliciously inject SQL queries into input fields, which are then executed by the database engine. As a result, they may gain unauthorized access to sensitive data, manipulate or delete information, and even obtain full control of the system. When an SQL Injection attack succeeds, attackers can extract user account information, analyze the database structure, modify or remove records, and, in some cases, compromise the entire web application [1,2]. The impact of these attacks is especially severe in domains that handle sensitive personal information, such as finance, e-commerce, and healthcare. In these sectors, a single vulnerability can lead to catastrophic consequences, including loss of customer trust, legal disputes, and substantial financial damage. A real-world example of such an incident is a major domestic case involving an online accommodation reservation platform. In this case, a large amount of personal data was leaked due to a successful SQL Injection attack, causing a significant decline in public trust and serious legal repercussions. In response to these critical threats, this study implements and analyzes three concrete defensive techniques within a unified test environment. First, the use of Prepared Statements via PDO ensures a structural separation between SQL commands and user input, preventing the execution of injected code [3]. Second, the Input Pattern Validation Technique (PVT) employs regular expressions to detect and block inputs containing malicious SQL keywords or special characters before they reach the database layer [4]. Third, the Attacker Redirection Technique (ART) introduces a filtering-based mechanism that redirects users to a warning or decoy page upon detection of suspicious input, thereby interrupting the attack process and deterring repeated attempts. SQL Injection remains one of the most common and dangerous attack vectors in web security, with consequences extending far beyond data breaches to include service disruption, brand damage, and operational risks [5,6]. Therefore, this research emphasizes the urgent need to understand both the mechanics and defensive strategies of SQL Injection. The paper is deliberately structured to progress from explaining the attack mechanism to presenting the three defensive methods, and finally to providing a comparative experimental analysis. This progressive organization not only enhances readability but also provides educational value for practitioners, developers, and students of web security.

The main contributions of this study can be summarized as follows:

-

It presents the first unified comparative analysis of three widely used SQLi defense mechanisms—PDO, PVT, and ART—under consistent experimental conditions.

-

It provides practical implementation guidelines and code-level validation for each technique, offering reproducible reference materials for academic and educational use.

-

It clarifies the relative strengths, weaknesses, and trade-offs among the techniques, helping practitioners choose suitable combinations for real-world deployment.

Ultimately, this study aims to serve as a reproducible benchmark and educational reference that bridges theoretical understanding and practical implementation of SQL Injection defense. Unlike studies that introduce new defense algorithms, this paper aims to serve as an educational and comparative reference that systematically evaluates three standard SQL injection prevention techniques—PDO, pattern validation, and attacker redirection—under identical test conditions.

The remainder of this paper is organized as follows. Section 2 explains related works in detail. Section 3 introduces and elaborates on the proposed defense strategies and prevention techniques. In Section 4, we present the results of our experimental analysis and evaluate the effectiveness of the proposed methods. Finally, Section 5 concludes the study by summarizing the key findings and suggesting directions for future research.

2. Related Works

2.1. SQL Injection Vulnerability

In interactions between web applications and databases, SQL injection vulnerabilities—such as the process illustrated in Figure 1—can arise when user inputs are not properly sanitized. This flaw enables attackers to craft malicious queries that the database may execute, potentially resulting in unauthorized data access or manipulation [7,8,9].

SQL Injection remains one of the most prevalent and damaging forms of web-based attacks [10], primarily due to its relative ease of execution and the potentially severe consequences of successful exploitation. A notable real-world example occurred in March 2017, when the Korean accommodation service platform Yogiyo experienced a large-scale personal information breach. Investigations revealed that the incident was caused by an SQL Injection vulnerability in the platform’s database interface [11]. SQL Injection attacks are commonly classified into several types, including Error-Based Injection, Union-Based Injection, Boolean-Based Injection, and attacks exploiting Stored Procedures. Among these, Union-Based Injection leverages the UNION SQL operator to append additional queries to an existing SELECT statement executed by the server. This technique enables attackers to retrieve unauthorized information from the database by combining query results. For a Union-Based Injection to succeed, two primary conditions must be met. When employing a UNION SELECT statement, the number of columns must correspond to those of the original SELECT statement, and the data types of the respective columns must be compatible in order. In this study, we applied the Union-based SQL injection technique. The experimental target was a PHP-based bulletin board without any protective mechanisms, and the baseline query used by the application is presented in Figure 2. To simulate a vulnerable environment, the system was deliberately left without any security measures. The SQL query constructed to exploit the vulnerability is illustrated in Figure 2 [12], which shows the original query without the UNION clause.

The test database was constructed with the following fields: idx (int), username (varchar), userid (varchar), userpw (varchar), useremail (varchar), and regdate (datetime), as shown in Figure 3.

To execute the attack on the constructed database, the following SQL injection payload was used: ‘UNION SELECT 1, ‘admin’, ‘dummy’, ‘dummy’, ‘dummy@example.com’, ‘2024-01-01’ --’ This payload was injected into the ID input field, while an arbitrary value was entered into the Password field. Since the second column in the UNION SELECT statement corresponds to the username, the application identifies the injected value ‘admin’ as the logged-in user. As a result, the attacker is granted access under the administrator’s identity. Once the attack is successful, the attacker can log in as admin, post messages on the bulletin board, and perform actions such as editing, deleting, or reading posts written by other users. As a result, the attacker is granted access under the administrator’s identity. Once the attack is successful, the attacker can log in as admin, post messages on the bulletin board, and perform actions such as editing, deleting, or reading posts written by other users, as rated in Figure 4 and Figure 5 [13,14].

This study specifically focuses on Union-Based SQL Injection because it represents one of the most frequently exploited and practically impactful techniques. Compared to other forms such as Boolean- or Error-based injection, Union-based attacks allow attackers to directly extract large volumes of structured data with relatively low technical effort. By concentrating on this technique, our experiments reflect a realistic and highly prevalent threat scenario in modern web applications. In addition to traditional techniques, several modern approaches have recently been proposed. Runtime Application Self-Protection (RASP) frameworks integrate security functions directly into the application runtime, allowing them to monitor and block suspicious queries before they reach the database. Moreover, machine learning–based models, including deep learning, have demonstrated improved performance in detecting obfuscated or zero-day SQL injection payloads. These emerging techniques, while not part of our experimental evaluation, represent promising complementary defenses and are highlighted as potential directions for extending this study in the future.

2.2. Literature Analysis

Numerous studies have investigated SQL Injection (SQLi) detection and prevention techniques over the past two decades. Early research such as Halfond and Orso [10] and Bertino and Sandhu [1] analyzed structural vulnerabilities and proposed query-parameterization and runtime monitoring approaches. Subsequent works, including Appelt et al. [3] and Nasereddin et al. [2], advanced static and dynamic analysis for web-application firewalls and automatic repair of vulnerable code. A second stream of studies applies machine-learning and deep-learning models to identify SQLi payloads through pattern or semantic analysis [4,5,8,9,12]. These approaches show improved detection of obfuscated or zero-day attacks but require large labeled datasets and training overhead. A third direction focuses on deception-based and honeypot frameworks [15,16], which record attacker behavior and serve as complementary defense layers rather than direct query protection. Despite these advances, most prior works evaluate individual mechanisms under differing testbeds and technologies, making direct comparison difficult. Few studies systematically analyze multiple standard techniques (e.g., PDO, pattern validation, redirection) within a consistent PHP–MySQL environment. To fill this gap, our study provides an educational comparative evaluation of three representative and well-established methods under identical experimental conditions, highlighting their practical trade-offs and applicability to real-world legacy systems.

3. SQL Injection Mitigation and Defense

This section presents defense strategies to address the challenges of SQL injection attacks. It emphasizes the importance of inspecting user input for special characters and suspicious keywords during the input-handling process. The three techniques analyzed in this study were selected to represent the most widely adopted categories of SQL injection prevention methods.

-

PHP Data Objects (PDO) exemplifies structural defenses that separate query logic from user input using parameterized queries.

-

Pattern Validation Technique (PVT) represents input validation approaches that rely on detecting suspicious patterns before query execution.

-

Attacker Redirection Technique (ART) illustrates behavioral and deception-based responses that handle detected attacks through diversion and logging.

These categories are consistent with the three-layer defense model—structural, validation, and behavioral—described in prior studies [1,10,15,16,17]. By comparing these representative techniques under identical test conditions, the study aims to provide a balanced understanding of their effectiveness, limitations, and practical applicability in typical PHP–MySQL environments. Based on this approach, three key defense techniques are discussed: the use of PDO with prepared statements, input pattern validation, and filtering-based redirection mechanisms to divert attackers away from the target system. Relying solely on simple string-based filtering is insufficient, as many SQL injection techniques are specifically designed to bypass such basic defenses. Therefore, it is essential to use parameterized queries or prepared statements to ensure a clear separation between user input and SQL commands. This not only prevents injection attacks but also enhances security by enabling strict validation of user input based on known attack patterns. Finally, the third defense method involves detecting malicious input and redirecting the attacker to a decoy or warning page. This approach is conceptually related to deception-based defense strategies, such as honeypots and moving target defense, which aim to mislead adversaries and observe their behavior. In our implementation, the redirection mechanism does not solely prevent SQL injection attacks but functions as a supplementary layer: it deters attackers by presenting a non-functional interface, enables the collection of malicious query logs for forensic analysis, and increases the cost of further exploitation attempts. Thus, while not a standalone preventive measure, redirection serves as an auxiliary defense technique within a defense-in-depth framework. This approach effectively blocks unauthorized access attempts and disrupts the attack process at an early stage.

3.1. PHP Data Objects (PDO)

The first defense technique implemented was the use of PDO [Figure 6].

PDO is a PHP extension that provides a consistent interface for accessing various types of databases, enabling more secure and maintainable database interactions. Specifically, Prepared Statements in PDO separate the SQL query from user-supplied data by precompiling the SQL statement before execution. User input is then bound to the query at runtime. This separation ensures that the SQL code and data are processed independently, so the database interprets the input strictly as values rather than executable SQL commands. Consequently, malicious SQL code injected by an attacker is not executed, effectively preventing SQL injection attacks [18].

3.2. Input Pattern Validation Technique for Injection Defense (PVT)

The second defense technique involves validating user input to detect and block potentially malicious keywords. During the login process, the system checks whether the entered user ID contains specific keywords commonly used in SQL injection attacks, thereby enhancing overall security (See Algorithm 1).

Algorithm 1: Filtering-based Protection Technique

1: Define suspicious patterns for SQL injection: - SQL keywords: select, insert, update, delete, drop, union, where, and, or, limit - Special characters: “, ‘, ; - SQL comment: -- 2: For each pattern in the list of suspicious expressions:   2.1. Compare the user input id against the pattern using regular expression matching.   2.2. If the input matches a forbidden pattern: - Display an alert message: “Your ID contains forbidden characters.” - Redirect the user back to the previous page - Exit program execution immediately 3: If no matches are found, continue to normal query processing

To achieve this, the system inspects the input for keywords such as select, insert, update, delete, drop, union, where, and, or, and limit. If any of these keywords are detected, the system immediately displays an error message and denies the login attempt. This technique serves as a pre-filtering mechanism to prevent SQL query manipulation and is specifically designed to block attempts by attackers to inject harmful SQL commands through user input [19,20].

3.3. Attacker Redirection Technique (ART)

The third and final defense technique employs a filtering-based attacker redirection mechanism. The core concept of this technique is to create the illusion of a successful attack while, in reality, exposing the futility of the attacker’s efforts. Specifically, when a user attempts to log in with an ID containing SQL Injection-related keywords, the system does not direct them to the actual bulletin board page. Instead, the user is silently redirected to a decoy page named fake.php (See Figure 7) [15,16].

It should be noted that the defensive techniques discussed in this section are individually well-established. Our contribution lies in applying these approaches under a unified experimental setup and comparing their practical effectiveness, limitations, and trade-offs in a consistent manner.

Table 1. SQL Injection Defense Techniques Comparison.

Item	PHP Data Objects (PDO)	Input Pattern Validation	Attacker Redirection
Basic Principle	Separates SQL query structure from user input using prepared statements.	Blocks suspicious patterns using regex for SQL keywords/special characters.	Redirects user to a fake page upon detecting malicious input.
Security Strength	Very high–provides structural protection.	Medium–depends on detection pattern quality.	Low–ineffective if detection fails.
Input Validation Method	Parameter binding with explicit type validation.	Regex-based keyword/pattern matching using preg_match.	Pattern check followed by conditional redirection.
Bypass Possibility	Low (if implemented correctly).	Present–obfuscated inputs may evade detection.	Present–attacker may detect redirection.
Accuracy (False Positives/Negatives)	High–clear separation between data and query.	Low–risks of false positives and missed detections.	Low–depends on pattern quality.
Implementation Difficulty	Medium to high–may require restructuring code.	Low–simple regex implementation.	Low–basic conditional logic.
Maintenance Overhead	High–requires consistent PDO usage.	Medium–regular updates to patterns needed.	Medium–managing fake pages and policies.
Integration with Existing Systems	Difficult–legacy code migration required.	Easy–can be injected into existing logic.	Easy–minimal modification required.
Performance Impact	Low–may improve due to query plan reuse.	Medium–many regex checks may slow down system.	Low–redirection incurs minimal cost.
Logging and Response Capability	Limited–requires custom logging.	Possible–log filtered attempts.	Excellent–logs and behavior analysis enabled.
Key Advantages	Strong structural defense, DBMS compatibility, auto escaping.	Easy to implement, preemptive blocking, client-side possible.	Disrupts attacker behavior, supports logging and analysis.
Key Disadvantages	Steep learning curve, hard with dynamic queries, migration effort.	Bypassable, false positives, needs frequent update.	No structural defense, ineffective if undetected.

explains SQL Injection Defense Techniques Comparison that we discussed in this Section.

Table 1 summarizes the core characteristics of the three representative SQL Injection (SQLi) defense mechanisms—PDO, PVT, and ART—across multiple evaluation dimensions such as structural protection, accuracy, bypass possibility, and maintenance effort. The comparative results shown in the table are consistent with the findings of several previous studies. First, PHP Data Objects (PDO) provides the strongest structural defense because its parameterized query model eliminates the possibility of code injection by design. This observation aligns with Halfond and Orso [10] and Bertino and Sandhu [1], who demonstrated that strict separation between query logic and user input is the most reliable protection against SQLi. Moreover, PDO’s low performance impact and type-safety advantages correspond with recent work by Alkhalaf et al. [4], which reported that parameter binding improves both security and query-plan efficiency. Second, the Pattern Validation Technique (PVT) represents a lightweight, rule-based approach that inspects inputs before query execution. As shown in the table, its medium security strength and possible false positives are in line with the results of Jemal et al. [5] and Souza et al. [20], who noted that regex-based detection is easy to deploy but vulnerable to evasion through encoding or case manipulation. Nevertheless, as Dasari et al. [8] reported, such methods remain valuable as pre-filters when combined with structural defenses. Third, the Attacker Redirection Technique (ART) illustrates a behavioral and deception-based response that supplements structural and validation mechanisms. Its logging and deterrence capability supports the perspective of Muntaha et al. [15] and Moric et al. [16], who emphasized that honeypot-like mechanisms contribute to attacker profiling and post-incident analysis. Although ART alone cannot prevent injection before query execution, Table 1 confirms its role as an auxiliary layer that disrupts malicious behavior at minimal system cost. Collectively, these textual analyses confirm that Table 1 reflects a well-grounded synthesis of existing SQLi defense paradigms. By combining structural, validation, and behavioral perspectives, the table operationalizes the three-layer defense model proposed in prior literature [1,10,15,16,17] and provides a clear comparative overview for both researchers and practitioners.

4. Experiment and Analysis

4.1. PHP Data Object (PDO) Defense

The prepare function used in the code shown (See Algorithm 2) stands for Prepared Statement, which is a method for preparing an SQL query in advance. In this process, the structure of the query is defined before execution, and the required data is later bound to the query before it is executed.

Algorithm 2: PDO-based SQL Injection Defense with Prepared Statements

1: Establish PDO connection with host, database name, charset, and credentials 2: Set the PDO error mode to ERRMODE_EXCEPTION 3: Read input userid from the HTTP request 4: Prepare SQL query:    SELECT * FROM member WHERE userid = : userid 5: Bind parameter : userid with the input value (string type) 6: Execute the prepared statement 7: Fetch the query result 8: If a record exists, return the result; otherwise, return “not found.”

This method prevents user input from altering the structure of the SQL query or injecting malicious SQL code by separating the SQL statement from the user-supplied data. In other words, even if an attacker attempts to inject malicious SQL code, the query structure remains fixed, and the input is treated strictly as data, not as part of the executable query. Additionally, this approach enables explicit data type validation. By defining the data types of the bound parameters, the system can raise an error if the input format does not match the expected type, thereby preventing the execution of potentially harmful inputs. Algorithm 3 shows a sample implementation using the first defense technique: PDO-based prepared statements.

Algorithm 3: PDO-based User Authentication Process

1: Prepare SQL query using PDO with parameter binding:    SELECT * FROM member WHERE id = : id LIMIT 1 2: Execute query with the user-provided id value 3: Fetch one row from the result set 4: Check user existence: - If no row is returned, display an alert “The ID does not exist” and redirect back to the previous page 5: If user exists, verify password: - Compare the stored password with the provided password - If they do not match, display an alert “Password does not match” and redirect back 6: If both ID and password match: - Create a new session with the user ID - Redirect the user to the main page (index.php)

Using prepared statements not only helps prevent SQL injection attacks but also contributes to performance improvements by precompiling the query execution plan. Furthermore, it enhances security through data type enforcement and automatic escaping of special characters. For example, if an attacker attempts to log in by injecting the following code into the ID field: ‘UNION SELECT 369, ‘dummy’, ‘dummy’, ‘dummy’, ‘dummy’, ‘dummy’, --’ and enters an arbitrary value in the password field, the system when using prepared statements successfully prevents the SQL injection attack (See Algorithm 4).

Algorithm 4: Filtering-based Protection Technique

1: Define injection patterns to detect suspicious input: - SQL keywords: select, insert, update, delete, drop, union, where, and, or, limit - Special characters: “, ‘, ; - SQL comment syntax: -- 2: Iterate through each pattern in the defined list 3: Check user input against the current pattern using regular expression matching 4: If a match is found: - Display an alert message: “Your ID contains forbidden characters.” - Redirect the user back to the previous page - Terminate program execution 5: If no patterns match, proceed with normal query execution

4.2. Input Pattern Validation Technique for Injection Prevention

The second filtering-based defense technique incorporates a pattern-matching mechanism designed to prevent SQL Injection attacks. This method inspects the user-provided ID input to identify any potentially malicious SQL-related patterns and blocks the request accordingly. In the implementation, a set of known SQL Injection patterns is defined as an array. These patterns include common SQL keywords, special characters that can terminate string literals, and elements used to initiate SQL comments. All of these components are frequently employed in SQL Injection attempts to manipulate or bypass query logic. As shown in Figure 8, the system iteratively examines the input against each defined pattern using the preg_match function. If a match is found, the system immediately displays a warning message and redirects the user to the previous page. This process alerts the user that their input contains prohibited characters or structures, thereby helping to prevent SQL Injection attacks. For example, if an attacker inputs a payload such as: ‘UNION SELECT 369, ‘dummy’, ‘dummy’, ‘dummy’, ‘dummy’, ‘dummy’, --’ into the ID field and enters an arbitrary value in the Password field, the system detects the presence of injection related keywords and blocks the login attempt.

4.3. Attacker Redirection Technique via Input Filtering

The third defense technique utilizes input filtering to redirect the attacker to an arbitrary page when a malicious input pattern is detected. This approach inspects the user-submitted data, and if it matches known SQL Injection patterns, the system immediately redirects the user to a different page, effectively interrupting the attack flow. As shown in Figure 9, the code defines an array containing common SQL injection elements, such as SQL keywords, special characters, and comment symbols. It then checks whether the input value, $id, matches any of these patterns using the preg_match function. This PHP function employs regular expressions to detect specific patterns within a string. If a match is found, the user is redirected to a decoy (fake.php Code) and the result (See Figure 10). This redirection serves as an indicator that a potential SQL injection attempt has been detected and effectively prevents the attacker from accessing the main bulletin board page.

Figure 9. Filter Protection Method Results.

Figure 9. Filter Protection Method Results.

Figure 10. Fake page results.

Figure 10. Fake page results.

The fake.php example with an infinite JavaScript alert() loop was included only for demonstration and educational purposes. This implementation is not recommended in any production or live system because it may cause client-side denial of service or ethical issues. In practical environments, the attacker redirection (ART) technique should be deployed only within a controlled deception or honeypot framework, separated from the application logic, to safely log and analyze malicious access attempts without affecting legitimate users. At first glance, the attacker may believe that the injection attempt succeeded; however, they are instead presented with a meaningless result. On the decoy page, a welcome message is initially displayed, followed by repeated messages stating you’re a hacker. Aside from interacting with these messages, the attacker is unable to carry out any further malicious actions. This method not only blocks the actual attack but also creates a sense of futility and confusion for the attacker, serving as a psychological deterrent.

4.4. Comparative Analysis of Three Methods

To enhance the clarity of our experimental results, we provide a structured summary of the relative effectiveness of the three defense techniques in

Table 2. Comparative experimental results of PDO, PVT, and ART based on controlled test cases. Values represent approximate effectiveness inferred from qualitative analysis rather than strict benchmark measurements.

Technique	Blocking Success Rate	False Positives	Performance Impact	Notes
PDO	~100% (all tested UNION/Boolean/Tautology queries blocked)	None observed	Low (query plan reuse improves efficiency)	Strong structural defense, requires refactoring legacy code
PVT	80–85% (most keyword-based injections blocked; obfuscation bypassed some cases)	Occasional blocking of legitimate inputs with “union” in username field	Medium (regex checks on input)	Lightweight, requires regular updates to patterns
ART	70–75% (attacks redirected to decoy; some undetected queries passed)	None	Very low	Effective as a deterrent/logging method, but not standalone

. These results are not intended as absolute quantitative benchmarks but as approximate comparative observations derived from our controlled test cases and qualitative analysis. PDO consistently blocked all tested SQL injection attempts, showing the highest structural reliability. PVT achieved moderate protection but was occasionally bypassed by obfuscated inputs and produced some false positives. ART successfully redirected many malicious attempts and enabled logging, but its protection was partial when payloads were not matched by predefined patterns. This comparative table highlights the practical trade-offs among the three approaches in terms of blocking rate, false positives, and performance overhead.

Table 3. Comparative Analysis of Three SQL Injection Defense Methods.

Technique	Advantages	Disadvantages
PDO (PHP Data Objects)	Security: Separates query structure from user input, preventing injection attacks Type Validation: Explicit type binding via bindParam Reusability & Performance: Reuse of execution plans improves speed Flexibility: Works across multiple DBMSs Automatic Escaping: Special characters are automatically escaped	Learning Curve: Developers must adapt to new syntax Maintenance Overhead: Prepared Statements increase code volume Implementation Dependency: Security depends on correct usage Limited Support for dynamic queries (e.g., table names) Legacy Integration: Migration can require major changes Driver Dependency: Some DBMS-specific feature limitations
PVT (Pattern Validation Technique)	Immediate Blocking of malicious patterns Simple Implementation with regex Compatible with other defenses (e.g., PDO) Preemptive Detection possible at client-side Selective Application to critical fields	Bypass Possibility: Obfuscated inputs may evade regex Regex Limitations: Complex patterns may be missed; risk of false positives Maintenance Overhead: Frequent updates to patterns required Policy Design Challenges: Deciding what to block is non-trivial Performance Impact: Too many regex checks may slow system
ART (Attacker Redirection Technique)	Attack Disruption: Misleads attacker with fake page Safe Redirection prevents real damage Detection & Logging of attacks Security Log Collection for forensic analysis Protects system resources from repeated malicious attempts	Not a Complete Defense: If query executes first, still vulnerable Bypass Possibility: Skilled attackers may evade redirection Maintenance of fake pages required Additional overhead for redirection infrastructure

summarizes the comparative analysis of the three SQL Injection defense techniques—PDO, PVT, and ART—by highlighting their respective advantages and disadvantages. This comparison provides a clear overview of the strengths, limitations, and practical considerations associated with each method.

The two comparative tables (See Table 2 and Table 3) of advantages and disadvantages serve as practical guidelines for security practitioners and researchers. By highlighting trade-offs such as security strength versus implementation difficulty, or performance overhead versus maintainability, these tables assist decision-makers in selecting or combining methods best suited to their specific operational environments.

4.4.1. Comparison and Analysis Between Techniques

Prepared statements supported by PHP Data Objects (PDO) offer one of the most robust structural defenses against SQL injection by clearly separating query structure from user input. Since the query is precompiled and only the input values are bound at execution time, this method can be highly secure when implemented correctly. However, it presents an initial learning curve for developers accustomed to traditional string-based SQL construction and can be challenging to apply in legacy systems or those heavily reliant on dynamic queries. Conversely, input filtering using regular expressions is a lightweight and rapidly deployable technique that enhances security by blocking predefined malicious patterns. It can also be implemented on the client side, which helps reduce server-side processing load. However, if the filtering rules are not precise enough, attackers may bypass them. There is also a risk of false positives, where legitimate inputs are incorrectly blocked. Furthermore, filters must be regularly updated to address emerging attack vectors, which introduces a maintenance burden. The redirection approach is a behavior-based response strategy that blocks access by redirecting suspicious requests to a decoy page. This method offers the advantage of logging detected attacks and segregating malicious traffic for more efficient management. On the other hand, if the system fails to detect the attack before the query executes, redirection becomes ineffective. Moreover, attackers may find ways to circumvent the redirection itself, limiting the method’s effectiveness when used alone. Maintaining the decoy page and designing appropriate redirection policies also require ongoing management.

4.4.2. Integration of Practical Application and Combination Strategies

Although various techniques exist to protect web applications from SQL injection attacks, relying solely on a single security mechanism is rarely sufficient in real-world environments. Even if a method is theoretically robust, its practical effectiveness is influenced by factors such as the development environment, legacy code structure, developer expertise, and maintenance costs. For example, prepared statements using PHP Data Objects (PDO) are considered one of the most secure approaches against SQL injection. However, systems that previously relied on string-based SQL queries may require significant code refactoring, and developers must have a solid understanding of SQL and the PDO framework to implement them effectively. In contrast, regular expression–based filtering is easier to implement and can be quickly integrated into legacy systems, but it is vulnerable to bypass techniques and may generate false positives. Additionally, redirection techniques-which redirect users to a decoy page upon detecting malicious input-can support detection and response strategies but are not structural defense mechanisms on their own. Therefore, when applying security techniques in practice, it is essential to consider not only theoretical effectiveness but also system architecture, security requirements, and the feasibility of ongoing development and maintenance. In this context, the key is not to rely solely on a single method but rather to combine multiple techniques to construct a layered security strategy. For instance, user inputs can be filtered on both the client and server sides using regular expressions to detect suspicious patterns early. On the backend, prepared statements can be used to securely construct SQL queries, and if malicious input is detected, the system can redirect the user to a decoy page and log the attempt, thereby ensuring both security and traceability. Such a multi-layered defense approach creates a continuous flow of prevention, structural mitigation, and post-incident response, allowing the limitations of each individual method to be offset by others. Ultimately, robust security is not the result of a single solution, but of a carefully designed, multi-layered framework that is aligned with organizational goals and sustainable over time. Rather than introducing new mechanisms, this analysis emphasizes comparative insights. By systematically evaluating structural defenses (PDO), input validation (pattern filtering), and deception-based responses (redirection), the study provides concrete guidelines on their applicability in real-world PHP environments, which distinguishes it from purely technical implementation work. In terms of practical deployment, all three proposed techniques can be readily applied in contemporary web development environments. PDO with prepared statements is natively supported in popular PHP frameworks such as Laravel and Symfony, making integration straightforward. The input pattern validation method is lightweight and can be easily embedded into legacy systems with minimal code modification. The attacker redirection technique requires only simple configuration of a decoy page, which is feasible in most server environments. Thus, the combination of these approaches offers a realistic and deployable multi-layered defense.

4.4.3. Security Operations Strategy Proposal

Most security vulnerabilities originate during the coding phase. Proactive prevention, therefore, is both more effective and more cost-efficient than reactive measures. Therefore, to fundamentally reduce web vulnerabilities such as SQL injection, it is essential to incorporate secure design principles based on secure coding from the early stages of development. Secure coding refers to a development methodology that applies safe programming practices and coding standards to prevent the introduction of security vulnerabilities. In recent years, many companies have adopted secure coding as part of their internal development guidelines and provide security training for developers. Practices such as avoiding unsafe functions or dynamically constructed SQL queries are representative examples of secure coding. For these principles to be effectively implemented in practice, regular code reviews and systematic vulnerability assessments must be conducted concurrently. Through peer review, developers can detect and correct issues such as improper input handling or insecure query construction at an early stage, significantly contributing to the prevention of real-world security incidents. At the organizational level, establishing a robust security framework requires not only technical practices but also the formulation and consistent enforcement of security policies. These policies go beyond simple development guidelines and serve as a foundation for defining and managing organization-wide security norms and operational principles. In particular, security certification systems such as ISMS-P (Information Security Management System-Personal Information) are increasingly recognized domestically and internationally as official frameworks for evaluating and verifying an organization’s security posture. ISMS-P outlines comprehensive administrative, technical, and physical safeguards for the entire lifecycle of personal information processing and requires holistic protective measures for information security systems. Accordingly, by practicing secure coding from the development phase and systematically aligning it with the organization’s security policies and certification requirements, organizations can establish a stable security environment that meets both regulatory compliance and technical protection standards.

4.4.4. Limitations and Applicability

Although the proposed methods demonstrate practical effectiveness in controlled experiments, several limitations and considerations remain. To provide a balanced perspective, this subsection outlines the limitations of each approach, possible ways to mitigate them, and the subdomains where the techniques can be effectively applied.

(1) Limitations

-

PDO (Prepared Statements): Requires extensive code refactoring in legacy systems that rely on string-based SQL queries; limited flexibility with dynamic query structures such as variable table or column names.

-

PVT (Pattern Validation Technique): Vulnerable to bypass via obfuscated or encoded payloads; may trigger false positives when legitimate inputs contain reserved SQL keywords.

-

ART (Attacker Redirection Technique): Not a structural defense when deployed in isolation; effectiveness is reduced if malicious queries are executed before redirection takes place.

(2) Possible Mitigations

-

Employing a layered defense strategy, where PDO is used as the primary structural safeguard, PVT serves as a lightweight pre-filter, and ART functions as a deception-based deterrent.

-

Continuously updating pattern lists and using advanced regex or lexical analysis to reduce bypass attempts and false positives in PVT.

-

Integrating machine learning–based anomaly detection models and Web Application Firewalls (WAFs) to complement traditional defenses and adapt to new attack variants.

-

Ensuring secure coding practices and developer training to reduce misconfigurations and strengthen the overall defense framework.

(3) Potential Subdomains of Applications

-

E-commerce and financial platforms: Protecting sensitive user information such as payment details, which are prime targets for SQL Injection.

-

Online reservation and service portals: Reservation systems and ticketing platforms that often rely on PHP–MySQL backends can benefit from lightweight yet effective defense layers.

-

Educational and organizational intranet systems: University portals, learning management systems, and internal bulletin boards where legacy code and resource constraints are common.

By explicitly addressing these points, the proposed defense techniques are positioned not as a one-size-fits-all solution but as adaptable components of a broader, multi-layered web security strategy.

Furthermore, relying solely on blacklist-based filtering is insufficient, as attackers can easily obfuscate payloads to bypass simple keyword detection. Future implementations should instead adopt allow-listing strategies, where only inputs that conform to strictly defined formats are accepted. This includes canonicalization of user inputs, type- and length-based validations (e.g., restricting usernames to alphanumeric characters within a fixed range, or validating emails against RFC-compliant patterns), and enforcing such rules at the server side. In addition, non-parameterizable dynamic query parts such as table names, column names, or ORDER BY clauses—which cannot be safely parameterized—should be handled using server-side whitelisting. By shifting from blacklist-based rejection to whitelist-based acceptance, the defense framework can significantly reduce false positives and mitigate bypass attempts, thereby aligning with best practices in secure coding. Although the keyword-based blacklist filtering (PVT) demonstrated practical utility in our controlled tests, it is inherently bypassable through spacing, comment insertion, encoding, or case changes. Therefore, in real-world environments, such filtering should only be used as an auxiliary layer. The recommended best practice is to employ strict allow-list validation (based on input type, length, and format) together with parameterized queries to ensure reliable and maintainable protection against SQL injection.

4.4.5. Comparative Discussion with Previous Studies

To validate our findings and position them within the broader research landscape, this subsection compares the results of our experimental evaluation with those of prior works on SQL Injection (SQLi) detection and prevention. Previous studies such as Halfond and Orso [10] and Bertino and Sandhu [1] emphasized the effectiveness of parameterized queries and static code analysis in eliminating injection vulnerabilities. Our findings with PDO-based prepared statements are consistent with their conclusions, demonstrating complete prevention of injection attacks when parameter binding is correctly implemented. This alignment reaffirms that structural separation between data and code remains the most reliable defense mechanism, even in modern PHP environments. In contrast, studies employing keyword-based or regular-expression filtering methods, such as those by Souza et al. [20] and Jemal et al. [5], have reported moderate accuracy due to evasion by obfuscated payloads. Our Pattern Validation Technique (PVT) exhibited similar limitations, confirming these earlier findings while adding quantitative context: approximately 80–85% blocking success in controlled PHP–MySQL experiments. This result strengthens prior literature by providing empirical validation under a unified, reproducible environment, rather than isolated or simulation-based conditions. Meanwhile, recent works exploring deception and honeypot-based defenses (e.g., Muntaha et al. [15]; Moric et al. [16]) have highlighted the value of behavioral deterrence and attacker tracing rather than direct query prevention. Our Attacker Redirection Technique (ART) supports these perspectives by demonstrating that such deception-based methods, while not structurally preventive, play a crucial complementary role in multi-layered defense frameworks. Hence, our results both confirm and extend prior studies by illustrating how ART can be integrated into PHP systems to enhance forensic traceability and attacker disruption. Overall, the comparative analysis of PDO, PVT, and ART conducted here validates and synthesizes the fragmented insights of earlier research. Unlike previous works that focused on isolated methods or specific detection algorithms, this study presents a unified experimental comparison across structural, pattern-based, and behavioral defense layers, thereby establishing a clearer understanding of their relative trade-offs. This integrative perspective represents a scientific advancement by translating theoretical concepts from prior literature into an experimentally grounded, educational framework that can guide both academic research and real-world web security practice.

4.5. Threat Model and Evaluation Criteria

To ensure clarity and reproducibility, we explicitly define the threat model and the evaluation criteria adopted in this study.

(1) Threat Model. The assumed adversary is an external unauthorized actor who interacts with a vulnerable PHP–MySQL web application through public input fields. The attacker is not an administrator but a normal user with knowledge of SQL syntax and basic understanding of PHP database interactions. Their capabilities include crafting and injecting malicious SQL payloads, obfuscating queries using comments, whitespace, or encoding, and iteratively probing the database structure through repeated attempts. The payload classes considered in our experiments include:

-

Union-based injections (e.g., UNION SELECT …) for extracting structured records,

-

Boolean-based injections that rely on conditional logic to infer database content,

-

Tautology-based payloads such as OR 1 = 1 to force query success, and

-

Obfuscated payloads that use encoding or alternative representations to evade detection.

The controlled experiments conducted in this study did not involve human respondents. Instead, the “sample” corresponds to 50 distinct SQL injection payloads applied to a PHP–MySQL bulletin-board test environment. These payloads were grouped into four categories: Union-based (15), Boolean-based (15), Tautology-based (10), and Obfuscated (10) attacks. Each payload was injected under identical conditions for three defense methods (PDO, PVT, and ART), and outcomes were recorded as either blocked (attack prevented) or passed (attack succeeded). The test environment was built on PHP 8.2 and MySQL 8.0, executed on a Windows 11 host system using Apache 2.4. All defensive mechanisms were implemented in PHP with identical database schemas. Results presented in Table 2, Table 3 and

Table 4. Evaluation Results of SQL Injection Defense Techniques.

Technique	TP	FP	FN	FPR	Accuracy	Latency (ms)	Notes
PDO	50	0	0	0%	100%	+2–3	Strong structural defense
PVT	42	3	5	~6.7%	~91%	+5–6	Regex bypass possible
ART	38	0	12	0%	~88%	+1–2	Logging & deterrence only

are based on these repeated controlled runs, which allow for consistent comparison across defense techniques.

(2) Evaluation Criteria. The defense methods are assessed using well-established security metrics:

-

True Positives (TP): correctly detected and blocked attack attempts,

-

False Positives (FP): legitimate inputs incorrectly flagged as malicious,

-

False Negatives (FN): undetected injections that succeeded,

-

False Positive Rate (FPR): FP/(FP + TN),

-

Accuracy: (TP + TN)/(TP + FP + FN + TN), and

-

Latency: additional processing time (ms) introduced by each defense technique.

While our controlled experiments primarily reported blocking success rate, false positives, and performance impact (See Table 2), these can be naturally mapped to the above criteria. PDO consistently achieved TP = 100% with no observed FP, resulting in the highest accuracy and minimal latency. PVT showed strong results but produced occasional FP when legitimate inputs contained reserved SQL keywords, and a small number of FN due to obfuscated payloads. ART provided effective deterrence and logging with low latency, but FN occurred whenever queries bypassed pattern detection. Table 4 illustrates how our qualitative analysis can be reframed into these standard evaluation metrics, thereby aligning our comparative study with realistic baselines and reproducible security testing practices. The UNION-based authentication bypass example used in this study assumes a specific insecure authentication implementation: a query that retrieves a user row by userid (via string concatenation), followed by creation of a session based solely on the returned row (or omitting password verification). Under robust implementations (parameterized queries + server-side password-hash verification) this bypass does not succeed. See Appendix A for the vulnerable code example, the exact UNION payload used, and a secure implementation comparison. All attack tests were performed against a small controlled PHP–MySQL testbed that intentionally contained a vulnerable login implementation (see Appendix A). Each defense technique (PDO, PVT, ART) was evaluated against the same set of 50 payloads (Union, Boolean, Tautology, Obfuscated). Table 4 reports the observed TP/FP/FN counts from this single controlled run. We emphasize that the reported attack that yields admin authentication requires the vulnerable login logic shown in Appendix A and does not apply to implementations that correctly perform parameter binding and password hash verification. Authentication handling in the testbed was updated to use secure password storage and verification: passwords are stored using password_hash() (preferably PASSWORD_ARGON2ID, otherwise PASSWORD_BCRYPT) and verified with password_verify(). With PDO prepared statements combined with password_verify(), the UNION-style payloads used in our attack set cannot bypass authentication because injected data are treated as values and password verification requires the correct credential hash.

Values in this table represent approximate observations from a single controlled PHP–MySQL testbed. True-negative counts were not explicitly measured; FPR and accuracy are conceptual mappings from observed blocking behaviors. Latency is described qualitatively (“low additional processing time”) since hardware and system configuration details were not benchmarked. TP/FP/FN values in this table were recorded from a single controlled testbed run against an intentionally vulnerable PHP–MySQL bulletin-board implementation. The same set of 50 payloads was applied to each defense technique. The payload list and reproduction code are provided in Appendix A. Statistical generalization (multiple repeats and confidence intervals) is left for future work. The numerical results in Table 4 should be interpreted as comparative observations rather than strict quantitative benchmarks. Precise latency or confusion-matrix values would require multiple repetitions under fixed hardware, OS, and DBMS conditions, which are reserved for future extended experiments.

5. Conclusions

This study should therefore be understood as an educational comparative analysis rather than a proposal of new mechanisms, providing practical insights into how well-known defense methods perform in controlled PHP–MySQL environments. It also analyzed the risks posed by SQL Injection attacks, among the most prevalent and severe threats to web applications, and proposed effective countermeasures to mitigate them. SQL Injection exploits the communication interface between web applications and databases, enabling attackers to steal sensitive information or manipulate the system. It is widely recognized as a primary cause of numerous security breaches. To address this issue, we propose three core defense techniques. First, prepared statements using PDO were employed to secure the structure of SQL queries, thereby preventing structural injection attempts at their source. Second, an input pattern validation technique based on regular expressions was introduced to detect and block potentially malicious keywords during user input, such as in login procedures. Third, an attacker redirection method was implemented, which detects suspicious input and redirects the attacker to a decoy page, disrupting the attack flow and preventing further damage. Experimental results demonstrate that these techniques effectively block SQL Injection attacks, thereby enhancing the overall security and stability of web applications. However, web-based threats are continually evolving, with attackers employing new evasion methods and emerging attack vectors. Therefore, future research should focus on improving these defense mechanisms by integrating machine learning-based anomaly detection, incorporating Web Application Firewalls (WAFs), and developing automated security assessment tools. Additionally, it is essential to broaden the scope beyond SQL Injection and develop comprehensive security strategies capable of addressing other common web threats such as Cross-Site Scripting (XSS), Cross-Site Request Forgery (CSRF), and Server-Side Request Forgery (SSRF). It should be noted that the three defensive techniques investigated in this study (PDO, pattern-based verification, and redirection) are individually well-established in the literature. The novelty of our study lies not in the invention of new mechanisms, but in conducting a systematic comparative evaluation of these approaches under an identical experimental environment. The redirection technique, in particular, has often been considered a weak protection if deployed in isolation. Nevertheless, when positioned as part of a deception-based supplementary defense strategy, it contributes to misleading attackers, collecting attack traces, and supporting administrator response. Therefore, we position redirection not as a primary safeguard, but as an auxiliary measure complementing traditional SQL injection prevention methods. Although conceptually similar to frameworks such as JDBC or ORM system, our focus on the PHP–MySQL ecosystem addresses a context that remains dominant in small- to medium-scale and legacy web applications. The scientific contribution of this study is threefold: (i) providing a comparative evaluation under consistent experimental conditions, (ii) offering practical findings relevant to widely deployed PHP-based systems, and (iii) reframing auxiliary methods, such as redirection, within the broader context of deception-based defense strategies. In conclusion, this study presents practical and effective SQL Injection defense techniques that can serve as a strong foundation for establishing safer, more resilient, and trustworthy web environments. Future work should integrate emerging defense paradigms such as RASP and machine-learning-based anomaly detection, which provide runtime adaptability and automated learning capabilities. These techniques can extend our multi-layered defense model and further strengthen protection against novel SQL injection variants. The main contributions of this paper can be summarized as follows: (1) a systematic comparative evaluation of three standard SQL injection prevention mechanisms (PDO, PVT, and ART) under a consistent PHP–MySQL environment; (2) a practical interpretation of their respective advantages, limitations, and trade-offs; and (3) an educational perspective that supports secure-coding instruction and awareness in web-security curricula. Future research will extend this framework by incorporating machine-learning-based anomaly detection, runtime application self-protection (RASP), and automated vulnerability-testing pipelines for adaptive, real-time defense.