Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:95548
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain ohgaki.net designates 180.42.98.130 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <232F1604-2211-4351-B830-EDC958A25D6D@strojny.net>
References: <CAGa2bXarw2jTj0yhXpywWNQOJLR2pdhfaqSdwj_btT2giEL15Q@mail.gmail.com>
 <CAGa2bXaA+uvh_wpRAHeiv+Xb-JOrTAkyoe3jzq3FVCEbfja_5w@mail.gmail.com> <232F1604-2211-4351-B830-EDC958A25D6D@strojny.net>
Date: Fri, 2 Sep 2016 09:25:20 +0900
Message-ID: <CAGa2bXb2y4afY28rwdcjgxUEkr41ZPMMdj4dUtMDVtJLBONAbA@mail.gmail.com>
To: Lars Strojny <lars@strojny.net>
Cc: "internals@lists.php.net" <internals@lists.php.net>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Subject: Re: [PHP-DEV] [RFC][VOTE] Add validation functions to filter module
From: yohgaki@ohgaki.net (Yasuo Ohgaki)

Hi Lars,

On Thu, Sep 1, 2016 at 8:59 PM, Lars Strojny <lars@strojny.net> wrote:
>> On 31 Aug 2016, at 21:45, Yasuo Ohgaki <yohgaki@ohgaki.net> wrote:
> [...]
>> Thank you for voting!
>> The RFC is declined 1 vs 13
>> A bit surprised this result.
>>
>> I requested the reason of objection, but many of them does not disclose =
why.
> [...]
>> lstrojny (lstrojny)
> [...]
>
> sorry for not chiming in earlier, but I indeed owe you an explanation. I =
believe making ext/filter a part of PHP created more trouble than it solved=
, even though I applaud it=E2=80=99s intention. Of course, filtering and va=
lidation are necessary essentials of any secure web application. I neverthe=
less strongly believe validation and filtering must live in userland.
> Validation and filtering are often very much tied to the domain problem a=
 user of PHP is to solving and the change rate of the application will be h=
igher than the change rate of the language (hopefully). To give a more conc=
rete example: let=E2=80=99s say our problem is we want to validate if a str=
ing is a valid domain because our business is registering domains. Nowadays=
, top level domains are introduced quite often and there is no way PHP coul=
d have a nice, up to date whitelist of TLDs all of the time and as a domain=
 registration business it=E2=80=99s impossible for me to wait for the updat=
ed whitelist in PHP NEXT. That=E2=80=99s why I believe this is something th=
at belongs to userland so the library that offers (domain) validation can f=
ollow a lifecycle that fits the problem it is trying to solve.

Thank you for reply.

It seems many of us is mixed up what "input handling should do" and
"business logic should do".

There are number of ways how to implement input data validations and
input error checks, from ideal to poor, or even bad. The validator is
trying "to validate input string (format, used char, length,
existence, etc) is expected". Business logic should handle input
errors, logical consistency, etc. i.e. Domain whitelisting should be
handled by logic generally speaking.

I don't understand why new validator would cause more problems than
solving. If users validate all inputs (e.g. request headers, cookies,
all of post/get tampering), apps became much more secure. This task
does not belong to business(app) logic. Even when users use the
validator non optimal way, it will improve security.

Anyway, bottom line is "There are too many apps that do not validate
inputs properly", "Many users do not distinguish 'input validation'
and 'logic/mistake check'". It seems.

Regards,

P.S. I was about to reactivate DbC proposal. This kind of  validation
is mandatory for DbC. Otherwise, DbC will cause more problems than
solving.

--
Yasuo Ohgaki
yohgaki@ohgaki.net