[ 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.