Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:115031 Return-Path: Delivered-To: mailing list internals@lists.php.net Received: (qmail 86142 invoked from network); 22 Jun 2021 15:38:22 -0000 Received: from unknown (HELO php-smtp4.php.net) (45.112.84.5) by pb1.pair.com with SMTP; 22 Jun 2021 15:38:22 -0000 Received: from php-smtp4.php.net (localhost [127.0.0.1]) by php-smtp4.php.net (Postfix) with ESMTP id 9D8C21804DA for ; Tue, 22 Jun 2021 08:56:37 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on php-smtp4.php.net X-Spam-Level: X-Spam-Status: No, score=-1.5 required=5.0 tests=BAYES_00,HTML_MESSAGE, KHOP_HELO_FCRDNS,SPF_HELO_NONE,SPF_NONE,UNPARSEABLE_RELAY autolearn=no autolearn_force=no version=3.4.2 X-Spam-Virus: No X-Envelope-From: Received: from processus.org (ns366368.ip-94-23-14.eu [94.23.14.201]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-256) server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by php-smtp4.php.net (Postfix) with ESMTPS for ; Tue, 22 Jun 2021 08:56:36 -0700 (PDT) Received: from authenticated-user (PRIMARY_HOSTNAME [PUBLIC_IP]) by processus.org (Postfix) with ESMTPA id 6619D5101324 for ; Tue, 22 Jun 2021 15:56:34 +0000 (UTC) To: internals@lists.php.net References: <4FFA0160-1A05-4DA0-9C9A-79F778443A35@newclarity.net> <83D62559-0B87-4723-93B8-801905508E1F@koalephant.com> Message-ID: <8eb429ba-6f1f-c234-69af-3f707381ae09@processus.org> Date: Tue, 22 Jun 2021 17:56:33 +0200 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------EA16ACF38F90F416E50BFECC" Content-Language: en-US Authentication-Results: processus.org; auth=pass smtp.auth=pierre-php@processus.org smtp.mailfrom=pierre-php@processus.org X-Spamd-Bar: / Subject: Re: [PHP-DEV] Sql Object Model Parser & Sanitizer (was [RFC] is_literal) From: pierre-php@processus.org (Pierre) --------------EA16ACF38F90F416E50BFECC Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Le 22/06/2021 à 17:35, Mike Schinkel a écrit : > https://github.com/WordPress/WordPress/blob/master/wp-includes/wp-db.php#L2050 Sorry for the discussion pollution here but, but ouch, plugins are still using this unsafe form ? Reminds when I was a student, I learnt to parametrize queries there, it was 20 years ago. I never understood people not doing that in the first place. > But also because of much legacy code exists in the form of plugins and themes that do not support parameterized queries. Yes I agree, legacy is legacy, you have to deal with it. But all legacy code cannot be fixed, and doing a highly complex SQL parsing / escaping / vulnerability detection code that explicitly targets legacy code and not modern code seems weird to me. > 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. Not being able to parametrize table or field names is not only a problem for mysqli, but it is for PDO and pgsql too. That's a place where userland query-builders and others DBALs, even the most basic ones do shine, and brings a real added-value. But having anyone, writing SQL with user-given table names or column names, and executing it using something like WP's _do_query() method seems like they *WANT* to be hacked. I'm not sure how you will succeed in plugging the is_trusted() / is_literal() / is_wathever() method correctly in an SQL Model Parser & Sanitizer anyway, knowing that at this point, all you'll receive is a huge string issued by some plugin API which has already done crazy dark (and probably bugguy as well) magic. I don't see how adding magic in PHP core will avoid the need to fix all those legacy plugins, they probably would need themselves to use this new shiny API to benefit from it ? In the opposite, if something alters the behavior of mysqli implicitly for everyone in order to make it safe, it sounds like there will be a lot of BC ? In both case, it seems that it will not do any shiny magic to me. But, I might be wrong, this thread becomes harder and harder to read, and I may have missed a few points. Regards, -- Pierre --------------EA16ACF38F90F416E50BFECC--