Lesson 5 of 6 in SQL Injection · 3 min left in this chapter

What The Database Saw

You ran the injection. Now look at the same moment from the other side of the glass — the query as it landed in the database log. This is the beat almost nobody teaches, and it is the one that turns an exploit you performed into an attack you can recognise.

3 min read

Not yet reviewed

Rookmentor

You have the attack and you have the fix. Before the fix, though, sit on the other side of the glass for a minute. When you sent ' OR 1=1 --, a real database wrote a line about it. Defenders live in those lines.

Wrenlearner

I never think about that. I see the page change. What did the database actually see?

The same event, from the other side

Every query the application runs, the database can be told to log. Your injection did not arrive as "an attack" — it arrived as a query, a slightly strange one, sitting in the log next to thousands of ordinary ones. Reading that log is how a defender notices an attack they were never in the room for.

112:04:59  SELECT * FROM products WHERE name LIKE '%socks%'
212:05:01  SELECT * FROM products WHERE name LIKE '%' OR 1=1 --%'
312:05:07  SELECT * FROM products WHERE name LIKE '%'
4          UNION SELECT username, password FROM users --%'
512:05:09  ERROR: each UNION query must have the same number of columns

Line 2The tautology you injected, exactly as the database received it. A human reading the log sees a WHERE clause that can never be false — which no legitimate search box produces.
Line 4The UNION reaching into users. The shape of the query — a product search selecting usernames and passwords — is the attack confessing itself in the log.
Line 5The error you provoked while tuning the payload is in the log too. A burst of SQL errors from one user is one of the loudest signals there is.

None of these lines needed a security product to exist. They are the database doing ordinary bookkeeping. The difference between a breach found in minutes and one found by a customer months later is often just whether anyone was reading them.

The fix from the last lesson — parameterised queries — stops the injection working. So why would a defender still care what the attack looked like in the log, once the hole is closed?

The beat nobody teaches

Attack courses stop at the exploit. Defence courses start at the alert, with the attack already an abstraction. The join between them — this is what my exploit looked like from your monitoring — is where an exploit stops being a trick and becomes something you can hunt. It is worth a whole beat precisely because it is the one that usually gets skipped.