[ale] Seven Deadly Sins - PHP

[J.M. Taylor]

Disclaimer: the following are generalizations based on my experiences as a
systems admin and professional PHP developer.

I think what Bob is trying to say with that deadly sin is, that most sys
admins aren't programmers, and very very few programmers know a SCSI drive
from a garden hose.  And in all cases, running services that you don't
need is bad, bad, bad.

However, if you *do* need some sort of dynamic web content, PHP is a
popular choice. PHP is a scripting language, like Perl (and shame on Bob
for not including Perl in this, and JSP, and ASP,etc).  Scripting
languages allow newbies to easily construct stuff without worrying about
what's going on under the hood, and most programmers that I've met don't
ever think about security anyway (that's the admin's job!).  PHP in
specific is fast to write, and is insanely powerful and flexible.

PHP does have some default settings that can be very dangerous. Lots of
freely downloadable programs break very very badly if you secure PHP
correctly, so many admins are forced into not locking PHP down enough.

http://galinux.com/howtos/phpconfig.html and
http://galinux.com/howtos/apacheconfig.html#php are what I do to lock down
PHP -- not saying it's 100% correct, it's just what I do.

The real danger comes in when bad code meets the web. Most small web
development shops have absurd deadlines and web apps most often are
written by people whose main experience before PHP/perl/asp was with HTML.
There's a lot going on with the web application model that opens your
server up for attack or even suffering from inefficient code, most of
which is totally lost on your average web developer. I've seen
professional PHP devlopers (we're not talking newbies here) write database
calls inside nested loops, essentially calling the database over 400 times
in one script, which is just a total lack of awareness as far as how the
whole server/scripting language/supporting database thing is put together.

So you've got sloppy/deadline-pushed/newbie code on the one hand. You've
got a web hosting environment where the admin is assuming that the
permissions are OK because the machine is trusted (not thinking about the
web being a great big front door to the server), and you've got malicious
people poking at your code.

As an admin, PHP does present a huge number of nightmares, especially if,
as in most cases, you can't tell people not to install things they
download off the web.  I'm sure PhpWidget is very useful, but it's also
probably shite code. (again, replace any code in any language executable
by your web server in place of PHP -- formmail.pl comes to mind).

Your best bet is to use apache to restrict where PHP can execute or even
include files, make sure your web accessible directories are off by
themselves somewhere and locked down like fort knox, batten down PHP thru
its ini file, and periodically search for what your users have installed
on security focus to see if there are known security issues.  You also
probably need to understand enough PHP to offer workarounds for when
PhpWidget breaks because you've got open_basedir in effect, or remote
fopen turned off.

People demand utility at the expense of security, and until more software
companies are made to suffer for crap code, that's not going to change. 
The best you can do is be aware, read everything you can about the
services you run especially with regards to security, and monitor your
server as best you can.  There's no magic language that's secure for
writing web apps, and there's no darkly evil language that is inherently
bad.  There are, however, lazy, overworked and just plain ignorant coders
and admins, and malicious users in abundance.

HTH

here's my 10 cents, my 2 cents is free
jenn


_______________________________________________
Ale mailing list
Ale at ale.org
http://www.ale.org/mailman/listinfo/ale