Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:14526
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Message-ID: <42010818.2090002@prohost.org>
Date: Wed, 02 Feb 2005 12:04:24 -0500
User-Agent: Mozilla Thunderbird 1.0 - [MOOX M3] (Windows/20041208)
MIME-Version: 1.0
To: Rasmus Lerdorf <rasmus@lerdorf.com>
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> <42001D7B.1040707@trickie.org> <420024EC.4080601@lerdorf.com> <4200457F.5080305@prohost.org> <42005629.3000905@lerdorf.com> <4200D48A.9070305@prohost.org> <42010045.20807@lerdorf.com>
In-Reply-To: <42010045.20807@lerdorf.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] PHP 5.1
From: ilia@prohost.org (Ilia Alshanetsky)

> I see no point in introducing this feature which is aimed at solving the 
> XSS and other related security issues once and for all across all PHP 
> applications while at the same time providing a completely insecure side 
> door.  Dealing with security issues is a pain in the ass.  This pain 
> doesn't go away and there is always the temptation to escape out through 
> a side door and ignore it.  This filtering extension is like your 
> nagging mother constantly there telling you to eat your veggies and 
> clean your room.

No amount of filtering will ever completely solve the problem of code 
written without concern for security. A generic filter that strips HTML 
would break many apps that depend on HTML being submitted via POST. And 
while it seems to the Admin like a good idea, it may not reflect the 
needs of various applications running on the server.
The solution would have to be something like

if (filter_enabled(POST, HTML_TAGS)) {
	foreach ($_POST as $k => $v) {
		$_POST[$k] = filter(POST, $k, FILTER_RAW);
	}
}

Which is exceptionally slow.

> You are coming from the position of already having a decently secure 
> application meant to run everywhere and you have endured this pain 
> already, so I can see that this is additional mostly unnecessary pain 
> for you.  And having to call a function to get the raw data is going to 
> slow you down a little bit.  On the other hand, during installation and 
> configuration of your application you should be able to check if the 
> filtering extension is available and instead of using your user-space 
> data validation checks, replace some of them with the likely much faster 
> checks provided by the extension, so it may be a net gain for you in the 
> end with the added benefit that the application next to you not written 
> by someone as adept as you isn't going to take down the server on you.

Well a cast (int/float) check is going to be still faster then a 
function call even if done internally by PHP. Validating strings in many 
instances would corrupt the desired data by replacing it with spaces or 
what not making the filtered data next to useless.
The end result is that we are punishing people who have already written 
good code and continue to encourage people to write bad code by saying 
"we'll take care of data filtering", which is sorta like safe_mode.

I am by no means opposed to offering functions that can be used to 
perform input data filtering to save the time of having to write your 
own. But, I'd prefer to be able to easily access raw data. Perhaps 
something like filter_restore_raw_data() function that would put the raw 
data back into GET/POST/COOKIE super globals.

Ilia