Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:14492 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 75993 invoked by uid 1010); 2 Feb 2005 00:45:18 -0000 Delivered-To: ezmlm-scan-internals@lists.php.net Delivered-To: ezmlm-internals@lists.php.net Received: (qmail 75978 invoked from network); 2 Feb 2005 00:45:18 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 2 Feb 2005 00:45:18 -0000 X-Host-Fingerprint: 66.198.51.121 lerdorf.com Linux 2.4/2.6 Received: from ([66.198.51.121:60794] helo=colo.lerdorf.com) by pb1.pair.com (ecelerity HEAD (r4105:4106)) with SMTP id BB/9C-00705-79220024 for ; Tue, 01 Feb 2005 19:45:12 -0500 Received: from [207.126.233.18] (rasmus2.corp.yahoo.com [207.126.233.18]) (authenticated bits=0) by colo.lerdorf.com (8.13.3/8.13.3/Debian-4) with ESMTP id j120bL0w008714 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 1 Feb 2005 16:37:21 -0800 Message-ID: <420020C0.9080801@lerdorf.com> Date: Tue, 01 Feb 2005 16:37:20 -0800 User-Agent: Mozilla Thunderbird 1.0 (Macintosh/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Christian Schneider 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> In-Reply-To: <42001C1D.3090105@cschneid.com> 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) Christian Schneider wrote: > Rasmus Lerdorf wrote: > >> I don't actually see it as a per-script thing. Obviously the ini >> would be per-dir Apache configurable, but I see this as being >> something set across the board on a dedicated server that defines the >> security policy of that server. Shared servers are most likely not >> going to be able to > > > Uh, that's a big goal but also asking for trouble. As you pointed out > there is a different rule on what's safe for a specific input variable > based on what it's used for (e.g. SQL, output, shell arg) and what's > not. Wouldn't one have to set up default filters for every possible use > to be safe then, i.e. a combination of all filters? Well, if you set a global filter you set an extremely strict one. Like only letting a-z through or the equivalent in your charset, for example. Want a number? Tough, call the filter function to get at it. The idea is to force people to think about how to filter each piece of data they need, and if they forget one it will still work, but what gets through will be extremely limited. > Another major point would be to handle UTF8 properly, something which is > not easily handled by regular expressions, right? The preg* functions support UTF8. But yes, the filters need to understand charsets correctly. -Rasmus