Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:95281
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.220.67 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>
 <fe3ccc4c-e81e-34fc-3257-19bd943e4abe@gmail.com>
 <CAGa2bXYy_tNiRfmy=jTsy-GALN4t8SDfxZ5vZocVCMw_7mMO6Q@mail.gmail.com>
Cc: Marco Pivetta <ocramius@gmail.com>, Dan Ackroyd <danack@basereality.com>,
 PHP Internals List <internals@lists.php.net>
Message-ID: <40279244-a1ba-2680-8a14-89708bcd1852@gmail.com>
Date: Wed, 17 Aug 2016 18:34:08 -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: <CAGa2bXYy_tNiRfmy=jTsy-GALN4t8SDfxZ5vZocVCMw_7mMO6Q@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!

> I think you wrote your JavaScript code to impose certain format for "date",
> "phone", "zip", etc. It's not my JavaScript code, but your JavaScript code
> that defines output of browser to your PHP web apps.

There are a lot of use cases that don't have Javascript (or browser, for
that matter) frontends. Not that it should matter, as browser is not
under your code's control, it's under user's control, and you never know
on the PHP side if such thing as browser exists at all.

> Accept means that allow program to process input data. (continue execution)

Then we disagree here. I strongly object to the notion that the program
should stop execution at any unexpected data. This is only marginally
better than crashing, and is not very helpful behavior. Modern
application is expected to handle data in a more intelligent manner.

> If your JavaScript date picker uses "YYYYMMDD" format (date like
> 20160817) for a date, anything other than "YYYYMMDD" format is
> attacker tampered inputs.

You keep returning to Javascript. What I am asking you to consider is
that we're not talking about Javascript, we are talking about PHP, and
PHP has no relation to Javascript date picker. Some apps use Javascript
date pickers, true, but there is a whole world of applications that do
nothing of the sort. Javascript does not add much to the picture here.

> It may be considered "valid input" means expected inputs from _legitimate_
> users. Anything other than "valid input" should not be accepted because
> they come from non legitimate users. i.e. attackers.
> 
>  - Broken encoding
>  - CNTRL chars
>  - Bad format ( YYYYMMDD is the format for this case )
>  - Too long or short ( Exactly 8 chars is the length for this case )
>  - and so on
> 
> are examples of invalid inputs.

I think this has a smell of blacklisting, which is always almost wrong
approach to dealing with data filtering/validation. Blacklists almost
always lose to whitelists. If you have a whitelist filter that validates
the data, you don't need to worry about chars, lengths and such
separately. However, there's nothing here that requires the whitelist
filter would bring down the app on failure. It should tell the business
logic "this string you gave me is not a valid date" and business logic
should deal with it. There's nothing special here in encodings, control
chars, etc. that I can see that needs any special handling.

> It may increase your work, but you'll get less risks in return.

I don't see how. I can write intelligent code that produces helpful
messages and be the same - in fact, more, see above about whitelisting -
robust than blackbox code that explodes on bad inputs.

> The input validation only reject invalid input.
> 
> If you use plain <input> for "date", then you should consider any valid
> UTF-8 without CNTRL chars up to 100 char or so, not "YYYYMMDD".
> (Assuming UTF-8 is the encoding)

But why? If I just check for YYYYMMDD I automatically get all invalid
UTF-8 etc. rejected, without even thinking about it.

> Software design is upto developers. There are many softwares that do
> not follow best practices. Nobody enforce to use the validator as I
> explains. It's okay to me this is used by only users who need. As I
> mentioned, ISO 27000/ISMS requires this kind of validations, not few
> users may need this.

I'm not sure what ISO says there, but I'm pretty sure ISO does not
specify which exactly code you should use to validate your inputs. The
objections are not about validating inputs as a concept, nobody would
object to that, it's to specific model of doing this that you propose -
namely, doing two separate validation passes, doing blacklisting and
bailing out on validation failure. At least I would not do input
validation in this manner.

-- 
Stas Malyshev
smalyshev@gmail.com