Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:94828
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: <6811e0bd-811c-bd44-2e84-6d08aa8eef9d@gmail.com>
References: <CAGa2bXa8Oj=xi6ZUKYFe5XXuhZvOL6JT=31QHoq8EG-9veGDBg@mail.gmail.com>
 <CAGa2bXYpKOZOzzexPQLYZdUW1gyGLBuvzBDbQvgCj9NvE8hMKA@mail.gmail.com> <6811e0bd-811c-bd44-2e84-6d08aa8eef9d@gmail.com>
Date: Thu, 4 Aug 2016 19:45:09 +0900
Message-ID: <CAGa2bXYP4372hyhbK5_na+cpNrfqEYqdv50OBF0yZFjPt8y-Yw@mail.gmail.com>
To: Rowan Collins <rowan.collins@gmail.com>
Cc: "internals@lists.php.net" <internals@lists.php.net>
Content-Type: text/plain; charset=UTF-8
Subject: Re: [PHP-DEV] Re: Adding validate_var_array()/validate_input_array()
 to which version?
From: yohgaki@ohgaki.net (Yasuo Ohgaki)

Hi Rowan,

On Tue, Aug 2, 2016 at 11:37 PM, Rowan Collins <rowan.collins@gmail.com> wrote:
> On 01/08/2016 23:12, Yasuo Ohgaki wrote:
>>
>> Raising Exception would be prefered.
>> Any comment raising exception? ExceptionFilterValidate wouldn't
>> cause much BC, IMO.
>
>
> I don't follow. Do you mean throwing an exception to the existing
> filter-and-continue functions? If so, that would surely break every single
> use of those functions.

Existing filters currently used are not changed at all. They behave
exactly as they are now. If not, it's a bug. Exceptions are raised
only when validate_*() functions are used.

Input validations should pass almost always. So checking return value
from validation functions are not prefered.

>
> Or do you mean adding a new function which either silently succeeds or
> throws an exception? That doesn't sound good to me - an exception shouldn't
> be the expected result of something, and invalid input is an expected
> condition (just an undesirable one). It's easier to add a throw statement
> based on a boolean result than to catch an exception and continue with other
> checks.
>
> I may have misunderstood your question, though.

Invalid inputs that violate input validation rules should not happen
almost always because input validation is _not_ the same input
mistakes by normal users. e.g. typo, user send a little too long
password. These mistakes should be handled as input errors/mistakes,
not input validation error.

Example input validation errors are,
 - Broken UTF-8 encoding
 - NUL, etc control chars in string.
 - Too long or too short string. e.g. Client side validation inputs -
JS validated and values set by server programs like
<select>/<radio>/etc, 100 chars for username, 1000 chars for password,
empty ID for a database record, etc.
 - Broken number string for a database record ID.
 - Newline chars in <input>, hash value, etc.
 - and so on.

If there are these kind of inputs, they are intentionally broken
inputs. It should result in Exception and program should be
_terminated_ script execution after logging attack and sending nicely
formatted page that warns attackers, for instance.

validate_*() functions should be used to handle above input violations
that should never happen under normal condition.

Did I understand your concern correctly?
I hope explained well.

Regards,

--
Yasuo Ohgaki
yohgaki@ohgaki.net