The regex-based validator worked for everything tested, but had a
class of structural blindspot: it didn't actually know what a token
was, so it accepted `SELECT 1; SELECT 2` (no forbidden keyword in
either statement) and relied entirely on the keyword scan catching
write verbs. With sqlparse we get:
- Explicit multi-statement detection via `len(sqlparse.parse(query))`
— `SELECT 1; SELECT 2` is now refused with a clear "Multiple
statements detected" message.
- Proper string/comment boundary handling — `'log: DROP detected'`
is one Literal.String token; the DROP inside it never reaches the
forbidden-keyword scan. `inserted_at` is one Name token; INSERT
isn't matched as a substring.
- Same conservative behavior for keywords-as-identifiers (sqlparse
is a lexer, not a parser, so `SELECT delete FROM device` is still
refused — CUCM's data dictionary doesn't use SQL keywords as
column names anyway).
Hamilton review CRITICAL #1 preserved: the cleaned query returned to
the caller is still byte-for-byte the input (modulo trailing ; and
outer whitespace). sqlparse is consulted for analysis only.
Tests: +6 sqlparse-specific cases in TestSqlparseSpecific covering
multi-statement, comment-disguised injection, keyword-substring
identifiers, and CTE walks. 2 existing tests broadened from
match="DROP" to match="DROP|Multiple" — same query refused, the
diagnosis just got more accurate (multi-statement caught earlier
than forbidden-keyword scan).
36/36 validator tests pass.
Ryan Malloy
59f9df5b3b