Press Release
Last Updated on January 19, 2024
View our free cybersecurity resources »
Enabling users to upload images, videos, documents and all manner of files is essential for many web applications, from social networking sites to web forums to intranet collaboration portals to document repositories to blog sites. But allowing users to upload files makes the application vulnerable to a wide range of attack vectors.
You need to “get file upload right” from an information security standpoint, or hackers will find a way to execute malicious code on your server. From there they could potentially “own” the application, intentionally overload a database or filesystem, attack backend systems, or simply deface the website and damage your brand.
Sifting Through Secure File Upload Best Practices
Enforcing secure file upload is easier said than done, because attackers can counter many of the typical controls developers might implement. Moreover, automated scanning and other automated vulnerability assessments often won’t find file upload vulnerabilities. Manual code review or penetration testing are generally required.
Let’s start with the most basic scenario: Your social media site allows users to upload profile images, with no validation. An attacker simply uploads a PHP file, runs the code inside it and the cyber attack progresses from there.
The most basic information security controls would check the file type; e.g., by checking the file’s “content type” header. Now an attacker can’t simply upload a PHP file. But they can set up a proxy, intercept traffic between the browser and the application, change “PHP” to “GIF” or whatever file type is allowed, and then pass the altered data to the server. The application uploads it and the attack progresses from there.
Blacklisting vs. Whitelisting vs. Double Extensions
Developers might choose to counter that vulnerability with a blacklisting mechanism that scrutinizes file names and blocks, say, PHP, Java, JavaScript and other executable file formats. The problem is that it’s hard to maintain an explicit list of every possible file type to block. The attacker might succeed simply by changing the file extension from .PHP to .PHP3, .PHP4 or .PHP5, for instance.
A better approach is whitelisting: specify the short list of file types you’ll allow users to upload. Let’s say you’ll only allow .GIF files—that shuts down the hackers, right?
Unfortunately, not with many Apache server versions/configurations, which are vulnerable to “double extension” attacks. It’s possible if you pass the server a file with two extensions, like ABC.PHP.GIF, the server will process the file as a PHP file while treating it as a GIF for file upload purposes.
Newer versions of Apache won’t execute a file with a double extension; that is, they would treat ABC.PHP.GIF as a GIF, not a PHP. But hackers can also bypass this behavior. After setting up a proxy to intercept traffic between the browser and the application, they upload a GIF file. Using the proxy, they change the name from ABC.GIF to ABC.PHP.GIF. Then, using hex mode, they add a null character after ABC.PHP. The C libraries underlying the Apache server will interpret that as “end of string” and save the file as ABC.PHP, all set to execute malicious code.
What’s a developer to do now? One approach is to check the contents of the uploaded file and allow or disallow it based on that check. For example, you could use the PHP getimagesize() function to check out the height, width, etc. of the uploaded file. If getimagesize() fails, it’s not a real GIF (or any image file) and should be rejected.
But attackers can bypass even this control, by inserting malicious PHP code into the metadata (comments area) of an otherwise valid GIF file. Now when the application processes the file, it will execute the code in the comments section as well.
The Best Approach to Secure File Upload
It’s probably obvious to anyone who’s read this far that blocking file upload attacks will require some application-level and server-side controls. The OWASP Application Security Verification Standard (ASVS) section 16 (File and Resources Verification Requirements) describes the specific controls developers can implement to ensure their application is secure from all the above attacks.
Some of the design parameters the OWASP ASVS specifies include ensuring uploaded files are stored outside the webroot and with limited permissions, the file is not stored with the user-provided name, and the file content is not executed.
To verify the security of your critical application and ensure the safety of your data, contact Pivot Point Security.
For more information:
- The OWASP ASVS Standard version 3 (PDF)
Free OWASP ASVS Testing Guide
If you are just learning about OWASP’s testing standard or are considering the best way to prove the security of an application, this guide is meant for you!
