Re: [RFC] [Discussion] array_get and array_has functions

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