Insecure File Uploads

Introduction

In most web applications today, you always find a page that requires you to upload a file to create a profile or register, etc. It may be an image, a resume, or any type of file that is required on that website either for registration purposes, identity verification, etc. Users in general will play by the rules and send their files but on the other hand, attackers may want to use this opportunity maliciously.

In this article, we are going to take a look at insecure file uploads, their impacts, how they are perpetrated, and lastly, how to mitigate the vulnerabilities.

Insecure file uploads

In general, insecure file upload is abusing a web application’s file upload functionality to upload a malicious file to the system with intentions to cause harm. Insecure file uploads can have a greater impact if the attacker creates a specific file that he wants to upload, has specific intentions for that file, and knows the location those malicious files are stored.

In most web applications, the file upload comes as a control or tool that developers may easily put in place so that users may upload files to the web applications. Normally, developers use white-list or black-list to check on the uploaded file types but on the other hand, attackers are well aware of these flaws and may stealthily bypass these operations.

Whitelist file Extensions

public class FileUpload1 {
public string ErrorMsg {
get;
set;
}
public decimal Fil_Size {
get;
set;
}
public string UserFile(HttpPostedFileBase file) {
try {
var fil_Type = new [] {
"txt",
"doc",
"docx",
"pdf",
"xls",
"xlsx"
};
var fileExt = System.IO.Path.GetExtension(file.FileName).Substring(1);
if (!fil_Type.Contains(fileExt)) {
ErrorMsg = "Only Upload WORD/PDF/EXCEL/TXT Files";
return ErrorMsg;
} else if (file.ContentLength > (Fil_Size * 1024)) {
ErrorMsg = "File too Large,File size must be up to " + Fil_Size + "KB";
return ErrorMsg;
} else {
ErrorMsg = "File was successfully Uploaded";
return ErrorMsg;
}
} catch (Exception ex) {
ErrorMsg = "No File Chosen:Upload Container cannot be empty!";
return ErrorMsg;
}
}
}
}

In the above code snippet, the developer lists the file extensions which are expected to be processed by the application. An attacker on the other hand after getting an error message:

ErrorMsg = "Only Upload WORD/PDF/EXCEL/TXT Files";
return ErrorMsg;

They will try to bypass the extension checking and by now, they know the list of extensions the application is expecting, so he may go on and pass a shell script in this way:

shell.pdf.php

The check will recognize the element at the first index.pdf and save the file. In reality, the attacker will have successfully uploaded his malicious shell script, and depending on where it is saved, this could cause a lot of harm to the context of the server.

In modern-day secure coding principles, developers have tried to counter attacker’s methods by checking the last extension of the uploaded file using various functions depending on their programming languages, using blacklist extension checking but some element of stealth from attackers has always managed to bypass all these checks.

Blacklist Extension Checking

Blacklist extension checking is rather the opposite of whitelist extension checking on the application’s context. Instead of checking permitted file extensions, the application checks for restricted file extensions. In this case, the developer tries to pick out all restricted extensions which they are aware may cause disrepute to the application. For instance, they may restrict .php, .xml, .html, .css, etc file extensions to protect the application from known vulnerabilities. Attackers on the other hand are also aware of these mitigation measures, so to bypass Blacklist extension checking, they might use the following extension tricks.

shell.pdf.pHp or shell.pdf.php5 or .phar

Developers, just like attackers have tried to come up with a lot of ways to cross-check user input on uploads and another way they have tried to validate uploaded files from users is through Content-Type Validation.

Content-Type Validation

Web applications may check the Content-Type in the header of the request because it is meant to reveal the content carried within a file. Web applications may search for a 'Content-Type' of "text/plain".

Attackers on the other hand may use a web proxy to change the request header of their malicious upload such that it suites the web application's permitted Content-Type.

File uploads may also be used by attackers to:

Upload .exe files with Trojan horse files which may corrupt the server.
Upload virus-infected files to disturb the functionality of the application and the server.
Upload .jpg files which may be used to perpetrate Cross-site content hijacking if the files contain a Flash Object.
Upload .html files that may be used for Cross-Site Scripting if the file contains a malicious script.
Upload a file with a phishing page that might deface the web application/website.
An overloaded file which may cause a denial-of-service on the server.

How to prevent Insecure File Uploads

File uploads should always authenticate the user from which the upload is coming.
Developers should choose a specific file extension which can be used for processing and perform an end to end checking of the file name and its extensions.
Data from file uploads should go through a WAF before being allowed to be saved or executed on the server.
Uploaded files should not be saved inside the root folder of the application.
Antivirus programs should be put in place and disallow executions without user permissions.
Developers should limit the information given through Error messages.
Set maximum and minimum size for file uploads and make sure they do not disclose it in any application error messages.
Make use of Content Disarm and Reconstruct on all PDF, image, and Office Microsoft files so they are scanned for all embedded malicious threats in scripts, and macros

Conclusion

File uploads are a severe threat to websites and applications and have serious implications on organizations and unsuspecting users. Developers should make sure that they mitigate insecure uploads at all costs.