Web Hacking Lesson 5 - File Upload Vulnerabilities
PHP File Upload Exploits
Note: If you haven't read Lesson 1 go check it out first for test application install instructions.
File upload exploits are a common problem with web based applications. In a nutshell this vulnerability hinges on functionality that allows an attacker to upload a script file that can then be executed on the server. The most common cause of this vulnerability is functionality that is supposed to allow users to upload inert content (things like images, PDF documents and the like) that is designed to be displayed. Often, however, developers forget to accomplish proper input validation (are you noticing a theme here yet?) that doesn't restrict the types of files an attacker can upload.
Let's start the exploration of PHP file include vulnerabilities by creating a simple PHP file. Open a text editor and paste the following code into it, then save the file as phpinfo.php:
<?php echo phpinfo();?>
This file will simply print out server configuration information (which could potentially be very dangerous information to expose). Next we'll upload this file utilizing the file inclusion vulnerability we exposed earlier. Call the page:
/index.php?include=image_upload.php
Next browse to the file you saved as phpinfo.php and upload it. Next browse to the URL
images/phpinfo.php
You can see that the PHP code that we included in our file was executed by the server. There are several vicious attacker tools (like the c99 shell) that are single PHP files that can be uploaded to a server and used to execute pretty much any command the attacker wants. At that point the attacker has taken over whatever account is running the web server process, which is usually a system level account. Damage can be pretty widespread at that point, with the attacker being able to take over the entire machine without too much additional work.
Preventing PHP File Upload Exploits
The best strategy for preventing file upload exploits is to limit the attackers ability to call view files from their upload location. For instance, files should be uploaded to directories that exist outside of the application path. This means that the file can still be read by the web server, but can never be directly called by an attacker via a specific URL.
Developers should never trust user uploaded content. It isn't easy to determine the type or contents of files uploaded by an end user. Careful control over the display of these files should be utilized. For instance, when displaying a file the developer can call the file by calling a separate PHP file that renders the file with code such as:
<?php
header('Content-Type: text/plain');
header("Content-Disposition: inline; filename=\"$file_name\"");
echo $file;
?>
This PHP code will display PHP code uninterpreted (meaning the code itself will be displayed, but it will not be run).
Displaying images can similarly be controlled by either carefully utilizing libraries like GD to do image manipulation and checking when the file is uploaded, and 'Content-Type' declarations when the images are displayed.
It bears repeating again, however, that user uploaded content can never be trusted. Even when users upload 'allowed' file types there is no guarantee that the files will be safe. Users can upload documents infected with viruses or malicious versions of files designed to exploit flaws and vulnerabilities outside the web application. Utmost care should be utilized when allowing user uploaded content.