class.upload.php
class.upload.php is a powerful and mature PHP class to manage uploaded files, and manipulate images in many ways. The script is available under a GPL license.
class.upload.php is a powerful and mature PHP class to manage uploaded files, and manipulate images in many ways. The script is available under a GPL license.
During a security review I discovered an issue where it is possible to upload a HTML file to the server, even if the no_script directive is true (default). In a worst case scenario, if the server is configured to run a script interpreter across HTML files (e.g. PHP) then that clears the way for a base script from which further scripts can be uploaded.
IE & Firefox will supply the mime type for a file, in the case of a HTML file the mime type is text/html, and the process() function of the upload class will check for mime types starting with "text/", but if a utility such as curl is used to manually specify the mime type for the file you are uploading, you are able to bypass this check and land a .html file on the server.
Example:
Assume that upload.php creates a new upload() class and processes it using the process() method. This curl command will send in a html file with a different (but valid) mime type, resulting in the html file being placed on the server.
C:\Utils>curl -F "file=@hacker.html;type=application/excel" http://localhost/upload.php
I am yet to have a good think about the best way to prevent this as there may be times where uploading a html file is perfectly legitimate, but for the case of those people whose servers are configured to evaluate script content in html on the server this poses a significant security threat.
Cheers,
- Bob -
You can harden the security a bit more by having a very restricted set of MIME types that you accept. Yes, the attacker can still fake it.
It is planned to implement the fileinfo support, which will allow for further MIME checks. It will also be helpful when uploading from a Flash uploader.
I will look more into it when I implement fileinfo and will try to implement a "paranoid" setting with more checks.
In the case where you did want to allow a .html file to be uploaded and stored with .html extension, AND where the target server was configured to process .html using PHP (or other) there's no way to prevent this security flaw. I suspect that any server should not be configured to process .html with a server-side interpreter anyway.