How to get over your fear of implementing file uploads

Usually, to make life easier, applications have a file upload function that allows users to upload any documents, images and other files that relate to the daily tasks of the application. However, uploaded files can sometimes pose a risk to the application if they’re neither verified nor checked before being uploaded. Fortunately, most risks associated with file uploads can be mitigated depending on what the application does with the uploaded file and where it’s stored. Not implementing a secure file upload has several consequences, varying in severity depending on the situation.

Server-side attacks

Insecure implementation on the server can allow an attacker to upload web shells that can be used for remote code execution (RCE). Applications also allow uploads of inherent XML types such as XLSX, DOCX, PPTX which could be used by an attacker to upload malicious files embedded with XML External Entity (XXE) payloads that will execute when the server parses the file. Essentially, an attacker can view and download confidential information in the system. In certain cases, they can attack other hosts on the network depending on how the internal network is segregated.

Client-side attacks

Sometimes, an attacker can upload malicious files which let them carry out Cross-Site Scripting and Cross-Site Content Hijacking, or even display a page on a website used for phishing-based attacks. File upload can also allow the application to be defaced with lies or slander, ultimately affecting the integrity of the application.

But what exactly are the most common types of file upload vulnerabilities?

No anti-virus checks on files

Some applications don’t have an anti-virus check function for uploaded files, so an attacker could upload malicious files like malware, macro or even exploits that can be used to gain control of the application or even infect another user’s machine. Unix-based systems don’t always use a malware solution, whereas Windows-based do, potentially causing another issue.

Ability to overwrite an existing file

Uploading a file with the same name and extension as an existing file on the server can potentially overwrite the original file (depending on the application’s permissions). Replacing configuration files such as “web.config” can lead to a Denial of Service (DoS) attack and crash the application.

Insufficient verification routines on file uploads

Weak protections can be bypassed by finding missed extensions that can be executed (such as “.php5”). Occasionally, there may be flaws in a web server configuration if files with double extensions are permitted – like in certain Apache servers (e.g. “file.php.jpg”). Uncontrolled resource consumption may occur when an attacker can upload a very large file or many small files sequentially, causing a Denial of Service (DoS) attack and bringing down the application.

Solutions to Secure File Upload Functionality

Here’s some things you can do to mitigate risks related to the file upload functionality:

Whitelisting and verifying files

Only allow certain file extensions and types that are used for the business functionality – this is a widely-used practice. If you want to combine two methods, then additionally blacklist certain extensions. This helps to avoid executables, scripts and other malicious content from being uploaded to the application.

Reduce maximum file upload size

Set a maximum file length size tailored to the configuration of the server and, if possible, only allow users to upload a fixed number of files, preventing an attacker from launching a Denial of Service (DoS) attack.

Randomize the uploaded file names

Another option is changing uploaded file names to something random. This will hinder an attacker trying to locate and execute the file once it has been uploaded; a separate vulnerability may be required to locate the correct file.

Usage of anti-virus on the server

Scan files that are uploaded before they reach the server. This can be done either by reverse proxy checks such as HTTP Antivirus proxy (HAVP) which supports free GPL ClamAV scanner or alternative commercial solutions.

Authorised users

The file upload functionality should be limited to authorised users only, with an authentication mechanism in place. All users’ activities should also be logged, and the logging mechanism should be secure against log forgery and code injection. If there is any misuse of the functionality, you will be able to trace it via logs which can act as a reference if there is any suspicious activity.