Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:130576
Content-Type: text/plain; charset=utf-8
Message-ID: <1775386552370.2592038250.1050472667@yahoo.de>
To: rob@bottled.codes
Cc: internals@lists.php.net, Barel <barel.barelon@gmail.com>
Subject: Re: [PHP-DEV] [RFC] [Discussion] array_get and array_has functions
Date: Sun, 05 Apr 2026 11:24:26 +0000
In-Reply-To: <e1027599-93c1-4a73-b55f-497523ab0aa1@app.fastmail.com>
References: <e1027599-93c1-4a73-b55f-497523ab0aa1@app.fastmail.com>
User-Agent: Vivaldi Mail/7.9.3970.47
Content-Transfer-Encoding: quoted-printable
Precedence: list
MIME-Version: 1.0
From: hanskrentel@yahoo.de (Hans Krentel)





On Sunday 05 April 2026 11:12:02 (+02:00), Rob Landers wrote:

>=20
>=20
> On Sun, Apr 5, 2026, at 10:22, Hans Krentel wrote:
> >=20
> >=20
> >=20
> >=20
> > On Sunday 05 April 2026 08:51:30 (+02:00), Rob Landers wrote:
> >=20
> > > On Sat, Apr 4, 2026, at 16:06, Barel wrote:
> > > > Hi,
> > > >=20
> > > > I would like to open the discussion on my proposal to add two small=
, focused array functions for retrieving and checking nested array elements=
 using dot notation.
> > > >=20
> > > > This is the link to the RFC: https://wiki.php.=
net/rfc/array_get_and_array_has
> > > >=20
> > > > This is the link to the proposed implementation: https://github.=
com/php/php-src/pull/21637
> > > >=20
> > > > Thanks!!
> > > >=20
> > > > Carlos
> > >=20
> > > Hi Barel,
> > >=20
> > > Interesting! As dot-notation isn't used anywhere else, and I don't =
see it discussed as part of the RFC, how are developers to prevent =
injections of dots in user input? With SQL, we have parameters and escaping=
 ... but I don't see any of that here.
> > >=20
> > > As an example:
> > >=20
> > > $user =3D [ 'data' =3D> [...], 'password' =3D> 'secret' ];
> > >=20
> > > If the path is completely user-controlled (as in the examples given),=
 then they can access sensitive information in the array. Even if it is =
prefixed, ie., "data.%s" -- an attacker can simply enumerate all possible =
keys and subkeys.
> > >=20
> > > As it stands, it appears to add a new vulnerability to PHP that will =
be unfamiliar with PHP developers -- unless they're using a framework that =
already does this sort of notation.
> >=20
> > I wouldn=E2=80=99t go that far, but I=E2=80=99d like to start by =
emphasizing that the dot notation described here clearly does not provide a=
 mechanism for escaping the dot. That=E2=80=99s probably a shortcoming, but=
 if any user-supplied string key poses a security risk, then PHP arrays are=
 also affected, and this vulnerability would be nothing new! (Rather, it =
would be to be expected.)
> >=20
> > -- hakre
> >=20
>=20
> My point is that this is different and distinct from regular array =
vulnerabilities and injections.
>=20
> $user['data'][$key] !=3D=3D array_get($user['data'], $key, null);
>=20
> In the former 'some.key' is a full key; in the latter, it would access =
['some']['key'].

For the sake of this discussion, it would probably make sense to use =
$dot_path or $dot_pointer instead of $key in this function; this would make=
 the distinction clearer. If I recall correctly, this was already suggested=
 earlier in the discussion=E2=80=94though in the function name, not the =
parameter name=E2=80=94but I=E2=80=99d have to look it up to find out the =
exact details.

However, I don=E2=80=99t see any difference from accessing a standard array=
, apart from the fact that the first parameter contains a container object =
in the domain and the standard variable on the left-hand side; I =
wouldn=E2=80=99t expect that !=3D=3D must be equal to =3D=3D=3D.

>=20
> Further, the former could be a valid key, but there is no way to access =
it using the proposed RFC

If I'm not mistaken, this is due to the lack of an escape mechanism, which =
could very well be intentional=E2=80=94I don't know for sure, but in =
another thread, Carlos wrote that they want to reconsider this.

And even if it were intentional, without an escape mechanism, it would fall=
 back to the value of the default parameter. Technically speaking, I =
don=E2=80=99t see a problem here, unless this is unintended or would, in =
good faith, violate expectations regarding key-value pairs.

Neither of these is a new security issue that you=E2=80=99ve =
raised=E2=80=94even though, in my opinion, you=E2=80=99ve made good points =
with your distinctions.

-- hakre