Re: PHP File Upload Security Hole - Still No Fix?

From: Date: Tue, 05 Sep 2000 11:58:57 +0000
Subject: Re: PHP File Upload Security Hole - Still No Fix?
References: 1 2  Groups: php.dev 
Request: Send a blank email to php-dev+get-32127@lists.php.net to get a copy of this message
James Moore <jmoore@php.net> wrote: > I would strongly dissagree with this, this IMHO is one of the most useful > features of PHP, I know that I can write a form processor for example and > wether it is used with a get or a post I will still have the same variables, Err, yes. Exactly as you would if you had to call a function, or use some other special syntax, to get the form variables. Suppose you said that form variables should be accessed as '%foo' rather than '$foo', which would still be used for 'real' variables. This would remove the disastrous confusing over the source of variables, without any loss of convenience. > Another point about killing register_globals is that 99.99% of form > processing does not include uploading so why should we break this great > functionality for this? This point has nothing to do with file uploads. register_globals is a disaster regardless of whether or not files are being uploaded. > I feel that we cannot make users write secure scripts (If so we should > remove eval,<List of Useful Functions in here>). But I do feel we should > give users the ability to write secure scripts. Indeed! And you should also *encourage* them to write secure scripts. PHP as it stands *actively discourages* people from writing secure code. If they want to do things right they must ignore a great deal of the 'usual' way of doing things in PHP, and go off in their own direction. > They should be able to tell where a variable comes from and also if it > came from where they expected (One and the same thing). Yes. This is exactly what register_globals does not do, and is exactly why it is a terrible idea. The same argument applies to magic_quotes - the lack of any easy way to tell the difference between a variable which has been magic_quoted and one which has not will inevitably lead to confusion, and calls to addslashes() being missed out where they were essential. > I think that you have jumped on the bugtraq band wagon here, of course PHP > has some bugs Yes, I know. I've been using it for a long time. I'm not 'jumping on a bandwagon'. I simply took advantage of the fact that I was pointing out errors in the PHP response to the BUGTRAQ article to get a few other things off my chest that I've been meaning to for a while. > I think your criticism of the php interpriter is unneeded. It has been > very well written !!! Don't even *go* there. > that is why PHP is now installed on goodness knows how many million servers. No, PHP is useful, *that* is why it is widely used. That is why *I* use it. It doesn't make it well-written, or secure, or the developers clever. Cheers Jon

« previous php.dev (#32127) next »