Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:94844 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 56138 invoked from network); 4 Aug 2016 23:59:16 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 4 Aug 2016 23:59:16 -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:39825] helo=es-i.jp) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id DF/B3-33134-0D6D3A75 for ; Thu, 04 Aug 2016 19:59:16 -0400 Received: (qmail 104142 invoked by uid 89); 4 Aug 2016 23:59:09 -0000 Received: from unknown (HELO mail-qk0-f180.google.com) (yohgaki@ohgaki.net@209.85.220.180) by 0 with ESMTPA; 4 Aug 2016 23:59:09 -0000 Received: by mail-qk0-f180.google.com with SMTP id x185so56147963qkc.2 for ; Thu, 04 Aug 2016 16:59:09 -0700 (PDT) X-Gm-Message-State: AEkooutIajxlkW/kgPR6RH9RPaqrpg3GKeKWYyrpe3irdBqV2UxbC1aMaKBrdtzkQDVaLSHLjgT2/LyPFHv0dA== X-Received: by 10.55.137.70 with SMTP id l67mr9375419qkd.132.1470355142361; Thu, 04 Aug 2016 16:59:02 -0700 (PDT) MIME-Version: 1.0 Received: by 10.140.85.242 with HTTP; Thu, 4 Aug 2016 16:58:21 -0700 (PDT) In-Reply-To: <7150dcf2-b571-a5d6-ccb5-9b04a65def90@lsces.co.uk> References: <27c5add4-2c4c-bab1-6ca7-9c191917dd0e@gmail.com> <65975a09-1d96-c03b-ecb2-ab37d91e621c@gmail.com> <7150dcf2-b571-a5d6-ccb5-9b04a65def90@lsces.co.uk> Date: Fri, 5 Aug 2016 08:58:21 +0900 X-Gmail-Original-Message-ID: Message-ID: To: Lester Caine Cc: "internals@lists.php.net" Content-Type: text/plain; charset=UTF-8 Subject: Re: [PHP-DEV] Adding validate_var_array()/validate_input_array() to which version? From: yohgaki@ohgaki.net (Yasuo Ohgaki) On Fri, Aug 5, 2016 at 7:03 AM, Lester Caine wrote: > On 04/08/16 22:47, Yasuo Ohgaki wrote: >>> The correct response to a form validation error is to show a message to the >>> > user with as much detail as possible, not to simply terminate the script and >>> > assume they are trying to attack your application. >> We are talking about different things. >> I'll document it clearly in RFC. > > But both need to be done at the same time ... Right and wrong? Both have to be done in a software. > > Validating the input data requires that you have a set of rules for each > variable, and if all are correct then one can process the 'array', but > if an element fails validation then one needs to handle the error either > as suspicious, or simply out of range. I repeat that handling the > complexities of EACH variable of the validation is a package of work in > it's own right, and trying to handle some aspects via an array function > does not remove the more obvious need to decide what order to handle > validation errors on each element, or to return error messages for each > variable that fails validation. If the element is some attempt to create > an injection of js or html tags then it should fail validation, but > equally it may be a valid input as long as it is escaped and stored in a > correct manor. The complexity of what you plan for your array validation > elements start with all the same rules applied to a single variable. Modern softwares are complex enough to handle inputs securely. Softwares should use "divide and conquer" principle. Input validation is like assertion that should never happen. It should be validated(asserted) according to the software input spec and it should be checked as soon as inputs arrive to the software, and leave behind mistakes, logical inconsistency, etc. Validation(assertion) errors are: - Broken char encoding - Broken input format. e.g. Broken int/float/bool, strings like hash/id/etc - Invalid chars in string. i.e. NUL and other control chars - Too large/small values. e.g. Too long/short string, too large/small int, float. - Too few/many inputs. ("Too many inputs" cannot be address by filter functions, but can be addressed input validation code) Some of above are need to be addressed by software business logic on occasions depending on client output, but input validation should make sure input values validity as much as possible to reduce software complexity. After input validation, business logic should take care of the rest. Input error(user mistake, logical inconsistency) check should be checked separately by the software as a part of the software business logic. This way, business logic code can concentrate on jobs that it should and reduce complexity of input handling. This is my view of what input validation should do. (and what business logic should do) Regards, -- Yasuo Ohgaki yohgaki@ohgaki.net