Gemini on Question 19, Sep 21

To effectively brief your developers on SQL Injection (SQLi), it helps to categorize the attacks based on how the attacker retrieves the data from the database.

Industry standards (like OWASP) generally divide SQL Injection into three main classes, plus a fourth behavioral class that developers frequently overlook.

Here is a breakdown you can use for your briefing:

1. In-Band SQLi (Classic SQLi)

This is the most common and easiest type of SQL injection to exploit. "In-Band" means the attacker uses the same communication channel to launch the attack and gather the results (e.g., they submit a payload via a web form and see the stolen data directly on the web page).

There are two primary sub-types:

• •Error-Based SQLi: The attacker intentionally inputs bad syntax to force the database to generate an error message. If the application displays these database errors to the user, the attacker can use the information (like table names, column types, or database versions) to map out the database structure.
• •Union-Based SQLi: The attacker uses the UNION SQL operator to combine the results of the application's legitimate query with the results of their own malicious query. The application then returns the combined data to the attacker’s screen.

2. Inferential SQLi (Blind SQLi)

In a "Blind" SQLi, the application is secure enough not to display database errors or raw data on the screen, but it still executes the injected payload. Because the attacker cannot see the data directly, they must reconstruct it piece by piece by asking the database a series of True/False questions.

There are two sub-types:

• •Boolean-Based (Content-Based) Blind SQLi: The attacker sends a SQL query that forces a TRUE or FALSE condition (e.g., "Is the first letter of the admin's password an 'A'?"). They then observe the web page's response. If the page loads normally, the answer is TRUE. If a generic "item not found" or slight variation of the page appears, the answer is FALSE.
• •Time-Based Blind SQLi: If the application returns the exact same web page regardless of a TRUE/FALSE outcome, the attacker relies on time. They inject a command like SLEEP(10) or WAITFOR DELAY '0:0:10'. They ask the same True/False question, but append: "If TRUE, sleep for 10 seconds." If the web page takes 10 seconds to load, the attacker knows the answer is TRUE.

3. Out-of-Band (OOB) SQLi

This is the rarest type of SQLi. It occurs when an attacker cannot use the same channel to get the data (In-Band), and Time-Based attacks are impossible (e.g., the query is executed asynchronously in a background job).

Instead, the attacker injects a payload that forces the database server itself to make an external network connection (via DNS or HTTP) to a server controlled by the attacker.

• •Example: The database takes the admin password, appends it to a URL (http://password123.attacker.com), and makes a DNS request. The attacker looks at their DNS logs and extracts the password.
• •Note: This relies on specific database features being enabled (like xp_cmdshell in SQL Server or UTL_HTTP in Oracle).

4. Second-Order SQLi (Stored SQLi)

You should highly emphasize this one to your developers, as it bypasses many basic security checks.

In a Second-Order SQLi, the injected payload is not executed immediately.

• 1.First order: The attacker submits a malicious payload (e.g., creating a username like ' OR 1=1 --). The application safely escapes this and stores it in the database.
• 2.Second order: Later, a different part of the application retrieves that username from the database and uses it in a new SQL query without parameterizing it, assuming that data already in the database is "safe." The payload executes.

How to Instruct Your Developers to Prevent These

To wrap up the briefing, give them the bottom line: You do not need different defenses for different classes of SQLi. The defenses for all of them are the same:

• 1.Primary Defense: Prepared Statements (Parameterized Queries). This forces the database to treat user input as raw data (a string), never as executable code, neutralizing 99% of SQLi attempts.
• 2.Use Object-Relational Mapping (ORMs) Safely: Tools like Entity Framework, Hibernate, or Prisma generally use parameterized queries by default, but developers must be warned against using "raw query" escape hatches improperly.
• 3.Input Validation (Allow-listing): If user input dictates table names or column names (which usually cannot be parameterized), validate the input against a strict list of allowed values.
• 4.Zero Trust for Stored Data: Remind them to prevent Second-Order SQLi by using parameterized queries even when querying data that originated from your own database.
• 5.Principle of Least Privilege: The database user the application connects with should only have the bare minimum permissions required. It should not be able to drop tables or make outbound network requests (mitigating OOB SQLi).