In this chapter, we are going to learn about file upload vulnerabilities.
| Type of vulnerability: | Server-Side |
| Chances to find: | Common; File upload vulnerabilities are part of “Insecure Design” ranked #4 in the “OWASP Top-10 Vulnerabilities“ |
| TL;DR: | File upload vulnerabilities enable an attacker to place a file of their choosing onto the target server, e.g. leading to the execution of code remotely. |
What is a file upload vulnerability?
Uploaded files represent a significant risk to applications. The first step in many attacks is to get some code to the system to be attacked. Then the attack only needs to find a way to get the code executed. Using a file upload helps the attacker accomplish the first step. The consequences of unrestricted file upload can vary, including complete system takeover, an overloaded file system or database, forwarding attacks to back-end systems, client-side attacks, or simple defacement. It depends on what the application does with the uploaded file and especially where it is stored. (src: OWASP)
Let’s have a look at an example. You are browsing to your favourite image sharing platform. All your friends share their favourite holiday pictures there. You go to the upload screen and find a view similar to the one below:
An attacker could now try to upload a malicious file instead of a benign image file (such as a .png or a .jpg). If the target application is e.g. running on PHP, an attacker could try to upload a file with a .php file ending.
If the application is not performing any validation of the uploaded file, the file will most likely get stored on the file system.
An image sharing platform usually has a functionality to view images. An example HTTP request to retrieve the file could look like this:
GET /view/images?imageName=new_york_2021-12-24.png HTTP/1.1 Host: example.com
In the example above, the regular user would see a beautiful picture of New York City. If the attacker however tries to open his malicious image, he would end up querying this:
GET /view/images?imageName=evil.php HTTP/1.1 Host: example.com
In case the target’s web server is configured to execute .php files, the attacker would now run PHP code on the server. An example attack could e.g. be to read out the passwd file on a Linux server (by running <?php echo file_get_contents('/etc/passwd'); ?>).
The impact of file upload vulnerabilities!
As with many other vulnerability classes, there is no single answer to what file upload vulnerabilities can do to a target system. It heavily depends on the web application code written by developers, on the web server configuration, as well on the operating system running the web server.
We will therefor go ahead and have a look at some typical exploit scenarios (while also listing the prerequisites for those):
- Remote Code Execution: The most harmful outcome. If the web server configuration allows, an attacker can try to e.g. upload a web shell which enables him to pass on terminal commands to the server running the application. These commands can then be easily sent to the server via the browser.
- Denial of Service: If the application code is not validating file size or the number of files uploaded, an attacker could try to fill up the server’s storage capacity until a point is reached, where the application cannot be used anymore.
- Web Defacement: If the web root is not configured properly (allowing an attacker to overwrite existing files), an attacker could substitute existing web pages with his own content (potentially showing imagery which is conflicting to the original purpose of the application)
- Phishing Page: Similar to the example before, an attacker could also go ahead only slightly manipulate an existing page in order to e.g. extract sensitive data, sending it to a destination controlled by himself.
File upload vulnerabilities often go hand-in-hand with directory traversal vulnerabilities.
How to prevent file upload vulnerabilities?
Various techniques exist to prevent file upload vulnerabilities from causing harm to your system. Typically, it is recommend to use a defense-in-depth approach utilising multiple of the prevention strategies below:
- Implement allow-list containing only the file types which are really necessary for the proper functioning of the web app
- Restrict file size to a certain limit
- Create new file names for all uploaded files or remove all potentially dangerous characters (such as control characters, special characters and Unicode characters)
- Use existing well-tested validation frameworks for file uploads
- Remove EXIF data from uploaded files
- Host uploaded files on a separate domain from the main application (in order to obtain protection through the same-origin-policy during potential Javascript execution)
Also make sure to check out this cheat sheet by OWASP!
Additional resources:
Let’s have a look at a video example of a file upload vulnerability:
In this one, we are going to bypass a denylist on an Apache web server:
Okay, because it’s so cool, we’ll have a look at another one:
Following links are valuable to learn more about file upload vulnerabilities:
- File upload vulnerability overview and free labs by Portswigger
- File upload testing guide by OWASP
- File upload testing overview by HackTricks
Follow us on twitter and don’t forget to subscribe to our weekly Bug Bytes, a newsletter curated by Pentester Land & powered by intigriti containing more write-ups and helpful resources.