Re: [RFC] Name issue - is_literal/is_trusted
| From: | Bruce Weirdan | 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