PHP 5.2.0 release with "broken" input filters

Hello,

Hello,

Hi,

I just wanted to remind you that PHP 5.2.0 will be released with
broken
and inconsistent input filtering.

Right now _SERVER is only passed through the input filter for apache 1
SAPI. All other SAPIs do not pass _SERVER variables through the
filter.
This will be a major headache for people using ext/filter etc...

In some SAPIs such as CLI it makes little sense to filter $_SERVER in
majority of cases. As a whole I do not believe $_SERVER in its
entirety needs to be filtered, given that at least 1/2 the data there
is not based on user-input. My suggestion is that people use
filter_var() function to filter components of the $_SERVER super-
global that they are using.

That said, in future release there are plans to extend support to
Apache 2 and cgi/fcgi sapis as well as add handling for $_REQUEST.

Yes, and more generally as soon as we fix the leaks and the other
troubles we spoted recently. I still like to disable ENV/SERVER
support in 5.2.0 (just like _REQUEST), we can restore it later.

I just discussed with Ilia about this problem. 5.2.0 will be kept as
it is now, only the apache1 sapi will be supported. Other sapi will be
introduced for 5.2.1.

Ilia already have a patch for apache2 sapi support, it will be
commited in HEAD as soon as possible, other will follow.

Thanks for the head up,

--Pierre

I had left out SERVER filtering in the initial version for much the
same
reasoning, but it turns out that a good chunk of holes were due to the
fact that people used $_SERVER['REQUEST_URI'] unfiltered. Trying to
teach people which SERVER vars are safe and which aren't isn't a fun
task and the whole point of the filter extension is to take away the
guessing game.

Perhaps in 6.0 one could consider having:

$_SERVER
$_SERVER_DIRTY

or some similar scheme so that people know there is something
"wrong" with just blindly using that data...

Or rename it, so it's not "SERVER" for user-supplied data...

I mean, you've labeled it "SERVER" so I figure it comes from the
SERVER, right? Not from the USER... I know, that's a stupid way to
look at things, but there it is.

PS Digging the Yahoo! Maps API :-)

--
Some people have a "gift" link here.
Know what I want?
I want you to buy a CD from some starving artist.
http://cdbaby.com/browse/from/lynch
Yeah, I get a buck. So?

On Mon, 23 Oct 2006 10:38:31 -0700, in php.internals
rasmus@lerdorf.com (Rasmus Lerdorf) wrote:

I had left out SERVER filtering in the initial version for much the same
reasoning, but it turns out that a good chunk of holes were due to the
fact that people used $_SERVER['REQUEST_URI'] unfiltered. Trying to
teach people which SERVER vars are safe and which aren't isn't a fun
task and the whole point of the filter extension is to take away the
guessing game.

More well-known, the same goes for the HTTP headers populated in
_SERVER as well, even though some might be less obvious than other.

HTTP_HOST could be tainted as well in some cases where a DNS entry and
ServerAlias of *.example.com exists.

An attacker could trick a user into visiting
www.%22%3EXSS.example.com which at least IE6 would accept as a valid
URL.

--

• Peter Brodersen