Gemini on Question 18, Sep 28

SQL injection (SQLi) occurs when an application improperly sanitizes user input, allowing that input to alter the structure of a backend database query. The database engine then executes the modified query, treating the attacker's input as executable code rather than data.

For a developer briefing, it is useful to categorize SQL injection into three main classes based on how the injected data is retrieved or how the vulnerability is observed.

1. In-Band (Classic) SQLi

In-band SQL injection is the most common and straightforward class. It occurs when the attacker uses the same communication channel to both launch the attack and gather the results.

• •Error-Based SQLi: The attacker intentionally injects syntax that forces the database to generate an error. If the application is configured to display verbose database errors to the user, the attacker can use the information in the error message (such as table names, column names, or database version) to map out the database structure and construct further attacks.
• •Union-Based SQLi: This technique leverages the SQL UNION operator. If an application returns the results of a SELECT query directly to the web page, an attacker can append a UNION SELECT statement. This forces the database to combine the results of the original, legitimate query with the results of a new query crafted by the attacker, displaying the exfiltrated data directly on the page.

2. Inferential (Blind) SQLi

Inferential SQL injection occurs when the application is vulnerable to SQLi, but its HTTP responses do not contain the results of the relevant SQL query or any database errors. Because the data is not returned in-band, the attacker must send specific payloads and observe the application's behavior to infer the structure and contents of the database, typically on a true/false basis (one character at a time).

• •Boolean-Based (Content-Based) Blind SQLi: The attacker sends SQL queries designed to evaluate to either TRUE or FALSE. Even though no data is returned, the application might behave differently depending on the result. For example, a TRUE query might load a user profile, while a FALSE query might result in a generic "User not found" message or subtle differences in the page's HTML structure. By observing these differences, the attacker infers the result of the injected query.
• •Time-Based Blind SQLi: When an application does not exhibit varying behavior based on TRUE/FALSE conditions, an attacker can use time-based techniques. The injected payload includes a database command that instructs the engine to pause or sleep for a specific duration (e.g., 10 seconds) if a certain condition is met. The attacker then measures the time it takes for the server to respond. If the response is delayed by 10 seconds, the condition is inferred to be TRUE.

3. Out-of-Band (OOB) SQLi

Out-of-band SQL injection is less common and relies on specific features being enabled on the database server. It is typically used when an attacker cannot use the in-band channel (e.g., the application does not return data) and inferential techniques are too slow or unstable.

In an OOB attack, the injected payload commands the database server itself to initiate a secondary, out-of-band network connection (such as a DNS lookup or an HTTP request) to a server controlled by the attacker. The attacker appends the data they wish to steal into this external request (e.g., a DNS request for [password_hash].attacker.com). This class depends heavily on the specific database software (e.g., xp_cmdshell in Microsoft SQL Server, or specific Oracle packages).

Defensive Briefing Points

When discussing these classes with developers, the key takeaway is that the vulnerability mechanism (untrusted data modifying query logic) is the same across all classes. The classes only differ in how the results are extracted.

The primary defense against all forms of SQL injection is separating the data from the query structure:

• •Prepared Statements (Parameterized Queries): This is the most effective defense. It forces the database to treat user input strictly as data, neutralizing any SQL syntax contained within it.
• •Object-Relational Mapping (ORM): Modern ORMs often use parameterized queries by default, though developers must be cautious when writing custom or complex queries within the ORM framework.