Originally Posted by raymor

As of the latest report, something like 85% of all server hacks came through PHP.
So yes, PHP is by FAR the most likely way for your server to get hacked. Zend recognizes
this huge problem, but fixing some of the problems would make certain old code stop working,
so they can;t just fix everything immediately. The most recent version of PHP closes some
of the most obvious gigantic security holes in PHP itself, but it's still horrible. The upcoming
PHP 6 is slightly better, but still pretty bad. As an example, currently ANY PHP script
will allow hackers to upload any file they want onto your server. That's a HUGE security
hole built right into the language and there's not much that the person writing the script
can do about it. If your host runs Apache "SuExec", which several large hosts do, that's
even worse because that means all visitors to your site have the same rights to your files
that you do when you FTP. The combination is SuExec and PHP version 4.0 or less takes
down sites every day.

Add to that the one thing that everyone who likes PHP says about it - "PHP is so easy.
Anyone can write PHP, with no programming training required." Exactly. Any idiot can write
a PHP script and thousands of idiots do. If these people who have never taken a single
programming class or read a single computer science book were writing software for your
desktop, that would just mean there would be a bunch of crappy software available. But
take all this crap written by clueless people, in a braindead language, and put it on a public
web server and you have the worst computer security nightmare in history.

You've read about some of the more well known hacks, like NATS. We hear about smaller
programs being hacked a couple of week - almost always through stupid PHP scripts.

Your web host or admin can set several security related settings for PHP in the PHP
configuration file, php.ini. Setting some of these as restrictive as possible may reveal
security holes in some of your scripts, when HP refuses to execute certain parts of them.
Those scripts can be fixed. It's almost always just one or a few lines that need to be fixed
to make the script more secure, so it'll work in a more secure environment. Unless, of
course, the scriptor was dumb enough to use dozens of autoglobals spread all throughout
the code, with no central validation routine that can be used to populate them properly.
Similarly, if you're not using PHP 5 you can update first and some of the worst holes
from PHP 4 will be patched. Some scripts written for PHP 4 may have used deprecated
functions that were available, but not supposed to be used. They may have some small
problems under PHP 5, which is improved and has removed or changed some of the
worst things people could do under PHP 4.

We're also just starting to test a new service where we heck several thousand possible
security issues on your server. We make sure that it complies with the standards that
the department of defense uses for military computers. It's a pretty thorough scan which
will find a couple of dozen problems on a typical web server. However, it's brand new to
us, something we're testing. It's good enough for the military, so it's probably quite good,
but I can't make any guarantees of the quality just yet.