Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:14532
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Message-ID: <42013DB9.5000601@lerdorf.com>
Date: Wed, 02 Feb 2005 12:53:13 -0800
User-Agent: Mozilla Thunderbird 1.0 (Macintosh/20041206)
MIME-Version: 1.0
To: Jeff Moore <jeff@procata.com>
CC: internals@lists.php.net
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> <99da3c6937a48377bdb7790dccfaef1e@procata.com>
In-Reply-To: <99da3c6937a48377bdb7790dccfaef1e@procata.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)

Jeff Moore wrote:
> 
> 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.

We have seen definitively that many application writers do not know how 
to properly validate data.  And yes, it is another ini thing to worry 
about, and yes it will be painful, but I don't think we can continue to 
ignore this.  I also think that people who actually write good and 
secure web apps in PHP won't have too many problems with this.  It will 
just be an additional tool they can use if it is available.  For people 
who don't know what they are doing or don't care about security, it may 
very well break their applications, but those applications most likely 
should be broken.

Pick 10 random PHP apps out there and go through them.  With very very 
few exceptions 10 out of 10 will be insecure.  And the blame here is not 
just on the developers of those applications, we are partially to blame 
for not providing enough tools and guidelines.  This is what I am trying 
to rectify with minimum impact to the existing code and the way people 
do things.  Some of your suggestions are good, but some just aren't 
feasible.  For example, it would be difficult to implement your idea of 
only letting data through if a filter was assigned to it and having 
those filter assignments happen in the scripts themselves since that is 
too late in the game.  It could be hacked, but it would be ugly and 
complex.  Having just a single optional default filter per request is 
simpler to manage and implement.

-Rasmus