Re: hacks we should know about

> just found this article and the author recommends the following for secure php > scripting. what do the expects think? This article has been discussed in excruciating detail on PHP-Dev@lists.php.net and the expert's opinions are archived... http://php.net/support.php should lead you to this archive. > **** - Set register_globals off > This option will stop PHP creating global variables for user input. That is, > if a user submits the form variable 'hello' PHP won't set $hello, only > HTTP_GET/POST_VARS['hello']. This is the mother of all other options and is > best single option for PHP security, it will also kill basically every third > party application available and makes programming PHP a whole lot less > convenient. Expect to see register_globals off as the default setting in PHP 4.1, I *THINK*. > *** - Set safe_mode on > I'd love to describe exactly what safe_mode does but it isn't documented > completely. I dunno what more documentation he *WANTS* than what is on the web-site... Not that I claim to *UNDERSTAND* it all :-^ > - Kills file upload completely I *think* safe_mode can be on and files can be uploaded if the ISP works at it... But they have to want it bad enough to do some configuration. Most ISPs want to just install stuff as-is and not take the time to find out how to really configure it for optimum safety/functionality. > ** - Set open_basedir > This option prevents any file operations on files outside specified > directories. This can effectively kill a variety of local include() and > remote file attacks. > Caution is still required in regards to file upload and > session files. Which is why safe_mode exists. > ** - Set display_errors off, log_errors on > This prevents PHP error messages being displayed in the returned web page. > This can effectively limit an attackers exploration of the function of the > script they are attacking. It can also make debugging very frustrating. Not really. First of all, you *OUGHT* to be developing on a different, non-public box than your live server. Throw PHP on your laptop or desktop and write your new code there, where you have display_errors on. Only on the live site do you need display_errors off, and hopefully your code is mostly debugged by that point. Even so, you just open up another window and tail -f your error log file if you need to debug something. For any particularly tricky debugging, you can use something like this: if ($REMOTE_ADDR == 'your.IP.address.here'){ echo "whatever"; } Only you want to use $HTTP_ENV_VARS['REMOTE_ADDR'] or whatever it is. > * - Set allow_url_fopen off > This stops remote files functionality. Very few sites really need this > functionality, I absolutely recommend every site set this option. Well, I use it, but I suppose it's up to you. The things that go wrong with this being on are (I think) the result of stupid code like: include $foo; which is already problematic, regardless of whether $foo is hacked to be a remote file or a local one... Anybody else can weigh in on this, go ahead. I think the *REAL* issues raised here is that far too many PHP scripters, self included, are pushing code out to make it work and not focussing on security enough. It's *POSSIBLE* to write more safe code, and the PHP Dev team is working to make it easier. But for now, the onus is on *YOU* to figure out what's "safe enough" and what's not for *YOUR* application. -- WARNING richard@zend.com address is an endangered species -- Use ceo@l-i-e.com Wanna help me out? Like Music? Buy a CD: http://l-i-e.com/artists.htm Volunteer a little time: http://chatmusic.com/volunteer.htm