Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:115092
MIME-Version: 1.0
References: <CAFv4g+Gv1qQ2Gtx2Qwo0Dx2Cb_gOXJ=rm7rVy+Jo89PmD-3jnA@mail.gmail.com>
 <CAEMvS4GRaqMBPn7ocBX-XU3jzrtpe+9uGfYpG10qc_iKZY80UA@mail.gmail.com>
 <03f7955c-69a8-4841-9245-449d7851e207@www.fastmail.com> <CAFv4g+EaT309KDWz63j3S7n8E58czEWTKUEw9hAvgt7s6R9eKQ@mail.gmail.com>
 <CAKws9z02yCZTb2_mw-5xUO5-QLc4jbOUcBRfJ8nFSNPP1rgO3g@mail.gmail.com>
 <CA+hqhpfUiOMLDZyXTqP+mm9jjG6v+K94Ug7K_zvuuZus_XhOaQ@mail.gmail.com>
 <CAKws9z34nTT0_CXoo4Yq7zO2CZX622has23xmfHbWjfaDrgLqA@mail.gmail.com> <CA+hqhpdR=W8nbWy8UBgLtKdvb_KCss5mpzturS67HhqRj4q6BQ@mail.gmail.com>
In-Reply-To: <CA+hqhpdR=W8nbWy8UBgLtKdvb_KCss5mpzturS67HhqRj4q6BQ@mail.gmail.com>
Date: Wed, 23 Jun 2021 21:30:58 -0400
Message-ID: <CAKws9z1=6fmCxJWYVfN+xKT+u=_ZTq0m7C0nZPT6LB5scbfpXQ@mail.gmail.com>
To: Bruce Weirdan <weirdan@gmail.com>
Cc: Craig Francis <craig@craigfrancis.co.uk>, Larry Garfield <larry@garfieldtech.com>, 
	php internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="0000000000004bb0ab05c578fab0"
Subject: Re: [PHP-DEV] [RFC] Name issue - is_literal/is_trusted
From: scott@paragonie.com (Scott Arciszewski)

--0000000000004bb0ab05c578fab0
Content-Type: text/plain; charset="UTF-8"

On Wed, Jun 23, 2021, 9:23 PM Bruce Weirdan <weirdan@gmail.com> wrote:

> 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



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.

>
>

--0000000000004bb0ab05c578fab0--