Defensive hardening: SQL injection (sqli)

[ajrequenez]

What this changes

This closes SQL injection in vulnerabilities/sqli/ at the low, medium and high security
levels, on both the MySQL and SQLite branches of each level's switch ($_DVWA['SQLI_DB']), and
stops the module leaking database error text as an injection oracle. Three files change —
vulnerabilities/sqli/source/{low,medium,high}.php — and nothing else.

Mechanism

Each level's user lookup is now a native prepared statement with an integer-typed bound parameter,
written in that backend's own procedural style:

• MySQL arm: mysqli_prepare → mysqli_stmt_bind_param($stmt, "i", $id) →
  mysqli_stmt_execute → mysqli_stmt_get_result, with the existing fetch loop preserved and
  mysqli_stmt_close before the connection close.
• SQLite arm: SQLite3::prepare → bindValue(':id', $id, SQLITE3_INTEGER) → execute(), with
  the existing fetchArray() loop preserved and finalize() placed after the loop.

Above the switch in each file, a single shared is_numeric($id) → intval($id) guard mirrors the
validation the module's secure reference already performs. Non-numeric input falls through to the
level's ordinary "no rows" rendering — never a die(), never an error string, never a 500.

The reflected id is now encoded at its sink with
htmlspecialchars($id, ENT_QUOTES, 'UTF-8'), and the error-disclosing sinks are replaced with a
fixed generic string (the wording already used elsewhere in this module), so a database failure no
longer reveals the parser message, a stack trace, or the absolute source path.

Why binding rather than a better filter

prepare() sends the SQL text to the server with the parameter marker still in it, so the
execution plan is built while the value is still sitting in PHP memory. The value then travels
separately, as a typed integer, and is bound into a slot in an already-planned statement. There is
no point in that sequence at which the value is text inside the statement — so there is nothing for
a quote to close, no grammar for a UNION to enter through, and no token stream for a trailing
comment to truncate. The guarantee is about when parsing happened, and an attacker cannot change
when parsing happened.

That is a categorical difference from what medium previously relied on. Its
mysqli_real_escape_string call never engaged at all: the query interpolated the value into an
unquoted numeric context (WHERE user_id = $id), so a payload needs no quote characters to
break out — a space and a keyword suffice, and escaping has nothing to act on. That call was
removed rather than left in place beside the binding, because a vestigial defence reads to a
reviewer as load-bearing when it is not. Similarly at high, the trailing LIMIT 1 was never the
defence — the injection worked by commenting it out — so it is retained for the level's declared
shape, not as a control.

What is deliberately preserved

• Every level still dispatches to its own source/<level>.php; each remains a real, distinct
  implementation rather than a copy of the reference.
• Neither impossible.php is modified. No challenge definition, detection hook, or navigation
  entry is removed, and nothing is deleted.
• Each level keeps its original input source and query shape — $_REQUEST at low, $_POST at
  medium, $_SESSION at high; the multi-row loop where the level had no LIMIT, and LIMIT 1
  where it did.
• The trailing SELECT COUNT(*) block at medium is kept, with its row count initialised on the
  failure path as well — the module's index.php reads that variable unconditionally to build the
  medium-level dropdown, so an undefined read would empty the form.
• No CSRF token was added below impossible, and no rate limiting or other control was introduced
  that would change how the module is driven.

The legitimate lookup still returns its record at all three levels, and the medium dropdown still
renders its full set of options.

Scope

Further modules follow on this same branch.