EXERCISE 1 — Name the injection type, interpreter, and unified defence
======================================================================

(a) ' UNION SELECT ... in a search box.
    TYPE: SQL injection.
    INTERPRETER: the SQL database.
    DEFENCE: parameterized queries / prepared statements (bind the input as
    data so it's never parsed as SQL).

(b) <img src=x onerror=...> in a comment.
    TYPE: Cross-Site Scripting (XSS) — stored, here.
    INTERPRETER: the browser (HTML/JS parser).
    DEFENCE: context-aware OUTPUT ENCODING so the input renders as text, not
    markup (+ CSP as a backstop; sanitize if HTML must be allowed).

(c) ; cat /etc/passwd in a hostname field.
    TYPE: OS command injection.
    INTERPRETER: the operating-system shell.
    DEFENCE: avoid the shell; pass arguments as an ARRAY (e.g. execFile("ping",
    ["-c","1",host])) so input can't become shell syntax. (+ least privilege.)

(d) {{7*7}} returning 49.
    TYPE: Server-Side Template Injection (SSTI).
    INTERPRETER: the template engine.
    DEFENCE: never render user input AS a template; pass it as DATA to a fixed
    template. (Return of 49 proves the input was evaluated as template code.)

THE ONE ROOT CAUSE THEY ALL SHARE:
  UNTRUSTED INPUT IS PARSED AS CODE INSTEAD OF STAYING DATA. In each case,
  attacker-controlled input crosses a boundary where an interpreter (SQL DB,
  browser, OS shell, template engine) treats it as instructions rather than
  inert content. The interpreter and breakout syntax differ; the bug is
  identical — that's why they're all "injection" (A03).

UNIFYING DEFENCE PATTERN:
  Keep DATA off the CODE channel — separate the query/command/markup/template
  from the data so the data can never gain syntactic power:
    SQL      -> parameterized queries
    XSS      -> output encoding (+CSP)
    shell    -> argument arrays / avoid shell
    template -> render data into a fixed template, never render input as template
  Learn the principle once and every family member's fix follows.