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

The user or attacker node represents external callers supplying input to the login endpoint. By submitting crafted SQL payloads such as ' OR '1'='1 alongside normal credentials, the attacker tests whether untrusted input can alter the downstream database query structure.

Login Form (Client Interface)

The login form provides the client interface for entering credentials and packaging HTTP request parameters. Before transmission over the wire, it serializes the username into a URL-encoded payload that the application server later decodes.

WAF (Web Application Firewall)

The Web Application Firewall (WAF) serves as a perimeter filter that inspects incoming HTTP traffic before it reaches the application. This visualization’s WAF checks raw wire bytes with a basic signature and does not URL-decode before matching, so it allows the encoded request through; the application later decodes it to a value containing OR. This illustrates a signature normalization gap rather than claiming that all WAFs miss encoded tokens.

App Server (Vulnerable Query Builder vs Parameterized Validator)

The app server URL-decodes the incoming request and selects a query construction path. In the vulnerable path, string concatenation merges the decoded input directly into the SQL command string. In the defended path, allowlist validation rejects malformed input early, and parameter binding sends the compiled SQL template and the decoded parameter value separately.

Database Engine

The database engine parses, compiles, and executes SQL queries for authentication and data retrieval. In the visualization, the concatenated statement alters the WHERE clause and returns a bypassed match, whereas the parameterized statement treats the decoded payload strictly as a literal string value and returns no match.

Audit Log

The audit log maintains a forensic trail of authentication attempts and database outcomes for detection and post-incident investigation. It records both the bypassed database outcome and the defended no-match outcome after each event reaches the logging sink. Logging supports investigation, though it does not prevent query execution on its own.

Least Privilege Role

The least-privilege database role enforces engine-level access control so the application connection can only touch authorized tables and operations. Restricting the database account to read-only SELECT permissions on the authentication view ensures that even if a query reaches the database, destructive operations like dropping tables are blocked.

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.