Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:115029
Message-ID: <F8DAF477-25CE-4AD9-B9CB-F292C23DA276@newclarity.net>
Content-Type: multipart/alternative;
	boundary="Apple-Mail=_22E5CE17-167B-4A8B-B842-7CA57651C8F5"
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.7\))
Date: Tue, 22 Jun 2021 11:35:48 -0400
In-Reply-To: <83D62559-0B87-4723-93B8-801905508E1F@koalephant.com>
Cc: PHP internals <internals@lists.php.net>
To: Stephen Reay <php-lists@koalephant.com>
References: <4FFA0160-1A05-4DA0-9C9A-79F778443A35@newclarity.net>
 <CAGBsUre=Asp+arHBWK0VdT-YdM=_3rR+WOhQQeghFVwsR+nGUg@mail.gmail.com>
 <F861461F-D070-4808-8B2E-A9BBF753CE6C@newclarity.net>
 <83D62559-0B87-4723-93B8-801905508E1F@koalephant.com>
Subject: Re: [PHP-DEV] Sql Object Model Parser & Sanitizer (was [RFC]
 is_literal)
From: mike@newclarity.net (Mike Schinkel)

--Apple-Mail=_22E5CE17-167B-4A8B-B842-7CA57651C8F5
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8

> On Jun 22, 2021, at 10:35 AM, Stephen Reay <php-lists@koalephant.com> =
wrote:
>=20
>> On 22 Jun 2021, at 20:39, Mike Schinkel <mike@newclarity.net> wrote:
>>=20
>>> On Jun 22, 2021, at 9:00 AM, Kamil Tekiela <tekiela246@gmail.com> =
wrote:
>>>=20
>>> Hi Mike,
>>>=20
>>> Please don't do this. We already have PDO with prepared statements. =
The data must be bound. This is the secure way of writing SQL queries.=20=

>>=20
>> The problem is that over 40% of the web currently runs on PHP code =
that using mysqli.  That CMS does not support PDO nor prepared =
statements, and is unlikely to switch to it anytime some in the =
foreseeable future. =20
>>=20
>> A SQL object model parser and sanitizer could more easily be used =
incrementally by that CMS since PDO does not share connections with =
mysqli (AFAIK, anyway.)
>>=20
>=20
> (Resending from on-list address)
>=20
> Apparently you didn't know mysqli supports parameterised queries?
> Wordpress could have adopted parameterised queries when they =
grudgingly switched to mysqli, years after both it and PDO were =
introduced.

Well, yes and no. =20

I admit I had forgotten it because frankly the WordPress wp-db object =
wrapper used by 99.7%[1] of WordPress developers does not support it and =
given I had long ago realized I could not use them in WP I guess my =
memory blocked out the existence of prepared statements in mysqli.

But it is not relevant in WordPress. Here is where (almost?) all SQL =
queries go to run in WordPress:

=
https://github.com/WordPress/WordPress/blob/master/wp-includes/wp-db.php#L=
2050=20

Note there are no bind_param() or execute() calls anywhere in that file. =
 Their is a prepare(), but WordPress rolled their own:

=
https://github.com/WordPress/WordPress/blob/master/wp-includes/wp-db.php#L=
1302=20

So saying that parameterized query is a solution leaves out 40% of the =
web.  Because some other guys are the intransigent ones here.=20

But also because of much legacy code exists in the form of plugins and =
themes that do not support parameterized queries.

HOWEVER, whether mysqli supports parameterised queries or not is all a =
moot point because parameterised queries do not allow for parameterizing =
field names or table names.  And the point of this thread was to discuss =
how to mark SQL that has been composed at run-time to be "safe."  =
Without being able to parameterize field names and table names =
parameterised queries are not a sufficiently complete solution. =20

At least not from an is_literal()/is_trusted() perspective.

> There=E2=80=99s zero reason to believe they would adopt this unless =
forced to.

Exactly! WordPress is not going to change, so that leaves it up to PHP =
developers using WordPress to protect themselves.=20

Since I am *assuming* that everyone on this list wants to minimize the =
number of security issues in PHP applications across the web by whatever =
reasonable means necessary, I also assume that pointing at WordPress and =
saying "It's their fault not ours" does not help achieve those security =
goals?  So I am also assuming that finding a pragmatic solution that =
would allow PHP to be able to empower the developer in a way that =
WordPress won't might be worth considering.
=20
But tell me if I am assuming wrongly here.

-Mike

[1] Yes, I made that up out of whole cloth. But honestly in 10+ years =
working with WP I have almost never seen anyone use anything but the =
$wpdb provided by WP =E2=80=94 except for one single plugin =E2=80=94 =
and $wpdb does not support parameterized queries.=

--Apple-Mail=_22E5CE17-167B-4A8B-B842-7CA57651C8F5--