Am 01.12.2020 um 21:13 schrieb Reindl Harald (privat) <ha...@rhsoft.net>:
> Am 01.12.20 um 21:09 schrieb Stanislav Malyshev:
>>> we are running error_reporting E_ALL for 17 years now and don't
>>> distinct between notice / warning / error, it has to be fixed -
>>> period
>> Surely you do. Your code continues to run after warning/notice but stops
>> after the error. It's impossible to ignore that. Unless you have an
>> error handler that does exit() after a notice (which I have hard time
>> believing, honestly, but who knows), there is a very major distinction.
>
> my server would trigger a mail every 15 minutes wioth all warnings and
> notices to enforce fixing the issue
Out of curiosity: What is your fix?
Because we are running into this issue with fuzzers bombarding our website with
all types of illegal parameters, string containing 0-bytes amongst them.
Our solution was to basically throw away all user input containing 0-bytes
(except $_FILES) which feels awkward but was the only way to avoid these
messages (and in some cases exceptions) consistently.
Concerning the original question:
My personal preference in this specific case is Stas’ way: is_file() is a
low-level function and should simply return false for *anything* which is not a
valid, existing filename. Having *everything* involving paths warn/throw an
exception when 0-bytes are involved is an overly broad generalization.
I challenge everybody to show me how changing is_file() to simply return false
(while keeping more high-level functions like, say, popen throwing an
exception) leads to a security hole.
In my preferred world the following code would be both safe and guaranteed to
report „File not found“ on any invalid input:
If (is_file($filename))
do_something($filename);
else
message("File not found“);
I’ll try to put a PR together for FileFunction() because I think those
functions should all handle 0-bytes like non-existing files.
- Chris
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
