Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:26190 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 4281 invoked by uid 1010); 23 Oct 2006 17:38:36 -0000 Delivered-To: ezmlm-scan-internals@lists.php.net Delivered-To: ezmlm-internals@lists.php.net Received: (qmail 4266 invoked from network); 23 Oct 2006 17:38:36 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 23 Oct 2006 17:38:36 -0000 Authentication-Results: pb1.pair.com smtp.mail=rasmus@lerdorf.com; spf=permerror; sender-id=unknown Authentication-Results: pb1.pair.com header.from=rasmus@lerdorf.com; sender-id=unknown Received-SPF: error (pb1.pair.com: domain lerdorf.com from 204.11.219.139 cause and error) X-PHP-List-Original-Sender: rasmus@lerdorf.com X-Host-Fingerprint: 204.11.219.139 lerdorf.com Linux 2.5 (sometimes 2.4) (4) Received: from [204.11.219.139] ([204.11.219.139:53442] helo=lerdorf.com) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id F9/69-39788-A1EFC354 for ; Mon, 23 Oct 2006 13:38:36 -0400 Received: from [207.126.233.18] (rasmus2.corp.yahoo.com [207.126.233.18]) (authenticated bits=0) by lerdorf.com (8.13.8/8.13.8/Debian-2) with ESMTP id k9NHcVhr014266; Mon, 23 Oct 2006 10:38:31 -0700 Message-ID: <453CFE17.5020809@lerdorf.com> Date: Mon, 23 Oct 2006 10:38:31 -0700 User-Agent: Thunderbird 1.5.0.7 (Macintosh/20060909) MIME-Version: 1.0 To: Ilia Alshanetsky CC: PHP internals References: <453C81F8.7080606@hardened-php.net> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [PHP-DEV] PHP 5.2.0 release with "broken" input filters From: rasmus@lerdorf.com (Rasmus Lerdorf) Ilia Alshanetsky wrote: > > On 23-Oct-06, at 4:48 AM, Stefan Esser wrote: > >> Hi, >> >> I just wanted to remind you that PHP 5.2.0 will be released with broken >> and inconsistent input filtering. >> >> Right now _SERVER is only passed through the input filter for apache 1 >> SAPI. All other SAPIs do not pass _SERVER variables through the filter. >> This will be a major headache for people using ext/filter etc... > > In some SAPIs such as CLI it makes little sense to filter $_SERVER in > majority of cases. As a whole I do not believe $_SERVER in its entirety > needs to be filtered, given that at least 1/2 the data there is not > based on user-input. My suggestion is that people use filter_var() > function to filter components of the $_SERVER super-global that they are > using. I had left out SERVER filtering in the initial version for much the same reasoning, but it turns out that a good chunk of holes were due to the fact that people used $_SERVER['REQUEST_URI'] unfiltered. Trying to teach people which SERVER vars are safe and which aren't isn't a fun task and the whole point of the filter extension is to take away the guessing game. -Rasmus