Security beginner LIVE DEMO
πŸ’‰

SQL Injection Attack Path

Walk through the SQL Injection lifecycle with guided steps for string concatenation, parameterized query, WAF, input validation, least privilege.

SQL injectionsecurityattackparameterized queriesWAFinput validationOWASPvisualization
Interactive Demo

Continue with the guided workspace

Use the paired workspace to connect this guide's mental model with live component state, visible signals, and the outcome each step or scenario is meant to prove.

SQL Injection (SQLi) is one of the most common and critical web application vulnerabilities. It occurs when untrusted user input is directly concatenated into a SQL statement, allowing an attacker to manipulate the query structure and execute arbitrary SQL commands.

Mental Model

Think of SQL execution like a recipe in a restaurant. Under a normal query (concatenation), the user writes their preferences directly into the instructions. If the user inputs "chocolate chips; burn down the kitchen", the chef (database) executes both instructions literally. Under a parameterized query, the instructions are printed on a laminated card with blank spaces. The chef only inserts user input into those blank spaces as raw ingredients. The instruction to "burn down the kitchen" is treated merely as a long name of an ingredient, never as a command to be executed.

For parameter-driven experiments, the SQL Injection Simulator sandbox is also available.

The 15-step visualization follows one encoded login request. It shows the WAF’s raw wire-byte signature limitation, its allow decision, application URL decoding, and unsafe string concatenation before tracing the bypass result and audit record. It then follows the decoded value through allowlist validation and a safe denial, and separately through parameter binding, least-privilege authorization, a no-match result, a generic response, and an audit record.

Components and Why They Exist

User / Attacker

Simulates the real-world actors, both legitimate users and malicious attackers, who supply input to the system. Inputs username/password values, which may contain normal text or malicious payloads like ' OR '1'='1. In the demo, observe how the attacker’s input travels to the backend to alter the database query structure.

Login Form (Client Interface)

Provides a user interface for entering credentials and capturing HTTP request parameters. Packages the URL-encoded username into an HTTP request. In the demo, observe the encoded payload on the wire before the application decodes it.

WAF (Web Application Firewall)

Serves as a perimeter defense that can inspect incoming traffic before it reaches the application. This visualization’s WAF checks raw wire bytes with a limited signature and does not URL-decode before matching. It therefore allows the encoded request; the application later decodes it to a value containing OR. This is a modeled signature limitation, not a claim that a WAF always permits or blocks that token.

App Server (Vulnerable Query Builder vs Parameterized Validator)

The core application logic layer URL-decodes the allowed request and then chooses a query construction path. In the vulnerable path, string concatenation merges the decoded value with SQL source. In the defended path, parameter binding sends the SQL template and decoded value separately; validation remains a distinct allowlist decision.

Database Engine

Provides persistence and handles query execution for authentication and data retrieval. Parses, compiles, and executes queries, returning the result set to the application server. In the visualization, the concatenated statement produces the bypassed result only when it reaches the database; the bound statement keeps the decoded payload as a value and produces no match.

Audit Log

Provides a forensic trail of database activities and security alerts for detection and post-incident investigation. Records the bypassed database outcome and the defended no-match outcome after each reaches the audit route. Logging supports investigation; it does not prevent execution.

Least Privilege Role

Enforces database-level access control, preventing a compromised application connection from accessing unauthorized tables. Restricts the database user account to the minimum necessary actions (e.g., read-only on the users table). In the demo, notice that even if SQL injection succeeds, restricted privileges prevent destructive actions like dropping tables.

Edge Cases and Misconceptions

  • Parameterized queries do not sanitize strings: A common misconception is that parameterization escapes or strips quotes. It does not. The database driver transmits the parameters separately from the SQL command structure using a binary protocol, so the engine never parses the parameters as SQL commands.
  • WAF coverage depends on normalization and signatures: The visualization models a WAF that matches raw wire bytes and does not URL-decode, so its signature misses the encoded request before the application decodes it. Real WAF behavior depends on its normalization, rules, and deployment; it is a defense-in-depth layer, not a replacement for parameter binding.
  • Least privilege is containment, not prevention: Limiting database permissions does not fix the SQLi vulnerability. It merely caps the maximum damage an attacker can do once they exploit it.

Common Questions

How does a parameterized query actually prevent SQL injection?

In a parameterized query (or prepared statement), the database engine compiles the SQL query structure first with placeholders. The user input is then bound to these placeholders as raw data values. Since the compilation step has already occurred, the database will never execute any SQL commands contained in the input data.

What is the difference between Classic SQL Injection and Blind SQL Injection?

In classic SQL injection, the database returns errors or data directly in the HTTP response. In blind SQL injection, the application does not return data or error messages directly; the attacker must infer database contents by asking true/false questions and observing differences in the application's response (e.g., changes in page content or timing delays).

Why is input sanitization/escaping considered inferior to parameterized queries?

Input sanitization tries to block or escape 'bad' characters (like quotes). However, attackers constantly discover new bypass methods, and different databases use different escape sequences. Parameterization is robust because it bypasses the need for escaping entirely by separating the code execution from data variables at the protocol level.

Why is mTLS or SSL/TLS not a defense against SQL injection?

SSL/TLS encrypts data in transit between the client and the server, protecting it from eavesdroppers. However, it does not validate or clean the contents of the payload. Once the server decrypts the traffic, it will execute the malicious payload exactly as if it were sent over plain HTTP.

What is the role of database-specific SQL injection?

Different database engines (MySQL, PostgreSQL, SQL Server, Oracle) use different SQL dialects, comment characters, and built-in functions. Attackers tailor their payloads to the specific database running behind the application to perform operations like database fingerprinting or command execution.

Can SQL injection occur in SELECT queries only?

No. SQL injection can occur in any query type, including INSERT, UPDATE, and DELETE statements. For instance, injecting into an UPDATE statement could allow an attacker to modify passwords or update another user's profile details.