Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:14639 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 72046 invoked by uid 1010); 4 Feb 2005 09:00:35 -0000 Delivered-To: ezmlm-scan-internals@lists.php.net Delivered-To: ezmlm-internals@lists.php.net Received: (qmail 72029 invoked from network); 4 Feb 2005 09:00:35 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 4 Feb 2005 09:00:35 -0000 X-Host-Fingerprint: 66.198.51.121 lerdorf.com Linux 2.4/2.6 Received: from ([66.198.51.121:38344] helo=colo.lerdorf.com) by pb1.pair.com (ecelerity HEAD (r4105:4106)) with SMTP id 9F/32-22541-DA933024 for ; Fri, 04 Feb 2005 04:00:29 -0500 Received: from [192.168.2.106] (c-24-6-1-160.client.comcast.net [24.6.1.160]) (authenticated bits=0) by colo.lerdorf.com (8.13.3/8.13.3/Debian-4) with ESMTP id j1490P9m023574 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 4 Feb 2005 01:00:26 -0800 Message-ID: <420339A7.7020707@lerdorf.com> Date: Fri, 04 Feb 2005 01:00:23 -0800 User-Agent: Mozilla Thunderbird 1.0 (Macintosh/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Ron Korving CC: internals@lists.php.net 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> <420149A4.6000201@lerdorf.com> <20050204073020.17514.qmail@lists.php.net> In-Reply-To: <20050204073020.17514.qmail@lists.php.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [PHP-DEV] PHP 5.1 From: rasmus@lerdorf.com (Rasmus Lerdorf) Ron Korving wrote: >>>You guys can write your own implementation and put it in PECL alongside >>>the one I am putting in there and we can decide if any of them should be >>>bundled by default. Perhaps none of them should, but like it or not, >>>people want to filter at this level and the extension to satisfy this >>>need will be available to them in PECL. >> >>Yes, there should be an extension that implements the filter functions - >>but the normal data should still be available like it is in PHP 4.3 and >>PHP 5.0. Adding an ext for those filters is a good thing, mangling >>request data isn't (see the magic_quotes_gpc mess). >> >>Derick > > > I agree very much with you on this. If PHP coders who are no admins on the > server themselves have to start worrying about a default filter, that means > they will have to filter all input because the default filter could be or > might become something they don't want to see. And in that case, there's no > use for a default for them anymore, they simply have to manually filter > everything, just so they can get to their raw data. This whole default > setting adds an uncertainty which will add a lot of lines of code. > > Please don't make the magic_quotes_gpc mistake again, because in my humble > opinion, that was the worst thing that ever happened to PHP. It comes down the fact that every single piece of data you get from GET, POST, Cookie and some Server variables *must* be at the very least be passed through htmlentities or striptags before you can display any part of them. If you in any place do an echo $_GET['foo'] or even echo $_SERVER['PATH_INFO'], REQUEST_URI, USER_AGENT, REFERER, etc. your application is broken. And even if you do call these if you haven't explicitly set your output encoding your application is likely still vulnerable. How many web applications (not just PHP) do you think suffer from this? Just about every one from my perusal of not just sourceforge stuff but even things written by core PHP developers, including myself. I don't think we can continue to stick our head in the sand and just push this onto users. And everyone here understands that &{ needs to be stripped or entitied as well, right? How many non-internals folks do you think know that? -Rasmus