EXERCISE 3 — The full 5-step union attack, automation, and the fix
===================================================================

THE FULL ATTACK, START TO FINISH:

  STEP 1 — CONFIRM INJECTABLE.
    A lone ' causes an error/changed behaviour, or ' OR '1'='1 vs ' AND '1'='2
    changes the results. This proves input reaches the query as SQL (Ch.2).
    MECHANICAL? Yes — a fixed set of probe strings + a diff of the responses.

  STEP 2 — FIND THE COLUMN COUNT.
    ' ORDER BY 1-- , 2-- , 3-- ... until error (last success = count); or
    ' UNION SELECT NULL[,NULL...]-- until success. (Ch.4 / Ex.1)
    MECHANICAL? Yes — increment a counter until the error/success flips. A loop.

  STEP 3 — FIND A DISPLAYABLE TEXT COLUMN.
    Place a string marker 'aaa' in each position (NULLs elsewhere); see which
    marker appears in the output. (Ex.2)
    MECHANICAL? Yes — N payloads for N columns, check which marker renders.

  STEP 4 — MAP THE SCHEMA.
    Query information_schema.tables for table names, then
    information_schema.columns WHERE table_name='users' for column names.
    MECHANICAL? Yes — standard metadata queries; the DBMS exposes its own
    structure. (Tool also fingerprints the DBMS to pick correct syntax.)

  STEP 5 — EXTRACT.
    ' UNION SELECT NULL, CONCAT(username,':',password), NULL FROM users--
    Read the dumped rows from the output (concatenated to fit one column).
    MECHANICAL? Yes — once schema is known, the dump query is templated.

WHY EACH STEP IS MECHANICAL / AUTOMATABLE (sqlmap):
  - Every step is a deterministic procedure driven by observing the app's
    response (error vs success, marker present vs absent, rows rendered). There
    is no creativity required — just probe, observe, branch, repeat.
  - That's why sqlmap (Ch.10) does ALL of it automatically: detect injection,
    determine count + types, fingerprint the DBMS, enumerate information_schema,
    and dump tables — typically in minutes with a single command. So a union-
    injectable parameter is effectively an AUTOMATIC full-database disclosure,
    not a theoretical risk.

WHY PARAMETERIZED QUERIES MAKE THE ENTIRE SEQUENCE IMPOSSIBLE:
  - With a parameterized query, e.g.
        SELECT name, price FROM products WHERE name LIKE ?
    the DRIVER sends the query TEXT (with the ? placeholder) and the user's
    VALUE on SEPARATE channels. The value is BOUND as data and is NEVER parsed
    as SQL.
  - So the attacker's input — ' UNION SELECT ... , ' ORDER BY 4-- , 'aaa', the
    information_schema queries, the CONCAT dump — is treated as a LITERAL
    SEARCH STRING for a product name (e.g. a product literally named
    "' UNION SELECT username,password FROM users-- "). It matches no product and
    has ZERO syntactic power.
  - Because the input can never become part of the SQL, there is nothing to
    UNION onto, no column count to match, no schema query to run — Step 1 fails
    (the input doesn't alter the query), and every later step is moot. The
    injection simply does not exist.
  - This is the chapter's recurring point: closing channels (hiding errors,
    showing one column) slows attackers; PARAMETERIZATION removes the
    vulnerability so the whole 5-step pipeline has no starting point.

ONE-LINE TAKEAWAY:
  Union extraction is a deterministic, automatable pipeline from "injectable"
  to "database dumped"; parameterized queries break it at step 0 by keeping the
  input as data that never becomes SQL.