SQL Injection

ID

sql_injection

Severity

critical

Kind

Injection

CWE

89

Description

SQL Injection (SQLi) is a web security vulnerability that allows an attacker to interfere with the queries an application makes to its database by injecting malicious SQL code through user-controllable input. It occurs when user-supplied data is incorporated into SQL queries using string concatenation or other unsafe methods, without proper sanitization or parameterization. This allows the attacker to break out of the intended data context, modify the structure of the query, and execute arbitrary SQL statements against the database.

Rationale

An attacker exploits SQL Injection by supplying crafted input — through form fields, URL parameters, cookies, or HTTP headers — that alters the logic of the underlying SQL query, enabling techniques such as UNION-based extraction, blind inference attacks, or out-of-band data exfiltration. A successful exploit can allow the attacker to bypass authentication, read sensitive data belonging to other users, modify or delete database records, execute administrative operations on the database server, and in some cases escalate to remote command execution on the underlying operating system. Because of this breadth of impact — from complete data breach to full system compromise — SQL Injection is consistently rated among the most critical web application vulnerabilities.

Remediation

  • Use parameterized queries (a.k.a. prepared statements). This is the most effective defense against SQL Injection. Ensure that all database queries use bind parameters instead of string concatenation. In Java JDBC, use PreparedStatement or CallableStatement with ? placeholders. In ASP/ADO, use Command Objects with strong type checking.

  • Never build SQL queries by concatenating user input. Avoid constructing dynamic SQL using string concatenation in application code or within stored procedures. Do not use exec, exec immediate, or equivalent dynamic execution functions with unsanitized input.

  • Apply the principle of least privilege. Connect to the database using an account with the minimum permissions required by the application. Never use administrative accounts such as sa or db-owner for routine application queries. This does not prevent SQL Injection, but it significantly limits the damage an attacker can cause.

For defense in-depth, or when dynamic SQL is really necessary because parameterized SQL is not possible, you may consider additional strategies:

  • Validate and sanitize all input on the server side. Do not rely on client-side validation alone. Apply strict type checking for all incoming data. Use an allow-list of permitted values or characters where possible, or a deny-list to reject known dangerous characters. Deny-list should be only the last option.

  • Escape user-supplied data. When parameterized queries are not feasible (e.g., for dynamic table or column names), apply context-appropriate escaping for all data received from the client.

References