Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:14662
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Date: Sun, 06 Feb 2005 11:33:29 -0700
In-reply-to: <42065229.20901@lerdorf.com>
To: internals@lists.php.net
Message-ID: <200502061133.29887.benjcarson@digitaljunkies.ca>
MIME-version: 1.0
Content-type: text/plain; charset=iso-8859-1
Content-transfer-encoding: 7bit
Content-disposition: inline
References: <5.1.0.14.2.20050201142816.026d21c0@localhost>
	<20050206170705.48791.qmail@lists.php.net> <42065229.20901@lerdorf.com>
User-Agent: KMail/1.7.2
Subject: Re: [PHP-DEV] PHP 5.1
From: benjcarson@digitaljunkies.ca (Benj Carson)

My opinion may not carry any weight here, as I'm just a user of PHP, but 
this discussion has given me a few ideas.  As Ron and Val (and others) have 
pointed out, there's no way for PHP to know how an *input* value is going 
to be used.  Would it perhaps be better to filter *output* values?

The same scheme of proposed filters could instead be applied just-in-time as 
values hit an output function.  I'm not sure how exactly it could be 
implemented, but something similar to the pg_{select|insert|update|delete} 
scheme might work.  For html output, echo() and print() could be modified.

This way, when I echo a $_GET variable, it could automatically be run 
through htmlentities(), and when I insert the same variable into a database 
it will be run through pg_convert()/pg_escape_string().  I can see there 
being difficulties identifying dangerous values if variables have been 
interpolated into a string, but perhaps a tainting model could solve this.

(The in-house PHP framework that we use does basically the above.  Our 
database objects read metadata for the tables they manipulate and their 
__set() methods automatically convert values to the appropriate column 
types.  Our template objects and functions automatically use htmlentities() 
or addslashes() as required when outputting variables.)

Just my $0.02,


Benj Carson


On February 6, 2005 10:21 am, Rasmus Lerdorf wrote:
> Well, you already have the problem.  The filter hook has been in PHP5
> for 2 years now and people are using it already.  And yes, your code is
> likely not to work on those servers if you are expecting raw html tags
> to get through.
>
> There are plenty of people who have to operate under a mandated security
> policy.  That policy may state among many other things that no
> user-originated raw html tags may ever be displayed.  Now, if I gave you
> that problem and a couple of thousand servers running millions of lines
> of PHP code, how would you solve it?
>
> My solution is to block everything and then go and fix the few places
> where raw tags are actually supposed to get through and make sure those
> few places are validated correctly.
>
> You seem to be be indicating that you would go through every line of
> code and make sure every single application did all validation correctly.
>
> Want to wager a guess at who would be done first?
>
> I am wide open to other approaches to solving this problem.
>
> -Rasmus
>
> Ron Korving wrote:
> > Well there you go. A default filter. So I don't know what you mean with
> > "For the 18th time, nobody is talking about enabling it by default.",
> > because an administrator might. And I as a developer have no clue.
> > Personally, I don't see why a webserver admin should need to secure his
> > server through means of a default filter. There are good ways to secure
> > a machine. This is not one of them  You don't secure a server by
> > setting a default that a user can override. So really, that is no
> > argument.
> >
> > Like I said before. If a webserver admin dicatates the default way
> > $_GET and $_POST data is perceived, a website developer has no choice
> > but to use this filtering mechanism on every input variable he
> > receives, because he just can't rely on PHP's default behaviour
> > anymore. You see, not everybody agrees that you can't do without input
> > filtering (myself for example), so in the end, there's no doubt in my
> > mind that forcing a new magic default on PHP-users will make a lot of
> > people unhappy.