On Fri, 18 Jun 2021 at 12:25 pm, Pierre <pierre-php@processus.org> wrote:
> Le 18/06/2021 à 12:45, Guilliam Xavier a écrit :
> > IIUC, with the addition of integers, the function will return true for
> e.g.
> > 'SELECT * FROM foo LIMIT ' . (int)$limit even if $limit
> > doesn't come
> from
> > a "static" value (e.g. random_int() or even
> > $_GET['limit'])
>
> OK I get it.
>
> I followed the initial discussions but I didn't read everything for a
> while.
>
> Doesn't it mean that is_literal() which doesn't test anymore if something
> is literal does a bit more than that ?
>
I think there may be a misunderstanding here.
We are only going to ‘trust’ variables created from:
- Literal Strings (i.e. written by the developer),
- Integers.
It’s a very basic approach. The only change to the implementation has been
the inclusion of integers, nothing else. (Any Future Scope is not relevant
yet in regards to a new type etc. and it currently works on its own.)
The original is_literal() function idea is nice, why not having both,
> is_literal() that exposes a purely technical information in one side, and
> [one] that is more specialized […] than simply string static state, for std
> provided SQL database layers ?
We have not found any issues with allowing integers in SQL, HTML, CLI; and
other contexts as well (like preg, mail additional_params, XPath query, and
even *gasp* eval).
While philosophically more pure, there is actually no extra security
benefit for excluding integers.
And to support having 2 functions, we would need 2 flags on strings. These
flags are limited, and managing 2 flags would affect performance.
Craig