Gemini on Question 18, Oct 3

SQL injection (SQLi) occurs when an application takes user input and passes it directly to a database without proper validation or parameterization. This allows an attacker to manipulate the input to interfere with the structure of the database query, potentially leading to unauthorized data access, modification, or deletion.

When briefing developers, it is helpful to categorize SQL injection into three main classes based on how the data is extracted or how the vulnerability is observed.

1. In-Band (Classic) SQLi

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

• •Error-Based SQLi: This occurs when the database returns detailed error messages directly to the application interface. If a developer concatenates input into a query and the input contains a syntax error (like an unescaped quote), the database may throw an error revealing information about its structure, table names, or the exact query executed.
• •Union-Based SQLi: This technique leverages the UNION SQL operator. An attacker injects a UNION SELECT statement into the original query, allowing them to append the results of their own injected query to the results returned by the application. This requires the injected query to have the same number of columns and compatible data types as the original query.

2. Inferential (Blind) SQLi

Inferential SQLi occurs when the application is vulnerable to SQL injection, but its HTTP responses do not contain the results of the relevant SQL query or any database errors. The attacker cannot see data directly; instead, they must infer the data bit-by-bit by observing how the application behaves in response to different conditions.

• •Boolean-Based (Content-Based) Blind SQLi: The attacker injects SQL statements that ask the database a TRUE or FALSE question. If the application's response changes depending on whether the injected condition is true or false (e.g., a "User found" message vs. a generic "Not found" page), the attacker can deduce the data one character at a time.
• •Time-Based Blind SQLi: If the application does not change its output based on TRUE/FALSE conditions, an attacker can inject commands that instruct the database to pause (e.g., using SLEEP() or WAITFOR DELAY) before responding. By measuring the time it takes the server to respond, the attacker can infer whether the injected condition was true or false.

3. Out-of-Band (OOB) SQLi

Out-of-band SQLi is less common and relies on the database server's ability to make external network requests (such as DNS or HTTP requests). This technique is typically used when in-band techniques fail and the server's responses are not reliable enough for inferential techniques.

• •In this scenario, the attacker injects a payload that forces the database server to transmit the data they want to exfiltrate to a server they control. For example, the injected query might concatenate a database password into a domain name and force the database to perform a DNS lookup for that domain, effectively sending the password to the attacker's DNS server.

Defensive Takeaways for Developers

When briefing the team, the primary takeaway regarding mitigation should be that all of these classes stem from the same root cause: untrusted data altering query logic.

The standard defense against all forms of SQL injection is the consistent use of parameterized queries (prepared statements). Parameterization ensures the database treats the user input strictly as data (a literal value) and never as executable code, neutralizing the injection regardless of which class the attacker attempts to use. Additionally, Object-Relational Mapping (ORM) frameworks often use parameterized queries by default, though developers must still ensure they are not using raw, unparameterized queries within the ORM.