Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:130569
Feedback-ID: ifab94697:Fastmail
Precedence: list
MIME-Version: 1.0
Date: Sun, 05 Apr 2026 11:12:02 +0200
Cc: internals@lists.php.net
Message-ID: <e1027599-93c1-4a73-b55f-497523ab0aa1@app.fastmail.com>
In-Reply-To: <1775376880059.1437066672.2965818070@yahoo.de>
References: <2c0a3342-aba5-4ca2-969e-350dd4cfcd9d@app.fastmail.com>
 <1775376880059.1437066672.2965818070@yahoo.de>
Subject: Re: [PHP-DEV] [RFC] [Discussion] array_get and array_has functions
Content-Type: multipart/alternative;
 boundary=c4adfbe89985415f8bc6f3446a3f3ccc
From: rob@bottled.codes ("Rob Landers")

--c4adfbe89985415f8bc6f3446a3f3ccc
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable



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 smal=
l, focused array functions for retrieving and checking nested array elem=
ents using dot notation.
> > >=20
> > > This is the link to the RFC: https://wiki.php.net/rfc/array_get_an=
d_array_has
> > >=20
> > > This is the link to the proposed implementation: https://github.co=
m/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 s=
ee it discussed as part of the RFC, how are developers to prevent inject=
ions 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 possib=
le 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 t=
hat already does this sort of notation.
>=20
> I wouldn=E2=80=99t go that far, but I=E2=80=99d like to start by empha=
sizing that the dot notation described here clearly does not provide a m=
echanism for escaping the dot. That=E2=80=99s probably a shortcoming, bu=
t 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

My point is that this is different and distinct from regular array vulne=
rabilities and injections.

$user['data'][$key] !=3D=3D array_get($user['data'], $key, null);

In the former 'some.key' is a full key; in the latter, it would access [=
'some']['key'].

Further, the former could be a valid key, but there is no way to access =
it using the proposed RFC

=E2=80=94 Rob
--c4adfbe89985415f8bc6f3446a3f3ccc
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE html><html><head><title></title></head><body><div><br></div><d=
iv><br></div><div>On Sun, Apr 5, 2026, at 10:22, Hans Krentel wrote:</di=
v><blockquote type=3D"cite" id=3D"qt" style=3D""><div><br></div><div><br=
></div><div><br></div><div><br></div><div>On Sunday 05 April 2026 08:51:=
30 (+02:00), Rob Landers wrote:</div><div><br></div><div>&gt; On Sat, Ap=
r 4, 2026, at 16:06, Barel wrote:</div><div>&gt; &gt; Hi,</div><div>&gt;=
 &gt;&nbsp;</div><div>&gt; &gt; I would like to open the discussion on m=
y proposal to add two small, focused array functions for retrieving and =
checking nested array elements using dot notation.</div><div>&gt; &gt;&n=
bsp;</div><div>&gt; &gt; This is the link to the RFC:&nbsp;<a href=3D"ht=
tps://wiki.php.net/rfc/array_get_and_array_has">https://wiki.php.net/rfc=
/array_get_and_array_has</a></div><div>&gt; &gt;&nbsp;</div><div>&gt; &g=
t; This is the link to the proposed implementation:&nbsp;<a href=3D"http=
s://github.com/php/php-src/pull/21637">https://github.com/php/php-src/pu=
ll/21637</a></div><div>&gt; &gt;&nbsp;</div><div>&gt; &gt; Thanks!!</div=
><div>&gt; &gt;&nbsp;</div><div>&gt; &gt; Carlos</div><div>&gt;&nbsp;</d=
iv><div>&gt; Hi Barel,</div><div>&gt;&nbsp;</div><div>&gt; Interesting! =
As dot-notation isn't used anywhere else, and I don't see it discussed a=
s part of the RFC, how are developers to prevent injections of dots in u=
ser input? With SQL, we have parameters and escaping ... but I don't see=
 any of that here.</div><div>&gt;&nbsp;</div><div>&gt; As an example:</d=
iv><div>&gt;&nbsp;</div><div>&gt; $user =3D [ 'data' =3D&gt; [...], 'pas=
sword' =3D&gt; 'secret' ];</div><div>&gt;&nbsp;</div><div>&gt; If the pa=
th is completely user-controlled (as in the examples given), then they c=
an access sensitive information in the array. Even if it is prefixed, ie=
., "data.%s" -- an attacker can simply enumerate all possible keys and s=
ubkeys.</div><div>&gt;&nbsp;</div><div>&gt; As it stands, it appears to =
add a new vulnerability to PHP that will be unfamiliar with PHP develope=
rs -- unless they're using a framework that already does this sort of no=
tation.</div><div><br></div><div>I wouldn=E2=80=99t go that far, but I=E2=
=80=99d like to start by emphasizing that the dot notation described her=
e clearly does not provide a mechanism for escaping the dot. That=E2=80=99=
s probably a shortcoming, but if any user-supplied string key poses a se=
curity risk, then PHP arrays are also affected, and this vulnerability w=
ould be nothing new! (Rather, it would be to be expected.)</div><div><br=
></div><div>-- hakre</div><div><br></div></blockquote><div><br></div><di=
v>My point is that this is different and distinct from regular array vul=
nerabilities and injections.</div><div><br></div><pre style=3D"border-to=
p-width:1px;border-right-width:1px;border-bottom-width:1px;border-left-w=
idth:1px;border-top-style:solid;border-right-style:solid;border-bottom-s=
tyle:solid;border-left-style:solid;border-top-color:rgb(204, 204, 204);b=
order-right-color:rgb(204, 204, 204);border-bottom-color:rgb(204, 204, 2=
04);border-left-color:rgb(204, 204, 204);border-image-source:initial;bor=
der-image-slice:initial;border-image-width:initial;border-image-outset:i=
nitial;border-image-repeat:initial;border-top-left-radius:3px;border-top=
-right-radius:3px;border-bottom-right-radius:3px;border-bottom-left-radi=
us:3px;background-image:initial;background-position-x:initial;background=
-position-y:initial;background-size:initial;background-repeat:initial;ba=
ckground-attachment:initial;background-origin:initial;background-clip:in=
itial;background-color:rgb(246, 246, 246);font-family:menlo, consolas, m=
onospace;font-size:90%;margin-top:7px;margin-right:0px;margin-bottom:7px=
;margin-left:0px;padding-top:7px;padding-right:10px;padding-bottom:7px;p=
adding-left:10px;white-space-collapse:preserve;text-wrap-mode:wrap;overf=
low-wrap:break-word;">$user['data'][$key] !=3D=3D array_get($user['data'=
], $key, null);</pre><div><br></div><div>In the former 'some.key' is a f=
ull key; in the latter, it would access ['some']['key'].</div><div><br><=
/div><div>Further, the former could be a valid key, but there is no way =
to access it using the proposed RFC</div><div><br></div><div id=3D"sig12=
1229152">=E2=80=94 Rob</div></body></html>
--c4adfbe89985415f8bc6f3446a3f3ccc--