sql injection attack types – a list of sqli types and papers

There are three main SQL injection attack types: in-band, blind (also called inferential) and out-of-band. They differ in how the attacker gets the data back out of the database. This post explains each type with an example, covers the older technique names you’ll meet in academic papers, and finishes with the defences that stop all of them.

Updated October 2026: restructured into a clear explainer. The original research notes and paper summaries are kept at the end.

The Three Main SQL Injection Attack Types

• In-band: the attacker sees the result on the same page or channel they attacked. Error-based and UNION-based injection are the common forms.
• Blind (inferential): the application shows nothing useful, so the attacker infers data from true/false responses (boolean-based) or from response delays (time-based).
• Out-of-band: the data leaves through a different channel, for example the database making a DNS or HTTP request to a server the attacker controls.

Only test these techniques against systems you own or have written permission to test.

In-Band SQL Injection

In-band injection is the easiest to exploit because the answer comes straight back. There are two main techniques.

Error-based

The attacker deliberately triggers a database error. If the application prints the raw error, it can leak table names, column names or even data. This is also called an illegal or logically incorrect query.

UNION-based

The attacker appends a UNION SELECT to the original query so the results of a second query are returned in the page:

SELECT name, price FROM products WHERE id = 5 UNION SELECT username, password FROM users--

The injected query must return the same number of columns, with compatible types, as the original. A classic related trick is the tautology, which makes a condition always true, for example turning a login check into ' OR '1'='1 so it matches every row.

Blind (Inferential) SQL Injection

When the application hides errors and results, the attacker asks the database yes/no questions and watches how the application behaves.

Boolean-based

Two requests that differ by one condition give different pages when the condition is true or false:

id=5 AND 1=1   -> normal page
id=5 AND 1=2   -> empty or different page

By repeating this with conditions such as “is the first letter of the admin password ‘a’?”, data can be rebuilt one character at a time.

Time-based

If the page looks identical either way, the attacker makes the database pause when a condition is true and measures the delay. The delay function depends on the database: SLEEP(5) in MySQL, pg_sleep(5) in PostgreSQL and WAITFOR DELAY '0:0:5' in Microsoft SQL Server.

Blind injection is slow by hand, which is why attackers automate it with tools such as sqlmap.

Out-of-Band SQL Injection

Out-of-band injection works when the application’s response can’t be used at all, but the database server can make outbound network requests. The attacker makes the database send the data to a server they control, for example inside a DNS lookup. It is less common because it depends on the database being allowed to reach the internet and on database-specific features. Blocking outbound connections from database servers closes this route.

Second-Order SQL Injection

In second-order injection the malicious input is stored safely at first, for example in a username or profile field, and causes damage later when a different part of the application reads it back and uses it in a query without escaping it. It is easy to miss because the vulnerable query isn’t the one that received the input. The fix is the same as everywhere else: never build a query from data, even data that came from your own database.

Classic Technique Names You Will See in Papers

Older papers classify SQL injection by technique rather than by how data returns. These names all map onto the types above:

• Tautologies: injecting into a conditional so it is always true.
• Illegal or logically incorrect queries: forcing errors to learn about the schema.
• Union queries: appending UNION SELECT to read other tables.
• Piggy-backed queries: ending the query with a delimiter such as ; and adding a second statement.
• Stored procedures: abusing procedures the database exposes, such as command execution procedures in older SQL Server setups.
• Alternate encodings: hiding the payload in hex, ASCII or Unicode to get past filters that look for bad characters.
• Inference: blind and timing attacks, covered above.

How to Prevent SQL Injection

1. Use parameterised queries (prepared statements) everywhere. The database treats user input as data, never as SQL. This stops every type above.
2. Use an ORM or query builder carefully. They parameterise by default, but raw-query escape hatches are as dangerous as hand-written SQL.
3. Validate input against an allow-list for things that can’t be parameterised, such as table names or sort columns.
4. Give the database account the least privilege it needs. The web app rarely needs to drop tables or run operating system commands.
5. Don’t show database errors to users. Log them privately and show a generic message. This takes away the easiest in-band technique.
6. Add a web application firewall as a second layer, not as the fix. Filters can be bypassed with alternate encodings.

The OWASP SQL Injection Prevention Cheat Sheet covers each language’s parameterised query syntax. For how detection and prevention tools compare, see the summary of the classification paper and its detection methodologies.

The Research Behind This Post

These are the papers I read while collecting these notes, with the comparison tables from them:

• Halfond, Viegas and Orso, A Classification of SQL Injection Attacks and Countermeasures (2006)
• Tajpour, Ibrahim and Masrom, SQL Injection Detection and Prevention Techniques, International Journal of Advancements in Computing Technology (2011)
• Sharma and Jain, Analysis and classification of SQL injection vulnerabilities and attacks on web applications, IEEE (2014)
• Kindy and Pathan, A Detailed Survey on Various Aspects of SQL Injection in Web Applications, arXiv (2012)
• Kumar and Pateriya, A survey on SQL injection attacks, detection and prevention techniques, IEEE (2012)