Re: Security implications of parsing env variables in .ini
| From: | Tim Düsterhus | Date: | Mon, 17 Jul 2023 12:52:57 +0000 |
| Subject: | Re: Security implications of parsing env variables in .ini | ||
| References: | 1 2 3 4 | Groups: | php.internals |
| Request: | Send a blank email to internals+get-120823@lists.php.net to get a copy of this message | ||
Hi
On 7/14/23 18:03, David Gebler wrote:
Defaults matter. Developers should not need to provide INI_SCANNER_PLEASE_DONT_PWN_ME to safely use a function. Yes, the function is documented to behave "like php.ini's parsing", but injecting potentially sensitive environment variables still violates the principle of least surprise for me. Nothing about the function's behavior or documentation indicates that it might be unsafe to use with untrusted input data. A short term improvement might be adding an explicit yellow warning to the documentation page. Best regards Tim Düsterhus2) These expansions should probably be disabled by INI_SCANNER_RAW; that flag already disables certain other types of value interpolation. (Oddly, it doesn't disable expansion of constants either; that might be worth revisiting as well.)Environment variable parsing is already disabled by INI_SCANNER_RAW mode, isn't it? Personally I don't think the default/normal mode should behave differently. If you're passing untrusted input to parse_ini_string, you should be sanitizing, white listing or using raw mode anyway really.