SQL Injection (SQLi)

Description

SQL Injection is a critical web application vulnerability where attackers manipulate user input to alter SQL queries sent to a database. By inserting or "injecting" malicious SQL statements into input fields, attackers can access or modify data far beyond their intended privileges. In severe cases, SQL Injection can lead to complete database compromise, data exfiltration, or even system-level access if the database is integrated with other server components.

This vulnerability typically arises when user input is concatenated directly into a query string without proper sanitization or parameterization. Applications that rely on string manipulation to build SQL statements are especially prone to SQL Injection if they fail to validate and escape user inputs.

Examples

Basic Injection Through Form Input

A typical vulnerable login query might look like this in pseudocode:

SELECT * FROM users WHERE username = 'USER_INPUT' AND password = 'USER_INPUT';

If the application simply places the user's input into the query, an attacker can inject special characters:

  • Username: admin'--
  • Password: anything

Which results in a query:

SELECT * FROM users WHERE username = 'admin'--' AND password = 'anything';

The -- comment syntax causes the password check to be ignored, potentially granting unauthorized access if the record for "admin" exists.

UNION-Based Injection

Attackers can also use the UNION keyword to fetch data from other tables. For example, if the application runs:

SELECT name, email FROM users WHERE id = '$ID';

An attacker might provide a parameter like:

1 UNION SELECT credit_card_number, security_code FROM creditcards

leading to a query:

SELECT name, email 
FROM users 
WHERE id = '1 UNION SELECT credit_card_number, security_code FROM creditcards';

Depending on error messages or the way results are rendered, the attacker may extract sensitive data, such as credit card numbers or other protected fields.

Error-Based Injection

Some databases and configurations return error messages revealing detailed SQL engine responses. Attackers can use these messages to refine their injection attempts and glean information about the database schema:

?id=1'

If the server responds with a syntax error mentioning table or column names, the attacker can adjust the query systematically to discover the structure of the database and plan further injections.

Remediation

  1. Use Parameterized Queries (Prepared Statements)

    • Leverage parameterized queries in your application code to ensure user input is treated strictly as data rather than executable SQL.
    • Most modern libraries (e.g., PDO in PHP, PreparedStatement in Java, parameterized queries in .NET or Python) provide robust support for secure query parameterization.

  2. Input Validation and Escaping

    • Validate user input against expected formats (e.g., numeric IDs, specific character sets) before sending to the database.
    • Use context-appropriate escaping for any dynamic SQL components that cannot be avoided (e.g., table names in some dynamic queries).

  3. Least Privilege Principle

    • Configure the database account used by the application to have only the necessary permissions (SELECT, UPDATE on specific tables).
    • Avoid using database accounts with root or admin privileges for routine application queries.

  4. Secure Error Handling

    • Do not display detailed SQL errors or stack traces to end-users.
    • Log detailed errors server-side for debugging but show generic error messages on the client side.