This is a great initiative. Briefing developers on the *mechanics* of how SQL injection (SQLi) works is one of the most effective ways to foster secure coding practices.
When presenting this to your development team, it is helpful to categorize SQLi into three primary classes based on **how the application responds** and **how the data is extracted**.
Here is a breakdown of the three general classes of SQL injection to use for your briefing:
---
### 1. In-Band SQLi (Classic SQLi)
This is the most common and straightforward type of SQL injection. It occurs when the attacker uses the **same communication channel** to both launch the attack and gather the results.
In-Band SQLi is typically broken down into two sub-types:
* **Error-Based SQLi:** The application is configured to return verbose database errors to the user. An attacker intentionally inputs syntax that breaks the SQL query. The resulting error message often reveals sensitive information about the database structure (e.g., table names, column names, or the exact SQL version), which the attacker uses to craft further attacks.
* *Developer Takeaway:* Never expose raw database exceptions or stack traces to the end-user. Always use generic error messages.
* **Union-Based SQLi:** The attacker leverages the `UNION` SQL operator to combine the results of the original, intended query with the results of a malicious query. The application then displays the combined data directly on the web page.
* *Developer Takeaway:* If user input can manipulate the structure of a `SELECT` statement, an attacker can append their own queries to read any table the application has access to.
### 2. Inferential SQLi (Blind SQLi)
Developers often believe that if an application does not display database errors or echo database content to the screen, it is safe from SQLi. Inferential SQLi proves this wrong. In this class, no actual data is transferred via the web application. Instead, the attacker sends payloads that ask the database **True or False questions** and observes how the application behaves.
There are two sub-types:
* **Boolean-Based (Content-Based) Blind SQLi:** The attacker sends a SQL query that forces a TRUE or FALSE condition. Even though no data is returned, the application's HTTP response changes depending on the result. For example, if the query evaluates to TRUE, the page loads normally; if FALSE, a specific image might not load, or a "no results found" message appears. The attacker can extract data character by character by asking, *"Is the first letter of the password an 'A'? (True/False)."*
* **Time-Based Blind SQLi:** If the application's responses are identical regardless of a TRUE/FALSE condition, the attacker relies on time. They inject a command that tells the database to pause (e.g., using `SLEEP(10)` or `WAITFOR DELAY`). They can then ask, *"If the first letter of the password is 'A', sleep for 10 seconds."* If the web page takes 10 seconds to load, the attacker knows the condition was true.
* *Developer Takeaway:* Hiding errors and data is a good practice, but it **does not fix the underlying vulnerability**. If the query structure can be altered, it can be exploited, even blindly.
### 3. Out-of-Band (OOB) SQLi
This is the rarest form of SQLi. It occurs when the attacker cannot use the same channel to extract data (In-Band) and the server is too slow or unstable for Inferential (Blind) attacks.
Instead, the attacker crafts a SQL payload that forces the database server itself to make an outbound network request (usually DNS or HTTP) to a server the attacker controls. For example, the attacker might force the database to do a DNS lookup for `<admin_password>.attacker.com`. The attacker looks at their DNS logs, sees the request, and captures the password.
* *Developer Takeaway:* OOB attacks rely on specific database features being enabled (e.g., `xp_dirtree` in Microsoft SQL Server, or `UTL_HTTP` in Oracle). This highlights the importance of **Database Least Privilege**—the database service account should not have network access or advanced features enabled unless strictly necessary.
---
### The Most Important Slide: Prevention
When concluding your briefing, you should pivot from *how it works* to *how we fix it*. The standard defenses developers should be using are:
1. **Parameterized Queries (Prepared Statements):** This is the ultimate defense. Parameterization ensures that the database treats user input strictly as *data*, never as executable *code*. Regardless of what the user types, it cannot alter the structure of the SQL query.
2. **Use of ORMs:** Object-Relational Mapping (ORM) frameworks (like Entity Framework, Hibernate, or Prisma) generally use parameterized queries by default, though developers must still be careful not to use raw query builder functions insecurely.
3. **Strict Input Validation / Allow-listing:** For parts of a SQL query that *cannot* be parameterized (like `ORDER BY` column names or `ASC/DESC` directions), developers must validate the input against a strict, hardcoded allow-list in the application code.
4. **Principle of Least Privilege:** Ensure the database user account the application uses only has the minimum permissions necessary (e.g., it shouldn't have `DROP TABLE` permissions or administrative rights).