On Wed, Jun 23, 2021, 9:23 PM Bruce Weirdan <weir...@gmail.com> wrote:
> On Thu, Jun 24, 2021 at 3:41 AM Scott Arciszewski <sc...@paragonie.com> > wrote: > > The failure condition of this query is > > "return all rows from the table already being queried", not "return > > arbitrary data the attacker selects from any table that the > > application can read". > > Imagine that was a DELETE rather than SELECT and the failure condition > becomes 'the table is emptied'. > It may have less disastrous consequences (depending on how good your > backup / restore procedures are) compared to arbitrary reads you > demonstrated, but it is still, quite clearly, a glaring security hole > caused by user input in SQL query - AKA SQL injection in layman's > terms. > > > it differs from Injection vulnerabilities in one > > fundamental way: The attacker cannot change the structure of the SQL > > query being executed. > > I would say replacing a column name with value is changing the > structure of SQL query, and, basically, in exactly the way you > describe SQL injection: confusing the code (column name) with data. > > I wholeheartedly welcome this RFC as it was originally proposed: > is_literal() doing exactly what it says on the tin, without any > security claims. But it has gone far from there real quick and now > people can't even name the thing. > > > -- > Best regards, > Bruce Weirdan mailto: > weir...@gmail.com We can agree that it is a bug. We don't agree on the definition of SQL injection. Changing a column name to a number (which prepared statements shouldn't allow in the first place) is a bug. This changes the effect of the command, but the *structure* of the query remains unchanged. > >
