Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:14484
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Message-ID: <42000EE8.2000104@lerdorf.com>
Date: Tue, 01 Feb 2005 15:21:12 -0800
User-Agent: Mozilla Thunderbird 1.0 (Macintosh/20041206)
MIME-Version: 1.0
To: Christian Schneider <cschneid@cschneid.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> <42000CA3.5020705@cschneid.com>
In-Reply-To: <42000CA3.5020705@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:
> 
>> 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, 
> 
> 
> I assume this will include PHP functions to do the filtering as well? 
> (Forgive me if we already have this now, I haven't looked at 5.0 enough 
> yet :-))

Right,a function to filter user data through any of the filters will be 
provided as well.

>> $age  = pfilter(POST, 'age', FILTER_DIGITS);
>> $addr = pfilter(POST, 'addr', FILTER_ALNUM);
>> $body = pfilter(REQUEST, 'body', FILTER_TAGS);
>> $raw  = pfilter(COOKIE,'cook', FILTER_RAW);
> 
> 
> Sounds like a good idea (even though the name pfilter reminds me too 
> much of packet filter :-)). A catch-all could be handy too, e.g.
> pfilter(REQUEST, DEFAULT, FILTER_TAGS);

I just made up the pfilter name.  I really don't care what it is called. 
  Figured filter() was a bit too generic and likely to step on existing 
user-space functions out there.


> which filters anything not handled before. Surely you can come up with a 
> better interface but I hope you get the idea. Being able to define a 
> default filter but still override it for certain variables is what I 
> mean. (Also important would be that FILTER_TAGS is more robust than 
> strip_tags which has some loopholes IIRC)

strip_tags only has loopholes if you allow some tags through.  But yes, 
this would be a very strict get rid of all tags filter and it needs to 
be charset aware.

> A bit off-topic: I'm sure variable tainting has been discussed before, 
> can some give the final opinion, was it found unsuitable/too much 
> work/too inefficient or was it just post-poned (maybe indefinitely)?

It is really hard to do this correctly.  Most user data in a web app is 
multi-purpose in the sense that it is often both displayed and inserted 
into a database, for example.  The untaint rules are vastly different 
for these two purposes.  Throw in a few more and you have a mess on your 
hands.  Just because you untainted it for one purpose doesn't mean it is 
safe for another, so I don't really see how a single taint flag can be 
all that effective.  I would rather see context-specific access function 
that retrieves the data for a specific purpose.  In this case 
implemented by calling pfilter with a given filter.

And just to clarify, since I added the hook to do this long ago, there 
aren't actually any PHP changes needed.  It can be completely handled in 
a pecl extension.  It just becomes a matter of whether/when to include 
it with PHP.

-Rasmus