Here is a clear, structured breakdown of the general classes of SQL Injection (SQLi) designed specifically to brief a development team.
When briefing your developers, it is helpful to frame SQLi not just as "bad input," but as an attacker successfully tricking the database interpreter into treating *data* as executable *code*.
Historically and technically, SQL Injection is divided into three primary classes based on how the attacker retrieves the data from the database.
---
### 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. If a web page is vulnerable, the stolen data is displayed directly on that web page.
There are two main sub-types of In-Band SQLi:
* **Error-Based SQLi:**
* **How it works:** The attacker intentionally inputs characters (like a single quote `'`) that cause the database to generate a SQL syntax error.
* **The goal:** If the application is misconfigured, it will display the raw database error on the web page. These errors often leak valuable information, such as the database type (MySQL, MSSQL), version, or even table and column names.
* **Developer Takeaway:** Never display raw database errors to the end-user in a production environment. Use generic error messages.
* **Union-Based SQLi:**
* **How it works:** The attacker leverages the SQL `UNION` operator. This operator combines the results of two or more `SELECT` statements into a single result set.
* **The goal:** The attacker appends a malicious query to the legitimate query. If the application expects to display a user's profile, the attacker uses `UNION` to append the usernames and passwords from the admin table, forcing the application to display them on the screen.
* **Example Payload:** `SELECT name, email FROM users WHERE id = 1 UNION SELECT username, password FROM admin_users--`
### 2. Inferential SQLi (Blind SQLi)
In a "Blind" SQL injection, the application is secure enough *not* to display database errors or raw data on the screen, but it is still executing the attacker's injected SQL. Because the attacker cannot see the results directly, they must extract data by asking the database a series of True/False questions.
This takes longer, but modern automated tools (like SQLmap) can extract entire databases this way.
* **Boolean-Based (Content-Based) Blind SQLi:**
* **How it works:** The attacker injects a SQL query that forces the database to evaluate a True or False condition.
* **The goal:** The attacker observes if the HTTP response (the web page content) changes based on whether the condition was true or false.
* **Example:** If injecting `id=1 AND 1=1` loads the page normally, but `id=1 AND 1=2` results in a "404 Not Found" or a missing element on the page, the attacker knows the injection works. They can then ask: `id=1 AND (SELECT SUBSTRING(password, 1, 1) FROM admin) = 'a'`. If the page loads normally, they know the first letter of the password is 'a'.
* **Time-Based Blind SQLi:**
* **How it works:** Sometimes a web page looks exactly the same regardless of whether a query is True or False. In this case, the attacker injects a command that forces the database to wait (sleep) for a specific amount of time *only if a condition is true*.
* **The goal:** The attacker measures how long the server takes to respond. If the page takes 10 seconds to load, the condition was true. If it loads instantly, the condition was false.
* **Example:** `id=1; IF (SELECT user) = 'sa' WAITFOR DELAY '0:0:10'--` (If the database user is 'sa', pause for 10 seconds).
### 3. Out-of-Band (OOB) SQLi
This is the rarest and most complex form of SQLi. It occurs when an attacker cannot use the same channel to launch the attack and gather information (e.g., the server is too slow for Blind SQLi, or the results aren't returned at all).
* **How it works:** The attacker injects SQL that forces the database server itself to make a network request (usually via DNS or HTTP) to a server controlled by the attacker.
* **The goal:** The stolen data is appended to that network request.
* **Example:** The attacker injects code that tells the database to perform a DNS lookup for a website. They format the query so the database looks up `<admin_password>.attacker.com`. The attacker checks their own DNS server logs, sees the request, and extracts the password.
* **Note:** This relies on specific database features being enabled (e.g., `xp_dirtree` in Microsoft SQL Server, or `UTL_HTTP` in Oracle).
---
### The "How to Fix It" Briefing for Developers
Understanding the classes is great for threat modeling, but prevention is universal. You can give your developers these three cardinal rules to prevent *all* classes of SQL injection:
1. **Use Prepared Statements (Parameterized Queries):** This is the ultimate defense. Instead of concatenating strings to build a query, prepared statements send the SQL code and the user data to the database *separately*. The database treats the user input strictly as data, making it impossible for it to be executed as code.
2. **Use Stored Procedures or ORMs:** Object-Relational Mapping frameworks (like Entity Framework, Hibernate, or Prisma) generally use parameterized queries by default.
3. **Implement the Principle of Least Privilege (PoLP):** The database user account that the web application uses should only have the bare minimum permissions required. It should not be a database admin (`sa` or `root`). It should not have the ability to execute shell commands, read local files, or make external network calls (which mitigates Out-of-Band attacks).