Re: [PHP-DEV] Re: [RFC] is_literal
On Fri, 18 Jun 2021 at 15:47, Bruce Weirdan wrote: > One would be potential denial of service prevention (e.g. with enormous > `LIMIT` value where only a limited set of ints was intended. > [...] Here you really *don't* want $allowed_ids to include user input. The developer is writing this query to find those IDs and what the developer asks for is what they get, the values inside that list came from somewhere else and *that part earlier* is the bit with the unknown vulnerability that allowed the value in there. I can’t address logical flaws from the Developer; what you’re describing is a different issue. This RFC is to help prevent Injection Vulnerabilities, and it can’t be an Injection Vulnerability because the variable doesn’t contain commands, it’s only containing values. We cannot create anything entirely ‘safe’ there’s no such thing as ‘safe code’, and neither I or anyone else can hope to create a single RFC that can do that. If we just use the original is_literal (without integers), the only difference in your example will be that, when using integers for something like this, the developer will need to use a Parameterised Query instead (because we’d only be accepting literal strings) to do the exact same thing, and get that same outcome. Overall I think allowing ints in literal concatenation without tainting the > result as non-literal is a mistake. To counter this, supporting integers makes adoption easier, and it’s not causing any security issues. I prefer something that more developers/systems will be able to easily use, especially when updating existing code. > BTW, Psalm already distinguishes `literal-int` from `int` > Psalm is its own engine - it’s looking at the code, not running it, so it’s not negatively impacting performance. However PHP itself cannot do this, integers cannot include a flag to state if they came from source code, because adding would have too much of a performance impact. Or to quote Joe directly "We can't really do that, non reference counted types are stack allocated, ie the zval on either side of a call boundary are unique." We can’t split integers into two groups. It’s accept integers or no integers at all. And no integers really isn’t feasible for most developers. Craig
Re: [PHP-DEV] Re: [RFC] is_literal
On Fri, Jun 18, 2021 at 4:53 PM Craig Francis wrote:
> While philosophically more pure, there is actually no extra security
> benefit for excluding integers.
One would be potential denial of service prevention (e.g. with enormous `LIMIT`
value where only a limited set of ints was intended, like
"Items per page: 10, 20, 50, 100"). Another would be preventing abuse if you
used some integers like role IDs for access control. Using slightly
modified Matt's example:
```php
function f(array $allowed_ids) {
//
$query .= 'WHERE `foo` IN (' . implode(', ', $allowed_ids) . ')';
//
}
```
Here you really *don't* want $allowed_ids to include user input.
Overall I think allowing ints in literal concatenation without
tainting the result as non-literal
is a mistake. It would either prevent implementing proper literal int
type in future, or will make
it inconsistent (where non-literal int would be considered literal by
`is_literal()` for BC reasons).
Personally I would prefer limited applicability today that would not
prevent future consistent
implementation.
BTW, Psalm already distinguishes `literal-int` from `int` and
considers the result of
literal-string + int concatenation a non-literal string:
https://psalm.dev/r/59ad602688
This may mean that Matthew's point has been misinterpreted.
--
Best regards,
Bruce Weirdan mailto:weir...@gmail.com
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] Re: [RFC] is_literal
On 18-06-2021 13:25, Pierre 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 ? > > The original intent of being able to tell if a string is literal or not > seems to be a very good idea, but now it forked to something that is > more SQL-OtherDatabase business related: this means that PHP own std > will, in my opinion, take a role it isn't supposed to have, by > arbitrarily (don't take wrongly, all discussions I had read until now > are smart and make sense) telling people what is safe, and what is not ? This is my feeling as well. The original proposal was pure with solid security guarantees, independent of the context (SQL, HTML, ...) in which it is used. Elevating some user input to the same level of security as literals is not ideal. On the other hand, as Craig pointed out to me (thanks!), a feature that is too much of a hassle to use may not be widely adopted and the goal of the proposal (improving security) may not be met. Regards, Dik Takken -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] Re: [RFC] is_literal
On Fri, 18 Jun 2021 at 12:25 pm, Pierre 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
Re: [PHP-DEV] Re: [RFC] is_literal
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 ? The original intent of being able to tell if a string is literal or not seems to be a very good idea, but now it forked to something that is more SQL-OtherDatabase business related: this means that PHP own std will, in my opinion, take a role it isn't supposed to have, by arbitrarily (don't take wrongly, all discussions I had read until now are smart and make sense) telling people what is safe, and what is not ? The original is_literal() function idea is nice, why not having both, is_literal() that exposes a purely technical information in one side, and is_secure() that is more specialized and supposes what is safe or not considering more than simply string static state, for std provided SQL database layers ? In such scenario, userland libraries could use, depending on their own need, one or both of theses functions. I'd much like to have the is_literal() function for my own needs, I do maintain an SQL query builder, but I don't expect it to handle int and other types as well, I'll probably continue to handle those by myself since I have a custom escaping API. In my use case, I'd probably not use the is_secure() function but I would use the is_literal() one, mostly for performance reasons (avoid to escape something that doesn't need to be). I think that both being introduced at the same time is a good idea. Regards, -- pierre -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] Re: [RFC] is_literal
On Fri, 18 Jun 2021 at 11:45 am, Guilliam Xavier wrote: > 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']`) Yes, that’s correct. Supporting integers from any source helps with adoption, and we cannot find any security issues (it’s a fairly small change to the RFC, and that prompted the new name, especially as the original is_literal wasn’t perfect).
Re: [PHP-DEV] Re: [RFC] is_literal
On 18.06.21 08:00, Craig Francis wrote: As there’s been no issues raised with supporting integers, and doing so will help adoption, the implementation will be updated to allow them. Now to choose the name, with the options is_known() from Joe and is_trusted() from Moritz: https://strawpoll.com/bd2qed2xs Keep in mind it might also become a dedicated type in the future. I think "trusted" is a good option, also if you think about adding it as a type in the future and how it reads for somebody looking through code. Something like public function process(string $input): string Would be good in terms of readability and captures the meaning quite well (although having a specific trusted string type might be more sensible, to avoid these intersection types everywhere). "trusted" could be used in a similar way like the "pure" annotations in Psalm/PHPStan (just for a different meaning of course): to signify where non-trusted variables should be reported and could even be used for whole objects to signify they should only ever get and return trusted variables. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] Re: [RFC] is_literal
On Fri, Jun 18, 2021 at 12:10 PM Pierre wrote: > Le 18/06/2021 à 08:00, Craig Francis a écrit : > > As there’s been no issues raised with supporting integers, and doing so > > will help adoption, the implementation will be updated to allow them. > > > > Now to choose the name, with the options is_known() from Joe and > > is_trusted() from Moritz: > > > > https://strawpoll.com/bd2qed2xs > > > > Keep in mind it might also become a dedicated type in the future. > > > > Craig > > If I'm understanding this correctly, what you call a literal value is a > statically written and compiled string, which doesn't originate from a > user given value, but was hardcoded at some point. If so, even if the > primary use is of course for security concerns, the realty of what it > does is not, it's mostly about how a certain variable was defined / > assigned. How about is_static() or is_value_static() ? Or even > is_statically_defined() ? There's many options in this path. > 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']`) -- Guilliam Xavier
Re: [PHP-DEV] Re: [RFC] is_literal
On Fri, 18 Jun 2021 at 9:48 am, Marc Bennewitz wrote: > Not sure but what happens if you have like a DB connection in big5, > sjis, ... and add an integer as ASCII char into it? But that's the only > edge case I can think of. The integer character code points are the same in all three. PHP represents integers with the western arabic numerals 0-9, so as long as their code points are the same, nothing changes between any of the charsets. While I’ve not checked all other character encodings (far too many), the ones I did check were the most-used character encodings and they all used extended ASCII (that includes big5 and Shift JIS). The only exception is that there is something called EBCDIC (an old IBM character encoding descended from punch cards), but it’s very deprecated and PHP doesn’t work with it anyway - PHP explicitly has not supported it since 8.0 “EBCDIC targets are no longer supported, though it's unlikely that they were still working in the first place.” https://www.php.net/manual/en/migration80.other-changes.php
Re: [PHP-DEV] Re: [RFC] is_literal
Le 18/06/2021 à 08:00, Craig Francis a écrit : As there’s been no issues raised with supporting integers, and doing so will help adoption, the implementation will be updated to allow them. Now to choose the name, with the options is_known() from Joe and is_trusted() from Moritz: https://strawpoll.com/bd2qed2xs Keep in mind it might also become a dedicated type in the future. Craig If I'm understanding this correctly, what you call a literal value is a statically written and compiled string, which doesn't originate from a user given value, but was hardcoded at some point. If so, even if the primary use is of course for security concerns, the realty of what it does is not, it's mostly about how a certain variable was defined / assigned. How about is_static() or is_value_static() ? Or even is_statically_defined() ? There's many options in this path. Regards, -- Pierre -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] Re: [RFC] is_literal
Le 18/06/2021 à 11:41, Craig Francis a écrit : Hi Pierre, On Monday we had the discussion about types: https://externals.io/message/114835#114846 The RFCs Future Scope was updated to note the suggestion from someniatko and Matthew about how this could be a type in the future (Joe has also shown an interest); where it was agreed that it should be added later. Thanks for pointing out this discussion, I must have missed it. The discussions I’ve had about this flag have been to ensure it covers all future use cases, including a dedicated type, where the function is an easy way to expose this flag to libraries today, so they can handle developer mistakes gracefully (rather than causing type errors), with types needing to have their own future/separate discussion. The type will still use this flag, so it will match the same definition in the RFC - strings defined by the programmer, and we will include integers after the feedback from Matthew (integers have always been considered, the only reason they were originally excluded was because I tried to keep the definition as small as possible, Matthew noted how they would help adoption, and no one can find a single issue with allowing them). Makes sense. In many cases, I didn't want to bypass/override the RFC to something else, but just point out that the discussion about future types names could give hint about the function name itself. Regards, -- Pierre -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] Re: [RFC] is_literal
On Fri, 18 Jun 2021 at 8:48 am, Pierre wrote: > Le 18/06/2021 à 08:00, Craig Francis a écrit : > > Keep in mind it might also become a dedicated type in the future. > > Hello, > > If so, why the question should not be about the type name instead ? It > might raises different concerns and new arguments to this discussion ? > > What is this type ? What does it covers ? Can float, int, etc... be > literals as well ? Are those subtypes of their actual existing related > type ? What should be the behavior regarding user method typings, etc etc ? > > Instead of introducing is_literal() may be directly introducing those > types could be a good idea as well ? Hi Pierre, On Monday we had the discussion about types: https://externals.io/message/114835#114846 The RFCs Future Scope was updated to note the suggestion from someniatko and Matthew about how this could be a type in the future (Joe has also shown an interest); where it was agreed that it should be added later. The discussions I’ve had about this flag have been to ensure it covers all future use cases, including a dedicated type, where the function is an easy way to expose this flag to libraries today, so they can handle developer mistakes gracefully (rather than causing type errors), with types needing to have their own future/separate discussion. The type will still use this flag, so it will match the same definition in the RFC - strings defined by the programmer, and we will include integers after the feedback from Matthew (integers have always been considered, the only reason they were originally excluded was because I tried to keep the definition as small as possible, Matthew noted how they would help adoption, and no one can find a single issue with allowing them). The RFC also explains why floats and booleans are not included, so wouldn’t be used by the type for the same reason. While adding a flag is an ideal to work towards, it is more important to have this simple change first, so it can start improving security immediately (so libraries don’t need to wait years for all of their supported versions of PHP to include the type), and it gives libraries full freedom in how they handle values which don’t have this flag. Hopefully this and the Future Scope section can also answer your questions. Craig
Re: [PHP-DEV] Re: [RFC] is_literal
On 18.06.21 08:00, Craig Francis wrote: On Wed, 16 Jun 2021 at 18:24, Craig Francis wrote: On Sat, 12 Jun 2021 at 18:00, Craig Francis wrote: I'd like to start the discussion on the is_literal() RFC: https://wiki.php.net/rfc/is_literal Following up on the is_literal() RFC, thanks for the feedback. It looks like there are only 2 minor open issues - updating the implementation to allow integers, and what to call the flag/function. As there’s been no issues raised with supporting integers, and doing so will help adoption, the implementation will be updated to allow them. Not sure but what happens if you have like a DB connection in big5, sjis, ... and add an integer as ASCII char into it? But that's the only edge case I can think of. Now to choose the name, with the options is_known() from Joe and is_trusted() from Moritz: https://strawpoll.com/bd2qed2xs Keep in mind it might also become a dedicated type in the future. Craig -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] Re: [RFC] is_literal
Le 18/06/2021 à 08:00, Craig Francis a écrit : Keep in mind it might also become a dedicated type in the future. Hello, If so, why the question should not be about the type name instead ? It might raises different concerns and new arguments to this discussion ? What is this type ? What does it covers ? Can float, int, etc... be literals as well ? Are those subtypes of their actual existing related type ? What should be the behavior regarding user method typings, etc etc ? Instead of introducing is_literal() may be directly introducing those types could be a good idea as well ? Regards, -- Pierre -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] Re: [RFC] is_literal
On Thu, Jun 17, 2021 at 11:01 PM Craig Francis wrote: > > As there’s been no issues raised with supporting integers, and doing so > will help adoption, the implementation will be updated to allow them. > > Now to choose the name, with the options is_known() from Joe and > is_trusted() from Moritz: > > https://strawpoll.com/bd2qed2xs > > Keep in mind it might also become a dedicated type in the future. > > Craig Someone somewhere will end up writing a function that drops their database when given a 3 that PHP told them to trust. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
[PHP-DEV] Re: [RFC] is_literal
On Wed, 16 Jun 2021 at 18:24, Craig Francis wrote: > On Sat, 12 Jun 2021 at 18:00, Craig Francis > wrote: > >> I'd like to start the discussion on the is_literal() RFC: >> https://wiki.php.net/rfc/is_literal >> > > Following up on the is_literal() RFC, thanks for the feedback. It looks > like there are only 2 minor open issues - updating the implementation to > allow integers, and what to call the flag/function. > As there’s been no issues raised with supporting integers, and doing so will help adoption, the implementation will be updated to allow them. Now to choose the name, with the options is_known() from Joe and is_trusted() from Moritz: https://strawpoll.com/bd2qed2xs Keep in mind it might also become a dedicated type in the future. Craig
Re: [PHP-DEV] Re: [RFC] is_literal
On 16-06-2021 23:01, Craig Francis wrote: >> Which leads us to the name, because "is_literal" may be, uh, too literal. >>> So can we come up with something better? >> >> Throwing in another idea: is_hard_coded(). >> > > > I’d be a little hesitant on the name ‘is_hard_coded’, if we allow integers, > that means that it’s no longer strictly hard coded, and might get confusing. > Ah, I was assuming that you were still strictly referring to integer literals, not variables containing integers. Then indeed the name would be confusing. Regards, Dik Takken -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] Re: [RFC] is_literal
> Am 16.06.2021 um 23:01 schrieb Craig Francis : >> Throwing in another idea: is_hard_coded() > I’d be a little hesitant on the name ‘is_hard_coded’, if we allow integers, > that means that it’s no longer strictly hard coded, and might get confusing. Has `is_trusted` been considered yet? That works for all data types and refers to the concept, namely “untrusted input”. Regards Moritz -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] Re: [RFC] is_literal
On Wed, 16 Jun 2021 at 10:19 pm, Bruce Weirdan wrote: > On Thu, Jun 17, 2021 at 12:01 AM Craig Francis > wrote: > > is_literal can be used for strings because we can flag what’s > > user and what’s developer defined, and with Matthew’s request, it could > do > > integers (because an integer value alone is not inherently risky, and > it’s > > already used a lot). > > To clarify, do you imply that *all* integers are safe? Or would they > also be differentiated into literal and non-literal varieties? This would be all integers, to support the request from Matthew. I also believe, after a quick check with Joe, that it’s not possible to add a flag to an integer (“non reference counted types are stack allocated, ie the zval on either side of a call boundary are unique”). So it couldn’t work the same way. Craig
Re: [PHP-DEV] Re: [RFC] is_literal
On Thu, Jun 17, 2021 at 12:01 AM Craig Francis wrote: > is_literal can be used for strings because we can flag what’s > user and what’s developer defined, and with Matthew’s request, it could do > integers (because an integer value alone is not inherently risky, and it’s > already used a lot). To clarify, do you imply that *all* integers are safe? Or would they also be differentiated into literal and non-literal varieties? -- Best regards, Bruce Weirdan mailto:weir...@gmail.com -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] Re: [RFC] is_literal
On Wed, 16 Jun 2021 at 9:13 pm, Dik Takken wrote: > On 16-06-2021 19:24, Craig Francis wrote: > > Matthew Brown wants to support integer values, simply because so much > code > > already includes them, and I cannot find a single way that integers alone > > can cause issues from an Injection Vulnerability point of view. > > […] > > Expanding the 'literal' concept to other types than just strings > sounds like a good idea. However, limiting it to just integers sounds a > little arbitrary. If people want to insert a float or boolean into their > query and they are happy with the way those are coerced into strings, why > not allow it? > Applying this to floats and booleans might be dangerous, as what’s put in might not be what comes out (I want to keep the scope as limited as possible). is_literal can be used for strings because we can flag what’s user and what’s developer defined, and with Matthew’s request, it could do integers (because an integer value alone is not inherently risky, and it’s already used a lot). However because of things like true/TRUE getting converted to "1", we can’t apply the same certainty to floats and booleans - it wouldn’t be a consistent secure approach. > Which leads us to the name, because "is_literal" may be, uh, too literal. > > So can we come up with something better? > > Throwing in another idea: is_hard_coded(). > I’d be a little hesitant on the name ‘is_hard_coded’, if we allow integers, that means that it’s no longer strictly hard coded, and might get confusing.
Re: [PHP-DEV] Re: [RFC] is_literal
On 16-06-2021 19:24, Craig Francis wrote: > On Sat, 12 Jun 2021 at 18:00, Craig Francis > wrote: > >> I'd like to start the discussion on the is_literal() RFC: >> https://wiki.php.net/rfc/is_literal >> > > > > Hi Internals, > > Following up on the is_literal() RFC, thanks for the feedback. It looks > like there are only 2 minor open issues - updating the implementation to > allow integers, and what to call the flag/function. > > Matthew Brown wants to support integer values, simply because so much code > already includes them, and I cannot find a single way that integers alone > can cause issues from an Injection Vulnerability point of view (but if > anyone can, I absolutely welcome their input). Other variable types like > floats and booleans will still be excluded (because the value you put in > often is not what you get out, e.g. true/TRUE being converted to "1"). The security concerns that this RFC is addressing arise from data that an attacker might control, like user input. In that respect I guess there need not be any difference between types of literals. Expanding the 'literal' concept to other types than just strings sounds like a good idea. However, limiting it to just integers sounds a little arbitrary. If people want to insert a float or boolean into their query and they are happy with the way those are coerced into strings, why not allow it? > Which leads us to the name, because "is_literal" may be, uh, too literal. > So can we come up with something better? > > It needs to be a name that suggests: This variable contains programmer > defined strings, integers, and interned values (as noticed by Claude Pache > and Rowan Tommins). Ideally staying in the standard convention of > ‘is_singleword’. > > Joe has suggested is_known(), where "we have the concept of known strings > internally", which I like (though might clash with more userland functions > than ‘is_literal’). Last night I also wondered about `is_constrained()`, as > the value has limited sources. But I'd also welcome more suggestions, and > am happy to set up a poll (thanks Dharman for the strawpoll.com suggestion). Throwing in another idea: is_hard_coded(). > I've also updated the RFC Future Scope to note how this could be a > dedicated type (thanks someniatko, Matthew Brown, and Dik Takken); and I'm > really impressed to see the addition to Psalm so quickly. > > Craig > -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
[PHP-DEV] Re: [RFC] is_literal
On Sat, 12 Jun 2021 at 18:00, Craig Francis wrote: > I'd like to start the discussion on the is_literal() RFC: > https://wiki.php.net/rfc/is_literal > Hi Internals, Following up on the is_literal() RFC, thanks for the feedback. It looks like there are only 2 minor open issues - updating the implementation to allow integers, and what to call the flag/function. Matthew Brown wants to support integer values, simply because so much code already includes them, and I cannot find a single way that integers alone can cause issues from an Injection Vulnerability point of view (but if anyone can, I absolutely welcome their input). Other variable types like floats and booleans will still be excluded (because the value you put in often is not what you get out, e.g. true/TRUE being converted to "1"). Which leads us to the name, because "is_literal" may be, uh, too literal. So can we come up with something better? It needs to be a name that suggests: This variable contains programmer defined strings, integers, and interned values (as noticed by Claude Pache and Rowan Tommins). Ideally staying in the standard convention of ‘is_singleword’. Joe has suggested is_known(), where "we have the concept of known strings internally", which I like (though might clash with more userland functions than ‘is_literal’). Last night I also wondered about `is_constrained()`, as the value has limited sources. But I'd also welcome more suggestions, and am happy to set up a poll (thanks Dharman for the strawpoll.com suggestion). I've also updated the RFC Future Scope to note how this could be a dedicated type (thanks someniatko, Matthew Brown, and Dik Takken); and I'm really impressed to see the addition to Psalm so quickly. Craig
[PHP-DEV] Re: [RFC] is_literal()
> On Mar 22, 2020, at 7:14 PM, Craig Francis wrote: > > On Sun, 22 Mar 2020 at 19:11, Mike Schinkel wrote: >> [...] hash out potential solutions on the list rather than propose a >> specific one in advance. > > As to your idea of a "safe" MySQL class, fortunately mysqli already stops > multiple queries, so a SELECT cannot have an UPDATE/DELETE/TRUNCATE appended > on to the end, but it can still do things like UNION another SELECT query, so > the original query returns nothing, then the attackers query gets appended, > potentially allowing them to extract everything from the database. To follow up, a "safe" MySQL class *could* disallow UNION then, no? In addition, it could possible have flags for every type of query and require you set on only the aspects you need. Unions, Updates, Deletes, Truncates, Joins, Where, etc. much like firewalls start will all ports closed. Just spitballing, anyway. -Mike -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
