> On 8 Sep 2021, at 13:33, Claude Pache <claude.pa...@gmail.com> wrote:
>
>
>
>> Le 7 sept. 2021 à 11:49, Craig Francis <cr...@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
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
