Re: PHP 8 is_file/is_dir input handling

Am 01.12.2020 um 21:13 schrieb Reindl Harald (privat) <harry@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