Security Hardening . . . . . . . (was Re: [tlug] Host Blocking and Logfile Parsing)

["Stephen J. Turnbull" <stephen@example.com>]

Jim writes:

 > Learn how to write safe shell scripts. 

That's not easy.

 > Many PHP exploits involve badly written PHP code. 
 > As with shell scripts, learn how to write safe PHP code. 

That's a dodge.  Exploits of badly written code should be listed as
exploits of badly written code, not attributed to the language or
platform (unless they basically amount to contributory negligence).
The fact is that PHP has had a long track record of exploits in PHP
itself.  My basic feeling is that web scripting languages that are
designed to be "called" from HTML[1] are inherently dangerous, and I'm
not surprised that PHP is a victim (for those who care about my
unsubstantiated intuition).

The big advantage to the sandboxing method is that it gives the
inexperienced developer a way to discover what "least privilege" is in
his application.  If cut'n'try is too slow, he can either book up so
he gets it "more right" the first time, or just rely on "learning by
doing" to kick in and give him better "intuition" on followup projects.


Footnotes: 
[1]  The distinction is against frameworks like Zope which place the
burden of checking access on the framework, rather than distributing
it across the scripts, the server, and the file system.