> 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
[EMAIL PROTECTED] 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 [EMAIL PROTECTED] address is an endangered species -- Use
[EMAIL PROTECTED]
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
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]
