Types of SQL Injection

SQL injection can be classified into four broad categories based on how the injected SQL interacts with the application and how the attacker receives or observes the results:

1. In-Band SQL Injection — The attacker uses the same communication channel to inject the SQL and receive the results. It includes UNION-Based and Error-Based SQL Injection.

2. Blind SQL Injection — The application does not directly return the results of the injected query. Instead, the attacker infers information from differences in the application's behavior. It includes Boolean-Based and Time-Based Blind SQL Injection.

3. Out-of-Band SQL Injection — The attacker obtains information through a separate communication channel from the application's normal response, when the database environment supports such interactions.

4. Second-Order SQL Injection — Malicious input is initially stored by the application and is later retrieved and used in an unsafe SQL query, causing the injection at a later stage.

In-Band SQL Injection is a type of SQL injection in which the same communication channel is used to send the injected SQL input and receive the application's response.

It has two main types:

1. Union-Based SQL Injection

2. Error-Based SQL Injection

Error-Based SQL Injection is a type of SQL injection in which an attacker intentionally manipulates application input to cause database errors and observes the application's response.

If detailed database errors are exposed to the client, they may reveal useful information about the underlying database environment, such as the database system, query structure, tables, columns, or other database-related details.

The attacker can use this information to better understand the application's database structure and refine subsequent SQL injection testing. Depending on the application's behavior, the attacker may then attempt other SQL injection techniques.

How It Works:
The basic flow is:

Manipulated Input → SQL Query → Database Error → Error Returned to Client → Information Disclosed

For example, an application may expose a database error containing information about the SQL query or database object involved in the error. An attacker can analyze that information to understand how the application interacts with the database.

Why Error Information Matters

Detailed database errors can potentially disclose:

Database type or version
SQL query details
Table names
Column names
Database objects
Database configuration details
Other information useful for further testing

The exact information disclosed depends on the database system, application, query, and error-handling configuration.

Limitation:
Error-Based SQL Injection becomes significantly less useful when the application properly handles database errors and does not expose detailed error information to the client.

UNION-Based SQL Injection is a type of SQL injection in which the UNION operator is used to combine the result of an injected SELECT statement with the result of the application's original query.

During testing, an attacker may first try to understand the structure of the original query, including the number of columns returned and the compatibility of the columns with the injected query. Techniques such as ORDER BY may be used to help determine the number of columns.

For a UNION operation to work, the original and injected SELECT statements must return the same number of columns. In addition, the corresponding columns must have compatible data types.

If the injection is successful and the application displays the combined query results, it may expose information accessible to the application's database account, such as table names, column names, or data stored in database tables.

Successful UNION injection does not automatically mean that sensitive information will be disclosed.
The outcome depends on:

1. What the original query returns
2. Shether the application displays the combined results
3. Database permissions
4. Query structure
5. What information the database account can access.

Blind SQL Injection is a type of SQL injection in which the application does not directly reveal the results of the injected SQL query in its response.

Instead, an attacker attempts to infer information about the database by observing changes in the application's response content, behavior, or response time.

Blind SQL Injection is commonly divided into two types:
1. Boolean-Based Blind SQL Injection — the attacker observes differences in the application's response or behavior based on whether an injected condition evaluates to true or false.
2. Time-Based Blind SQL Injection — the attacker observes differences in response time caused by conditions or operations that make the database response take longer.

These techniques used to infer information about the database when the application does not directly return the results of the injected query.

Boolean-Based Blind SQL Injection is a technique in which the attacker cannot directly see the result of the injected SQL query. Instead, the attacker injects conditions that evaluate to TRUE or FALSE and infers information from differences in the application's response or behavior.

Consider a URL such as:
example.com/product?id=5
The application may execute:
SELECT * FROM products WHERE id = 5;

Suppose the application displays the product page when a matching record is found and a "Not Found" page when no record is found.
An attacker may first test whether different Boolean conditions produce distinguishable responses:

id=5 AND 1=1

The condition is TRUE, so the product page loads normally.

id=5 AND 1=2

The condition is FALSE, so the application shows the "Not Found" response.

At this stage, the attacker has not obtained database information. They have established that TRUE and FALSE conditions produce different observable outcomes.

The attacker can then use Boolean conditions to ask questions about data in the database. For example, a condition can test whether a particular character at a particular position matches a specific value. If the application's response indicates TRUE, the attacker knows that the tested condition is satisfied; if it indicates FALSE, the condition is not satisfied.

By repeating this process, an attacker may infer database information one condition at a time, even though the database does not directly return the requested data in the application's response.

In Boolean-Based Blind SQL Injection, the attacker relies on a difference in the application's response or behavior between TRUE and FALSE conditions. In Time-Based Blind SQL Injection, the application produces essentially the same response for both conditions, so the attacker uses a difference in response time as the signal.

The attacker injects a condition that makes the database pause (e.g., via SLEEP()) only when it's true. The answer is read from response time, not response content.

Example:
id=5 AND IF(1=1, SLEEP(5), 0) ← delays the response 5 seconds (true);
id=5 AND IF(1=2, SLEEP(5), 0) ← return instantly (false);

Swap the trivial condition for a real one — e.g., testing a character of a username — to extract data one bit at a time.

Note: Network/server latency can produce false positive slow responses — repeat timing tests to confirm before trusting them.

Out-of-Band SQL Injection relies on a separate communication channel to obtain information from the database when the application's normal response does not provide a useful way to observe the result.

Unlike In-Band SQL Injection, the attacker does not rely on the application's response to receive the information. It also differs from Boolean-Based and Time-Based Blind SQL Injection, where the attacker infers information from changes in response content, behavior, or timing.

In an Out-of-Band attack, the attacker attempts to cause the database server to make an outbound network connection to an external system controlled by the attacker. Information may then be transmitted through that separate channel and observed outside the application's normal response.

Attacker Input → Vulnerable Application → Database → Outbound Network Request → External System

The external communication may use mechanisms such as DNS or other supported network protocols, depending on the database system and its configuration.

Limitations: It generally requires

A database system capable of performing outbound network operations.
The relevant database functionality to be available.
Network connectivity from the database server to the external destination.
Appropriate database and network permissions.
A vulnerable SQL injection point that can trigger the relevant operation.

Hardened environments commonly restrict unnecessary outbound connections and database functionality, which can significantly reduce the feasibility of this technique.

Second-Order SQL Injection occurs when untrusted input is stored and later used unsafely in a SQL query, causing the injection to occur at a different stage from the original input.

Second-Order SQL Injection, sometimes referred to as Stored SQL Injection, occurs when attacker-controlled input is stored by the application and later used unsafely in a SQL query.

Unlike a typical SQL injection attack, the malicious input does not necessarily trigger the vulnerability when it is initially submitted. Instead, the input is stored and becomes dangerous later when another part of the application retrieves the stored value and incorporates it into a SQL query without appropriate protection.

How It Works
The general flow is:

Attacker Input → Safe Storage → Stored Data → Later Retrieval → Unsafe SQL Query → SQL Injection

The registration feature may safely store this value using a parameterized INSERT query. Therefore, no SQL injection occurs during registration.

When the previously stored value is incorporated into this query, it may alter the intended SQL statement.

It may be difficult to identify because:

The initial input may appear to be handled safely.
The vulnerability may exist in a completely different feature.
The stored value may remain harmless until a particular operation retrieves it.
Testing only the original input point may not reveal the vulnerability.

Type

How the attacker gets data

Speed

What it requires

In-Band

Directly in the app's response

Fast : results (or errors) come straight back

Query output or error messages reach the response

Boolean-based Blind

Inferred from a content/behavior difference

Slow : one true/false answer per request

Some visible difference between a true and false result

Time-based Blind

Inferred from response timing

Slowest : real seconds of waiting per guess

Ability to trigger a measurable, controllable delay

Out-of-Band

Via a separate channel (DNS/HTTP), outside the normal response

Fast when it works, but unreliable

Database must support and be permitted to make outbound network calls

It is based on try the fastest, most direct option first, and only fall back to a slower/less certain one when the previous option gives you nothing.

* Does the response show query results or database errors directly?

In-Band (Error-based if you're seeing raw DB error messages, UNION-based if you can get query output injected into the normal page content). Fastest and most informative and always the first thing to check.

* No direct data, but the response visibly changes depending on whether an injected condition is true or false?

Boolean-based Blind. Slower than in-band (one bit of information per request), but reliable when there's any visible difference to read.

* No visible difference at all, response looks identical either way?

Time-based Blind, using a deliberate delay to read the answer from timing instead of content. Slowest of the three, and the fallback when boolean-based has nothing to observe.

* None of the above give any signal fully opaque, nothing distinguishable in the response?

Consider Out-of-Band, but only as a last resort, since it depends entirely on the database engine and configuration supporting outbound network calls, which often isn't available.

* Second-Order sits outside this ordering entirely

it's not a technique to select based on the response, it's a structural risk to check for separately, by tracing whether input gets stored and reused elsewhere. Once you find where it resurfaces, whichever of the above techniques applies there.

In-Band (UNION-based): Requires the injected query to have the same column count and compatible data types as the original query. It also requires the application to display the query results; if the results are not exposed, this technique cannot retrieve them.

In-Band (Error-based): Relies on database error messages being exposed in the response. Production applications with debug mode disabled and custom error handling often suppress these messages, limiting this technique.

Boolean-based Blind: Requires an observable difference between true and false conditions. If responses are identical, there is no useful signal. It is also request-intensive because data must be inferred through many requests, which can trigger rate limiting or detection.

Time-based Blind: Relies on measurable response delays and is generally slower than Boolean-based Blind. Network latency and server load can introduce timing noise, often requiring repeated tests and increasing request volume.

Out-of-Band: Depends heavily on the database and network configuration. The database must be able to make outbound connections, and the attacker needs external infrastructure to receive them. Egress filtering can prevent the technique entirely.

Second-Order: Is harder to detect because the input is stored first and executed later in a different code path. Finding it requires tracing stored data through the application to the eventual database query, making automated detection more difficult.