SQL Injection
CWE-89: Improper Neutralization of Special Elements used in an SQL Command ('SQL Injection')
SQL injection occurs when user input is concatenated into a database query, so characters such as quotes and comment markers change the structure of the query instead of being treated as data. Depending on the database and the privileges of the application account, an attacker can read or modify any table, bypass login checks, and in some configurations reach the file system or execute operating system commands. Blind variants infer data one bit at a time from true or false responses or from time delays when no output is shown.
Ranks change between editions as the underlying CVE data changes, so exam questions rarely hinge on an exact rank. Know what each weakness is, how it is exploited, and how it is prevented.
How it shows up in the real world
- A login form builds WHERE username = '<input>' AND password = '<input>', so entering ' OR '1'='1' -- as the username logs in as the first user in the table.
- A product filter parameter accepts a UNION SELECT payload that returns usernames and password hashes inside the product listing.
- A sort-order parameter is placed directly into an ORDER BY clause, which cannot be parameterized, and is used for time-based blind extraction.
How to mitigate it
- Use parameterized queries or prepared statements for every query, so input is always bound as data and never parsed as SQL.
- Where identifiers such as column names must vary, map user choices to an allow-list of fixed values rather than inserting the input.
- Run the application under a least-privilege database account with no rights to drop tables, read system catalogs, or execute OS commands.
- Return generic error messages so database errors do not reveal query structure, and monitor for injection patterns with a WAF as a secondary control.
Go deeper
Practice this topic
Test your knowledge of SQL Injection with exam-style practice questions.