Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:115026 Return-Path: Delivered-To: mailing list internals@lists.php.net Received: (qmail 68448 invoked from network); 22 Jun 2021 13:47:12 -0000 Received: from unknown (HELO php-smtp4.php.net) (45.112.84.5) by pb1.pair.com with SMTP; 22 Jun 2021 13:47:12 -0000 Received: from php-smtp4.php.net (localhost [127.0.0.1]) by php-smtp4.php.net (Postfix) with ESMTP id 992A61804D8 for ; Tue, 22 Jun 2021 07:05:28 -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.9 required=5.0 tests=BAYES_00,HTML_MESSAGE, SPF_HELO_NONE,SPF_PASS autolearn=no autolearn_force=no version=3.4.2 X-Spam-Virus: No X-Envelope-From: Received: from mail1.25mail.st (mail1.25mail.st [206.123.115.54]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by php-smtp4.php.net (Postfix) with ESMTPS for ; Tue, 22 Jun 2021 07:05:25 -0700 (PDT) Received: from smtpclient.apple (unknown [49.48.241.143]) by mail1.25mail.st (Postfix) with ESMTPSA id 61E0C60412; Tue, 22 Jun 2021 14:05:10 +0000 (UTC) Message-ID: <9B304735-E0AD-4CC0-98BF-AAF4CE5FA52C@koalephant.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_6BE22978-5608-4B69-A63D-974163C1A3F6" Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.100.0.2.22\)) Date: Tue, 22 Jun 2021 21:05:03 +0700 In-Reply-To: Cc: Benjamin Morel , Derick Rethans , PHP Internals , Yasuo Ohgaki To: Craig Francis References: <0CD1762E-6094-4DEB-B1B5-22CFBDAAFF44@php.net> X-Mailer: Apple Mail (2.3654.100.0.2.22) Subject: Re: [PHP-DEV] [RFC] is_trusted - was is_literal From: php-lists@koalephant.com (Stephen Reay) --Apple-Mail=_6BE22978-5608-4B69-A63D-974163C1A3F6 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On 22 Jun 2021, at 20:13, Craig Francis = wrote: >=20 > On Tue, 22 Jun 2021 at 09:59, Stephen Reay > wrote: > So I just want to make sure I understand the progression on this so = far. It started out with people wanting a way to check that a string was = a literal string, in code somewhere, and does not come from user input. = Ok makes sense. The name makes sense too. >=20 >=20 >=20 > The primary reason was never just to define literal strings, the = intention has always been to create a practical, implementable solution = to address the issue of Injection Vulnerabilities (SQl/HTML/CLI/etc). >=20 Preventing injection vulnerabilities may be your goal but I=E2=80=99m = talking about the intended behaviour of this one function. Your original = email says this: >> Distinguishing strings from a trusted developer from strings that may = be attacker controlled If you feel that somehow doesn=E2=80=99t mean the same as "check that a = string was a literal string, in code somewhere, and does not come from = user input=E2=80=9D, then we need to crack open a dictionary and work = out which words one of us doesn=E2=80=99t know the meaning of. > The name `is_literal()` has always just been a placeholder, it came up = when I first started looking at this problem because that was the most = obvious thing I knew we could anchor around. (Unfortunately I think it = was easy to make assumptions based solely on that name, rather than = focussing on the issue it is meant to address). >=20 > So, we cannot look for literals only - while it was part of the = solution, it was very much incomplete. Bearing in mind, there is = considerable amount of existing code and tutorials out there which = include integers in their SQL/HTML/CLI/etc, and they are perfectly safe = in doing so. Making a solution which does not support integers is not = going to be adopted/used because the task of rewriting and changing = everything, for no benefit, will not be considered by developers. >=20 There is a considerable amount of existing code that includes strings in = SQL, HTML without danger too. Plenty of string values are fine, and = plenty of integer values are fine. That doesn=E2=80=99t mean we should = just blindly trust a value that came from the user, just because it=E2=80=99= s a number. The saying goes =E2=80=9Cnever trust user input=E2=80=9D not =E2=80=9Cneve= r trust user input unless it=E2=80=99s a number=E2=80=9D.=20 > Likewise, a lot of code already builds SQL/HTML/CLI/etc strings via = concatenation and sprintf(), and forcing everyone to use a query builder = is likely to cause most people to not even consider using this. >=20 If they won=E2=80=99t adopt an existing solution to the problem why = would they adopt this? You=E2=80=99ve said very recently that this is not intended to be used = directly by most developers, and instead used within libraries and = frameworks. It seems a little weird to then make concessions that will = defeat the stated goal, in the name of adoption.=20 > It's all well thinking of one thing that might = theoretically/idealistically solve the issue, but it also needs to have = a plan on how this will be practically implemented and used by = developers (which this has done). > =20 Having a plan for how to implement something doesn=E2=80=99t help much = when the thing you=E2=80=99re implementing deliberately ignores a = specific type of =E2=80=98untrusted=E2=80=99 input.. --Apple-Mail=_6BE22978-5608-4B69-A63D-974163C1A3F6--