Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:95688 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 80431 invoked from network); 6 Sep 2016 07:59:50 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 6 Sep 2016 07:59:50 -0000 Authentication-Results: pb1.pair.com smtp.mail=lester@lsces.co.uk; spf=permerror; sender-id=unknown Authentication-Results: pb1.pair.com header.from=lester@lsces.co.uk; sender-id=unknown Received-SPF: error (pb1.pair.com: domain lsces.co.uk from 217.147.176.214 cause and error) X-PHP-List-Original-Sender: lester@lsces.co.uk X-Host-Fingerprint: 217.147.176.214 mail4-2.serversure.net Linux 2.6 Received: from [217.147.176.214] ([217.147.176.214:44770] helo=mail4.serversure.net) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id E0/EF-45301-3777EC75 for ; Tue, 06 Sep 2016 03:59:49 -0400 Received: (qmail 364 invoked by uid 89); 6 Sep 2016 07:59:36 -0000 Received: by simscan 1.3.1 ppid: 357, pid: 361, t: 0.0961s scanners: attach: 1.3.1 clamav: 0.96/m:52/d:10677 Received: from unknown (HELO ?10.0.0.7?) (lester@rainbowdigitalmedia.org.uk@81.138.11.136) by mail4.serversure.net with ESMTPA; 6 Sep 2016 07:59:36 -0000 To: "internals@lists.php.net" References: <232F1604-2211-4351-B830-EDC958A25D6D@strojny.net> <2de35db0-9974-cc96-83dd-3d2dbd48f7f8@lsces.co.uk> <5b72e9da-068a-bc79-82c2-f36f723f42bb@gmail.com> <819abe3a-5bfc-773a-025d-edfe92961a3a@lsces.co.uk> Message-ID: <3ac96216-51a9-305d-2500-083cb5905e5a@lsces.co.uk> Date: Tue, 6 Sep 2016 08:59:35 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.2 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Subject: Re: [PHP-DEV] [RFC][VOTE] Add validation functions to filter module From: lester@lsces.co.uk (Lester Caine) On 06/09/16 03:19, Yasuo Ohgaki wrote: > Hi Lester, > > On Fri, Sep 2, 2016 at 7:58 PM, Lester Caine wrote: >> A filter of "is this string corrupted with an injection attempt" seems >> rather more difficult to define than "email"? And applying the first in >> general on every string when there are as set of simple filters that can >> be used ... as an alternative to the more difficult to define ones? > > Input validation code does not have to address all of injections. It's > output code responsibility to prevent injections in the first place. > i.e. Top 10 Secure Coding Practices - #7 > https://www.securecoding.cert.org/confluence/display/seccode/Top+10+Secure+Coding+Practices Your statement and those coding points don't go together. 1 ... Any input to PHP has to be untrusted since you can't rely on even clean sources being intercepted. 8 ... Why not use the best available checks on the input side? 7 ... I've sanitised the data in the browser, but because of morons I can't use it without addressing 1 and 8. All this comes back to my simple idea of adding all these validation, filtering and sanitation steps wrapped around the basic PHP variable. And THAT also includes 'strict typing' since if we have the option to select soft or hard failure when a problem is found in the variable we can cover everybody’s 'need'! > Nonetheless, ID validation being poor is not rare even with well > known code. parameters like ID is easy to make sure it's safe from any > injections. > e.g. https://groups.google.com/forum/#!topic/rubyonrails-security/ly-IH-fxr_Q I know the range of values available for 'id' it's provided by the SEQUENCE source in the database but if you insist on 'autoinc' we can do the job properly. So my filter on the variable :id is looking for a number in a range. What could be a simpler validation than that? > ID is not the only one, accept language, encoding, referer, etc are > common source of injections also. > > Input validation code is for mitigation against unknown/unaddressed > vulnerabilities in entire code not only PHP code, but also language, > libraries written by C/C++ and/or external systems such as DB. If you need to retain the raw input of non-php material then that is just a more complex filter. Point 5 above - Default Deny - do not forward anything that you do not need. So once you have applied rule 9, and assured you know what you expect to receive, then only that is passed on to rule 8. If that data being passed on has a potential to carry a vulnerability forward it's because you have to allow for that data to be forwarded anyway, so a filter to prevent it is pointless? -- Lester Caine - G8HFL ----------------------------- Contact - http://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - http://lsces.co.uk EnquirySolve - http://enquirysolve.com/ Model Engineers Digital Workshop - http://medw.co.uk Rainbow Digital Media - http://rainbowdigitalmedia.co.uk