I want to post a file to a server with a relative path supplied to the file's filename within the Content-Disposition header (using PHP 7.0 on Ubuntu with curl 7.47):
curl server/index.php -F "[email protected];filename=a/b/c.txt"
Applying the --trace-ascii /dev/stdout option shows:
0000: POST /index.php HTTP/1.1
0031: Host: server
004a: User-Agent: curl/7.47.0
0063: Accept: */*
0070: Content-Length: 111511
0088: Expect: 100-continue
009e: Content-Type: multipart/form-data; boundary=--------------------
00de: ----e656f77ee2b4759a
00f4:
...
0000: --------------------------e656f77ee2b4759a
002c: Content-Disposition: form-data; name="file"; filename="a/b/c.txt
006c: "
006f: Content-Type: application/octet-stream
0097:
...
Now, my simple test script <?php print_r($_FILES["file"]); ?> outputs:
Array
(
[name] => c.txt
[type] => application/octet-stream
[tmp_name] => /tmp/phpNaikad
[error] => 0
[size] => 111310
)
However, I expected [name] => a/b/c.txt. Where is the flaw in my logic?
According to https://stackoverflow.com/a/3393822/1647737 the filename can contain relative path.
The PHP manual also implies this and suggests sanitizing with basename().
As we can see from the php-interpreter sources, _basename() filter invoked for security reason and/or to fix some cons particular browsers.
File: php-src/main/rfc1867.c
Lines ~1151 and below:
/* The \ check should technically be needed for win32 systems only where
* it is a valid path separator. However, IE in all it's wisdom always sends
* the full path of the file on the user's filesystem, which means that unless
* the user does basename() they get a bogus file name. Until IE's user base drops
* to nill or problem is fixed this code must remain enabled for all systems. */
s = _basename(internal_encoding, filename);
if (!s) {
s = filename;
}
Collected from the Internet
Please contact [email protected] to delete if infringement.
Comments