Hi internals team,
The discussion of extending the .ini env variable parsing capabilities with
ability to specify defaults it occurred to me that the while feature of env
variables may have undesirable security implications.
For instance, functions parse_ini_string() and parse_ini_file() do support the
aforementioned env variables syntax, because the underlying code is reused.
That means that these functions can potentially be exploited to read sensitive
information!
For example:
AWS_SECRET_ACCESS_KEY=amazonWebServicesSecretAccessKeyExample1 php -r
'var_export(parse_ini_string("secret=\${AWS_SECRET_ACCESS_KEY}"));'
array (
'secret' => 'amazonWebServicesSecretAccessKeyExample1',
)
This only affects INI_SCANNER_NORMAL (the default). Should the mode argument be
changed to disallow the env parsing by default? Perhaps another constant can be
introduced to activate it, for example:
INI_SCANNER_NORMAL | INI_SCANNER_PARSE_ENV
This would be a BC breaking behavior but it's doubtful many people expected the
env variable parsing syntax to extend to parse_ini_file/string() functions in
the first place.
P.S.
My email client doesn't properly support the top-reply and/or quoting
requirements of the mailing list. That's what made me disengage from the
mailing list to not annoy anybody with butchered reply threads until I find
time to migrate to another email client.
Here's a related tweet of mine:
https://twitter.com/SergiiShymko/status/1679598903925129222?s=20
Regards,
Sergii Shymko
