Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:95341
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.218.46 as permitted sender)
To: Yasuo Ohgaki <yohgaki@ohgaki.net>
References: <CAGa2bXarw2jTj0yhXpywWNQOJLR2pdhfaqSdwj_btT2giEL15Q@mail.gmail.com>
 <CAGa2bXY-vmEgEFrE0OxQPSx=FKHeHdCayrDXxtTkHUVaJbV+-A@mail.gmail.com>
 <CA+kxMuRiOBQpmTeKqNyV8rX0GKCLrYixi--y5TcYUkdqpT746w@mail.gmail.com>
 <CAGa2bXa78fkZw8gtepmBDu+VDwHW_WiDDv65=zzgLTFqYxF+DA@mail.gmail.com>
 <CADyq6s+Y-OeKEyMus5s7xp9MqY7Fq7udqd5BRwtyGXbYCY1Uag@mail.gmail.com>
 <CADyq6sJuHCrLOoL22MWHv+cfrQQx9z=avswCpDVmnuyBCAchsA@mail.gmail.com>
 <CADyq6sKs=e_1Pc_CCLuThsU-qsvRseQcpx=sWKB_uhWsg=aRmQ@mail.gmail.com>
 <7795ca21-bd70-fe65-9519-af95fdfee33f@gmail.com>
 <CAGa2bXZMrO__dVd=qVoKjuPmcvVJ-q4xa8XKc0+aj1kH7Xd2Fw@mail.gmail.com>
 <fe3ccc4c-e81e-34fc-3257-19bd943e4abe@gmail.com>
 <CAGa2bXYy_tNiRfmy=jTsy-GALN4t8SDfxZ5vZocVCMw_7mMO6Q@mail.gmail.com>
 <40279244-a1ba-2680-8a14-89708bcd1852@gmail.com>
 <CAGa2bXYfaAXHay0txn46ui6T+nJ78ey=zCm9tKuWU2vCpEKTpg@mail.gmail.com>
 <ba10221f-717c-3c8c-9768-23d6a4cf0386@gmail.com>
 <CAGa2bXZ8CiuZ1ofHSu5psQcdcFy5ad6+JU9oagc_q40QsFkW7g@mail.gmail.com>
Cc: Marco Pivetta <ocramius@gmail.com>, Dan Ackroyd <danack@basereality.com>,
 PHP Internals List <internals@lists.php.net>
Message-ID: <267d257c-a093-d25b-02ea-737b535fa1e2@gmail.com>
Date: Sat, 20 Aug 2016 21:39:39 -0700
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:45.0)
 Gecko/20100101 Thunderbird/45.2.0
MIME-Version: 1.0
In-Reply-To: <CAGa2bXZ8CiuZ1ofHSu5psQcdcFy5ad6+JU9oagc_q40QsFkW7g@mail.gmail.com>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] Re: [RFC][VOTE] Add validation functions to filter
 module
From: smalyshev@gmail.com (Stanislav Malyshev)

Hi!

> It's possible to design web pages/services to "unknown clients", but
> it's exceptional cases.

No, it's not. Every service exposed to the internet is for unknown clients.

> Almost all systems have intended clients. If protocol is HTTP/HTTPS,
> developers may reject strange data that cannot be right for
> HTTP/HTTPS. Even higher level than PHP does this. i.e. HTTP servers
> will rejects malformed and/or prohibited request and terminates
> execution. Web Application Firewall does more fancy things and

True, because we can have no PHP business logic that can work on HTTPS
level. We can have PHP business logic that works on PHP level though.

> validate/check, in general.  IMHO, use of WAF is more burden and
> costly than the input validation that I'm proposing.

I'm not sure where WAF comes in - these are two completely different uses.

> Web application developers have right to define "valid" inputs. ("have
> right" does not mean "can do anything") PHP script termination for
> invalid input is just one of terminations. It's nothing special.

You can perfectly well have your app do anything you like - including
termination - on filter failure. I don't see how it necessitates making
new set of filters though?

> I think your premise is "Show nice error message for any errors,
> proceed as normal case".  (Handle invalid/insane data just like mistakes)
> 
> My premise is "Shouldn't show nice messages to attacker, terminate as
> abnormal case". (Treat them as attack or serious system bug)
> 
> It's design choice. Either way is possible.

Sure, and it's possible with current filters too. If the check fails,
and you want to terminate, what prevents you from doing:

if(!filter_var($var, FILTER_VALIDATE_INT) === false) { exit(); }

Am I missing some important point here?
-- 
Stas Malyshev
smalyshev@gmail.com