File upload vulnerabilities aren’t as common as they once were, but that doesn’t mean you won’t encounter them. As you know, web applications sometimes let users upload files to their site, which can be in the form of a profile picture, a PDF upload functionality, or other features. If this functionality is implemented improperly, attackers can upload malicious files, potentially gaining Remote Code Execution (RCE). If there is an upload feature, you should be testing for this vulnerability.
Uploading a Simple Web Shell
One of the first things to do when testing file upload functionalities is to upload a simple command (cmd) backdoor, often called a web shell. Depending on the programming language of the target web application, your backdoor will look different.
| Language | Code Example (Simplified Shell) |
| PHP | "; $cmd = ($_REQUEST['cmd']); system($cmd); echo ""; die; }?> |
| ASPX | [Code snippet for a full ASP.NET webshell is lengthy and complex] |
In the most basic scenario, the application does not have any restrictions on which file type can be uploaded. An attacker could upload a PHP script (like the one above) and, if it’s placed in the web-accessible directory, they can navigate to it and it will execute.
Once the web shell is uploaded, you need to figure out where it’s located on the server. Once you know the path, you can navigate to the backdoor and execute any shell command you want:
As shown above, the shell successfully uploaded, and the attacker was able to execute remote commands on the server.
Bypassing File Upload Restrictions
Most modern applications implement basic checks to prevent malicious file uploads. Two common restrictions are Content-Type validation and File Name (Extension) validation.
Content-Type Bypass
Content-Type validation is when the server validates the content of the file by checking the MIME type of the file, which is found in the HTTP request’s Content-Type header.
The image clearly states the file has a Content-Type of application/x-php. If the server is configured to block this content type but allows images (e.g., image/jpeg), an attacker can exploit this. If the server trusts the Content-Type header in the HTTP request, an attacker can use a proxy tool (like Burp Suite) to intercept the request and change this value to image/jpeg, which would pass the validation.
This simple change bypasses the client-side or poorly implemented server-side Content-Type validation check and allows the attacker to upload a malicious PHP payload.
File Name (Extension) Bypass
Sometimes the server will check the file name extension to see if it is blacklisted or whitelisted. As you might know from other vulnerabilities, this approach to defense (blacklisting) has many flaws.
The issue with blacklisting is that if even one file extension is forgotten, attackers can bypass the validation. To implement this check, most developers use a regex (regular expression) to check the file extension.
If the validation check is insufficient, an attacker can bypass the regex validation by changing the extension to uncommon or lesser-known ones, such as .phpt or .phtml. Most people don’t know about these extensions, but they can often be used to execute PHP files. The developer only has to be missing one such extension from the validation check for a bypass to be successful.
Summary
File upload vulnerabilities may be a little harder to find in the wild since most developers are aware of this bug, but if you do find this vulnerability, it almost always leads to Remote Code Execution (RCE). For this reason alone, you should always check for this vulnerability whenever you see the ability to upload files to an application. This is a high-impact bug that is invaluable in a bug bounty program.
