On Fri, 18 Jun 2021 at 12:25 pm, Pierre <pierre-...@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
