Problem
User values are correctly bound through prepared-statement placeholders (and there are tests proving injection payloads stay inert), but SQL identifiers — the table name and column names — are concatenated directly into the SQL text without quoting or validation.
This happens in:
CreateTableQuery::PrepareSql / CustomizedColumnName (src/queries.cc) — record_.name and column names
InsertQuery::PrepareSql (src/queries.cc)
UpdateQuery::PrepareSql (src/queries.cc)
DeleteQuery::PrepareSql / FetchRecordsQuery::PrepareSql (src/queries.cc)
QueryPredicate::Evaluate (src/query_predicates.cc:58) — member_name_ emitted unquoted
Impact
Identifiers originate from the REFLECTABLE / FIELDS macros, i.e. they are developer-controlled at compile time, so this is not runtime SQL injection. However:
- A member or record named like an SQL keyword (
order, group, select, where) produces invalid SQL.
- A name containing whitespace or special characters breaks the generated statement.
- There is no validation, so the failure mode is a confusing runtime SQL error rather than a clear diagnostic.
Suggested direction
Quote identifiers when emitting SQL (e.g. wrap in double quotes "name"), and/or validate member/record names at registration time (reject names that aren't safe SQL identifiers) so the error surfaces early with a clear message.
Problem
User values are correctly bound through prepared-statement placeholders (and there are tests proving injection payloads stay inert), but SQL identifiers — the table name and column names — are concatenated directly into the SQL text without quoting or validation.
This happens in:
CreateTableQuery::PrepareSql/CustomizedColumnName(src/queries.cc) —record_.nameand column namesInsertQuery::PrepareSql(src/queries.cc)UpdateQuery::PrepareSql(src/queries.cc)DeleteQuery::PrepareSql/FetchRecordsQuery::PrepareSql(src/queries.cc)QueryPredicate::Evaluate(src/query_predicates.cc:58) —member_name_emitted unquotedImpact
Identifiers originate from the
REFLECTABLE/FIELDSmacros, i.e. they are developer-controlled at compile time, so this is not runtime SQL injection. However:order,group,select,where) produces invalid SQL.Suggested direction
Quote identifiers when emitting SQL (e.g. wrap in double quotes
"name"), and/or validate member/record names at registration time (reject names that aren't safe SQL identifiers) so the error surfaces early with a clear message.