Re: Security techniques
| From: | Zeev Suraski | Date: | Mon, 30 Jul 2001 05:03:59 +0000 |
| Subject: | Re: Security techniques | ||
| References: | 1 2 | Groups: | php.dev |
| Request: | Send a blank email to php-dev+get-61419@lists.php.net to get a copy of this message | ||
At 21:23 29/07/2001, Stephen van Egmond wrote:
Zeev Suraski (zeev@zend.com) wrote: At 12:04 29/07/2001, Stephen van Egmond wrote:Umm, there's no need for that code. $HTTP_POST_FILES can only contain uploaded files (I added code that protects $HTTP_*_VARS and $HTTP_POST_FILES from the register_global danger around 4.0.3 or so; Stuff in these variables can only come from the real POST/GET/etc. sources). is_uploaded_file() was added only for those who use register_globals.2. when a uploaded file fails is_uploaded_file().My English parser bailed out on this one :) How's your PHP parser doing? :) foreach $f ($HTTP_POST_FILES) {if (!is_uploaded_file($f)) { die "Ayiee!"; }}
While it may be rare to find a situation in which it's useful more than move_uploaded_file(), these cases do exist. I'm not sure what's wrong with it, can you be more specific? My feelings upon seeing it were of the "aw, man, couldn't something else check for that?". There isn't any reason you would want to accept a file that failed is_uploaded_file() -- so why bother even leaving it as a possibility. While I'm typing this, I also understand that it may have been an emergency introduction into the language in response to a vulnerability report. And I also understand that functionality that exists in some Server API should, in some way, be reproducible in the core without duplicating code.It was just one of the examples to the emergencies that register_globals created for us in the past :) Zeev