Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:95333
Return-Path: <yohgaki@ohgaki.net>
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Delivered-To: mailing list internals@lists.php.net
Received: (qmail 98749 invoked from network); 20 Aug 2016 07:31:15 -0000
Received: from unknown (HELO lists.php.net) (127.0.0.1)
  by localhost with SMTP; 20 Aug 2016 07:31:15 -0000
Authentication-Results: pb1.pair.com header.from=yohgaki@ohgaki.net; sender-id=pass
Authentication-Results: pb1.pair.com smtp.mail=yohgaki@ohgaki.net; spf=pass; sender-id=pass
Received-SPF: pass (pb1.pair.com: domain ohgaki.net designates 180.42.98.130 as permitted sender)
X-PHP-List-Original-Sender: yohgaki@ohgaki.net
X-Host-Fingerprint: 180.42.98.130 ns1.es-i.jp  
Received: from [180.42.98.130] ([180.42.98.130:42689] helo=es-i.jp)
	by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP
	id 5F/03-03566-14708B75 for <internals@lists.php.net>; Sat, 20 Aug 2016 03:31:14 -0400
Received: (qmail 111099 invoked by uid 89); 20 Aug 2016 07:31:09 -0000
Received: from unknown (HELO mail-qt0-f169.google.com) (yohgaki@ohgaki.net@209.85.216.169)
  by 0 with ESMTPA; 20 Aug 2016 07:31:09 -0000
Received: by mail-qt0-f169.google.com with SMTP id x25so17327761qtx.2
        for <internals@lists.php.net>; Sat, 20 Aug 2016 00:31:08 -0700 (PDT)
X-Gm-Message-State: AEkoouvhrZ/Z2E9Kb/8hNOHoiUxxoEjZwm5BIqEgyqSudh8uQ7qYgSwJZCOzObAAGfMDGsstJPHMTY9Aa+2kdQ==
X-Received: by 10.200.45.181 with SMTP id p50mr12309491qta.31.1471678263095;
 Sat, 20 Aug 2016 00:31:03 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.140.85.242 with HTTP; Sat, 20 Aug 2016 00:30:21 -0700 (PDT)
In-Reply-To: <08c8ca8b-fb14-fd1a-c6fa-2ee4db6e870a@lsces.co.uk>
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>
 <ba10221f-717c-3c8c-9768-23d6a4cf0386@gmail.com> <08c8ca8b-fb14-fd1a-c6fa-2ee4db6e870a@lsces.co.uk>
Date: Sat, 20 Aug 2016 16:30:21 +0900
X-Gmail-Original-Message-ID: <CAGa2bXZ_r86Q6BAA+_5U55aR-j0iVRofoPFx8AQbe+sbPTE9qw@mail.gmail.com>
Message-ID: <CAGa2bXZ_r86Q6BAA+_5U55aR-j0iVRofoPFx8AQbe+sbPTE9qw@mail.gmail.com>
To: Lester Caine <lester@lsces.co.uk>
Cc: "internals@lists.php.net" <internals@lists.php.net>
Content-Type: text/plain; charset=UTF-8
Subject: Re: [PHP-DEV] Re: [RFC][VOTE] Add validation functions to filter module
From: yohgaki@ohgaki.net (Yasuo Ohgaki)

Hi Lester,

On Thu, Aug 18, 2016 at 4:27 PM, Lester Caine <lester@lsces.co.uk> wrote:
> On 18/08/16 07:54, Stanislav Malyshev wrote:
>>> 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.
>
> Currently if the post data contained a large block of text how is that
> handled in the $_POST array? If we have specified a validator that say
> ['note'] has a 1k limit, then only the first 1024 characters will be
> usable so anything else can be scrapped. Yes I know that we have a
> chicken and egg in that $_POST['note'] has to be created before we can
> augment it with other information, and currently that happens by copying
> $_POST['note'] to a well defined $note further down the chain, but how
> difficult would it be for a set of annotations to be picked up as part
> of the process of creating $_POST['note'] in the first place?

If $_POST['note'] is limited to 1KB by business logic and there is no
restriction on client side, have only a memo that "You can enter up to
1KB text", then I'll treat up to 10KB of text or more as "valid input".

>
> Even strict typing does not help here since all we have is 'string'
> where even something as simple as 'short_string' for a 256 byte limit
> string would help, but adding even a simple set of limits to the base
> variables addresses the majority of what is being discussed? Even if you
> leave the finer validation rules such as 'valid email' to later
> 'business' logic? But is it really that difficult to go from
> 'short_string' to 'email' as a validation rule?

If you validate "email" as email on client side, then you can have
validation rule that rejects anything other than client side validation
rule. If you don't have client side validation(rule), then you should
treat them as normal strings in the input validation.

The input validation we are discussing is "Input/output rules between
client and server". It decides what's valid/invalid.

Regards,

--
Yasuo Ohgaki
yohgaki@ohgaki.net