EXERCISE 1 — Classify each SQLi scenario ========================================= The test: "HOW does the extracted data get back to the attacker?" (a) The app prints "SQL error near..." with table names. TYPE: IN-BAND, sub-type ERROR-BASED. WHY: the data/structure returns through the app's OWN response, inside a visible database error message. The attacker reads schema (and can force values into errors) directly from what the app shows. Same channel as the injection -> in-band; the carrier is the error -> error-based. (b) A search page shows extra rows from another table after a UNION. TYPE: IN-BAND, sub-type UNION-BASED. WHY: UNION SELECT appends a second query's results onto the original, so other-table data appears in the app's NORMAL output (the result list). Data returns in-band, via appended results -> union-based. (c) The page looks identical but takes 5s longer with a SLEEP payload. TYPE: BLIND, sub-type TIME-BASED. WHY: there's no visible data or error — you can't SEE the answer. The only signal is the RESPONSE TIME: the DB was made to pause (SLEEP) when a condition was true, so a delay = "true." Data is inferred from timing behaviour -> blind, time-based. (d) The DB makes a DNS lookup to your domain. TYPE: OUT-OF-BAND (OOB). WHY: the data leaves through a SEPARATE channel — the database itself makes a network request (DNS/HTTP) to an attacker-controlled domain, with the stolen data encoded in the hostname. The attacker reads it from their DNS logs, not from the app's response at all -> out-of-band. SUMMARY: (a) in-band / error-based -> data in the error message (b) in-band / union-based -> data in the appended results (c) blind / time-based -> data inferred from response delay (d) out-of-band -> data exfiltrated via DB's DNS/HTTP request KEY POINT: all four are the SAME underlying vulnerability (an injectable query). They differ only in the READOUT CHANNEL. Identify the type by asking how the answer comes back; the technique (and tooling) follows from that.