Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:112383
User-Agent: Cyrus-JMAP/3.3.0-622-g4a97c0b-fm-20201115.001-g4a97c0b3
Mime-Version: 1.0
Message-ID: <8d324ed9-2267-4334-95dd-f840816629f0@www.fastmail.com>
In-Reply-To: <23E6CF0B-77EF-4358-9576-BCB7919154A5@cschneid.com>
References: <b845d5bf-63da-d564-1f0f-cc934188d693@aimeos.com>
 <b546b5bf-27f8-62cc-cc4b-d859132998a4@gmx.de>
 <CAN2symjht9iZLDhYEKCYb9V7B4xEoHBG8MFMoAVQS55OKzWC7Q@mail.gmail.com>
 <CAFPFaM+Np_jQgDFr8vV8TofYyLMZ0EDWmt3+yr1_KQzJTbW6MQ@mail.gmail.com>
 <CAFPFaMLULyFB0R14rQGCPmzZdXUSg81rHJQEQPRK2C6tDK6__w@mail.gmail.com>
 <cf5d6d15-a50c-caba-79fd-a615391121dc@aimeos.com>
 <3dd3c22d-0959-5425-46b1-dade4ac75b00@rhsoft.net>
 <f433784d-41bf-6a22-e34b-4d0f8b57f925@gmail.com>
 <d0b78b71-e8f3-0e50-c934-71aa8fc2cfe1@rhsoft.net>
 <23E6CF0B-77EF-4358-9576-BCB7919154A5@cschneid.com>
Date: Wed, 02 Dec 2020 14:48:22 -0600
To: "php internals" <internals@lists.php.net>
Content-Type: text/plain;charset=utf-8
Content-Transfer-Encoding: quoted-printable
Subject: Re: [PHP-DEV] PHP 8 is_file/is_dir input handling
From: larry@garfieldtech.com ("Larry Garfield")

On Wed, Dec 2, 2020, at 2:18 AM, Christian Schneider wrote:
> Am 01.12.2020 um 21:13 schrieb Reindl Harald (privat) <harry@rhsoft.ne=
t>:
> > 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 ti=
me
> >> believing, honestly, but who knows), there is a very major distinct=
ion.
> >=20
> > my server would trigger a mail every 15 minutes wioth all warnings a=
nd notices to enforce fixing the issue
>=20
> Out of curiosity: What is your fix?
>=20
> Because we are running into this issue with fuzzers bombarding our=20
> website with all types of illegal parameters, string containing 0-byte=
s=20
> amongst them.
>=20
> Our solution was to basically throw away all user input containing=20
> 0-bytes (except $_FILES) which feels awkward but was the only way to=20=

> avoid these messages (and in some cases exceptions) consistently.
>=20
> Concerning the original question:
> My personal preference in this specific case is Stas=E2=80=99 way: is_=
file() is=20
> a low-level function and should simply return false for *anything*=20
> which is not a valid, existing filename. Having *everything* involving=
=20
> paths warn/throw an exception when 0-bytes are involved is an overly=20=

> broad generalization.
>=20
> I challenge everybody to show me how changing is_file() to simply=20
> return false (while keeping more high-level functions like, say, popen=
=20
> throwing an exception) leads to a security hole.
>=20
> In my preferred world the following code would be both safe and=20
> guaranteed to report =E2=80=9EFile not found=E2=80=9C on any invalid i=
nput:
> 	If (is_file($filename))
> 		do_something($filename);
> 	else
> 		message("File not found=E2=80=9C);
>=20
> I=E2=80=99ll try to put a PR together for FileFunction() because I thi=
nk those=20
> functions should all handle 0-bytes like non-existing files.
>=20
> - Chris

I'm inclined to agree here.  An is_*() function isn't asking why somethi=
ng isn't a legit file; "missing" and "it's a stupid name anyway and it s=
hould feel bad" and "the disk is missing" are all the same thing as far =
as it's concerned.  All it's asking is "if I try to open this file, shou=
ld I expect it to work?"

Having it throw an exception in some cases, it's understandable how that=
 ends up happening, but from a user/API point of view it's still incorre=
ct.

--Larry Garfield