A few days ago one of our users requested that I look into some security features requested 2 years ago on bugs.php.net by Peter Brodersen. The first one is an addition to the session extension that stops attempts to access the session data of another user during SAFE MODE and the second one is a change in the behaviour of glob() to better obey SAFE MODE and open_basedir restrictions. In plain PHP glob() allows retrieving a list of all files on the server through the SAFE MODE or open_basedir error messages.

While I consider SAFE MODE and open_basedir broken solutions that should get replaced by proper UNIX file permissions I created two patches for both problems to make the users happy. The first problem is solved by appending the UID of the script to the session filename during safe_mode and the second one by performing silent safe_mode/open_basedir check for every single file. I did not bother commiting the patches into the PHP CVS because the bug was rejected several times as bogus.

glob_safe_mode_open_basedir_fix

session_safe_mode_postfix

I wanted to announce that in 2007 the Hardened-PHP Project is going to create a few new security products. One will be a userspace PHP Input Filtering library that can be used in PHP 4 and PHP 5 for Input Filtering in a compatible way and that is not part of some framework, so that it can be easily used in your existing application. If you are interested in contributing don't hesitate to contact us by email.

From time to time the ext/filter topic comes up. Yesterday one of its authors was attacking serendipity for having code inside that bypasses ext/filter to get the original RAW values. Quite amusing how he claims the only correct way to do input filtering is to use the ext/filter functions and only use your own functions as a fallback. Infact the only sane way is the other way around: Have your own input filtering functions and do not even think about using ext/filter. There was actually never a need for ext/filter because everything it does can be implemented on a PHP level with plain PHP functions. ext/filter is just a new irritating API to already existing functionality, that potentially introduces new security holes, because it reimplements existing stuff again.

ext/filter is a similar stupid idea like magic_quotes_gpc. When you use it, the security of your application depends on the server configuration and no longer on your application code. And if you have similar input filtering functions to be compatible with servers that do not have ext/filter (which is the majority of all servers) then there is no reason at all to use ext/filter. Supporting ext/filter makes your code more complex and in case of a bug in ext/filter you have no chance to protect your users, because security only relies on the admin's will to upgrade. Considering the fact, that ext/filter is a builtin extension this means he has to recompile PHP.

Additionally ext/filter will keep a copy of all GPC variables in memory even when it is not used, therefore it is wise to add --disable-filter to your configure line if you do not want to waste ressources.