What is SQL Injection (SQLi)? | NOC.org

Understanding SQL Injection

SQL Injection (SQLi) is a code injection attack that exploits vulnerabilities in an application's database layer. It occurs when user-supplied input is included directly in SQL queries without proper sanitization or parameterization. An attacker can manipulate the SQL query to read, modify, or delete data, bypass authentication, or even execute operating system commands on the database server.

SQL injection has been one of the most critical web application vulnerabilities for over two decades and consistently ranks at the top of the OWASP Top 10. Despite being well understood and entirely preventable, SQLi remains common because developers continue to build queries using string concatenation with unsanitized user input.

How SQL Injection Works

Consider a login form that checks credentials with the following SQL query built using string concatenation:

SELECT * FROM users WHERE username = '$username' AND password = '$password'

If a user enters a normal username and password, the query works as intended. But if an attacker enters the following as the username:

' OR '1'='1' --

The resulting query becomes:

SELECT * FROM users WHERE username = '' OR '1'='1' --' AND password = ''

The OR '1'='1' condition is always true, and the -- comments out the rest of the query. The database returns all rows from the users table, and the application logs the attacker in as the first user, which is often the administrator.

Types of SQL Injection

In-Band SQLi (Classic)

In-band SQL injection is the most common type, where the attacker uses the same communication channel to launch the attack and receive results. There are two sub-types:

• Error-based SQLi: The attacker sends input that causes the database to produce error messages containing information about the database structure. These error messages reveal table names, column names, and data types.
• UNION-based SQLi: The attacker uses the UNION SQL operator to combine the results of the original query with results from a query of their choosing, extracting data from other tables in the database.

Blind SQLi

Blind SQL injection occurs when the application does not display database errors or query results to the user. The attacker must infer information by observing the application's behavior:

• Boolean-based blind: The attacker sends queries that evaluate to true or false and observes whether the application responds differently. By asking a series of yes/no questions, the attacker can extract data one bit at a time.
• Time-based blind: The attacker sends queries that cause the database to pause for a specified number of seconds. By measuring response times, the attacker determines whether conditions are true or false. For example: IF(1=1, SLEEP(5), 0).

Out-of-Band SQLi

Out-of-band SQL injection uses a different channel to extract data, such as DNS lookups or HTTP requests initiated by the database server. This technique is used when in-band and blind methods are impractical, typically requiring the database server to have outbound network access.

Impact of SQL Injection

The consequences of a successful SQL injection attack can be severe:

• Data breach: Attackers can read the entire contents of the database, including user credentials, personal information, financial records, and proprietary data.
• Authentication bypass: Login forms vulnerable to SQLi can be bypassed entirely, granting the attacker administrative access.
• Data modification: Attackers can insert, update, or delete records, corrupting business data or creating fraudulent accounts.
• Privilege escalation: In some database configurations, SQL injection can be used to create new database users with elevated privileges.
• Remote code execution: Certain database features (such as SQL Server's xp_cmdshell or MySQL's LOAD_FILE) can be abused through SQL injection to execute operating system commands.

Preventing SQL Injection

Parameterized Queries (Prepared Statements)

The most effective defense against SQL injection is using parameterized queries, also called prepared statements. Instead of concatenating user input into the SQL string, you define the query structure with placeholders and pass the user input as separate parameters. The database treats the parameters as data, not executable SQL code.

Example in PHP with PDO:

$stmt = $pdo->prepare('SELECT * FROM users WHERE username = :username AND password = :password');
$stmt->execute(['username' => $username, 'password' => $password]);

Even if the attacker submits ' OR '1'='1' -- as the username, the database treats the entire string as a literal value to compare against, not as part of the SQL syntax.

Stored Procedures

Stored procedures can provide protection when implemented correctly, but they are not automatically safe. If a stored procedure uses dynamic SQL with string concatenation internally, it is still vulnerable to injection.

Input Validation

Validate all user input against expected types and patterns. If a field expects a numeric ID, ensure the input contains only digits. While input validation alone is not sufficient to prevent SQL injection, it adds an important layer of defense.

Least Privilege

Configure database accounts used by your application with the minimum necessary permissions. A web application should not connect to the database as root or with permissions to drop tables, create users, or execute system commands. Limiting database privileges reduces the impact if an injection vulnerability is exploited.

WAF Rules

A Web Application Firewall detects common SQL injection patterns in HTTP requests and blocks them before they reach your application. WAF rules identify SQL keywords, operators, and encoding tricks in request parameters. While a WAF provides an important safety net, it should complement proper coding practices, not replace them. Skilled attackers can sometimes craft payloads that evade WAF signatures.

Summary

SQL injection is one of the oldest and most dangerous web vulnerabilities, but it is also one of the most preventable. Using parameterized queries consistently throughout your application eliminates the root cause of SQLi entirely. Combined with input validation, least-privilege database accounts, and WAF protection, you can effectively defend your application against this pervasive class of attacks.