Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:95255
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.192.196 as permitted sender)
To: Yasuo Ohgaki <yohgaki@ohgaki.net>
References: <CAGa2bXarw2jTj0yhXpywWNQOJLR2pdhfaqSdwj_btT2giEL15Q@mail.gmail.com>
 <CAGa2bXadVagTwBzEym9PZROmXu3SKxg=huCAQNK3k1-jZeG_pg@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>
Cc: Marco Pivetta <ocramius@gmail.com>, Dan Ackroyd <danack@basereality.com>,
 PHP Internals List <internals@lists.php.net>
Message-ID: <fe3ccc4c-e81e-34fc-3257-19bd943e4abe@gmail.com>
Date: Wed, 17 Aug 2016 01:33:21 -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: <CAGa2bXZMrO__dVd=qVoKjuPmcvVJ-q4xa8XKc0+aj1kH7Xd2Fw@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!

> Let's say your app validate user written/chosen "Date" on client side by
> JavaScript. Then browser must send whatever "Date" format you impose
> to client. It may be "YYYYMMDD", for example.

I'm not sure what Javascript has to do with it. Many apps don't have any
client-side and have little to do with Javascript. Assuming that whole
world is browser applications running Javascript (controlled by you)
would be a big mistake.

> Then programer should not accept "Date" format other than "YYYYMMDD"
> because other format is invalid. Accepting format other than "YYYYMMDD"
> does only bad and increase risks of program malfunctioning. i.e. All kinds
> of injections like JavaScript, SQL, Null char, Newline, etc.

What you mean by "accept" here? I think you are under impression (please
correct me if I'm wrong) that there are only two ways for application to
work - either treating all inputs equally, or bailing out immediately
when incorrect input is detected. However, this is not the case, there
are many other ways for application to handle the situation of invalid
input - while knowing it is invalid - and exact manner of this handling
is application-dependent.

> "Input validation" should reject all of them and does not have to inform users
> (attackers) to "there is invalid input". If you need to tell  legitimate users

I think we disagree here. I think not doing this makes my work as a
developer much much harder.

> "There is invalid input", then it should be treated by "Business logic", not by
> "Input validation".

Wait, input validation happens before business logic has a chance to
run, so if input validation bails, how business logic can treat anything?

> "User name" and "Password" shouldn't have CNTRL chars or invalid char
> encoding. Even when fields are plain <input>, there shouldn't be 500 chars
> long inputs for them.

So your proposal seems to be having two input checking procedures
instead of one. I don't think people would find it very useful to have
two separate input checking procedures.

-- 
Stas Malyshev
smalyshev@gmail.com