Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:114911
MIME-Version: 1.0
References: <CAFv4g+F-7F7o6va5wCrojKe+Uysx2Ec3H4yV_mUZYEyNm3MkdQ@mail.gmail.com>
 <CAFv4g+GYwH-nQ8bLGbm=ThARghGUG5hMpw7W5SjMnSPMTom7+g@mail.gmail.com> <e179b4f4-22ae-5dbb-ce9a-28fb909f90b9@gmail.com>
In-Reply-To: <e179b4f4-22ae-5dbb-ce9a-28fb909f90b9@gmail.com>
Date: Wed, 16 Jun 2021 22:01:08 +0100
Message-ID: <CAFv4g+Ejohe70=-7qobJ9z4HzHzGnBE1zYXUrAvivtf+Ad8onQ@mail.gmail.com>
To: Dik Takken <dik.takken@gmail.com>
Cc: internals@lists.php.net
Content-Type: multipart/alternative; boundary="000000000000683de905c4e864d0"
Subject: Re: [PHP-DEV] Re: [RFC] is_literal
From: craig@craigfrancis.co.uk (Craig Francis)

--000000000000683de905c4e864d0
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Wed, 16 Jun 2021 at 9:13 pm, Dik Takken <dik.takken@gmail.com> wrote:

> On 16-06-2021 19:24, Craig Francis wrote:
> > Matthew Brown wants to support integer values, simply because so much
> code
> > already includes them, and I cannot find a single way that integers alo=
ne
> > can cause issues from an Injection Vulnerability point of view.
>
> [=E2=80=A6]
>
> Expanding the 'literal' concept to other types than just strings
> sounds like a good idea. However, limiting it to just integers sounds a
> little arbitrary. If people want to insert a float or boolean into their
> query and they are happy with the way those are coerced into strings, why
> not allow it?
>



Applying this to floats and booleans might be dangerous, as what=E2=80=99s =
put in
might not be what comes out (I want to keep the scope as limited as
possible). is_literal can be used for strings because we can flag what=E2=
=80=99s
user and what=E2=80=99s developer defined, and with Matthew=E2=80=99s reque=
st, it could do
integers (because an integer value alone is not inherently risky, and it=E2=
=80=99s
already used a lot). However because of things like true/TRUE getting
converted to "1", we can=E2=80=99t apply the same certainty to floats and b=
ooleans
- it wouldn=E2=80=99t be a consistent secure approach.


> Which leads us to the name, because "is_literal" may be, uh, too literal.
> > So can we come up with something better?
>
> Throwing in another idea: is_hard_coded().
>


I=E2=80=99d be a little hesitant on the name =E2=80=98is_hard_coded=E2=80=
=99, if we allow integers,
that means that it=E2=80=99s no longer strictly hard coded, and might get c=
onfusing.

--000000000000683de905c4e864d0--