Re: [PHP-DEV] [RFC] Block requests to builtin SQL functions where PHP can prove the call is vulnerable to a potential SQL-injection attack

many developers are out there who will see it as an annoyance (at least until the feature is introduced to them properly). I've also added a couple of notes below. Craig On 12 Aug 2015, at 00:27, Yasuo Ohgaki yohg...@ohgaki.net wrote: Hi all, On Mon, Aug 10, 2015 at 6:57 PM, Craig

Re: [PHP-DEV] [RFC] Block requests to builtin SQL functions where PHP can prove the call is vulnerable to a potential SQL-injection attack

On 12 Aug 2015, at 00:43, Christoph Becker cmbecke...@gmx.de wrote: On 10.08.2015 at 11:57, Craig Francis wrote: You only have to skim read things like the second comment (with 27 up votes) on the PDO prepare page to see that these problems are happening all the time: http

Re: [PHP-DEV] [RFC] Block requests to builtin SQL functions where PHP can prove the call is vulnerable to a potential SQL-injection attack

On 29 Jul 2015, at 10:02, Lester Caine les...@lsces.co.uk wrote: The problem is removing all of the poor quality on-line guides and replacing them with ones which provide a mush better working model. Trying to get PHP too pick up a few edge cases is a poor use of time. I completely

Re: [PHP-DEV] [RFC] Block requests to builtin SQL functions where PHP can prove the call is vulnerable to a potential SQL-injection attack

, touching many parts of the engine, changing many things ... which I don't really like. Cheers Joe On Thu, Jul 30, 2015 at 10:14 AM, Craig Francis cr...@craigfrancis.co.uk wrote: On 30 Jul 2015, at 08:24, Lester Caine les...@lsces.co.uk wrote: But that is a perfect example of what I

Re: [PHP-DEV] [RFC] Block requests to builtin SQL functions where PHP can prove the call is vulnerable to a potential SQL-injection attack

...@paragonie.com wrote: On Thu, Jul 30, 2015 at 11:20 AM, Craig Francis cr...@craigfrancis.co.uk wrote: On 30 Jul 2015, at 14:43, Scott Arciszewski sc...@paragonie.com wrote: This may have been true at one point in time, but my own experience and the statistics collected by Dan Kaminsky

Re: [PHP-DEV] [RFC] Block requests to builtin SQL functions where PHP can prove the call is vulnerable to a potential SQL-injection attack

On 30 Jul 2015, at 16:26, Ronald Chmara rona...@gmail.com wrote: Perhaps I have missed something in this discussion I think you have... my email from a couple of weeks ago was ignored... so I replied to Matt's suggestion (which is similar, but different). Please, just spend a few minutes

Re: [PHP-DEV] [RFC] Block requests to builtin SQL functions where PHP can prove the call is vulnerable to a potential SQL-injection attack

30, 2015 at 10:14 AM, Craig Francis cr...@craigfrancis.co.uk wrote: On 30 Jul 2015, at 08:24, Lester Caine les...@lsces.co.uk wrote: But that is a perfect example of what I am talking about. You do not educate people by publishing the very thing that is wrong. You educate them by pointing

Re: [PHP-DEV] [RFC] Block requests to builtin SQL functions where PHP can prove the call is vulnerable to a potential SQL-injection attack

On 30 Jul 2015, at 14:43, Scott Arciszewski sc...@paragonie.com wrote: This may have been true at one point in time, but my own experience and the statistics collected by Dan Kaminsky of White Hat Security indicates that Cross-Site Scripting vulnerabilities are much more prevalent in 2015

Re: [PHP-DEV] [RFC] Block requests to builtin SQL functions where PHP can prove the call is vulnerable to a potential SQL-injection attack

be wrong, Pierre can be wrong, we can all be wrong ... Cheers Joe On Fri, Jul 31, 2015 at 11:40 AM, Craig Francis cr...@craigfrancis.co.uk wrote: On 30 Jul 2015, at 17:02, Joe Watkins pthre...@pthreads.org wrote: Even if some of those people replying haven't read or don't understand what

Re: [PHP-DEV] [RFC] Block requests to builtin SQL functions where PHP can prove the call is vulnerable to a potential SQL-injection attack

Hi Matt, I take it all back... I've been so sure of my own suggestion, I've not really given your RFC a proper read... and I think this could work. The main difference I had was the ability to support to support the escaping functions (see pg_escape_literal for PostgreSQL, or htmlentities for

Re: [PHP-DEV] [RFC] Block requests to builtin SQL functions where PHP can prove the call is vulnerable to a potential SQL-injection attack

a single function to say yes, I know this one is fine... then PHP can identify anything that has been missed. Craig On 31 Jul 2015, at 17:40, Ronald Chmara rona...@gmail.com wrote: On Thu, Jul 30, 2015 at 8:38 AM, Craig Francis cr...@craigfrancis.co.uk wrote: On 30 Jul 2015, at 16:26

Re: [PHP-DEV] [RFC] Block requests to builtin SQL functions where PHP can prove the call is vulnerable to a potential SQL-injection attack

(explained in the next email). -- http://news.php.net/php.internals/87370 From: Me (Craig Francis) Reply: Lester Caine Just saying I disagree with Lester, and giving a very simple example of how developers can still mess up (once you start adding some

Re: [PHP-DEV] [RFC] Block requests to builtin SQL functions where PHP can prove the call is vulnerable to a potential SQL-injection attack

should have probably called string_escaping_set)... which is simply to tell PHP that this one variable is already safe (something I can't see being needed very often). Craig On 30 Jul 2015, at 08:24, Lester Caine les...@lsces.co.uk wrote: On 29/07/15 16:11, Craig Francis wrote: I

Re: [PHP-DEV] [RFC] Block requests to builtin SQL functions where PHP can prove the call is vulnerable to a potential SQL-injection attack

Hi Anthony, Julien, Yasuo, I have been reading your conversation with great interest. But I would urge you to see Matts suggestion as a simple addition to the language (it's simpler than my suggestion), where his RFC seems to have already addressed your concerns (and he seems to have a working

Re: [PHP-DEV] [RFC] String Types (security)

On 17 Jul 2015, at 14:08, Mats Lindh mats.li...@gmail.com wrote: On Fri, Jul 17, 2015 at 3:03 PM Craig Francis cr...@craigfrancis.co.uk wrote: I'm looking at creating an RFC to address security issues that relate to poor string handling / escaping, such as SQL-Injection, XSS, etc. You

[PHP-DEV] [RFC] String Types (security)

Hi, I'm looking at creating an RFC to address security issues that relate to poor string handling / escaping, such as SQL-Injection, XSS, etc. Considering these are still major issues on the OWSP Top 10, we need to do more to mitigate them. For example, an inexperienced programmer can easily

Re: [PHP-DEV] PHP 7.1 - Address PHPSadness #28?

On 26 Aug 2015, at 16:06, Rowan Collins rowan.coll...@gmail.com wrote: Craig Francis wrote on 26/08/2015 14:53: On 26 Aug 2015, at 12:36, Rowan Collins rowan.coll...@gmail.com wrote: Fortunately, the function you are looking for already exists: http://php.net/array_key_exists It does

Re: [PHP-DEV] PHP 7.1 - Address PHPSadness #28?

On 26 Aug 2015, at 16:44, Stanislav Malyshev smalys...@gmail.com wrote: Depending on the website I may then add a key to define the 'report-uri', or I may set it to NULL to say that I don't want one. NULL is not the best value to for this, but the function you're looking for is

Re: [PHP-DEV] PHP 7.1 - Address PHPSadness #28?

On 26 Aug 2015, at 05:36, Stanislav Malyshev smalys...@gmail.com wrote: Would anyone be interested in adding another helper like isset()/empty() simply called exists() which would return true if the variable is defined in the current scope (i.e. without raising an E_NOTICE)? Not sure what

Re: [PHP-DEV] PHP 7.1 - Address PHPSadness #28?

to NULL. On 26 Aug 2015, at 12:36, Rowan Collins rowan.coll...@gmail.com wrote: Craig Francis wrote on 26/08/2015 12:23: If you want some example of where I got this wrong... I have a config array [...] When creating a URL builder that allowed the query string to be passed

Re: [PHP-DEV] PHP 7.1 - Address PHPSadness #28?

6 Aug 2015, at 19:44, Rowan Collins <rowan.coll...@gmail.com> wrote: > Craig Francis wrote on 26/08/2015 18:07: >> I provide examples to help explain that I (and I suspect most developers) >> default to using isset which works on either. >> >> Just because there is

Re: [PHP-DEV] PHP 7.1 - Address PHPSadness #28?

nly appears 3 times in that code). And the second one does not really check for the existence of $_GET, which in this case is probably ok. Craig On 1 Sep 2015, at 19:17, Rowan Collins <rowan.coll...@gmail.com> wrote: > On 01/09/2015 10:29, Craig Francis wrote: >> Personally

Re: [PHP-DEV] PHP 7.1 - Address PHPSadness #28?

a variable in, but PHP doing some analysis of the thing in the brackets. Craig On 2 Sep 2015, at 13:31, Rowan Collins <rowan.coll...@gmail.com> wrote: > Craig Francis wrote on 02/09/2015 10:06: >> On 1 Sep 2015, at 19:17, Rowan Collins <rowan.coll...@gmail.com> wrote: &

Re: [PHP-DEV] PHP 7.1 - Address PHPSadness #28?

y, in a few years time, if developers did their NULL checks with "=== NULL", then isset(), is_null(), array_key_exists(), and empty() could all be deprecated :-) Craig On 8 Sep 2015, at 19:22, Rowan Collins <rowan.coll...@gmail.com> wrote: > On 7 September 2015 14:11:05 BST, Craig Fr

Re: [PHP-DEV] PHP 7.1 - Address PHPSadness #28?

On 9 Sep 2015, at 19:34, Rowan Collins <rowan.coll...@gmail.com> wrote: > Craig Francis wrote on 09/09/2015 16:54: >> I don't think it is an odd thing to suppress a warning for a plain variable. >> >> For example, on a blog you may have a list of articles, which is

Re: [PHP-DEV] PHP 7.1 - Address PHPSadness #28?

the slightly messy isset()... but each to their own. Maybe Scott (who proposed the idea) might follow up with more information? Otherwise I'm off on holiday, see you in a few weeks :-) Craig On 14 Sep 2015, at 13:09, Rowan Collins <rowan.coll...@gmail.com> wrote: > Craig Francis wr

Re: [PHP-DEV] taint

2015-09-14 4:44 GMT+02:00 Christopher Owen : > Please consider making ‘taint’ a first-class feature/extension in PHP 7.0. I would echo Kalle's suggestion of 7.1. But I think you will find it hard to get support... I was pushing this a few weeks ago (either the one

Re: [PHP-DEV] taint

esoft.com> wrote: > On 9/15/2015 9:10 AM, Dennis Birkholz wrote: >> Hi all, >> >> Am 15.09.2015 um 17:09 schrieb Craig Francis: >>> 2015-09-14 4:44 GMT+02:00 Christopher Owen <christopher.o...@live.com>: >>>> Please consider making ‘taint’ a first-

Re: [PHP-DEV] taint

While skim reading emails (just got back from holiday), I wanted to add... On 15 Sep 2015, at 17:23, Anthony Ferrara wrote: > All, > > On Tue, Sep 15, 2015 at 11:15 AM, Arvids Godjuks > wrote: >> I fully support your effort to get this into the

Re: [PHP-DEV] PHP 7.1 - Address PHPSadness #28?

While skim reading emails (just got back from holiday), I wanted to add... On 23 Sep 2015, at 11:40, Rowan Collins wrote: > A non-existent variable, however, is not something I've ever come across in a > database context - it would seem to require a result set having

[PHP-DEV] Literal / Taint checking

Hi, How likely would it be for PHP to do Literal tracking of variables? This is something that's being discussed JavaScript TC39 at the moment [1], and I think it would be even more useful in PHP. We already know we should use parameterized/prepared SQL, but there is no way to prove the SQL

Re: [PHP-DEV] Literal / Taint checking

On Thu, 15 Aug 2019 at 19:05, Benjamin Eberlei wrote: > On Thu, Aug 15, 2019 at 8:03 PM Craig Francis > wrote: > >> Hi, >> >> How likely would it be for PHP to do Literal tracking of variables? >> >> This is something that's being discussed JavaScript TC

Re: [PHP-DEV] Literal / Taint checking

On Thu, 15 Aug 2019 at 21:37, Matthew Brown wrote: > > If anything, this proposal would help user-land solutions (it gives them >> more information while the code is in running). >> > > Well, it might help runtime-based user-land solutions, but not static > analysis-based solutions. > I mostly

Re: [PHP-DEV] Literal / Taint checking

On Thu, 15 Aug 2019 at 7:43 pm, Matthew Brown wrote: > There are already some userland taint-checking solutions for PHP e.g. the > Phan taint-check plugin from MediaWiki: > https://www.mediawiki.org/wiki/Phan-taint-check-plugin > > I'm working on my own userland solution, too (based on

[PHP-DEV] Re: Literal / Taint checking

don't need to write this every time: $sql = '... WHERE id IN (' . substr(str_repeat('?,', count($ids)), 0, -1) . ')'; --- [1] https://github.com/laruence/taint [2] https://www.mediawiki.org/wiki/Phan-taint-check-plugin [3] https://psalm.dev/r/ebb9522fea --- On Thu, 15 Aug 2019 at 19:02, Craig F

Re: [PHP-DEV] $_FILES['name'] check

On Wed, 19 Feb 2020 at 05:23, Bishop Bettini wrote: > On Sun, Feb 16, 2020 at 6:24 PM Craig Francis > wrote: > >> Just to check, at the moment, if I was an evil hacker, and was to run: >> >> curl -F 'file=@example.jpg;filename=../../../example.php' &g

[PHP-DEV] $_FILES['name'] check

Hi, Just to check, at the moment, if I was an evil hacker, and was to run: curl -F 'file=@example.jpg;filename=../../../example.php' https://example.com/upload/ The $_FILES['file']['name'] would be set to "example.php", where PHP has removed the leading "../../../" (good to see). Does that

Re: [PHP-DEV] $_FILES['name'] check

On Wed, 19 Feb 2020 at 16:42, Bishop Bettini wrote: > On Wed, Feb 19, 2020 at 10:29 AM Craig Francis > wrote: > >> On Wed, 19 Feb 2020 at 05:23, Bishop Bettini wrote: >> >>> On Sun, Feb 16, 2020 at 6:24 PM Craig Francis >>> wrote: >>> >>&g

Re: [PHP-DEV] Re: Literal / Taint checking

s-web.php.net/php.internals/87650 [10] https://news-web.php.net/php.internals/87725 [11] https://news-web.php.net/php.internals/87667 On Mon, 9 Mar 2020 at 16:54, Rowan Tommins wrote: > On Mon, 9 Mar 2020 at 13:47, Craig Francis > wrote: > > > Hi, > > > > As I'm not

[PHP-DEV] Re: Literal / Taint checking

:31, Craig Francis wrote: > Hi, > > While there was a brief discussion about an *is_literal*() method in > August, I'm wondering where I can go next? > > Just as a reminder, the main objection seemed to be that Taint checking is > the current solution. For example, those

Re: [PHP-DEV] RFC Karma

Thanks Nikita. On Wed, 18 Mar 2020 at 10:59, Nikita Popov wrote: > On Wed, Mar 18, 2020 at 11:52 AM Craig Francis > wrote: > >> Hi, >> >> I've created a Wiki account (craigfrancis), and I believe the next step is >> to ask for RFC Karma. >> >>

[PHP-DEV] RFC Karma

Hi, I've created a Wiki account (craigfrancis), and I believe the next step is to ask for RFC Karma. This is so I can write up about the suggested is_literal() function. https://news-web.php.net/php.internals/108977 Craig

Re: [PHP-DEV] [RFC] is_literal()

On Sat, 21 Mar 2020 at 19:54, Dan Ackroyd wrote: > On Sat, 21 Mar 2020 at 19:14, Craig Francis > wrote: > > > > Any feedback would be appreciated. > > The RFC should probably define what a literal is. > > Good point Dan, I've added it to the intro. Please let

Re: [PHP-DEV] [RFC] is_literal()

, but please let me know if I've missed any. Craig On Sat, 21 Mar 2020 at 19:51, Larry Garfield wrote: > On Sat, Mar 21, 2020, at 2:13 PM, Craig Francis wrote: > > Hi, > > > > I've written up my suggestion for a is_literal() function: > > > > https://wiki

Re: [PHP-DEV] [RFC] is_literal()

On Sat, 21 Mar 2020 at 21:23, Jakob Givoni wrote: > On Sat, Mar 21, 2020 at 3:26 PM Craig Francis > wrote: > > > > As to the name, it's to work alongside functions such as > > is_int(), is_string(), etc - is that a good enough reason? > > I think it could cause

Re: [PHP-DEV] [RFC] is_literal()

Hi Tyson, Thanks for your email, I really appreciate it. I'm not a C developer, but if I was to have a go at implementing `is_literal()`, I probably would start with the existing taint extension. But you're right, that approach can cause performance issues, and doesn't play well with XDebug

Re: [PHP-DEV] Are PECL modules preferable?

On Sat, 21 Mar 2020 at 22:53, Mike Schinkel wrote: > A large number of PHP users have no control over the platform they run on, > so the option to use PECL modules is a non-starter for them. Thanks Mike, Personally I agree, I would say PECL modules are not preferable for "useful features";

[PHP-DEV] [RFC] is_literal()

Hi, I've written up my suggestion for a is_literal() function: https://wiki.php.net/rfc/is_literal Any feedback would be appreciated. Craig

Re: [PHP-DEV] [RFC] is_literal()

:58 PM Craig Francis > wrote: > > > I'm happy to use a different name; but I should add that is_numeric() > isn't really a type, there are other functions such as is_writable(), and > the taint extension uses is_tainted(). > > Right, good points. However, to my logic, whether

Re: [PHP-DEV] [RFC] is_literal()

fc/is_literal#taint_checking As to the name, it's to work alongside functions such as is_int(), is_string(), etc - is that a good enough reason? Craig On Sat, 21 Mar 2020 at 20:06, Ben Ramsey wrote: > > On Mar 21, 2020, at 14:13, Craig Francis > wrote: > > > > Hi, >

[PHP-DEV] Making mysqli easier to use with parameters

Hi, Considering many new developers don't use a database abstraction, and instead copy/paste mysqli_query() examples. I'm just wondering, is there a way we can make it easier to use parameterised queries? Some initial thoughts below. Craig Take this semi-complex case, in that it's

Re: [PHP-DEV] Making mysqli easier to use with parameters

On 22 Mar 2020, at 15:28, Levi Morrison wrote: > applying the ids array as `...` will handle the by-reference passing. That does help, thanks. But I still wonder if the ability to pass in a single array of parameters to `$statement->execute()` would remove a step, and be a bit easier to use

[PHP-DEV] [RFC] is_literal()

On Sun, 22 Mar 2020 at 19:11, Mike Schinkel wrote: > I think it would be better to specify the problem(s) you are trying to solve Thanks for your thoughts Mike, I've updated the RFC, tweaking the definition of a literal, and moving that to the end of the introduction, so the problems are now

Re: [PHP-DEV] is_literal() + WordPress

these "all too common" mistakes. But I do appreciate how much effort it can be to introduce anything in to WordPress :-) Craig > On 22 Mar 2020, at 19:10, Mike Schinkel wrote: > >> On Mar 21, 2020, at 7:15 PM, Craig Francis wrote: >> >> On Sat, 21 Mar

Re: [PHP-DEV] Making mysqli easier to use with parameters

ack and have talked > to a few internals folks about it off and on > > https://externals.io/message/107857#107857 > > Either way, mysqli lacks any proper way to do dynamic binds on a single > basis. This seems like low hanging fruit to make mysqli easier to use > >

[PHP-DEV] ENT_COMPAT for htmlentities and htmlspecialchars

Hi, Could htmlspecialchars() use ENT_QUOTES by default? I recently worked on an example script, where I tried to keep it simple by using htmlspecialchars directly, e.g. echo ""; I'd completely forgotten that single quotes are not escaped by default, creating a XSS vulnerability, e.g.

[PHP-DEV] Making mysqli easier to use with parameterised queries

Hi, Could the mysqli extension be tweaked to make parameterised queries easier? I've started an RFC at: https://wiki.php.net/rfc/mysqli_execute_parameters I'm going on the basis that some developers use mysqli directly, often because they want a small stand-alone script that has no

Re: [PHP-DEV] Making mysqli easier to use with parameterised queries

ng mysqli_result or null (only with mysqlnd) >> return $statement->get_result(); >> } >> } >> >> In C code, this could be easily achieved by creating a function that >> is just a mash-up of all 4 of these functions. I think this would >&

Re: [PHP-DEV] Making mysqli easier to use with parameterised queries

en though I doubt that it > will improve the state of mysqli code written by people. After all, we > can't force them to use parameter binding. > > Regards, > Kamil > > On Sat, 26 Dec 2020 at 11:23, Craig Francis > wrote: > > > > Hi, > > > > Could

Re: [PHP-DEV] ENT_COMPAT for htmlentities and htmlspecialchars

On Wed, 6 Jan 2021 at 15:46, Nikita Popov wrote: > On Sat, Dec 26, 2020 at 12:03 PM Craig Francis > wrote: > >> Hi, >> >> Could htmlspecialchars() use ENT_QUOTES by default? >> >> [...] > > > I agree that we should switch the default to

Re: [PHP-DEV] ENT_COMPAT for htmlentities and htmlspecialchars

On Thu, 7 Jan 2021 at 14:11, Claude Pache wrote: > Hi, > > > Le 26 déc. 2020 à 12:02, Craig Francis a > écrit : > > > > (...) > > PHP uses the numeric version with ENT_QUOTES, and it should > continue > > to do so - because the named version, w

Re: [PHP-DEV] ENT_COMPAT for htmlentities and htmlspecialchars

On Sat, Dec 26, 2020 at 12:03 PM Craig Francis wrote: > Could htmlspecialchars() use ENT_QUOTES by default? > [...] > I'd also be tempted to suggest ENT_SUBSTITUTE should be included, as I prefer > to keep as much of the valid data (rather than losing everything), but that's > n

Re: [PHP-DEV] MySQLi extension basic examples

On Sat, 28 Nov 2020 at 16:26, Kamil Tekiela wrote: > I would like to hear your opinions about the following page in the PHP > manual: > https://www.php.net/manual/en/mysqli.examples-basic.php Oh, wow, I didn't expect to find this on the PHP website: $aid = (int) $_GET['aid']; > ... > $sql =

Re: [PHP-DEV] Mysqli improvements

Hi Kamil, I like these proposals, especially error reporting, which I've got caught out with before: https://bugs.php.net/bug.php?id=78932 As to "add bind-in-execute to mysqli", by passing an array of parameters to mysqli_stmt::execute(), this is something I'd really like to see. I just wonder

Re: [PHP-DEV] silly question : what is more secure at the moment, php7, php8, or plain .sh shell scripts?

On Sun, 10 Jan 2021 at 08:10, Rene Veerman < rene.veerman.netherla...@gmail.com> wrote: > i run a website which i want to harden against hacking by 3rd parties. Hi Rene, I'm not sure the PHP Internals mailing list is the best place to ask for this kind of help. And what you're talking about

Re: [PHP-DEV] Mysqli bind_param and error exceptions

On Wed, 30 Dec 2020 at 18:33, Kamil Tekiela wrote: > [...] I have written an RFC which explains all my ideas. > https://wiki.php.net/rfc/improve_mysqli Hi Kamil, As there is a discussion about MySQLi raising exceptions, and you're looking at the general mysqli API... When using

Re: [PHP-DEV] [RFC] is_literal

On Mon, 14 Jun 2021 at 13:30, Dan Ackroyd wrote: > [...] it will cause some fatal errors in production. > No, the only way fatal errors can occur is if you choose to make them fatal (in userland code). I have included examples of the literal_concat() and literal_implode() functions in the

Re: [PHP-DEV] [RFC] is_literal

On Mon, 14 Jun 2021 at 09:07, Pierre wrote: > Le 14/06/2021 à 02:41, Mike Schinkel a écrit : > > A big*NO* on warnings. Full stop. > > [...] Any warning raised by the low level functions would be too > restrictive. > Hi Pierre, I'll be talking to Mike on Zoom later today (5pm UK time), which

Re: [PHP-DEV] [RFC] is_literal

On Mon, 14 Jun 2021 at 08:34, someniatko wrote: > I am sure even without a dedicated type it is still a valuable addition to > the engine [...] IMO it's okay to ship the feature without it for now. Thanks someniatko, it's certainly something I'm interested in (8.2?), as I think a dedicated

Re: [PHP-DEV] [RFC] is_literal

On Mon, 14 Jun 2021 at 11:53, Dik Takken wrote: > That sounds like a great future extension. Then it would be nice to have > the name of the new type match the name of the function that checks for > it. In case the existing 'string' type would be paired with a new > 'lstring' type the existing

[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 -

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

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 > > i

[PHP-DEV] [RFC] is_literal

e escaping). Thanks, Craig Francis PS: If anyone wants to discuss face-to-face on Zoom, I'll be available (UK Time/BST/UTC+1) at: https://chat.craigfrancis.co.uk/ Saturday 12th June, 6pm to 8pm; Sunday 13th June, 10am to Midday; Monday 14th June, 5pm to 7pm; Tuesday 15th June, 9pm to 11pm; Thursday

Re: [PHP-DEV] [RFC] is_literal

On Sat, 12 Jun 2021 at 19:59, Lauri Kenttä wrote: > Hi, > > I wrote the untaint() / make_literal() function, just in case. > > implode("", array_map(fn($c) => $chars[ord($c)], str_split($s, 1))) > > https://3v4l.org/EaN9Z#focus=rfc.literals > > Sorry and bye. > > Yes, I have a similar example

Re: [PHP-DEV] [RFC] is_literal

On Sun, 13 Jun 2021 at 07:46, Mike Schinkel wrote: > Nice! There is an awful lot to like here. > Thank you. > 1. [...] Minimally I'd ask for a separate vote on is_literal() vs. > is_from_literal(). > It would definitely be possible to have a vote on the name. I only went with

Re: [PHP-DEV] [RFC] is_literal

On Sun, 13 Jun 2021 at 20:33, someniatko wrote: [...] Have you considered [a] new `literal-string` type, which would be enforced by PHP all the time? Thanks someniatko, a "clearer intent" is a really nice way of putting it. It is something that Joe is considering, but for a future version,

Re: [PHP-DEV] [RFC] is_literal

On Sun, 13 Jun 2021 at 22:30, Matthew Brown wrote: > I was skeptical about the first draft of this RFC when I saw it last month > [...] Sorry for any unnecessary grief I caused. > Hi Matthew, actually I'd like to thank you for that early feedback, the first draft did need work doing to it, and

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 di

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

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

[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

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

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, 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

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

Re: [PHP-DEV] [RFC] is_trusted - was is_literal

On Tue, 22 Jun 2021 at 12:18 am, Benjamin Morel wrote: > On Tue, 22 Jun 2021 at 01:06, Derick Rethans wrote: > >> On 21 June 2021 23:37:56 BST, Yasuo Ohgaki wrote: >> > >> >The name "is_trusted" is misleading. >> >Literal is nothing but literal. >> >> I agree with this. The name is_trusted is

Re: [PHP-DEV] [RFC] is_literal

On Fri, 18 Jun 2021 at 1:30 pm, Mike Schinkel wrote: > For the avoidance of doubt can you confirm that this $sql would indeed be > trusted? > > $ids = array_map( 'intval', $_GET['ids'] ?? [] ); > > $where = implode( ',', $ids ); > $sql = 'SELECT * FROM foo WHERE id IN (' . $where . ')'; > > >

Re: [PHP-DEV] [RFC] is_trusted - was 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 > To recap, - We have chosen the name is_trusted(), based 18 votes for, vs 3 against. - Integers are now included, which will help

Re: [PHP-DEV] [RFC] is_trusted - was is_literal

On Mon, 21 Jun 2021 at 11:38 pm, Yasuo Ohgaki wrote: > Hi, > > The name "is_trusted" is misleading. > Literal is nothing but literal. > > > eval('$var= '. $_GET['a'] ); > > if (is_trusted($var)) echo $var; > ?> > > > Literals cannot always be trusted. > That’s explained in the RFC, under

Re: [PHP-DEV] [RFC] is_trusted - was is_literal

On Tue, 22 Jun 2021 at 11:31 am, Hans Henrik Bergan wrote: > How is one supposed to use this? like > > if(!is_trusted($val)){ > $val = htmlentities($str, ENT_QUOTES | ENT_HTML401 | ENT_SUBSTITUTE | > ENT_DISALLOWED, 'UTF-8', true); > } > echo "$val"; No, if anything that’s the opposite,

Re: [PHP-DEV] [RFC] is_trusted - was is_literal

On Tue, 22 Jun 2021 at 09:59, Stephen Reay wrote: > So I just want to make sure I understand the progression on this so far. > It started out with people wanting a way to check that a string was a > literal string, in code somewhere, and does not come from user input. Ok > makes sense. The name

Re: [PHP-DEV] [RFC] is_trusted - was is_literal

On Tue, 22 Jun 2021 at 3:05 pm, Stephen Reay wrote: > > On 22 Jun 2021, at 20:13, Craig Francis wrote: > > On Tue, 22 Jun 2021 at 09:59, Stephen Reay > wrote: > >> So I just want to make sure I understand the progression on this so far. >> It started out with

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] 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.

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

[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

[PHP-DEV] Injection vulnerabilities

Hi Internals, Just something for you to think about, to start the conversation (as the 8.1 deadline is fast approaching). Injection Vulnerabilities remain on the OWASP Top 10 List, same with XSS. https://owasp.org/www-project-top-ten/2017/ These mistakes happen when user supplied values are

[PHP-DEV] Re: Injection vulnerabilities

Hi Internals, To follow up on yesterdays post [1]... We *could* try to teach programmers to never make a mistake (yep, you can stop laughing). Take the previous example: $html = ""; We might be able to teach everyone to always quote their attributes (or use a different form of encoding):

[PHP-DEV] Re: Injection vulnerabilities

Fine, I'll finish with this... We know that HTML [3] and SQL [4] should be written by the programmer, with user data being handled *separately*. The same applies to OS Commands: $command = 'rm -rf ?'; Because we're using parameters (to escape the user values properly), we don't need to

  1   2   3   >