ID: 29937
Updated by: [EMAIL PROTECTED]
Reported By: justin at timelesstech dot com
-Status: Assigned
+Status: Wont fix
Bug Type: *Directory/Filesystem functions
Operating System: FreeBSD 4.8 stable
PHP Version: 4.3.8
Assigned To: derick
New Comment:
RFC 2616 "Hypertext Transfer Protocol -- HTTP/1.1"
lists:
15.5 Content-Disposition Issues
RFC 1806 [35], from which the often implemented Content-Disposition
(see section 19.5.1) header in HTTP is derived, has a number of very
serious security considerations. Content-Disposition is not part of the
HTTP standard, but since it is widely implemented, we are documenting
its use and risks for implementors. See RFC 2183 [49] (which updates
RFC 1806) for details.
RFC 2388 "Returning Values from Forms: multipart/form-data"
Lists:
"multipart/form-data" contains a series of parts. Each part is expected
to contain a content-disposition header [RFC 2183] where the disposition
type is "form-data", and where the disposition contains an (additional)
parameter of "name", where the value of that parameter is the original
field name in the form. For example, a part might contain a header:
Content-Disposition: form-data; name="user"
with the value corresponding to the entry of the "user" field.
Field names originally in non-ASCII character sets may be encoded
within the value of the "name" parameter using the standard method
described in RFC 2047.
RFC 2183 "Communicating Presentation Information in Internet Messages:
The Content-Disposition Header Field"
lists in 2.3:
The receiving MUA SHOULD NOT respect any directory path information
that may seem to be present in the filename parameter. The filename
should be treated as a terminal component only. Portable specification
of directory paths might possibly be done in the future via a separate
Content-Disposition parameter, but no provision is made for it in this
draft.
So the current behavior is correct and advocated by the RFCs. PHP's
handling of filenames will not be changed.
Previous Comments:
------------------------------------------------------------------------
[2004-09-03 19:03:01] brad at timelesstech dot com
Let me clarify a bit... we use a tool from Radinks, and in this tool
there is a "FULL_PATH" option that will pass along the full path and
filename in the $_FILES['..']['name'] variable. By default, it's just
the filename in this ['name'] variable, but Radinks did something
(possibly in headers?) to allow the fullpath to come through. It looks
as though the security "fix" broke this desired behavoiur.
------------------------------------------------------------------------
[2004-09-03 18:46:33] justin at timelesstech dot com
It was not documented, but this has been the well-known behavior for
quite some time, and the browsers do send the path information. Any
code written to deal the the 'name' value has always had to deal with
the path information, so changing it now breaks all code from previous
versions. Perhaps the new behaviour default could be to only get the
filename, but an override would allow us to get the path too? Just some
way so that old written systems will still be able to work =)
------------------------------------------------------------------------
[2004-09-03 17:49:08] [EMAIL PROTECTED]
I don't think the RFC actually allows that, nor was this ever
documented. I will check the RFC later.
------------------------------------------------------------------------
[2004-09-03 16:58:31] justin at timelesstech dot com
It is the path of the original uploaded file name. The reason this info
is needed, is when a bunch of files are uploaded via a web file manager
application, it needs to know the path of each file, so when it
re-creates the path/file structure on the server, it is able to put all
the files in the right places, rather than everything going in "one
directory".
------------------------------------------------------------------------
[2004-09-03 16:55:42] [EMAIL PROTECTED]
Which path is this, of the original uploaded file name or the one on
the server (in /tmp...)?
------------------------------------------------------------------------
The remainder of the comments for this report are too long. To view
the rest of the comments, please view the bug report online at
http://bugs.php.net/29937
--
Edit this bug report at http://bugs.php.net/?id=29937&edit=1
