File upload vulnerabilities are when a web server allows users to upload files to its filesystem without sufficiently validating things like their name, type, contents, or size. Failing to properly enforce restrictions on these could mean that even a basic image upload function can be used to upload arbitrary and potentially dangerous files instead. This vulnerability could even include server-side script files that enable remote code execution.
What if it allows file upload?
In some cases, the act of uploading the file is in itself enough to cause damage. Other attacks (XSS etc.) may involve a follow-up HTTP request for the file, typically to trigger its execution by the server.
The file’s type isn’t validated properly, and the server configuration allows certain types of file (such as .php and .jsp) to be executed as code. In this case, an attacker could potentially upload a server-side code file that functions as a web shell, effectively granting them full control over the server.
If the filename isn’t validated properly, this could allow an attacker to overwrite critical files simply by uploading a file with the same name. If the server is also vulnerable to directory traversal, this could mean attackers are even able to upload files to unanticipated locations.
Failing to make sure that the size of the file falls within expected thresholds could also enable a form of denial-of-service (DoS) attack, whereby the attacker fills the available disk space.
Browse to “test.php” to upload as an image from the image upload area to the web server, as shown in the screenshot below, with the malicious file previously created with the “msfvenom” of the Metasploit Framework tool.
When the image gets successfully uploaded on the web server it will send the link of the directory where the image is saved to view the uploaded image. Since can’t upload any real image, therefore, let try to execute a PHP backdoor by making click on the link “here”.
When the victim clicks the above link “here” will get the victim’s reverse connection through meterpreter session inside the Metasploit Framework.
Thus, the attacker or attackers can easily do what they want.
- Check the file extension against a whitelist of permitted extensions rather than a blacklist of prohibited ones. It’s much easier to guess which extensions you might want to allow than it is to guess which ones an attacker might try to upload. Make sure the filename doesn’t contain any substrings that may be interpreted as a directory or a traversal sequence (../).
Should be prohibit the content of byte values named “Magic Header Bytes”.
- Byte value of image files with the extension “.png”: “\x89PNG\r\n\x1a\n\0\0\0\rIHDR\0\0\x03H\0\xs0\x03[“
- Byte value of image files with the extension “.jpg”: “\xff\xd8\xff”
On the other hand, must be also prohibit null byte values (x00, 0xC0, 0x80, %00 and %0d%0a).
Here are other popular uses that are among the bans:
- .asp, .Asp, .ASp, .ASP, .aspx, .Aspx, .ASpx, .ASPx, .ASPX, .config, .Config, .ConfiG .ashx, .asmx, .aspq, .axd, .cshtm, .cshtml, .rem, .soap, .vbhtm, .vbhtml, .asa, .cer, .shtml,
- .cfm, .cfml, .cfc, .dbm
- .jsp, .jspx, .jsw, .jsv, .jspf, .wss, .do, .action, .JSP, .JSW
- .pl, .cgi, .PL
- .php, .php2, .php3, .php4, .php5, .php6, .php7, .phps, .phps, .pht, .phtm, .phtml, .pgif, .shtml, .htaccess, .phar, .inc, pHp, .pHP5, .PhAr, Php5, .PHP
- Rename uploaded files to avoid collisions that may cause existing files to be overwritten. Do not upload files to the server’s permanent filesystem until they have been fully validated. As much as possible, use an established framework for preprocessing file uploads rather than attempting to write your own validation mechanisms.