Re: [RFC] Name issue - is_literal/is_trusted

From: Date: Thu, 24 Jun 2021 01:22:53 +0000
Subject: Re: [RFC] Name issue - is_literal/is_trusted
References: 1 2 3 4 5 6 7  Groups: php.internals 
Request: Send a blank email to internals+get-115091@lists.php.net to get a copy of this message
On Thu, Jun 24, 2021 at 3:41 AM Scott Arciszewski <scott@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:weirdan@gmail.com

« previous php.internals (#115091) next »