Exercise 1: Why Parameterized Queries Aren't Enough — Possible Solution
====================================================================

"We use parameterized queries everywhere" only closes the ONE trust
boundary SQL injection is about: untrusted application input becoming
part of a SQL query's syntax. It says nothing at all about how the
database itself, as a running piece of infrastructure, is configured
or protected.

Three concrete attack paths a SQLi fix does nothing to prevent:

1. AN INSIDER WITH LEGITIMATE CREDENTIALS. A parameterized query stops
   a stranger from smuggling SQL through a web form. It does nothing
   to stop an employee, contractor, or ex-employee whose database
   account was never revoked from simply running
   SELECT * FROM customers directly — they never needed to inject
   anything, because they already had real, working access.

2. AN EXPOSED DATABASE PORT. If the database itself is bound to a
   public network interface and reachable directly from the internet,
   an attacker can connect straight to it with a normal database
   client — completely bypassing the application (and therefore
   bypassing whatever query-building code the parameterized-queries
   fix lives inside) entirely.

3. AN UNENCRYPTED OR STOLEN BACKUP. A backup file sitting in a loosely
   protected location contains the exact same data as the live
   database, with no SQL query involved in reading it at all — an
   attacker who obtains the backup file has the data, full stop,
   regardless of how well the application's queries are written.

All three bypass the application layer entirely, which is exactly the
layer parameterized queries protect.