On Sunday 05 April 2026 11:12:02 (+02:00), Rob Landers wrote:
>
>
> On Sun, Apr 5, 2026, at 10:22, Hans Krentel wrote:
> >
> >
> >
> >
> > On Sunday 05 April 2026 08:51:30 (+02:00), Rob Landers wrote:
> >
> > > On Sat, Apr 4, 2026, at 16:06, Barel wrote:
> > > > Hi,
> > > >
> > > > 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.
> > > >
> > > > This is the link to the RFC:
> > > > https://wiki.php.net/rfc/array_get_and_array_has
> > > >
> > > > 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 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.
> > >
> > > As an example:
> > >
> > > $user = [ 'data' => [...], 'password' => 'secret' ];
> > >
> > > 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.
> > >
> > > 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.
> >
> > I wouldn’t go that far, but I’d like to start by emphasizing that the dot
> > notation described here clearly does not provide a mechanism for escaping
> > the dot. That’s 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.)
> >
> > -- hakre
> >
>
> My point is that this is different and distinct from regular array
> vulnerabilities and injections.
>
> $user['data'][$key] !== array_get($user['data'], $key, null);
>
> 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—though in the function name, not the parameter name—but I’d
have to look it up to find out the exact details.
However, I don’t 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’t expect that !== must be
equal to ===.
>
> 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—I 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’t 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’ve raised—even though, in my
opinion, you’ve made good points with your distinctions.
-- hakre
