Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:14565 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 68000 invoked by uid 1010); 3 Feb 2005 10:52:17 -0000 Delivered-To: ezmlm-scan-internals@lists.php.net Delivered-To: ezmlm-internals@lists.php.net Received: (qmail 67984 invoked by uid 1007); 3 Feb 2005 10:52:17 -0000 To: internals@lists.php.net, Lukas Smith Message-ID: <42020261.80706@php.net> Date: Thu, 03 Feb 2005 11:52:17 +0100 User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 CC: Nick Loeve References: <5.1.0.14.2.20050201142816.026d21c0@localhost> <5.1.0.14.2.20050201111730.0299da70@localhost> <5.1.0.14.2.20050201111730.0299da70@localhost> <5.1.0.14.2.20050201142816.026d21c0@localhost> <5.1.0.14.2.20050201151955.02730ec0@localhost> <4200169A.6050905@lerdorf.com> <42001C1D.3090105@cschneid.com> <42001D7B.1040707@trickie.org> <420024EC.4080601@lerdorf.com> <4200457F.5080305@prohost.org> <42005629.3000905@lerdorf.com> <4200D48A.9070305@prohost.org> <42010045.20807@lerdorf.com> <12510140304.20050202223853@marcus-boerger.de> <42014F3B.5040607@lerdorf.com> <42018329.3010300@fission.org.uk> <42018B49.2030204@trickie.org> <4201E88E.4040306@php.net> In-Reply-To: <4201E88E.4040306@php.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Posted-By: 62.214.177.78 Subject: input filtering Re: [PHP-DEV] PHP 5.1 From: lsmith@php.net (Lukas Smith) Lukas Smith wrote: > Nick Loeve wrote: > >> Gareth Ardron wrote: >> >>> Rasmus Lerdorf wrote: >>> >>>> >>>> TCP/IP Firewalls break all sorts of applications as well until >>>> either the application is modified to poke a hole in the firewall >>>> itself via upnp, or you reconfigure the firewall. This makes >>>> firewalls annoying, but they are necessary. This is exactly the >>>> same thing. It is a data firewall for PHP. You don't have to use >>>> it, but people want it and need it. After a little discussion on #php.pecl I would like to clarify my position. I think it makes absolute sense to have an input filter that implements a global security for PHP. However as this feature only makes sense with considerable knowhow in defining a sensible global (global in the sense that it may span multiple applications) security policy I see no reason why this needs to be in core versus it being in PECL. Especially since alot of people are worried about smart ass admins (especially mass hosters) who dont listen to developers enabling the thing just because it sounds like a good idea. This means that the functionality will be available to people who know (tm). At the same time this is not a complete solution as a global security policy is not going to be as finely grained as needed. So a set of easy to use tools to use inside your application is also necessary. Actually it should be clear to all that just as a firewall input filtering does not replace data validation, even if in some cases data validation with inplut filters in front my seem redundant. We seriously need a taint model that will ensure that people get some sort of reminder if they let unchecked data pass through. regards, Lukas