What is file Upload Vulnerability :
File upload vulnerability is a security flaw in web applications that allows attackers to upload malicious files Suppose there is a file upload functionality in the web application and only jpeg & png extension file is allowed to be uploaded. When an attacker is able to upload any other extension file such as php, jsp, aspx, exe, html, etc. to a server, or even any double extension file such as php.jpeg, asp.png, aspx.txt, etc. then we say there is a malicious file upload vulnerability in the application.
Impact of Malicious File Uploads :
Malicious file uploads can have severe consequences, including:
Compromised system: Uploaded malware can infect the server, compromising sensitive information and compromising system security.
Data theft: Attackers can steal sensitive data by uploading malicious scripts and executing them on the server.
Unauthorized access: Malicious users can upload rogue scripts that grant them unauthorized access to sensitive parts of the application or system.
Downtime: A successful attack can cause downtime for the application and potentially for the entire network.
How do file upload vulnerabilities arise?
Given the fairly obvious dangers, it’s rare for websites in the wild to have no restrictions whatsoever on which files users are allowed to upload. More commonly, developers implement what they believe to be robust validation that is either inherently flawed or can be easily bypassed.
For example, they may attempt to blacklist dangerous file types, but fail to account for parsing discrepancies when checking the file extensions. As with any blacklist, it’s also easy to accidentally omit more obscure file types that may still be dangerous.
In other cases, the website may attempt to check the file type by verifying properties that can be easily manipulated by an attacker using tools like Burp Proxy or Repeater.
Ultimately, even robust validation measures may be applied inconsistently across the network of hosts and directories that form the website, resulting in discrepancies that can be exploited.
How do web servers handle requests for static files?
Before we look at how to exploit file upload vulnerabilities, it’s important that you have a basic understanding of how servers handle requests for static files.
Historically, websites consisted almost entirely of static files that would be served to users when requested. As a result, the path of each request could be mapped 1:1 with the hierarchy of directories and files on the server’s filesystem. Nowadays, websites are increasingly dynamic and the path of a request often has no direct relationship to the filesystem at all. Nevertheless, web servers still deal with requests for some static files, including stylesheets, images, and so on.
The process for handling these static files is still largely the same. At some point, the server parses the path in the request to identify the file extension. It then uses this to determine the type of the file being requested, typically by comparing it to a list of preconfigured mappings between extensions and MIME types. What happens next depends on the file type and the server’s configuration.
- If this file type is non-executable, such as an image or a static HTML page, the server may just send the file’s contents to the client in an HTTP response.
- If the file type is executable, such as a PHP file, and the server is configured to execute files of this type, it will assign variables based on the headers and parameters in the HTTP request before running the script. The resulting output may then be sent to the client in an HTTP response.
- If the file type is executable, but the server is not configured to execute files of this type, it will generally respond with an error. However, in some cases, the contents of the file may still be served to the client as plain text. Such misconfigurations can occasionally be exploited to leak source code and other sensitive information. You can see an example of this in our information disclosure learning materials.
