RE: [PHP-DEV] PHP File Upload Security Hole - Still No Fix?

> I would also suggest that you deprecate the utterly broken > 'register_globals', 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, if you want *you* can turn this feature off. You also have control over the order in which these variables are set. If you are paranoid (and sometimes this is needed) then you can always use the arrays set by PHP HTTP_POST_VARS, HTTP_GET_VARS and turn register_globals off (Thats what php.ini is there for, so you can choose how *you* set up PHP. HTTP_POST_FILES already exisits AFAIK. 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? Another idea might be to separate out the file upload in variables_order and add another option that lets you place file uploads separate from post or get. This enables to user/admin to stop uploads being registed globally and forcing the user to user HTTP_POST_FILES. Personally I think this might help. 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. 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). IMHO these few things would help secuity but its the same as Apache, BugZilla, MySQL, Linux, Windows 2000 or any other piece of software. It is only as secure as the weakest link. If this is PHP then we need to do somthing about it *WITHOUT* removing functionality (if possible). But if you set up MySQL, Apache and BugZilla incorrectly (as proved at apache.org) then the machine becomes vanrable. If you set up PHP incorrectly (and script unsecurly) then the machine can be come vanrable. There is nothing we can do about this, we should enable, as much as possible, for the user to ensure security (IE through the above and other methods) as well as making the users aware of potential security issues that are down to them to ensure. > and magic_quotes features, and try and remove > them completely in a later version of PHP. They are both recipes > for certain disaster. The CGI variables should be accessed via > a function. If you make its name short (I use 'F' for 'form'), > it requires little extra effort from the script programmer, in > return for making it possible to write secure scripts. once again magic_quotes can be turned off if you want but it is also used by a lot of scripts that have been already written, we want to keep PHP as backwardly compatible as possible, why should we remove it when you the user can turn it off, the same goes for safe mode (althought maybe it shouldnt be called safe_mode :)). <flame> I think that you have jumped on the bugtraq band wagon here, of course PHP has some bugs (It is bound to with goodness knows how many different developers and thousands of lines of code) But I think that if they can be fixed when they are brought to the developers attention then that is the best we can ask from the developers. I think your criticism of the php interpriter is unneeded. It has been very well written that is why PHP is now installed on goodness knows how many million servers. Im also sure that if you looked at the ASP or Coldfusion code that their interpriters are also, in your high opinion are nowhere near well-written enough. I think that this is very unfair of you when Zeev, Andi and many many others have spent many hours working on that code and has been proved by its uptake by others it is well written and in the majority of cases secure. </flame> Anyway just my ?0.02 Keep up the good work guys.. James