Re: [RFC] [VOTE] is_literal

> On 8 Sep 2021, at 13:33, Claude Pache <claude.pache@gmail.com> wrote: > > > >> Le 7 sept. 2021 à 11:49, Craig Francis <craig@craigfrancis.co.uk> a écrit : >> >> >> Obviously I'd still like libraries to be able to protect everyone from >> introducing Injection Vulnerabilities (as the majority of programmers don't >> use static analysis), but that's for another day. >> > > > Hi, > > We all want to protect from injection vulnerability, but I think there are better way than > is_literal. > > One way is to use templates, an area where PHP is ironically lagging behind. I suggest looking > at JS tagged templates: > > > https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Template_literals > <https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Template_literals> > > For example: > > > $qb->select('u') > ->from('User', 'u') > ->where('u.id = ' . $_GET['id']); // INSECURE > could be written as > > > <?php > $qb->exec ` > SELECT u > FROM User u > WHERE u.id = %{ $_GET['id'] } > ` > ?> > > where the part between %{ ... } is transformed into an SQL literal string (with delimiters > "...", not just “escaping”) when it is a string; into the SQL expression NULL when it > is null; into an SQL subexpression if it is an object (provided by the library) that represents a > well-formed SQL subexpression, etc. > > —Claude > Resending from on-list address because I’m an idiot. Apologies for the dupe Claude/Craig. Hi Claude, I had my share of issues with Craig’s PR, but I think the original goal of it was a good and useful concept - provide developers (mostly lib authors, but its not like it couldn’t be used by end developers too) a way to _know_ that a string came from something hard coded in a php file. A ‘tagged template’ like that doesn’t help solve the problem in any way that parameterised queries can’t already do, and if you want to make it more ’templated’ like that, you could implement the same thing already by passing a printf-compatible template and the arguments to a function/method. None of that helps solve what the is_literal function (or potential type hint) would help with: when the part of the query that needs to be substituted, is something that cannot be parameterised at the SQL level (i.e. a column name) you _really_ don’t want that to accept user input of any kind. Cheers Stephen