Unrestricted File Upload
Severity: High
Test name: Unrestricted File Upload
Test ID: file_upload
Test name: Unrestricted File Upload
Test ID: file_upload
Summary |
---|
Unrestricted File Upload vulnerability allows an attacker to upload malicious files to a web server without proper validation. The web application takes the uploaded file and saves it in the file system, data storage, or in a database.
If a malicious file has been uploaded into the file system, the attacker is able to request this file using the URL of the victim’s site. As a result, the attacker can execute any command on the web server. In this case, the attacker should know the uploaded file path.
Impact |
---|
This vulnerability allows an attacker to:
- Execute code on the server side and the client side.
- Gain sensitive information. Browse server folders and files.
- Crash the server. Overload the file system or the database.
- Send attacks to other servers. Create spam content.
- Overwrite critical files or personal data.
Example of uploading a web-shell script |
---|
- Consider that you have a web application which allows uploading an account photo without proper validation.
- Instead of a picture, an attacker uploads a prepared PHP script ("malicious-file.php") using the file picker for the account photo. The content of the PHP script is the following:
<?php
exec($_GET['c']); // Execute an external command passed to the script as entry parameter
- AAfter the script has been successfully uploaded, the attacker can execute any system command on the web server using the following URL:
https://www.{your_web_site}.com/account-photos/malicious-file.php?c=<any-command>
- As a result, the attacker can send a large number of messages anonymously. The attacker may also send phishing emails, where the recipient believes that these messages are originating from a trusted source (your website).
Location |
---|
- The issue can be found in the source code on the server side.
- The issue can be found in the server configuration.
Remedy suggestions |
---|
- The uploaded file types must be restricted. Use a whitelist of accepted, non-executable file extensions.
- Validate the uploaded files. Limit the uploaded files amount and maximum file size.
- Make sure that your web server uses only one extension in the filename.
- Apache
- Insecure:
<FilesMatch ".+\.php">SetHandler application/x-httpd-php</FileMatch>
- Secure:
<FilesMatch ".+\.php$">SetHandler application/x-httpd-php</FileMatch>
- Nginx
- Insecure:
location ~* \.php$ { fastcgi_pass backend; # [...] }
- Secure:
location ~* \.php$ { try_files $uri = 404; fastcgi_pass backend; # [...] }
- Apache
- The directory with the uploaded files should not have any "execute" permission, and all the script handlers should be removed from these directories.
- When running on a web server that supports case insensitive names, apply the whitelist rule to filter extensions such as .exe or .EXE to disallow a situation where a bypass could be applied to the rules that state what type of file could be uploaded to the server.
- Consider saving the uploaded files in a specially designed data storage rather than in the file system of your web server.
- It is recommended to verify that the uploaded files are not saved with their original name (for example,
text.txt
will be saved as2504sgbrys3f.txt
- thereby decreasing the chance that an attacker will access the file he has uploaded).
Classifications |
---|
- CWE-434
- CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:L/A:L
References |
---|
Updated 4 months ago