Bug #1687 Updated: HTTP Upload with IE3

ID: 1687 Updated by: sander@php.net Reported By: php@tainted.org -Status: Assigned +Status: Bogus Bug Type: Other Operating System: Linux 2.0.x/glibc2.0 PHP Version: 3.0.9 Assigned To: rasmus New Comment: Thank you for taking the time to report a problem with PHP. Unfortunately, PHP 3 is no longer supported. Please download the latest version of PHP 4 from http://www.php.net/downloads.php If you are able to reproduce the bug with one of the latest versions of PHP, please change the PHP version on this bug report to the version you tested and change the status back to "Open". Again, thank you for your continued support of PHP. Previous Comments: ------------------------------------------------------------------------ [2000-08-06 09:20:07] rasmus@php.net Remind myself to look into this one. ------------------------------------------------------------------------ [1999-11-14 04:00:19] joey@cvs.php.net Has this gone anywhere? ------------------------------------------------------------------------ [1999-07-10 14:14:00] rasmus@cvs.php.net I don't think the suggestion in the second note is very good. $userfile should be determined by the server and never by the client. The fact that IE3 can get around this because it sucks is simply a bug and we need to check for that in an intelligent manner. Once detected we simply set $userfile to "" or false ------------------------------------------------------------------------ [1999-07-10 14:06:02] markonen@cvs.php.net My suggestion on this: change the file upload functionality on the next major release (4.0?) to fill the $userfile variable with the uploaded filename relative to the php temp directory. With our file upload implementation identical otherwise, this would mean that a proper file upload would never lead to $userfile value that contains a slash or a backslash. My opinion is that the security implications of this problem seem to warrant breaking of backward compatibility. My proposed change would: a) force the script implementors to rework their code, taking into consideration the security implications of this problem b) allow script implementors to check for a safe $userfile to fopen() by just looking for slashes or backslashes in it ------------------------------------------------------------------------ [1999-07-09 10:51:13] php@tainted.org HTTP Uploading is built into PHP3. HTTP Uploading is not supported by IE3. Having a form with an entry like: <INPUT ENCTYPE="multipart/form-data" NAME="userfile" TYPE="file"> Should make a browser provide a string gadget and a "Browse..." button to locally select a file to upload. PHP3 normally accepts the data stream and puts it into a temporary file. When the form is submitted, the form handler will have a variable of "$userfile" which contains the name of the file PHP3 accepted it as, most webmasters check to make sure that the $userfile is not "" or "none" and then proceed to fopen($userfile,...) for their needs. IE3 does not support HTTP Upload, but decides to give the browser user a string gadget nevertheless. The user may enter the name of a file on the server "/etc/fstab" (or worse), which is sent to PHP3 from IE3 and the HTTP-Upload portion of the form is not triggered. This leaves the $userfile variable with the name of the file the user has entered, which many scripts would just fopen() and use. I believe the only work around for this is to document it and ensure to check the filename that it starts with the php3 temporary path; other methods could likely be exploited. ------------------------------------------------------------------------ -- Edit this bug report at http://bugs.php.net/?id=1687&edit=1