Unrestricted File Upload


Description

The application is vulnerable to unrestricted file uploads. Effective controls have not been implemented to restrict users from uploading malicious content to the web server. Files containing active code can be uploaded and executed on the server allowing for a number of serious attacks against the application and infrastructure.

Custom Description

Unrestricted file upload was found on the following pages:

[Insert URL]

Impact

Unrestricted file upload is a serious vulnerability with significant impact on the application and its infrastructure. An attacker with the ability to upload a malicious file to the application can set up drive-by-download attacks, deface the website, or gain access to the file system through a web shell.  Once an attacker has remote access to the server, they can exfiltrate sensitive data, compromise the integrity of application data, or cause denial of service to the application.

Risk Rating

Likelihood – Medium

Impact – High

Overall Risk – High

Remediation

Limit the types of files that can be uploaded to only those needed by the application. For instance, on an image upload page, only image files such as .jpg/.gif should be accepted.

Ensure that the user has no control over the filename and location of the uploaded file on the server.

Never use the name that the user assigns it. Never derive the filename from a predictable value such as the username or session ID.

Do not place the file in a directory accessible by web users. It is preferable for this location to be outside of the web root.

Ensure that strict permissions are set on both the uploaded file and the directory it is located in. Do not allow execute permissions on uploaded files. If possible, deny all permission for all users but the web application user.

Verify that the uploaded file contains appropriate content. For instance, an uploaded JPEG should have a standard JPEG file header.

Implement virus scanning on all uploaded files to ensure they are free of malware before being accepted by the application and served to users.

Reject attempts to upload compressed archives such as ZIP files.

How To Test

Manual testing

In most cases, applications will restrict what types of files can be uploaded. The goal is to test for ways that these restrictions can be bypassed.

Test for accepted extensions

  1. Manually upload a file that will fail the extension test and capture the error message in the reponse to help Burp identify what a failed response looks like
  2. Send the request to Burp Intruder
  3. Highlight the file extension as the insertion point
  4. Choose a payload containing a list of valid file extensions
  5. Under options, configure Burp to grep for the error message
  6. Indentify responses where the error message was not identified

Test for valid content types

  1. Manually upload a file that will fail the content-type header test and capture the error message in the reponse to help Burp identify what a failed response looks like
  2. Send the request to Burp Intruder
  3. Highlight the value of the content-type header as the insertion point
  4. Choose a payload containing a list of valid content-types
  5. Under options, configure Burp to grep for the error message
  6. Indentify responses where the error message was not identified

Test the file name

Use Burp and fuzz the file name with payload strings looking for vulnerabilities such as XSS, SQLi, LDAP or command injection.

Test for virus scanning

Upload a valid file and insert the EICAR test string into it:

https://www.eicar.org/download/eicar.com.txt

Test for blacklist bypass

Some of our favorites include:

Test a file with semicolon after the blacklisted extension such as cmd.asp;.gif

Test a null byte %00 at various places within the file name such as cmd.php%00.jpg

Test double extensions if the application is stripping or renaming the extension such as  cmd.php.php or cmd.html.gif.jpg.asp

Test long file names

Test using spaces or dots after the extension such as cmd.asp… .. . . .

See the OWASP reference for a full list of checks.

Time Saving Tips

Upload an HTML file containing both the EICAR string and a cross-site scripting payload and your point is made. Done!

Testing Gotchas

Testing for a file upload vulnerability takes patience. This is not something a scanner handles well so it is up to you to be thorough. In our experience, it takes time to work through all the possible bypass vectors to find one that works. It also takes some creativity. You should definitely invest the time because this is the one finding you don’t want to miss. You don’t want to hear that an attacker uploaded a web shell and made off with sensitive data after you recently tested the application.

References

OWASP https://www.owasp.org/index.php/Unrestricted_File_Upload

CWE 434  https://cwe.mitre.org/data/definitions/434.html

 

Want access to the full AppSec Findings Database? Click here to subscribe today.

 

Discussion

Have a thought or question? Leave a comment below.

 

Leave a Reply