EXERCISE 1 — A SQLi test plan for one endpoint
===============================================

(Test only systems you own or are authorized to assess.)

STEP 1 — MAP EVERY INPUT THAT REACHES A QUERY.
  - Obvious: URL query/path params, form fields, JSON/XML body fields.
  - Less obvious: HTTP headers (User-Agent, Referer, X-Forwarded-For), COOKIES,
    file contents.
  - STORED / SECOND-ORDER: values previously saved (a username, a profile field)
    that THIS or ANOTHER endpoint later reads into a query. List inputs by where
    they END UP (which queries), not just where they enter. (Ch.6)

STEP 2 — PROBE INJECTABILITY (per parameter).
  - String context: a lone '  -> DB error or changed behaviour suggests it
    reaches the query unescaped.
  - Logic flip: ' OR '1'='1  vs  ' AND '1'='2  -> if results/behaviour differ,
    your input alters the query's logic.
  - Numeric context: compare id=5 vs id=4+1 -> same record returned means the DB
    evaluated 4+1, so it's numeric and injectable (no quote needed). (Ch.2)

STEP 3 — IDENTIFY CONTEXT AND TYPE.
  - CONTEXT: quoted (string) vs bare (numeric) — decides the break-out (Ch.2).
  - TYPE (how data returns, Ch.3): in-band (results/errors shown) -> union/
    error-based; no output but behaviour differs -> boolean blind; identical
    responses -> time-based blind; nothing in-band but DB can call out -> OOB.
    The type dictates the technique.

STEP 4 — CONFIRM IMPACT SAFELY.
  - Prove the finding with a HARMLESS, UNIQUE read, not a destructive payload:
      * extract the DB version: ' UNION SELECT @@version,NULL-- (MySQL/MSSQL) or
        version() (Postgres), or read it via a blind condition;
      * or show a controlled boolean/time difference.
  - NEVER use DROP/DELETE/UPDATE or dump real PII to "prove" it on systems you
    don't fully control; demonstrate the vulnerability minimally and report it.

STEP 5 — CHECK FOR BLIND EXPLICITLY.
  - If there's no visible output or error, don't conclude "safe." Test BOOLEAN
    (page difference on ' AND 1=1-- vs ' AND 1=2-- ) and TIME-BASED
    ( ' AND IF(1=1,SLEEP(5),0)-- — a 5s delay = injectable). (Ch.5)
  - Also re-test STORED inputs by reaching the second-order trigger path.

WHAT SQLMAP AUTOMATES:
  - Pointed at a parameter, sqlmap automatically: detects injectability;
    determines the TYPE (error/union/boolean/time/OOB) and CONTEXT; fingerprints
    the DBMS; enumerates information_schema (databases, tables, columns); and
    DUMPS data — and can escalate to reading files / running OS commands where
    the DB account allows. It performs the entire Chapters 2-6 workflow with no
    manual SQL.

WHY "A SINGLE INJECTABLE PARAMETER" IS A SERIOUS FINDING:
  - It is not theoretical. Because every exploitation step is mechanical and
    automated by sqlmap, one injectable parameter typically equals a
    ONE-COMMAND FULL-DATABASE DISCLOSURE (and possibly auth bypass, data
    modification, file read, or RCE depending on privileges). There is no
    "minor" SQLi: the same flaw that leaks one column can usually dump the whole
    schema. Treat any confirmed injection as high/critical and fix it
    (parameterize) immediately.

TOOLING NOTE:
  - Burp Suite / OWASP ZAP scanners FLAG candidate parameters; sqlmap CONFIRMS
    and exploits. But the highest-value testing is manual reasoning about input
    -> query data flow, especially for second-order paths scanners miss.