Exercise 2: A Clean SQLi Review Doesn't Mean a Secure Database — Possible Solution
====================================================================

Two realistic ways the database could still be breached despite a
clean SQL injection finding:

1. MISCONFIGURED ACCESS. The security review tested the APPLICATION's
   queries for injection — it likely said nothing about whether the
   database account the application connects with has been granted
   far more privilege than it needs (e.g. full admin rights instead of
   scoped read/write on just its own tables), or whether a default
   admin password was ever changed after installation. An attacker who
   compromises the application server through a completely different,
   unrelated vulnerability (e.g. a vulnerable dependency, a leaked
   credential) could then use that same overly broad database account
   to read or modify far more than the application itself was ever
   designed to access.

2. NETWORK/PHYSICAL EXPOSURE. A SQL injection review checks the
   application's code and query-building logic — it does not check
   whether the database's own network port is reachable directly from
   the public internet, or whether an unencrypted backup of that same
   database sits in a loosely-protected storage location. Either one
   lets an attacker reach the data WITHOUT going through the
   application (and its clean query-parameterization) at all.

Both examples share the same underlying point this chapter makes: a
SQL injection review specifically tests the app-to-database boundary
— it doesn't and can't test whether the database, as its own piece of
infrastructure, is properly secured.