Why is this an issue?

If the file upload feature is implemented without proper folder restriction, it will result in an implicit trust violation within the server, as trusted files will be implicitly stored alongside third-party files that should be considered untrusted.

This can allow an attacker to disrupt the security of an internal server process or the running application.

What is the potential impact?

After discovering this vulnerability, attackers may attempt to upload as many different file types as possible, such as javascript files, bash scripts, malware, or malicious configuration files targeting potential processes.

Below are some real-world scenarios that illustrate the potential impact of an attacker exploiting the vulnerability.

Full application compromise

In the worst-case scenario, the attackers succeed in uploading a file recognized by in an internal tool, triggering code execution.

Depending on the attacker, code execution can be used with different intentions:

• Download the internal server’s data, most likely to sell it.
• Modify data, install malware, for instance, malware that mines cryptocurrencies.
• Stop services or exhaust resources, for instance, with fork bombs.

Server Resource Exhaustion

By repeatedly uploading large files, an attacker can consume excessive server resources, resulting in a denial of service.

If the component affected by this vulnerability is not a bottleneck that acts as a single point of failure (SPOF) within the application, the denial of service can only affect the attacker who caused it.

Even though a denial of service might have little direct impact, it can have secondary impact in architectures that use containers and container orchestrators. For example, it can cause unexpected container failures or overuse of resources.

In some cases, it is also possible to force the product to "fail open" when resources are exhausted, which means that some security features are disabled in an emergency.

These threats are particularly insidious if the attacked organization does not maintain a disaster recovery plan (DRP).

How to fix it in Formidable

Code examples

Noncompliant code example

const Formidable = require('formidable');

const form          = new Formidable(); // Noncompliant
form.uploadDir      = "/tmp/";
form.keepExtensions = true;

Compliant solution

const Formidable = require('formidable');

const form          = new Formidable();
form.uploadDir      = "/uploads/";
form.keepExtensions = false;

How does this work?

Use pre-approved folders

Create a special folder where untrusted data should be stored. This folder should be classified as untrusted and have the following characteristics:

• It should have specific read and write permissions that belong to the right people or organizations.
• It should have a size limit or its size should be monitored.
• It should contain backup copies if it contains data that belongs to users.

This folder should not be located in /tmp, /var/tmp or in the Windows directory %TEMP%.
These folders are usually "world-writable", can be manipulated, and can be accidentally deleted by the system.

Also, the original file names and extensions should be changed to controlled strings to prevent unwanted code from being executed based on the file names.

How to fix it in Multer

Code examples

Noncompliant code example

The following code sample is vulnerable because it implicitly uses /tmp or /var/tmp as upload directory.

const crypto = require('node:crypto');
const multer = require('multer');

let diskStorage = multer.diskStorage({
  filename: (req, file, cb) => {
    const buf = crypto.randomBytes(20);
    cb(null, buf.toString('hex'))
  }
}); // Noncompliant

let diskUpload = multer({
  storage: diskStorage,
});

Compliant code example

const multer = require('multer');

let diskStorage = multer.diskStorage({
  filename: (req, file, cb) => {
    const buf = crypto.randomBytes(20);
    cb(null, buf.toString('hex'))
  },
  destination: (req, file, cb) => {
    cb(null, '/uploads/')
  }
});

let diskUpload = multer({
  storage: diskStorage,
});

How does this work?

Use pre-approved folders

Create a special folder where untrusted data should be stored. This folder should be classified as untrusted and have the following characteristics:

• It should have specific read and write permissions that belong to the right people or organizations.
• It should have a size limit or its size should be monitored.
• It should contain backup copies if it contains data that belongs to users.

This folder should not be located in /tmp, /var/tmp or in the Windows directory %TEMP%.
These folders are usually "world-writable", can be manipulated, and can be accidentally deleted by the system.

Also, the original file names and extensions should be changed to controlled strings to prevent unwanted code from being executed based on the file names.

Resources

• OWASP - Top 10 2021 Category A4 - Insecure Design
• CWE - CWE-434 - Unrestricted Upload of File with Dangerous Type
• CWE - CWE-400 - Uncontrolled Resource Consumption
• OWASP Unrestricted File Upload - Unrestricted File Upload