SQL Injection: Attack Techniques, Detection & Prevention

SQL Injection (SQLi) is a web security vulnerability that allows attackers to interfere with the queries a web application makes to its database. By inserting malicious SQL code into application inputs, attackers can read, modify, or delete database contents.

SQLi occurs when user input is concatenated directly into SQL queries without proper sanitization. For example, a login query like 'SELECT * FROM users WHERE username = '' + input + '' AND password = '' + input + ''' allows an attacker to inject SQL syntax that changes the query's logic.

The classic ' OR '1'='1' payload demonstrates the concept: injected into the username field, it modifies the WHERE clause to always be true, potentially bypassing authentication. This simple example reveals a fundamental flaw — the application treats user input as executable code.

SQL injection has been one of the most critical web vulnerabilities for over two decades. Despite being well-understood, it still appears in modern applications due to legacy code, developer inexperience, and the challenge of consistently parameterizing every database query.

In-band (Classic) SQLi returns results directly in the application's response. Union-based SQLi uses the UNION operator to combine results from the injected query with the original: ' UNION SELECT username, password FROM users--. Error-based SQLi extracts information from database error messages.

Blind SQLi does not return data directly. Boolean-based blind SQLi infers information by observing whether queries return true or false results (e.g., page loads differently). Time-based blind SQLi uses database delay functions (SLEEP, WAITFOR) to infer data one bit at a time.

Out-of-band SQLi uses alternative channels to extract data when direct responses are not available. The attacker might trigger DNS lookups or HTTP requests from the database server to an external server they control, carrying extracted data in the request.

Second-order SQLi stores malicious input in the database through one function and triggers it through another function that uses the stored data in a query. This delayed execution makes it harder to identify the vulnerable injection point.

Test every input point that interacts with the database: login forms, search fields, URL parameters, cookies, HTTP headers, and any place where user-supplied data could end up in a SQL query. Insert single quotes, double quotes, and SQL comment characters to observe responses.

SQLMap automates SQL injection detection and exploitation. Basic usage: 'sqlmap -u "http://target.com/page?id=1" --dbs' tests the 'id' parameter and attempts to enumerate databases. SQLMap supports all major database systems and injection techniques.

Manual testing provides deeper understanding. Use Burp Suite to intercept requests, modify parameters with SQL payloads, and analyze responses. Look for database error messages, behavioral differences, and time delays that indicate successful injection.

Common test payloads: single quote (') to break syntax, 'OR 1=1--' for authentication bypass, 'UNION SELECT null,null--' to determine column count, and '; SELECT SLEEP(5)--' for time-based blind testing. Adjust payloads for the specific database system (MySQL, MSSQL, PostgreSQL, Oracle).

Parameterized queries (prepared statements) are the primary defense. They separate SQL code from data, ensuring user input is always treated as data, never as executable SQL. Every modern programming language and database driver supports parameterized queries.

Stored procedures can reduce SQLi risk when used correctly. However, stored procedures built with dynamic SQL (string concatenation) are just as vulnerable. Only procedures that use parameterized inputs provide protection.

Input validation provides defense in depth. Validate data types (reject text in numeric fields), enforce length limits, use whitelists for expected values, and reject input containing SQL syntax characters. Never rely on input validation alone — always use parameterized queries.

Principle of least privilege: database accounts used by web applications should have only the minimum permissions needed. A read-only application account cannot execute INSERT, UPDATE, DELETE, or DROP commands even if injection is successful. Never use database admin accounts for application connections.