Re: [PHP-DEV] [RFC] Name issue - is_literal/is_trusted

On 26/06/2021 14:47, Dan Ackroyd wrote: There is a line of code that has a bad assumption of whether $color is a literal string or not, and it's that line of code that needs to be changed, to use something that understands HTML escaping, in particular how to escape user input for html attribute c

Re: [PHP-DEV] [RFC] Name issue - is_literal/is_trusted

On Sat, 26 Jun 2021 at 13:47, Rowan Tommins wrote: > the actual bug will almost certainly have happened somewhere else in the > program, and you'll need to trace the data flow of $foo and $bar to find out > where. > That depends on what you mean by bug. In particular I don't agree that "The act

Re: [PHP-DEV] [RFC] Name issue - is_literal/is_trusted

On 26 June 2021 13:24:55 BST, Dan Ackroyd wrote: >It allows silly mistakes to slip through and make it to production. As > per https://news-web.php.net/php.internals/114858: Perhaps you missed my reply earlier where I pointed out that the traceability problem you've identified is valid, but not

Re: [PHP-DEV] [RFC] Name issue - is_literal/is_trusted

Please, stop spamming us with the same comments. Cheers Joe On Sat, 26 Jun 2021 at 14:25, Dan Ackroyd wrote: > On Fri, 25 Jun 2021 at 00:57, Craig Francis > wrote: > > > Dan Ackroyd wrote: > > > Please can you go into some detail about what you think people are > > > meant to do when they det

Re: [PHP-DEV] [RFC] Name issue - is_literal/is_trusted

On Fri, 25 Jun 2021 at 00:57, Craig Francis wrote: > > Dan Ackroyd wrote: > > Please can you go into some detail about what you think people are > > meant to do when they detect a non-literal used where a literal is > > expected? > > By using a simple function, it allows the library to handle > t

Re: [PHP-DEV] [RFC] Name issue - is_literal/is_trusted

On Thu, 24 Jun 2021 at 21:25, Dan Ackroyd wrote: > > Please can you go into some detail about what you think people are > > meant to do when they detect a non-literal used where a literal is > > expected? > > There is a whole load of hand waving going on of "you can protect > yourself!" but then

Re: [PHP-DEV] [RFC] Name issue - is_literal/is_trusted

On Thu, 24 Jun 2021 at 19:12, Joe Watkins wrote: > > we're not > talking about a function that protects you from all possible security > concerns or bugs. I know. We're talking about something that is meant to protect programmers against silly mistakes. And this RFC doesn't do that. It allows s

Re: [PHP-DEV] [RFC] Name issue - is_literal/is_trusted

Nobody has demonstrated that "string" . int can lead to anything but mistakes. It CANNOT lead to injection, and that's what we're talking about, we're not talking about a function that protects you from all possible security concerns or bugs. The actual definition of injection matters, when we ar

Re: [PHP-DEV] [RFC] Name issue - is_literal/is_trusted

> On Jun 24, 2021, at 6:33 AM, Stephen Reay wrote: > >> On 24 Jun 2021, at 17:07, Kamil Tekiela wrote: >> >> Hi Stephen, >> >> I believe the idea was for dynamically generate table names, or numbered >> tables/columns. E.g. >> >> function getTable(string $table){ >>// is_literal check

Re: [PHP-DEV] [RFC] Name issue - is_literal/is_trusted

On Thu, Jun 24, 2021, at 11:18 AM, Scott Arciszewski wrote: > On Thu, Jun 24, 2021 at 5:22 AM Stephen Reay wrote: > 1. I never claimed that it wasn't a bug. > 2. I never claimed it wasn't impactful. > 3. I never claimed it wasn't security-affecting. > > I've simply said that this isn't an exampl

Re: [PHP-DEV] [RFC] Name issue - is_literal/is_trusted

On Thu, Jun 24, 2021 at 5:22 AM Stephen Reay wrote: > > If you **inject a `1=1` clause where one didn't exist before**, that's > > injection. Notice the introduction of an OR operator in the examples > > you cited. > > Please, explain to us all, how `where foo=‘bar’ OR 1=1` is functionally > diff

Re: [PHP-DEV] [RFC] Name issue - is_literal/is_trusted

On 24/06/2021 11:35, Stephen Reay wrote: On 24 Jun 2021, at 17:16, Craig Francis wrote: On Thu, 24 Jun 2021 at 10:55, Stephen Reay wrote: but still I have to keep asking: Why integers at all? While I'm not a fan of this approach, there is a lot of existing code and tutorials that use: $s

Re: [PHP-DEV] [RFC] Name issue - is_literal/is_trusted

> On 24 Jun 2021, at 17:16, Craig Francis wrote: > > On Thu, 24 Jun 2021 at 10:55, Stephen Reay wrote: > >> but still I have to keep asking: Why integers at all? >> > > > While I'm not a fan of this approach, there is a lot of existing code and > tutorials that use: > > $sql = 'WHERE id

Re: [PHP-DEV] [RFC] Name issue - is_literal/is_trusted

> On 24 Jun 2021, at 17:07, Kamil Tekiela wrote: > > Hi Stephen, > > I believe the idea was for dynamically generate table names, or numbered > tables/columns. E.g. > > function getTable(string $table){ > // is_literal check here > } > > $number = (int) $_GET['tableno']; > if($number

Re: [PHP-DEV] [RFC] Name issue - is_literal/is_trusted

On Thu, 24 Jun 2021 at 10:55, Stephen Reay wrote: > but still I have to keep asking: Why integers at all? > While I'm not a fan of this approach, there is a lot of existing code and tutorials that use: $sql = 'WHERE id IN (' . implode(',', array_map('intval', $ids)) . ')'; $sql = sprintf('SEL

Re: [PHP-DEV] [RFC] Name issue - is_literal/is_trusted

Hi Stephen, I believe the idea was for dynamically generate table names, or numbered tables/columns. E.g. function getTable(string $table){ // is_literal check here } $number = (int) $_GET['tableno']; if($number < 0 || $number > 10) { throw new Exception("Invalid number"); } $tablename

Re: [PHP-DEV] [RFC] Name issue - is_literal/is_trusted

> On 24 Jun 2021, at 14:29, Scott Arciszewski wrote: > > On Thu, Jun 24, 2021 at 2:10 AM Stephen Reay wrote: >> >> >> >> On 24 Jun 2021, at 08:30, Scott Arciszewski wrote: >> >> On Wed, Jun 23, 2021, 9:23 PM Bruce Weirdan wrote: >> >> On Thu, Jun 24, 2021 at 3:41 AM Scott Arciszewski >

Re: [PHP-DEV] [RFC] Name issue - is_literal/is_trusted

> On 24 Jun 2021, at 14:14, Scott Arciszewski wrote: > > On Thu, Jun 24, 2021 at 2:10 AM Stephen Reay wrote: >> Hi Scott, >> >> I wrote that example where an integer could be dangerous. > > I don't disagree that it's an example where an integer could be dangerous. > > Danger is too broad t

Re: [PHP-DEV] [RFC] Name issue - is_literal/is_trusted

On Thu, Jun 24, 2021 at 4:34 AM Guilliam Xavier wrote: > > > On Thu, Jun 24, 2021 at 9:14 AM Scott Arciszewski wrote: >> >> On Thu, Jun 24, 2021 at 2:10 AM Stephen Reay >> wrote: >> >> > I would absolutely make use of a function that tells me if the string >> > given is in fact from something

Re: [PHP-DEV] [RFC] Name issue - is_literal/is_trusted

On Thu, Jun 24, 2021 at 9:14 AM Scott Arciszewski wrote: > On Thu, Jun 24, 2021 at 2:10 AM Stephen Reay > wrote: > > > I would absolutely make use of a function that tells me if the string > given is in fact from something controlled by the developer. But once that > same string can also include

Re: [PHP-DEV] [RFC] Name issue - is_literal/is_trusted

On Thu, Jun 24, 2021 at 2:10 AM Stephen Reay wrote: > > > > On 24 Jun 2021, at 08:30, Scott Arciszewski wrote: > > On Wed, Jun 23, 2021, 9:23 PM Bruce Weirdan wrote: > > On Thu, Jun 24, 2021 at 3:41 AM Scott Arciszewski > wrote: > > The failure condition of this query is > "return all rows from

Re: [PHP-DEV] [RFC] Name issue - is_literal/is_trusted

On Thu, Jun 24, 2021 at 2:10 AM Stephen Reay wrote: > Hi Scott, > > I wrote that example where an integer could be dangerous. I don't disagree that it's an example where an integer could be dangerous. Danger is too broad to have a meaningful discussion about. You can, of course, always do danger

Re: [PHP-DEV] [RFC] Name issue - is_literal/is_trusted

> On 24 Jun 2021, at 08:30, Scott Arciszewski wrote: > > On Wed, Jun 23, 2021, 9:23 PM Bruce Weirdan > wrote: > >> On Thu, Jun 24, 2021 at 3:41 AM Scott Arciszewski >> wrote: >>> The failure condition of this query is >>> "return all rows from the table already bein

Re: [PHP-DEV] [RFC] Name issue - is_literal/is_trusted

On Wed, Jun 23, 2021, 9:23 PM Bruce Weirdan wrote: > On Thu, Jun 24, 2021 at 3:41 AM Scott Arciszewski > wrote: > > The failure condition of this query is > > "return all rows from the table already being queried", not "return > > arbitrary data the attacker selects from any table that the > > a

Re: [PHP-DEV] [RFC] Name issue - is_literal/is_trusted

On Thu, Jun 24, 2021 at 3:41 AM Scott Arciszewski wrote: > The failure condition of this query is > "return all rows from the table already being queried", not "return > arbitrary data the attacker selects from any table that the > application can read". Imagine that was a DELETE rather than SELE

Re: [PHP-DEV] [RFC] Name issue - is_literal/is_trusted

On Wed, Jun 23, 2021 at 8:09 PM Bruce Weirdan wrote: > > > - String + int concatenation isn't an injection risk. > > I think this demonstrates it very well could be: > https://externals.io/message/114988#115038 > > -- > Best regards, > Bruce Weirdan > m

Re: [PHP-DEV] [RFC] Name issue - is_literal/is_trusted

On Thu, 24 Jun 2021 at 1:09 am, Bruce Weirdan wrote: > > - String + int concatenation isn't an injection risk. > > I think this demonstrates it very well could be: > https://externals.io/message/114988#115038 That’s the developer choosing to use a variable, and it’s no different than the deve

Re: [PHP-DEV] [RFC] Name issue - is_literal/is_trusted

> - String + int concatenation isn't an injection risk. I think this demonstrates it very well could be: https://externals.io/message/114988#115038 -- Best regards, Bruce Weirdan mailto:weir...@gmail.com -- PHP Internals - PHP Runtime Development Mai

Re: [PHP-DEV] [RFC] Name issue - is_literal/is_trusted

On Wed, Jun 23, 2021 at 10:54 AM Craig Francis wrote: > > On Wed, 23 Jun 2021 at 14:37, Larry Garfield wrote: > > > I'm still very torn on is_literal; I fear that the people who would > > benefit from it are the very people that don't use the tools that would > > leverage it (DBALs et al), and so

Re: [PHP-DEV] [RFC] Name issue - is_literal/is_trusted

On Wed, 23 Jun 2021 at 14:37, Larry Garfield wrote: > I'm still very torn on is_literal; I fear that the people who would > benefit from it are the very people that don't use the tools that would > leverage it (DBALs et al), and so the net benefit will be small. > This RFC will not help those w

Re: [PHP-DEV] [RFC] Name issue - is_literal/is_trusted

On Wed, 23 Jun 2021 at 11:27 am, Guilliam Xavier wrote: > Alternatively, if integers are too controversial, how about reverting the > implementation to `is_literal()` > Starting to look like that, yeah.

Re: [PHP-DEV] [RFC] Name issue - is_literal/is_trusted

On Wed, Jun 23, 2021, at 8:05 AM, Hossein Baghayi wrote: > Hello, > What about `is_vulnerable`? Its behaviour would be the inverse of > is_literal. > I mean we don't have to avoid the other side of the coin. That has the same core problem as is_trusted. It's making a claim about the probable sec

Re: [PHP-DEV] [RFC] Name issue - is_literal/is_trusted

Hello, What about `is_vulnerable`? Its behaviour would be the inverse of is_literal. I mean we don't have to avoid the other side of the coin. On Tue, 22 Jun 2021 at 22:41, Craig Francis wrote: > Hi Internals, > > As the name `is_trusted()` seems to be causing contention, I think more > than the

Re: [PHP-DEV] [RFC] Name issue - is_literal/is_trusted

On Tue, Jun 22, 2021 at 8:11 PM Craig Francis wrote: > > The Function: > - Is a security-based function that prevents Injection Vulnerabilities in > PHP. > - Flags strings written by the developer, including when concatenated. > - Also accepts integer values, which as purely numerical cannot cont

Re: [PHP-DEV] [RFC] Name issue - is_literal/is_trusted

FWIW, I would prefer is_literal, but without integers in scope. Modern code is often type hinted. I would expect that a lot of libraries would accept only strings and then check whether it's a literal string. I don't think accepting integers in scope increases security or improves ease of use. Howe

Re: [PHP-DEV] [RFC] Name issue - is_literal/is_trusted

On 22 June 2021 19:11:05 BST, Craig Francis wrote: >Hi Internals, > >As the name `is_trusted()` seems to be causing contention, I think more >than the alternative option would. Since we want to get this right, and >we >still have time before the feature freeze, this might be worth >re-looking >at.

Re: [PHP-DEV] [RFC] Name issue - is_literal/is_trusted

On Tue, 22 Jun 2021 at 20:38, Mel Dafert wrote: > Another idea - `is_internal()`, since it is not external code, and > internal would be the > opposite of external. Unfortunately, because we cannot record internal vs external integers (too big of a change to how integers are stored), we are cu

Re: [PHP-DEV] [RFC] Name issue - is_literal/is_trusted

>- `is_trusted()` - suggested by Moritz and separately by Mike, was the >second option in the original vote, and was based on the idea that what is >returned can be 'trusted' to be free from external code. Another idea - `is_internal()`, since it is not external code, and internal would be the op

[PHP-DEV] [RFC] Name issue - is_literal/is_trusted

Hi Internals, As the name `is_trusted()` seems to be causing contention, I think more than the alternative option would. Since we want to get this right, and we still have time before the feature freeze, this might be worth re-looking at. Particularly if you are one of those unsure about it, read