Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:95286
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.213.171 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>
 <40279244-a1ba-2680-8a14-89708bcd1852@gmail.com>
 <CAGa2bXYfaAXHay0txn46ui6T+nJ78ey=zCm9tKuWU2vCpEKTpg@mail.gmail.com>
Cc: Marco Pivetta <ocramius@gmail.com>, Dan Ackroyd <danack@basereality.com>,
 PHP Internals List <internals@lists.php.net>
Message-ID: <ba10221f-717c-3c8c-9768-23d6a4cf0386@gmail.com>
Date: Wed, 17 Aug 2016 23:54:57 -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: <CAGa2bXYfaAXHay0txn46ui6T+nJ78ey=zCm9tKuWU2vCpEKTpg@mail.gmail.com>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 8bit
Subject: Re: [PHP-DEV] Re: [RFC][VOTE] Add validation functions to filter
 module
From: smalyshev@gmail.com (Stanislav Malyshev)

Hi!

> Even when there is no JavaScript nor HTML5 forms, input validations
> can be done. It's matter of definition of "valid inputs" for <input
> type="text" name="var" />. If page encoding is UTF-8, web browsers
> must return response by UTF-8 encoding. (Unless other encoding is

I think you're still missing my point. The point is that it is
absolutely irrelevant what browser might or might not do, since PHP does
not have any means to know if browsers even exist. PHP doesn't talk to
browser, it talks to HTTP channel (provided we're in webserver
scenario), what's on the other end is unknown and irrelevant. So there's
no point discussing browsers.

> We recently added number of
> php_error_docref(E_ERROR, "Cannot process too large data");
> in PHP core to avoid possible memory destruction attacks.

We added it because we didn't have choice. PHP does not have generic
error mechanism that allows to fail an arbitrary function and still
continue execution. It's because PHP is highly complex C code and C is
not the most friendly language out there. Your app is not in C, so it
can do it differently.

If you talk about such situations, fine, but it's not input validation -
it's limitation of the environment (since PHP can't support arbitrary
length string). If your application has such limitations - fine, but it
would be application-defined and will not apply for most cases of input
validation.

> Broken char encoding shouldn't came from legitimate users. Text
> contains CNTRL chars from <input type="text" name="var" /> shouldn't
> come from legitimate users. 1MB data from <input type="text"
> name="var" /> shouldn't come from legitimate users. Numeric database
> record ID that is set by app shouldn't contain anything other than
> digits. And so on.

I think you are mixing abnormal situations due to physical limitations
of software (like memory limits, etc.) with business logic. Numeric
format validation and size limits are clearly business logic. Encoding
may be not, depending on what the input is and used for.

> Broken char encoding (Accept only valid encoding)
> NUL, etc control chars in string. (Accept only chars allowed)
> Too long or too short string. e.g. JS validated values and values set
> by server programs like <select>/<input type=radio>/etc, 100 chars for
> username, 1000 chars for password, empty ID for a database record,
> etc. (Accept only strings within range)

These all fine filters/validators, and may be very useful in many
situations. What I still don't understand is insistence of application
dropping everything and exiting when one of them fails. We already have
sanitization/filtering infrastructure, we can add new filters and flags
- what I don't understand, why we need parallel infrastructure which
seems to be only different by an unhelpful feature of crashing each time
it sees something unexpected. Am I missing something?

> How to deal with bad inputs.
>   - You seem you would like to treat as normal input.

No, you didn't understand. I would like to treat is as erroneous input,
but not stop the application immediately, but return error status to the
business logic and let it sort things out.

> When plain <input> is used, users may type in any valid UTF-8 char by mistake.
> For example, this wouldn't happen for date field, but autocomplete may
> fill my name "大垣靖男" to name field that supposed to contain alphabets
> only.

If the software is properly internationalized (like my email client)
there's absolutely nothing wrong with this string. If it is not, it
should check that the text matches its expectations - that's part of
business logic.

> If developers try to validate "all inputs", validation in MVC model is
> not efficient nor reasonable. It does not make sense to validate
> browser request headers in db model, for example. Ideally, input
> validation is better to be done as fast as possible to maximize the
> mitigation effect.

If you use browser headers, you validate them. If you don't use them, no
point validating them, of course, since they are not your inputs.


-- 
Stas Malyshev
smalyshev@gmail.com