Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:115028
MIME-Version: 1.0
References: <CAFv4g+GjXqiZkA2fawt7jHDtDAKjB0rv=Lfbcobu7bn8B=wvpw@mail.gmail.com>
 <CAGa2bXbGv33zHfRpu-hN_wNcNKPpFw_ed1ZRnn96tpDf0ROcLg@mail.gmail.com>
 <0CD1762E-6094-4DEB-B1B5-22CFBDAAFF44@php.net> <CAG9XoMQUUYGhA6QL3Se4FNJgydjzX0MAeR_CWr5O1SH8xgypLA@mail.gmail.com>
 <CAFv4g+ET4YDpygjKqGbAwxt+jkA8kWTeUrmTcR3hbFGEGNgmDg@mail.gmail.com>
 <BFFD3FBB-721B-491B-ADDB-DE3CA535BB52@koalephant.com> <CAFv4g+GJrX6uNSAq=kAXDk2Lx=NLx=GxAw9Qh+cpZwbaVdgtJA@mail.gmail.com>
 <9B304735-E0AD-4CC0-98BF-AAF4CE5FA52C@koalephant.com>
In-Reply-To: <9B304735-E0AD-4CC0-98BF-AAF4CE5FA52C@koalephant.com>
Date: Tue, 22 Jun 2021 15:38:51 +0100
Message-ID: <CAFv4g+GuqPYHjAzQ2YzdBh2R5+62xneZCz-Wdj5cE8On4BpHog@mail.gmail.com>
To: Stephen Reay <php-lists@koalephant.com>
Cc: Benjamin Morel <benjamin.morel@gmail.com>, Derick Rethans <derick@php.net>, 
	PHP Internals <internals@lists.php.net>, Yasuo Ohgaki <yohgaki@ohgaki.net>
Content-Type: multipart/alternative; boundary="00000000000057dc0605c55bc04d"
Subject: Re: [PHP-DEV] [RFC] is_trusted - was is_literal
From: craig@craigfrancis.co.uk (Craig Francis)

--00000000000057dc0605c55bc04d
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Tue, 22 Jun 2021 at 3:05 pm, Stephen Reay <php-lists@koalephant.com>
wrote:

>
> On 22 Jun 2021, at 20:13, Craig Francis <craig@craigfrancis.co.uk> wrote:
>
> On Tue, 22 Jun 2021 at 09:59, Stephen Reay <php-lists@koalephant.com>
> 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.
>>
>
>
>
> The primary reason was never just to define literal strings, the intentio=
n
> has always been to create a practical, implementable solution to address
> the issue of Injection Vulnerabilities (SQl/HTML/CLI/etc).
>
>
> Preventing injection vulnerabilities may be your *goal* but I=E2=80=99m t=
alking
> about the *intended behaviour of this one function*.
>



I understand this is not the one true perfect solution, but that solution
does not exist without tanking performance and never being accepted solely
on that basis alone.

If you can point me to an example where including integers in this has
introduced a security vulnerability then please do, and I mean it, that=E2=
=80=99s
what this process is for, I genuinely want people to come forward with them
so we can refine this.

The only thing that you could suggest as an alternative is to not include
integers at all. That is not realistic for the reasons I=E2=80=99ve stated =
not just
here, but in replies to others, and the RFC itself. So if we can=E2=80=99t =
do that,
and we can=E2=80=99t mark developer-integers for reasons mentioned before, =
what
else is there? That we just don=E2=80=99t do it??

Torpedoing the idea because it is not 100% idealistically perfect, and
ignoring the fact that it, (as it stands right now with integers and all),
**Prevents Injection Vulnerabilities** - the most common security
vulnerability that dominates the top of the leaderboards again and again -
and does that without adding in any new security vulnerabilities, is just
nonsensical.

Craig

--00000000000057dc0605c55bc04d--