Exercise 3: Why SQL Injection Is Just as Real Without a Network-Facing Surface — Possible Solution
====================================================================

WHY THE ABSENCE OF NETWORK EXPOSURE DOESN'T REMOVE THE RISK
------------------------------
Per this chapter's own warn-box, "even without a username, password,
or network exposure to worry about, SQL injection risk is exactly as
real inside SQLite application code as anywhere else — sqli1's and
postgres1-8's own material applies unchanged... the absence of a
network-facing attack surface doesn't mean the absence of the
underlying vulnerability class." SQL injection's root cause — per
sqli1's own material — is a failure to separate DATA from CODE when
building a SQL statement: when untrusted input is concatenated
directly into a SQL string rather than passed as a genuine, separate
parameter, that input can be crafted to change the actual structure
and meaning of the query being executed. Nothing about this mechanism
depends on the query having arrived over a network connection — it
depends entirely on how the SQL string itself was constructed,
regardless of where the input that ends up in it originally came
from.

WHY A LOCAL/EMBEDDED APPLICATION ISN'T AUTOMATICALLY SAFE
------------------------------
A common but mistaken intuition is that because a SQLite-backed
application (a CLI tool, a desktop app) has no open network port for
an attacker to connect to, the application itself must be safe from
injection. But the vulnerable code path is inside the APPLICATION,
not inside a network listener — if that application ever builds a SQL
string by concatenating input it received from ANYWHERE it doesn't
fully control, that's exploitable, entirely independent of whether the
application has a network-facing surface at all.

A CONCRETE EXAMPLE OF AN "UNTRUSTED LOCAL INPUT" SOURCE
------------------------------
Per this chapter's own list, "a file the application opens, a value a
user pastes in, or data synced in from elsewhere." A concrete example:
a desktop note-taking app that lets a user import notes from a
plain-text or CSV file. If the app reads values from that imported
file and concatenates them directly into a SQL INSERT statement rather
than using a parameterized query, a maliciously crafted import file
(perhaps shared by someone else, or downloaded from an untrustworthy
source) could contain a note "title" deliberately engineered to break
out of the intended SQL statement structure and execute additional,
attacker-chosen SQL — even though the entire interaction happened
purely locally, with no network connection involved at any point. The
"local" file is untrusted precisely because its actual origin (who
created it, what's really inside it) isn't controlled by the
application or its user with certainty.

WHY THIS WORKS AS AN ANSWER
------------------------------
It explains the actual mechanism of SQL injection (data/code
separation failure) as being independent of network exposure, and
gives a concrete, plausible example of untrusted local input (an
imported file) that demonstrates the risk applies just as much to a
purely local, embedded SQLite application as to a networked one.