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.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
