Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:130575 X-Original-To: internals@lists.php.net Delivered-To: internals@lists.php.net Received: from php-smtp4.php.net (php-smtp4.php.net [45.112.84.5]) by lists.php.net (Postfix) with ESMTPS id E0C621A00BC for ; Sun, 5 Apr 2026 11:12:04 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=php.net; s=mail; t=1775387529; bh=DrKyFQy8OjJYixwqeIDRVo3aTx8ZQPJNjQaGZkju3yA=; h=Date:From:To:Cc:In-Reply-To:References:Subject:From; b=hEZOi6AKaDtg0qUvsdOPVjNgZTSh1JvoCCa20Skou31MEAAKgQQYonOdRMp13uCjL bvNSYNhNfdbnUIMmB5Z/aHQE+Huc9nn0mWpel0hh0Db3EVMhP5/IlPsPKS3DZQ2aST lVOkMBpwov6odJefukj5EJcLtQd2RpraDj4MDR4RBCo/G0MpHWTLdYx1VMcw8lRU8s qGZ36pv22b6qhtu+ElqmFs4jcGeeEMEICu+nuLjw4HCkTAtzWIlGZQIW3EufPhF0Ou 28XLreQXJaOUV3WlqcCYSzPKZrjqH4QS7eFj9Tn9lMOcF2s6WShDkpXimEG0WyomS8 rSAbnAlgqU8Mg== Received: from php-smtp4.php.net (localhost [127.0.0.1]) by php-smtp4.php.net (Postfix) with ESMTP id 02783180068 for ; Sun, 5 Apr 2026 11:12:08 +0000 (UTC) X-Spam-Checker-Version: SpamAssassin 4.0.1 (2024-03-25) on php-smtp4.php.net X-Spam-Level: X-Spam-Status: No, score=-0.1 required=5.0 tests=BAYES_50,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,DMARC_MISSING,HTML_MESSAGE, RCVD_IN_DNSWL_LOW,SPF_HELO_PASS,SPF_PASS autolearn=no autolearn_force=no version=4.0.1 X-Spam-Virus: No X-Envelope-From: Received: from fhigh-a6-smtp.messagingengine.com (fhigh-a6-smtp.messagingengine.com [103.168.172.157]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by php-smtp4.php.net (Postfix) with ESMTPS for ; Sun, 5 Apr 2026 11:11:57 +0000 (UTC) Received: from phl-compute-12.internal (phl-compute-12.internal [10.202.2.52]) by mailfhigh.phl.internal (Postfix) with ESMTP id 76A611400058; Sun, 5 Apr 2026 07:11:52 -0400 (EDT) Received: from phl-imap-05 ([10.202.2.95]) by phl-compute-12.internal (MEProxy); Sun, 05 Apr 2026 07:11:52 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bottled.codes; h=cc:cc:content-type:content-type:date:date:from:from :in-reply-to:in-reply-to:message-id:mime-version:references :reply-to:subject:subject:to:to; s=fm3; t=1775387512; x= 1775473912; bh=DrKyFQy8OjJYixwqeIDRVo3aTx8ZQPJNjQaGZkju3yA=; b=X asMgCI2gPMJH0H1hgqVGwSop7y0yCHkTn/YN7uwX2Pbc2GAm4v5sNVdhuTk64NkN J9Fga+w7rave0WGWKxWZqSUOtFaZJGA/N5ET7amTMLH1KZfjexAY7AobK6TPrevA uvqiqitYmYAtalWbf0wKCyDyNWp/wD2bECnK7MLzkOrckJ+9VZCc+Pklg1t0I5f1 D1RskF818hKKGqk0tuR2iqYMcUYJ0/KIidJNne74Tpzo4NWfYeCU3PYgPSjVHaj6 UYHGsshjGcXCuyxYiKEJAxQZGW1fBjSAoJKSQ+hTRcdIdPfAvBVvxPYAsd3ZS5IB 0ViC5uFO9s6CBslX5LM0A== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:cc:content-type:content-type:date:date :feedback-id:feedback-id:from:from:in-reply-to:in-reply-to :message-id:mime-version:references:reply-to:subject:subject:to :to:x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm2; t= 1775387512; x=1775473912; bh=DrKyFQy8OjJYixwqeIDRVo3aTx8ZQPJNjQa GZkju3yA=; b=AkDvR63IOSJsuGgMOAzSuJFfSFYKl9szHPiDH8dDjr93KL8CsJF 3offcG23tpUjUWYdW3W2pQ9AaHbaqGKEIiwO0pgH8YApIS9HIE1JMbpjFMHvPsjx WKsLqPQyEZhC/i5Y8ni+2JfTSu1X47eOdlkQDXWQz6YJwE905FWHvju/9xbxxdJQ pc93AWwJADF/p5hptS0KkQX3srZYxhqPkEB5RBwuDg2xylsIxjzf7SMSWr5jZai6 UTDtoUEmmaQqgiuABwfp2TznkpJLr08UNRRnBVeaWkUjZd28JmkJsfY4ig5fqetr SghJNgW6tnHbswmf/QquOwiRh7yMpCNwLpw== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeefhedrtddtgddugeeitdcutefuodetggdotefrod ftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpuffrtefokffrpgfnqfghnecuuegr ihhlohhuthemuceftddtnecunecujfgurhepofggfffhvfevkfgjfhfutgesrgdtreerre dtjeenucfhrhhomhepfdftohgsucfnrghnuggvrhhsfdcuoehrohgssegsohhtthhlvggu rdgtohguvghsqeenucggtffrrghtthgvrhhnpeetfeffgedvudelgeekvdeuvdfhieffgf fgvddujeeikedtledtgfekveefgefgfeenucffohhmrghinhepphhhphdrnhgvthdpghhi thhhuhgsrdgtohhmnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilh hfrhhomheprhhosgessghothhtlhgvugdrtghouggvshdpnhgspghrtghpthhtohepvddp mhhouggvpehsmhhtphhouhhtpdhrtghpthhtohepsggrrhgvlhdrsggrrhgvlhhonhesgh hmrghilhdrtghomhdprhgtphhtthhopehinhhtvghrnhgrlhhssehlihhsthhsrdhphhhp rdhnvght X-ME-Proxy: Feedback-ID: ifab94697:Fastmail Received: by mailuser.phl.internal (Postfix, from userid 501) id 15037182007A; Sun, 5 Apr 2026 07:11:52 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface Precedence: list list-help: list-unsubscribe: list-post: List-Id: x-ms-reactions: disallow MIME-Version: 1.0 X-ThreadId: AeWzGyuMXtOs Date: Sun, 05 Apr 2026 13:10:59 +0200 To: Barel Cc: internals@lists.php.net Message-ID: In-Reply-To: References: <2c0a3342-aba5-4ca2-969e-350dd4cfcd9d@app.fastmail.com> Subject: Re: [PHP-DEV] [RFC] [Discussion] array_get and array_has functions Content-Type: multipart/alternative; boundary=745868c6669641c9a1cc41e983486f60 From: rob@bottled.codes ("Rob Landers") --745868c6669641c9a1cc41e983486f60 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On Sun, Apr 5, 2026, at 11:34, Barel wrote: > On Sun, 5 Apr 2026 at 08:54, Rob Landers wrote: >> __ >> 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 elemen= ts 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 se= e it discussed as part of the RFC, how are developers to prevent injecti= ons 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 possibl= e 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 th= at already does this sort of notation. >>=20 >> =E2=80=94 Rob >=20 > Thanks Rob. Probably user input is not the best use case for these fun= ctions, I just used it in the examples because it is simple. And quite dangerous. I=E2=80=99d recommend using realistic examples that= showcase the work instead of simple examples that scream =E2=80=9Chack = me=E2=80=9D to anyone who=E2=80=99s written PHP more than a few years.=20 > In any case, if your program allows unrestricted array access using a = user defined path, the vulnerability already exists, these functions jus= t make it easier to implement the access.=20 That=E2=80=99s the rub, right? Array access simply cannot have a user-de= fined array path today. This feature allows that but as of this reply, t= he RFC does not disclose the danger of such a thing despite using it in = the examples. It=E2=80=99s either irresponsible or na=C3=AFve. > If you did not have them and wanted the same functionality you would u= se a custom implementation (like the one provided by Laravel) and you wo= uld have the same vulnerability=20 >=20 > Cheers >=20 > Carlos Different frameworks and implementations assign different semantics. I=E2= =80=99ve seen dots (such as in laravel), slashes, double back-slashes, e= tc. over the years. I think dots is a fine choice, but it is worth point= ing out that, currently, array keys are binary-safe. These simple lookin= g functions completely ignore that. Even if you escape the dots, now you= have two variables: $escaped_key (for use in these functions) and $unes= caped_key.=20 I see that wildcards are also being considered in the future. Maybe, ins= tead of adding two thin utility functions to global space, it would be b= etter to create an QueryableArray class =E2=80=A6 kinda like Linq in C# = =E2=80=A6 to handle this type of stuff? Otherwise, this becomes a slippe= ry slope of assigning semantics to random byte sequences. If you=E2=80=99re going to add query semantics to arrays, do it properly= .=20 =E2=80=94 Rob --745868c6669641c9a1cc41e983486f60 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable


On Sun, Apr 5, 2026, at 11:34, Barel wrote:
On Sun, 5 Apr 2026 at 08:54, Rob Landers <rob@bottled.codes> w= rote:
<= u>
On Sat, Apr 4, 2026, at 16:06, Barel wrote:
Hi,

I would like to open the di= scussion on my proposal to add two small, focused array functions for re= trieving and checking nested array elements using dot notation.


This is = the link to the proposed implementation: https://github.com/php/php= -src/pull/21637

Thanks!!
Carlos

Hi Barel= ,

Interesting! As dot-notation isn't used anywh= ere else, and I don't see it discussed as part of the RFC, how are devel= opers to prevent injections of dots in user input? With SQL, we have par= ameters and escaping ... but I don't see any of that here.
As an example:

$user =3D [ 'data' =3D> [...], 'password' =3D> 'secret' ];

If the path is completely user-controlled (as in =
the examples given), then they can access sensitive information in the a=
rray. Even if it is prefixed, ie., "data.%s" -- an attacker can simply e=
numerate all possible keys and subkeys.

As it s=
tands, it appears to add a new vulnerability to PHP that will be unfamil=
iar with PHP developers -- unless they're using a framework that already=
 does this sort of notation.

=E2=80=94 Rob
Thanks Rob. Probably user input is not the best use case for= these functions, I just used it in the examples because it is simple.

And quite dangerous. I=E2= =80=99d recommend using realistic examples that showcase the work instea= d of simple examples that scream =E2=80=9Chack me=E2=80=9D to anyone who= =E2=80=99s written PHP more than a few years. 

=
In any case, if you= r program allows unrestricted array access using a user defined path, th= e vulnerability already exists, these functions just make it easier to i= mplement the access.

= That=E2=80=99s the rub, right? Array access simply cannot have a user-de= fined array path today. This feature allows that but as of this reply, t= he RFC does not disclose the danger of such a thing despite using it in = the examples. It=E2=80=99s either irresponsible or na=C3=AFve.
<= /div>

= If you did not have them and wanted the same functionality you would use= a custom implementation (like the one provided by Laravel) and you woul= d have the same vulnerability 

Cheers=

Carlos

Different frameworks and implementations assign differe= nt semantics. I=E2=80=99ve seen dots (such as in laravel), slashes, doub= le back-slashes, etc. over the years. I think dots is a fine choice, but= it is worth pointing out that, currently, array keys are binary-safe. T= hese simple looking functions completely ignore that. Even if you escape= the dots, now you have two variables: $escaped_key (for use in these fu= nctions) and $unescaped_key. 

I see that w= ildcards are also being considered in the future. Maybe, instead of addi= ng two thin utility functions to global space, it would be better to cre= ate an QueryableArray class =E2=80=A6 kinda like Linq in C# =E2=80=A6 to= handle this type of stuff? Otherwise, this becomes a slippery slope of = assigning semantics to random byte sequences.

I= f you=E2=80=99re going to add query semantics to arrays, do it properly.=  

=E2=80=94 Rob
<= /body> --745868c6669641c9a1cc41e983486f60--