[ Curse you `Lusercop', you know I can't resist a PHP-rant... ]

On Tue, 29 Oct 2002, Lusercop wrote:

> On Tue, Oct 29, 2002 at 03:35:22PM +0000, Paul Makepeace wrote:
> > I'd read this as FUD, frankly, until you can show PHP has suffered
> > vulnerabilities so severe as to require shutting down service "every
> > few weeks".
> > This might seem anal of me but people might actually take what you're
> > saying to heart and then continue to spread disinformation. If a package
> > deserves commentary like that (say MS not fixing reported bugs for after
> > several weeks of being notified), fair enough, if it doesn't, it's worth
> > IMO avoiding hyperbole.
> 
> I read what you're saying, and I'm unlikely to support PHP on my server
> for similar reasons to Roger. Chris Andrews, who reads this list[1], can
> probably explain better, as he has to deal with user support for PHP. In
> essence, however, it seems to be very easy to write PHP in a way that it
> silently eats errors, fails to quote appropriately, and other such things,
> and much harder to write PHP of a quality that will withstand serious
> attempts against it.

Of course, it's very easy to write such code in any language, but PHP's
way of dealing with this is wrong. Instead of attempting to educate the
user community as to how to write secure code, the PHP approach is to
offer 'magic bullets', such as escapeshellcmd(), and to simply say 'you
should use this, it makes everything better'.

There are also a significant amount of convenience features, designed to
reduce the overhead of getting a script up and running, such as injecting
CGI variables as globals - yuck! Sure, this lets you embed little snippets
of code into a web page very easily, but these days it looks to me like an
indication of PHP's roots as SSI-on-steroids.

You can take steps to lock PHP down, even on a shared server, but it's not
the default state after install and there doesn't seem to be a canonical
way of securing a shared PHP installation. Most importantly, if you *do*
succeed in locking it down, your users will just complain that their
scripts don't work. Worse, they will work around the 'security': just look
in the user submitted notes for the 'Safe Mode' feature in the PHP manual
for ways of avoiding it.

Apart from anything else, the reason I don't use PHP on my personal
machines is that I think it's about as good a language as a collision
between all the bad bits of Perl and all of Visual Basic. 


Chris.



Reply via email to