Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:100523 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 33854 invoked from network); 11 Sep 2017 21:08:54 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 11 Sep 2017 21:08:54 -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:45730] helo=es-i.jp) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id E9/4A-10715-26BF6B95 for ; Mon, 11 Sep 2017 17:08:52 -0400 Received: (qmail 9899 invoked by uid 89); 11 Sep 2017 21:08:47 -0000 Received: from unknown (HELO mail-io0-f174.google.com) (yohgaki@ohgaki.net@209.85.223.174) by 0 with ESMTPA; 11 Sep 2017 21:08:47 -0000 Received: by mail-io0-f174.google.com with SMTP id g32so17444181ioj.2 for ; Mon, 11 Sep 2017 14:08:46 -0700 (PDT) X-Gm-Message-State: AHPjjUg5J0qp43QUM/t2pkxKWvkTxxsXelf4daReFncBA/agX+Twj73Y ejfTltWeCVSAjKZzujRYomfqemFoJg== X-Google-Smtp-Source: AOwi7QDsaLHWI3Vdtd8Sfe6T6L5jjFdnemmHtIKp0fY5FjZppgeEJ/qUhpHO6VOg8B4Lsogk4DIQFICpZIeOepaKp3Q= X-Received: by 10.107.135.147 with SMTP id r19mr15240966ioi.26.1505164121065; Mon, 11 Sep 2017 14:08:41 -0700 (PDT) MIME-Version: 1.0 Received: by 10.79.72.5 with HTTP; Mon, 11 Sep 2017 14:07:59 -0700 (PDT) In-Reply-To: <05A8DB1C-4683-4934-A7DA-C7CD71E6CCB6@koalephant.com> References: <2a4491b4-e6f5-4297-beec-363f373a93e6@lsces.co.uk> <3f8be7b1-0e59-21c6-4fe8-8299b2c05645@rhsoft.net> <6ba62d62-f1ab-9e7b-93f0-a1a9238c47a6@lsces.co.uk> <0db9cfa3-2b31-ee41-713c-889b7cc06406@lsces.co.uk> <3C.DD.10715.4E501B95@pb1.pair.com> <93.85.10715.AB3B3B95@pb1.pair.com> <049578E9-4C9A-42D8-B206-8ABAF070E151@koalephant.com> <05A8DB1C-4683-4934-A7DA-C7CD71E6CCB6@koalephant.com> Date: Tue, 12 Sep 2017 06:07:59 +0900 X-Gmail-Original-Message-ID: Message-ID: To: Stephen Reay Cc: Tony Marston , "internals@lists.php.net" Content-Type: multipart/alternative; boundary="001a113ec75ac3cf480558f054a2" Subject: Re: [PHP-DEV] A validator module for PHP7 From: yohgaki@ohgaki.net (Yasuo Ohgaki) --001a113ec75ac3cf480558f054a2 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Stephen, On Tue, Sep 12, 2017 at 12:22 AM, Stephen Reay wrote: > > On 11 Sep 2017, at 17:41, Yasuo Ohgaki wrote: > > Hi Stephen, > > On Mon, Sep 11, 2017 at 6:37 PM, Stephen Reay > wrote: > > On 11 Sep 2017, at 15:42, Yasuo Ohgaki wrote: > > It seems you haven't try to use filter module seriously. > It simply does not have enough feature for input validations. > e.g. You cannot validate "strings". > > > Yasuo, > > I=E2=80=99ve asked previously what your proposal actually offers over the= filter > functions, and got no response, so please elaborate on this? > > > > Can you show a concrete example that cannot be validated in user land > currently, using the filter functions as a base? > > > FILTER_VALIDATE_REGEXP is not good enough simply. > PCRE is known that it is vulnerable to regex DoS still. (as well as > Oniguruma) > Users should avoid regex validation whenever it is possible also to avoid > various > risks. > > In addition, current filter module does not provide nested array validati= on > array key validation, etc. It's not true validation neither. It does not > provide > simple length, min/max validations. It does non explicit conversions (i.e= . > trim), etc. > Length, min/max validation is mandatory validation if you would like to > follow > ISO 27000 requirement. > > Regards, > > -- > Yasuo Ohgaki > yohgaki@ohgaki.net > > > > So, you still didn=E2=80=99t actually provide an example. I *guess* you= =E2=80=99re talking > about character class validation or something else equally =E2=80=9Csimpl= e=E2=80=9D, > because I can=E2=80=99t imagine what else would be a common enough case t= hat you=E2=80=99d > want to have built-in rules for, and that you wouldn=E2=80=99t internally= use > RegExp to test anyway. > Your request is like "Devil's Proof". Example code that cannot do things with existing API cannot exist with meaningful manner. It can be explained why it cannot, though. Try what "validate" string validator can do, Then you'll see. $input =3D [ 'defined_but_should_not_exist' =3D> 'Developer should not allow unwanted value', '_invalid_utf8_key_should_not_be_allowed_' =3D> 'Developer should validat= e key value as well', 'utf8_text' =3D> 'Validator should be able to allow UTF-8 and validate it= s validity at least', 'default_must_be_safe' =3D> 'Crackers send all kinds of chars. CNTRL char= s must not be allowed by default', 'array' =3D> [ 'complex' =3D> 1, 'nested' =3D> 'any validation rule should be able to be applied', 'array' =3D> 1, 'key_should_be_validated_also' =3D> 1, 'array' =3D> [ 'any_num_of_nesting' =3D> 'is allowed', ], ], 'array_num_elements_must_be_validated' =3D> [ "a", "b", "c", "d", "e", "f", "and so on", "values must be able to be validated as user wants", ], ]; There is no STRING validation filter currently. This fact alone, it could be said "filter cannot do string validation currently". List of problems in current validation filter - no STRING validator currently - it allows any inputs by default - it does not allow multiple rules that allows complex validation rules for string - it does not have callback validator - it does not have key value validation (note: PHP's key could be binary) - it does not validate num of elements in array. - it cannot forbids unwanted elements in array. - it cannot validate "char encoding". - it does not enforce white listing. - and so on These are the list that "filter" cannot do. Ok so we can=E2=80=99t use filter_var() rules to validate that a string fie= ld is an > Alpha or AlphaNum, between 4 and 8 characters long (technically you could > pass mb_strlen() to the INT filter with {min,max}_range options set to ge= t > the length validation, but I=E2=80=99ll grant you that *is* kind of a cra= ppy > workaround right now) > > Why not stop trying to re-invent every single feature already present in > PHP (yes, I=E2=80=99ve been paying attention to all your other proposals)= , and just > *add* the functionality that=E2=80=99s missing: > https://wiki.php.net/rfc/add_validate_functions_to_filter It's _declined_. You should have supported this RFC if you would like to add features to filter. (I'm glad there is a new RFC supporter regardless of occasion) I don't mind this result much. Adding features to "filter" has some of shortcomings mentioned above even with my proposal. A `FILTER_VALIDATE_STRING` filter, with =E2=80=9COptions=E2=80=9D of `min` = =3D> ?int, `max` > =3D> ?int and =E2=80=9CFlags=E2=80=9D of FILTER_FLAG_ALPHA, FILTER_FLAG_N= UMERIC (possibly a > built in bit mask =E2=80=9CFILTER_FLAG_ALPHANUMERIC=E2=80=9D ?) > Simply adding these wouldn't work well as validator because - Filter is designed for black listing As you may know, all of security standards/guidelines require - White listing for validation We may change "filter", but it requires BC. > > Lastly: it may not be the format you personally want, but the filter > extension *does* have the `filter_{input,var}_array` functions. Claiming > something doesn=E2=80=99t exist because it doesn=E2=80=99t work exactly h= ow you would like > it to, makes you seem immature and petty, IMO. > Discussion is confusing because you ignore this RFC result. https://wiki.php.net/rfc/add_validate_functions_to_filter This RFC proposes filter module improvement while keeping compatibility. I understand your point. This exactly the same reason why I proposed "improvement" at first, not new extension. I don't understand why you insist already failed attempt repeatedly. Would you like me to propose previous RFC again? and implement "ture validation" with filter? I don't mind implementing it if you would like to update the RFC and it passes. I must use "white list" as much as possible. Regards, P.S. "Filter" module is black listing module. "Validate" is white listing module. Even with BC, mixing them would result in confusing FLAGs and codes. Codes may be cleaned up later, but FLAGs cannot. We should consider this also. -- Yasuo Ohgaki yohgaki@ohgaki.net --001a113ec75ac3cf480558f054a2--