php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login

go to bug id or search bugs for

Bug #1687 HTTP Upload with IE3
Submitted: 1999-07-09 10:51 UTC Modified: 2002-06-16 08:33 UTC
From: php at tainted dot org Assigned:
Status: Not a bug Package: Other
PHP Version: 3.0.9 OS: Linux 2.0.x/glibc2.0
Private report: No CVE-ID: None
View Developer Edit
 [1999-07-09 10:51 UTC] php at tainted dot 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.

Patches

Pull Requests

History

AllCommentsChangesGit/SVN commitsRelated reports
 [1999-07-10 14:06 UTC] markonen at cvs dot php dot 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-10 14:14 UTC] rasmus at cvs dot php dot 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-11-14 04:00 UTC] joey at cvs dot php dot net 
Has this gone anywhere?
 [2000-08-06 09:20 UTC] rasmus@php.net 
Remind myself to look into this one.
 [2002-06-16 08:33 UTC] sander@php.net 
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.
 
PHP Copyright © 2001-2024 The PHP Group
All rights reserved. 		Last updated: Sat Dec 21 11:01:30 2024 UTC