Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:115159
MIME-Version: 1.0
References: <CAFv4g+GCbRataTtCKSrej5yU259=hbjNxQVzZX+oXm_vh0z-TQ@mail.gmail.com>
 <A0784946-A9F5-4EB0-B04C-EAFDD1359FF5@newclarity.net>
In-Reply-To: <A0784946-A9F5-4EB0-B04C-EAFDD1359FF5@newclarity.net>
Date: Sat, 26 Jun 2021 15:03:30 +0100
Message-ID: <CAFv4g+GSrbErpT-hCUVbtTagphz79kmtzvMQcuRbarKTsQd+4w@mail.gmail.com>
To: Mike Schinkel <mike@newclarity.net>
Cc: PHP internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="0000000000003f544305c5abb9e8"
Subject: Re: [PHP-DEV] is_literal() is back
From: craig@craigfrancis.co.uk (Craig Francis)

--0000000000003f544305c5abb9e8
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Just a quick reply at the moment, but what happens if a db library had a
method to set what was in the LIMIT part of a query, you did the MySQL
thing of =E2=80=9C30, 10=E2=80=9D to get paginated results, and then one da=
y the library
changed to require the argument to be an integer?





On Sat, 26 Jun 2021 at 2:51 pm, Mike Schinkel <mike@newclarity.net> wrote:

> The idea behind is_literal() is of good intention, but as they say the
> road to hell is paved with good intentions.
>
> The RFC proposes to add an internal "literal" flag to a string, the
> is_literal() function, and nothing else.
>
>  Further the RFC states a vision to get "libraries to start using
> is_literal() to check their inputs."  Again, that comes from a great
> intention.
>
> The problem lies with the fact that library developer who choose to
> disallow non-literal strings will offer solutions when a use-case literal=
ly
> (pun-intended) cannot produce a literal string.
>
> Sure, most leading library developers will offer a solution, but many of
> the long-tail library developers will not either because it will add scop=
e
> and/or because those library developers don't have to skill and/or
> experience to do so.
>
> So what will those users of those libraries do when faced with a required
> to only use literal strings?  They will find a workaround so they can get
> their jobs done.  And that workaround is really simple:
>
> function make_literal(string $non_literal):string {
>     $literal =3D '';
>     for( $i =3D 0; $i< strlen($non_literal); $i++ ){
>         $literal .=3D chr(ord($non_literal[$i]));
>     }
>     return $literal;
> }
>
> You can see it in action 3v4l.org <http://3v4l.org/> here[1] and for
> posterity on gist.github.com <http://gist.github.com/> here[2].
>
> Once developers start bypassing the is_literal() check then all those goo=
d
> intentions will be moot, and many who think they are secure from injectio=
n
> attacks will be vulnerable:
>
> $sql =3D 'SELECT * FROM foo WHERE id=3D' . make_literal( $_GET['id']);
> $result =3D mysqli_query($conn, $sql);
>
> So what am I suggesting we do?
>
> 1. We postpone passing this is_literal() RFC until we have collectively
> addressed how userland developers will be able to handle non-literals in
> SQL, HTML, etc. when their use-cases require non-literals.
>
> 2. We could also go ahead and add the internal "literal" flag to a string
> so that if someone wants to use it to write an extension to add an
> is_literal() function in the mean time it would be available, but not yet
> standardized into PHP.
>
> Thank you in advance for your consideration.
>
> -Mike
>
> [1] https://3v4l.org/oCBp7#focus=3Drfc.literals <
> https://3v4l.org/oCBp7#focus=3Drfc.literals>
> [2] https://gist.github.com/mikeschinkel/b9abd4178db461568b813269bc936c18
> <https://gist.github.com/mikeschinkel/b9abd4178db461568b813269bc936c18>

--0000000000003f544305c5abb9e8--