Gemini on Question 19, Sep 25

Here is a breakdown of the general classes of SQL Injection (SQLi) designed specifically for briefing a development team.

When talking to developers, it is helpful to categorize SQLi by how the attacker extracts the data. While the root cause (untrusted user input concatenated into a query) is always the same, understanding these classes helps developers realize how attackers can steal data even when no data is visibly returned to the screen.

There are three primary classes of SQL Injection: In-Band, Inferential (Blind), and Out-of-Band (OOB).

1. In-Band (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. If they send the payload via an HTTP request, the stolen data comes right back in the HTTP response.

There are two main sub-types:

• •Error-Based SQLi: The attacker intentionally inputs bad syntax to force the database to throw an error.
• •Why they do it: Default database errors are often highly verbose and will reveal table names, column names, or the specific database version (e.g., MySQL vs. MS SQL). This helps the attacker map the database before launching a targeted attack.
• •Union-Based SQLi: The attacker uses the UNION SQL operator to combine the results of their injected query with the results of the legitimate query.
• •Example: If a search bar runs SELECT name, description FROM products WHERE name = 'input', the attacker inputs ' UNION SELECT username, password FROM users--. The application will then display the usernames and passwords right on the webpage alongside the products.

2. Inferential (Blind) SQLi

Blind 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.

Because the attacker cannot see the data directly, they must play a game of "20 Questions" with the database, asking true/false questions and observing how the application behaves. This takes longer but is just as dangerous.

There are two main sub-types:

• •Boolean-Based (Content-Based) Blind SQLi: The attacker sends an SQL query that forces the application to return a different result depending on whether the query returns TRUE or FALSE.
• •Example: An attacker wants to know if the admin's password starts with 'A'. They inject: id=1 AND (SELECT SUBSTRING(password,1,1) FROM users WHERE username='admin') = 'A'.
• •If the page loads normally, the answer is TRUE. If the page loads missing some content or says "Item not found," the answer is FALSE. They repeat this byte-by-byte to steal the whole password.
• •Time-Based Blind SQLi: If the page content doesn't change based on true/false conditions, the attacker relies on response times. They inject an SQL command that tells the database to pause (sleep) if a condition is true.
• •Example: id=1; IF (SELECT SUBSTRING(password,1,1) FROM users WHERE username='admin') = 'A' WAITFOR DELAY '0:0:5'--
• •If the HTTP response takes 5 seconds to load, the attacker knows the first letter is 'A'. If it loads instantly, they move on to 'B'.

3. Out-of-Band (OOB) SQLi

Out-of-Band SQLi is rare but highly critical. It occurs when an attacker cannot use the same channel to launch the attack and gather results (perhaps the query happens in an asynchronous background job), and server responses are too unstable for Blind SQLi.

• •How it works: The attacker crafts a payload that forces the database server itself to make an external network request (usually DNS or HTTP) to a server the attacker controls, sending the stolen data inside that request.
• •Example: The attacker injects a command forcing the database to look up a web address containing the stolen data, such as: http://<admin_password>.attacker-controlled-server.com. The attacker checks their own server logs, sees the DNS request, and extracts the password.
• •Note: This relies on the database having features enabled that allow it to make external network requests (like xp_cmdshell in MS SQL or UTL_HTTP in Oracle).

The Developer Takeaway (How to Defend)

While it is fascinating to see the different ways attackers manipulate databases, the primary defense for all three classes is exactly the same.

You should emphasize these rules to your developers:

• 1.Use Parameterized Queries (Prepared Statements): This is the silver bullet. Parameterization forces the database to treat user input as data (a literal value) rather than executable code. If an attacker inputs ' UNION SELECT..., the database will literally look for a user named ' UNION SELECT... and fail safely.
• 2.Use Modern ORMs safely: Most Object-Relational Mappers (like Entity Framework, Hibernate, or Prisma) use parameterization by default. However, warn developers to avoid "raw query" escape hatches in ORMs unless absolutely necessary, and to parameterize those as well.
• 3.Implement Least Privilege: The database user account used by the web application should only have access to the tables it absolutely needs. It should never have DBA/sa privileges, and features allowing external network calls (disarming OOB attacks) should be disabled.
• 4.Generic Error Messages: Ensure the application catches database errors and returns generic, user-friendly messages (e.g., "An error occurred") rather than raw stack traces (disarming Error-Based attacks).