Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:14531 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 23077 invoked by uid 1010); 2 Feb 2005 20:34:44 -0000 Delivered-To: ezmlm-scan-internals@lists.php.net Delivered-To: ezmlm-internals@lists.php.net Received: (qmail 23054 invoked from network); 2 Feb 2005 20:34:44 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 2 Feb 2005 20:34:44 -0000 X-Host-Fingerprint: 65.19.190.98 procata.com Linux 2.4/2.6 Received: from ([65.19.190.98:39707] helo=procata.com) by pb1.pair.com (ecelerity HEAD (r4105:4106)) with SMTP id 66/16-25397-46931024 for ; Wed, 02 Feb 2005 15:34:44 -0500 Received: from 65.111.192.211 ([65.111.192.211]) by procata.com for ; Wed, 2 Feb 2005 12:34:37 -0800 In-Reply-To: <420005A3.8050605@lerdorf.com> References: <5.1.0.14.2.20050201111730.0299da70@localhost> <5.1.0.14.2.20050201111730.0299da70@localhost> <5.1.0.14.2.20050201142816.026d21c0@localhost> <420005A3.8050605@lerdorf.com> Mime-Version: 1.0 (Apple Message framework v619.2) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-ID: <99da3c6937a48377bdb7790dccfaef1e@procata.com> Content-Transfer-Encoding: 7bit Cc: internals@lists.php.net Date: Wed, 2 Feb 2005 15:35:21 -0500 To: Rasmus Lerdorf X-Mailer: Apple Mail (2.619.2) Subject: Re: [PHP-DEV] PHP 5.1 From: jeff@procata.com (Jeff Moore) On Feb 1, 2005, at 5:41 PM, Rasmus Lerdorf wrote: > But the general idea is to provide an optional filter that people can > enable in their ini file. This will strip out any XSS, quotes, > braces, etc. I hate to see more ini options. They make it more difficult to write programs that work under a variety of configurations and more difficult to integrate programs written for different configurations. I would like to less ini file variability in the wild, not more. It seems to me like only the application knows what is valid data. Trying to bolt on input checking to existing applications from the outside looks like it would just break applications, perhaps in subtle and difficult to detect ways. One example would be that applications which display back form values upon validation failure would be sending back modified values. This can be disconcerting to the user. The user may not even notice that what they typed was silently modified to be something else. Doing this from the ini file just seems like another kind of magic_quotes_gpc to me. I am not a fan of magic. If ini file based filtering causes too many problems to turn on in general, then what good is having it? If ini file based filtering becomes too specific to an individual application, then why not just let the application handle it? It seems like a fine line to walk. I am wary of an ini file based input filtering. > echo filter(GET,'foo',FILTER_NUMBER); A set of easy to use and easy to find whitelist oriented filtering and validation functions is a great idea. Eventually, someone is going to want to start adding parameters to control the filtering. This would be easier with individual functions for individual types. Also, the filters would be more useful if they were de-coupled from the input mechanism. What about: echo filter_number($_GET['foo']); echo filter_string($str); // Perhaps same thing as strip_tags with no $allowed_tags, but white list oriented naming. echo filter_html($str, $allowed_tags_and_attributes); // improved strip_tags etc. Also perhaps something like this for registering input filters: register_filter(GET, ALL, 'trim'); register_filter(GET, 'foo', 'filter_number'); register_filter(GET, 'bar', 'filter_html', $allowed_tags_and_attributes); echo $_GET['foo']; echo $_GET['bar']; If there had to be a ini file option, then perhaps something taint-like: block_unfiltered_input = 1 With this option, superglobals that didn't have filters registered would simply be NULL. An option like this has to be able to be modified at runtime. something like: echo $_GET['foo']; // 'bar' ini_set('block_unfiltered_input', TRUE); echo $_GET['foo']; // NULL I have no idea how super globals are implemented, so I don't know if this is even possible. These are just some additional ideas.