EXERCISE 1 — Insecure implementation vs insecure design
========================================================

Test: is the RIGHT control specified but coded wrong (implementation), or was
the right control NEVER SPECIFIED / is the mechanism itself unsafe (design)?

(a) A SQL query that forgot to parameterize.
    TYPE: Insecure IMPLEMENTATION.
    WHY: parameterized queries are the known-correct approach; this is just a
    line of code that did it wrong. The design intent ("read data safely") is
    fine; the implementation slipped. FIXABLE IN CODE: parameterize the query.

(b) A password reset that uses "mother's maiden name".
    TYPE: Insecure DESIGN.
    WHY: the MECHANISM itself is weak — security-question answers are public/
    guessable (Auth course). No matter how perfectly you code it (parameterized,
    no XSS, great validation), the recovery design is insecure. You can't make a
    weak factor strong with clean code. FIX REQUIRES REDESIGN: use a secure
    reset (emailed single-use token) / stronger recovery, not better code around
    security questions.

(c) A checkout that trusts the client-sent price.
    TYPE: Insecure DESIGN.
    WHY: the design DECISION to take the price from the request is the flaw — no
    line is "buggy"; the architecture trusts client-supplied business data. A
    perfectly implemented version still lets an attacker send price:1. FIX
    REQUIRES REDESIGN: the SERVER must derive the price from the catalogue by
    item id; the client never supplies trusted business values.

(d) A session cookie missing the HttpOnly flag.
    TYPE: Insecure IMPLEMENTATION (a missing configuration/attribute).
    WHY: the correct control (HttpOnly) is well known; it was simply not set.
    The design ("use secure session cookies") is right; the implementation
    omitted an attribute. FIXABLE IN CODE/CONFIG: add HttpOnly (+ Secure +
    SameSite). (Borderline with A05 misconfiguration, but it's a fix-the-setting
    issue, not a flawed design.)

SUMMARY:
  (a) implementation   (b) DESIGN   (c) DESIGN   (d) implementation

WHY THE DESIGN ONES CAN'T BE FIXED BY BETTER CODE ALONE:
  - In (b) and (c), nothing is "miscoded" — the code faithfully implements the
    intended behaviour. The vulnerability is in the INTENDED BEHAVIOUR itself:
    relying on guessable answers (b), or trusting client-supplied prices (c).
    Flawlessly implementing a flawed idea yields a flawlessly-built insecure
    feature. To fix them you must change WHAT is built (the mechanism/data flow)
    — i.e. redesign — not just clean up HOW it's coded.
  - This is the heart of A04: some vulnerabilities live at design time, and
    perfect implementation cannot save an insecure design. Catching these
    requires threat modeling BEFORE coding (Exercise 2), not code review after.