Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:95522
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: <CAGa2bXarw2jTj0yhXpywWNQOJLR2pdhfaqSdwj_btT2giEL15Q@mail.gmail.com>
References: <CAGa2bXarw2jTj0yhXpywWNQOJLR2pdhfaqSdwj_btT2giEL15Q@mail.gmail.com>
Date: Thu, 1 Sep 2016 04:45:22 +0900
Message-ID: <CAGa2bXaA+uvh_wpRAHeiv+Xb-JOrTAkyoe3jzq3FVCEbfja_5w@mail.gmail.com>
To: "internals@lists.php.net" <internals@lists.php.net>
Content-Type: text/plain; charset=UTF-8
Subject: Re: [RFC][VOTE] Add validation functions to filter module
From: yohgaki@ohgaki.net (Yasuo Ohgaki)

Hi all,

On Mon, Aug 15, 2016 at 9:15 AM, Yasuo Ohgaki <yohgaki@ohgaki.net> wrote:
>
> This RFC is to add functions that are suitable for input validations
> for secure coding. IMHO, these additions are mandatory for PHP.
>
> https://wiki.php.net/rfc/add_validate_functions_to_filter
> Vote ends 2016/08/22 23:59:59 UTC
>
> I don't mind suspend vote and continue discussion if there is issue.
> It's rather long RFC. Thank you for reading and voting!

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.

https://wiki.php.net/rfc/add_validate_functions_to_filter#proposed_voting_choices
bwoebi (bwoebi)
colinodell (colinodell)
danack (danack)
derick (derick)
diegopires (diegopires)
guilhermeblanco (guilhermeblanco)
kguest (kguest)
levim (levim)
lstrojny (lstrojny)
marcio (marcio)
nikic (nikic)
ocramius (ocramius)
peehaa (peehaa)
santiagolizardo (santiagolizardo)


I would like to summarize objection points during discussion.
I assume above of us voted no for these reasons.

0. Input data validation cannot be done because client can be anything.
1. Input data validation should show what's wrong, not exception.
2. Input data validation error and input mistake error should be treated
    by the same code to remove code redundancy.
3. Current filter module is good enough.

IMO. These are clearly wrong reasons of objection.

0. Almost all input data can be validated because of
     - Web standards. e.g. Almost all form input must be "valid string".
     - Client side validation. e.g. JS, HTML5.
     - Many parameters are set by program and shouldn't be changed.
       e.g. Select, radio, hidden, database record ID.

1. Showing what's wrong in input validation is _ANTI_ practice of security.
    - Developers should _NOT_ show error details unless it has to, otherwise
      it helps attackers to tamper system.
    - "You have broken encoding", "You have unallowed CNTRL char", etc, are
      the same as "You have entered wrong user name", "You have entered
      wrong password", "You have entered too long password", etc.

2. This is not reasonable choice for large applications that have higher
    security requirements.
    - Strict input validation should check all inputs including request
      headers and cookies. Checking these in business logic makes
      things messy and complicated, hence easy to make mistakes.

3. Current filter module does not work for strict validations.
    - I don't repeat. It just does not work well for strict validation.

(NOTE: "input validation" is "the input validation" mentioned in the RFC)

If you have question, I don't mind at all to explain more. I think most of
you misunderstood the concept.

If you have other reason(s), please let me know to improve RFC.
Thank you!

Regards,

--
Yasuo Ohgaki
yohgaki@ohgaki.net