Link Search Menu Expand Document
☰
×
Topics

Unrestricted File Download

Play SecureFlag Play Labs on this vulnerability with SecureFlag!

  1. Unrestricted File Download
    1. Description
    2. Impact
    3. Scenarios
    4. Prevention
    5. Testing

image

Description

Unrestricted File Downloads are a type of vulnerability that allow a malicious actor to download internal files, resulting in the potential, unintentional exposure of sensitive files, such as the configuration file, which contains credentials for the database. In milder forms, Unrestricted File Download attacks allow access to a specific directory subtree but could still enable cross-user breaches or access to crucial configuration and sensitive files.

Impact

The damage an attacker can cause by employing this type of attack is really only limited by the value of the exposed information. If a developer has structured their web root folder to include sensitive configuration files, for example, the fallout will, of course, be highly damaging. Furthermore, as with many other attacks that are a part of the attacker’s toolkit, the vulnerability can be used by an attacker as a stepping stone, leading to the full compromise of the system.

Scenarios

A classic scenario is a web application that dynamically fetches resources according to a query parameter; and the available resources are stored in a particular directory within the file systems. For example, the following URL fetches the /opt/wwwdata/assets/some-file file and uses it to build the web page, possibly returning it verbatim:

http://www.vulnerableapp.com/?pageId=some-file

The Directory Traversal technique is commonly used to exploit this type of vulnerability in file systems; the nickname “dot-dot-slash” is often used as an alternative label given the punctuated order of symbols (../ and ..\) that allow access to unintended resources of the server’s file system.

If no checks or sanitisation are in place, it is possible to traverse the resources directory and target any file on the file system. For example, the following fetches the sensitive /etc/passwd file on Linux and other unix-derived systems:

http://www.vulnerableapp.com/?pageId=../../../../../etc/passwd

Prevention

If possible, developers should avoid building file path strings with user-provided input. Many functions of an application can be rewritten to deliver functionally identical behavior but in a safer manner.

If passing user-supplied input to a filesystem API is absolutely necessary, developers must ensure the following:

  • Validate the user input by strictly accepting well-known, reputable candidates against an allow list
  • If validating against an allow list isn’t possible, validation should at least ensure that only permitted content is contained in the input

As defense in depth, developers should never run a server component with root or SYSTEM privileges, as this can enable access to any file or folder, including crypto keys and the registry, to a malicious actor exploiting this vulnerability. Server components should be run using a less-privileged user with no access to critical system files.

Testing

Verify that user-submitted filename metadata is not used directly by system or framework filesystems and that a URL API is used to protect against path traversal.

Table of contents