CWE WEAKNESSES  /  CWE-73

CWE-73

External Control of File Name or Path

What it is

The product allows user input to control or influence paths or file names that are used in filesystem operations.

This could allow an attacker to access or modify system files or other files that are critical to the application.Path manipulation errors occur when the following two conditions are met:``` 1. An attacker can specify a path used in an operation on the filesystem. 2. By specifying the resource, the attacker gains a capability that would not otherwise be permitted. ``` For example, the program may give the attacker the ability to overwrite the specified file or run with a configuration controlled by the attacker.

Impact

Mitigations

• [Architecture and Design] When the set of filenames is limited or known, create a mapping from a set of fixed input values (such as numeric IDs) to the actual filenames, and reject all other inputs. For example, ID 1 could map to "inbox.txt" and ID 2 could map to "profile.txt". Features such as the ESAPI AccessReferenceMap provide this capability.
• [Architecture and Design, Operation]Run your code in a "jail" or similar sandbox environment that enforces strict boundaries between the process and the operating system. This may effectively restrict all access to files within a particular directory.Examples include the Unix chroot jail and AppArmor. In general, managed code may provide some protection.This may not be a feasible solution, and it only limits the impact to th
• [Architecture and Design] For any security checks that are performed on the client side, ensure that these checks are duplicated on the server side, in order to avoid CWE-602. Attackers can bypass the client-side checks by modifying values after the checks have been performed, or by changing the client to remove the client-side checks entirely. Then, these modified values would be submitted to the server.
• [Implementation]Assume all input is malicious. Use an "accept known good" input validation strategy, i.e., use a list of acceptable inputs that strictly conform to specifications. Reject any input that does not strictly conform to specifications, or transform it into something that does.When performing input validation, consider all potentially relevant properties, including length, type of input, the full r
• [Implementation] Use a built-in path canonicalization function (such as realpath() in C) that produces the canonical version of the pathname, which effectively removes ".." sequences and symbolic links (CWE-23, CWE-59).
• [Installation, Operation] Use OS-level permissions and run as a low-privileged user to limit the scope of any successful attack.
• [Operation, Implementation] If you are using PHP, configure your application so that it does not use register_globals. During implementation, develop your application so that it does not rely on this feature, but be wary of implementing a register_globals emulation that is subject to weaknesses such as CWE-95, CWE-621, and similar issues.
• [Testing] Use tools and techniques that require manual (human) analysis, such as penetration testing, threat modeling, and interactive tools that allow the tester to record and modify an active session. These may be more effective than strictly automated techniques. This is especially the case with weaknesses that are related to design and business rules.

Real-world CVE examples

• CVE-2022-45918 — Chain: a learning management tool debugger uses external input to locate previous session logs (CWE-73) and does not properly validate the given path (CWE-20),
• CVE-2008-5748 — Chain: external control of values for user's desired language and theme enables path traversal.
• CVE-2008-5764 — Chain: external control of user's target language enables remote file inclusion.

Related weaknesses

Source: MITRE CWE. View on cwe.mitre.org →