Here is a structured, developer-focused briefing on the general classes of SQL Injection (SQLi). You can use this as an agenda or hand it directly to your team.
***
# Briefing: Understanding SQL Injection (SQLi) Classes
**The Core Concept:** SQL Injection occurs when untrusted user input is concatenated directly into a database query, allowing the input to alter the structure and logic of the SQL statement.
To defend against SQLi, we must understand how attackers categorize and exploit these vulnerabilities. In the cybersecurity industry, SQLi is divided into three primary classes based on **how the attacker retrieves the data**.
---
## Class 1: In-Band (Classic) SQL Injection
This is the most common and easiest type of SQLi to exploit. "In-Band" means the attacker uses the **same communication channel** to launch the attack and gather the results. (e.g., they send the payload via an HTTP request and see the stolen data in the HTTP response).
There are two main sub-types:
### A. Error-Based SQLi
* **How it works:** The attacker inputs characters (like a single quote `'`) designed to break the SQL syntax. They rely on the application returning verbose database error messages to the screen.
* **Why it's dangerous:** These error messages often reveal the database type, version, table names, or column structures, giving the attacker a blueprint of our database.
* **Developer Takeaway:** Never expose raw database errors or stack traces to the end-user in a production environment.
### B. Union-Based SQLi
* **How it works:** The attacker uses the SQL `UNION` operator to combine the results of the original, legitimate query with the results of an injected, malicious query.
* **Example:** If a product search query is `SELECT name, description FROM products WHERE id = [INPUT]`, the attacker inputs `1 UNION SELECT username, password FROM users`. The page will render the usernames and passwords as if they were products.
* **Developer Takeaway:** If input alters the query structure, attackers can extract entirely unrelated tables and display them on the frontend.
---
## Class 2: Inferential (Blind) SQL Injection
Developers often mistakenly believe that if an application does not display database errors or raw data on the screen, it is safe from SQLi. **This is false.**
In Blind SQLi, the attacker cannot see the data directly. Instead, they reconstruct the data character-by-character by asking the database a series of True/False questions (like playing a game of "20 Questions").
### A. Boolean-Based (Content-Based) Blind SQLi
* **How it works:** The attacker sends an SQL query that forces the database to evaluate a True/False condition. They then observe if the web page loads differently based on the result.
* **Example:** The attacker injects: `AND (SELECT SUBSTRING(password, 1, 1) FROM users WHERE username = 'admin') = 'a'`.
* If the page loads normally, the condition is TRUE (the first letter of the password is 'a').
* If the page returns a "404 Not Found" or is missing data, the condition is FALSE. They move on to 'b'.
* **Developer Takeaway:** Even subtle differences in HTTP responses or page content can be automated by attacker tools (like SQLmap) to dump entire databases.
### B. Time-Based Blind SQLi
* **How it works:** If the application returns the exact same web page regardless of whether a query is True or False, the attacker uses database pause commands (e.g., `SLEEP(10)` in MySQL or `WAITFOR DELAY` in MSSQL).
* **Example:** The attacker injects: `IF (SELECT SUBSTRING(password,1,1) FROM users WHERE username='admin')='a' WAITFOR DELAY '0:0:10'`.
* If the server takes 10 extra seconds to respond, the attacker knows the letter is 'a'.
* **Developer Takeaway:** Attackers can extract data based solely on how long the server takes to process the HTTP request.
---
## Class 3: Out-of-Band (OOB) SQL Injection
This is the rarest class and is only used when In-Band and Inferential techniques fail (for example, if the query is executed asynchronously in a background job, or the server is too slow for Time-Based attacks).
* **How it works:** The attacker injects a payload that forces the database server itself to make a network connection (usually DNS or HTTP) to a server controlled by the attacker. They append the stolen data to the network request.
* **Example:** The attacker injects a command forcing the database to perform a DNS lookup for `<stolen_password>.attacker-controlled-domain.com`. The attacker checks their DNS logs and sees the password.
* **Developer Takeaway:** Databases should not have unrestricted outbound internet access. (This is an infrastructure/DevOps control, but developers should be aware).
---
## 🛑 How We Mitigate SQL Injection (Developer Action Items)
To completely neutralize all three classes of SQL injection, our team must adhere to the following rules:
1. **Use Prepared Statements (Parameterized Queries):** This is the gold standard. Parameterization ensures that the database treats user input strictly as *data*, never as executable *code*. (e.g., using `?` in JDBC, or parameterized queries in Entity Framework / PDO).
2. **Use Safe ORMs:** Object-Relational Mappers (like Hibernate, Entity Framework, Prisma, Active Record) generally use parameterized queries by default. However, avoid "raw query" escape hatches within ORMs unless absolutely necessary (and if used, parameterize them).
3. **Strict Input Validation (Allow-listing):** For parts of a SQL query that *cannot* be parameterized (like dynamic `ORDER BY` column names or table names), validate the input against a strict allow-list in your code. (e.g., `if (input == "price") { order_by = "price"; }`).
4. **Principle of Least Privilege:** Ensure the database user account the application uses only has the minimum permissions necessary. The web app should not be connecting to the DB as `sa` or `root`.
5. **Generic Error Handling:** Catch exceptions gracefully. Return a generic "An error occurred" message to the user and log the actual database exception securely on the server side.