There are a few reasons why you should consider the network security for your upload directories. Whether you allow image uploads only, or various file types, security is extremely important. How you apply the available layers of security using the file system and PHP depends on your level of paranoia and the sensitivity of the uploaded content.
If your upload directory is intended for image files only, you must assume someone will try to upload a non-image file, perhaps even a harmful script. This poses an immediate need for evaluation. Is the destination directory for the image uploads publicly available, allowing a remote user to execute a harmful script? If the uploaded file is a PHP Program that creates a network security vulnerability to exploit, you definitely want public access to the upload directory restricted to NONE.
The method of file protection is similar to the methods for harmful program upload defunctification and storage for later retrieval. For image upload protection specifics, scroll to the bottom for the recap Â»
If your upload directory must remain publicly accessible and your uploads are a variety of filetypes, you must use PHP Programs to filter the uploaded content before the files are parked in the upload directory. PHP can check the MIME Type of the uploaded file, the file size, and the file content. Regardless of your ability to create and configure PHP filters, there are simple methods of avoiding the execution of harmful PHP Programs after upload.
Ideally, you would want PHP to handle the file system and hand the results and file content to the user. If the upload directory had no permissions for “Everyone,” you could let PHP read and write the files, forcing the user to use your PHP scripts to manage all file transactions. Still, the uploaded files might be harmful and if left intact, might cause problems. If you intend to let users upload harmful scripts to your upload directory, such as for a Virus Repository or a directory of Harmful Programs, you want to accept the uploads, provide them to your users, but prevent them from bringing your server down or compromising your web services.
If the user uploaded a Harmful Program (we’ll call it Linux.Backdoor.Rexob.exe), you would face a few questions before coding a filter or file upload management system. Does your web server have anti-virus and/or anti-spyware programs that will remove the file anyway? Is the upload directory publicly accessible such that the programs can be executed? What is the intent of file upload usage? How do users need to access the files?
Anti-virus and anti-spyware software may be monitoring the file upload directory. If so, your web server may generate unnecessary log files, which may make the evaluation of real server exploitation difficult to track and evidence difficult to identify. If the desire is to retain harmful files intact and executable, you must turn your anti-virus and anti-spyware programs off, or preferably to tell them to ignore your file upload directory.
If your file upload directory is accessible to the public, and they might be able to execute a file that was uploaded, you must take measures to secure the file and prevent rogue exploitation through remote file execution. Most measures so far would have eliminated the harmful programs by this point. Anti-whatever might have killed it, your PHP Program filter might have identified it and killed it or defunctified it (I like that term!). At this point we will say the harmful file is supposed to get into the file upload directory and sit there for future use.
The question posed is, “How do we make the harmful program inert until we are ready to use it?” If the file upload directory is publicly accessible and the file possibly executable, we could simply change the name of the file, so it isn’t predictable for the user. If we change the name of Linux.Backdoor.Rexob.exe to Linux.Backdoor.Rexob.exe.dead, the file isn’t necessarily executable or discoverable by prediction. However, this alone is insufficient to defunctify the harmful program.
The web server most likely carries the duty of tracking the files, their names, their locations and maybe other specs on each file that has been uploaded. Make use of this tracking system to make file name changes. The server can have its own ID creation and tracking system for filenames using a MySQL Database or flat file system. “Linux.Backdoor.Rexob.exe” is changed in the file system to “uploaded-id666-jan-23-2007-0545pm” without an extension. Who the heck would guess that name, unless they knew the programmer? The file shouldn’t be easily recognized by the server and is much less likely to be executed. Would could add a random extension from a rotating and tracked list, such as .bob or .hel, but not executable extensions like .exe or .dll etc. Leaving a file without an extension is a safer route.
So, the file has been made relatively inert and it is sitting in the file upload directory, awaiting further action. The file upload directory is navigable and executable by public users, and the file contains harmful code. A user has returned to your site to request the file for his/her ow malicious intent. How do we deliver the file without compromising our secret file system structure, and deliver a harmful product?
When the user reviews your list of harmful products, PHP will use the MySQL Database to translate the available files. The user sees the filename that was on the original file upload. The MySQL Database associates the new, secret filename system to the original upload file names. The PHP Program knows where the files exist and which file the user is really requesting. Upon download request, PHP streams the file to the user’s browser, uses the MIME-Tye setting to re-associate the original file extension to the downloading file, and replaces the temporary name with the original name. In essence, the PHP Program is reconstituting the harmful file to its originally uploaded state for the downloading user. The user receives the file the way it was uploaded, and good luck that the user doesn’t have a problem.
TO RECAP Â» Let’s review the basics of image file uploads protection. Images aren’t harmful, but they may contain sensitive imagery. We treat them like a harmful program, and prevent prying eyes from accessing them without permission. If your site is selling images and downloads must be carefully controlled, it is advisable to change the permissions on the file upload directory to disallow anyone from any permissions aside from the Web Server and the PHP Server.
Some programmers try to stuff the raw image data into their database, which bloats the database all to Hades, slows the database down, and makes for a painfully difficult site to use. There are advantages to seeing the image files on the file system when programming and debugging, or modifying the site for upgrades, etc.
MySQL Database management of larger file systems is strongly recommended. Create a file management system that is secret and predictable to your PHP Program. Perform file name replacement and MySQL Database name tracking by association. Remove file extensions from the uploaded file name. Advanced PHP Programmers working on systems with higher levels of security might break the raw file data into subcomponents stored into segments, which would be reconstituted into a single raw file before being renamed and delivered. Make sure to track the MIME-Types, extensions, file sizes, and other specs for configuring an efficient download to the user’s browser.
These methods may not be 100% secure, since n computer is completely secure until you pull the power cord out of the wall. The more difficult you make it for malicious users to access your file upload directory and the files within, the more likely they will move on to an easier target. If you have interest in the entire list of methods for protecting uploaded files and securing your network and website, contact The PHP Kemist for Network Security and Secure PHP Programming options.