Description
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: For example, the program may give the attacker the ability to overwrite the specified file or run with a configuration controlled by the attacker.
Potential Impact
Integrity, Confidentiality
Read Files or Directories, Modify Files or Directories
Integrity, Confidentiality, Availability
Modify Files or Directories, Execute Unauthorized Code or Commands
Availability
DoS: Crash, Exit, or Restart, DoS: Resource Consumption (Other)
Demonstrative Examples
String rName = request.getParameter("reportName");File rFile = new File("/usr/local/apfr/reports/" + rName);...rFile.delete();fis = new FileInputStream(cfg.getProperty("sub")+".txt");amt = fis.read(arr);out.println(arr);Mitigations & Prevention
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.
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 the operating system; the rest of your application may still be subj
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.
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 range of acceptable values, missing or extra inputs, syntax, consistency across relat
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).
Use OS-level permissions and run as a low-privileged user to limit the scope of any successful attack.
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.
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.
Detection Methods
- Automated Static Analysis — The external control or influence of filenames can often be detected using automated static analysis that models data flow within the product. Automated static analysis might not be able to recognize when proper input validation is being performed, leading to false positives - i.
Real-World CVE Examples
| CVE ID | Description |
|---|---|
| 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), allowing for filesystem path traversal u |
| 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
Taxonomy Mappings
- 7 Pernicious Kingdoms: — Path Manipulation
- Software Fault Patterns: SFP16 — Path Traversal
Frequently Asked Questions
What is CWE-73?
CWE-73 (External Control of File Name or Path) is a software weakness identified by MITRE's Common Weakness Enumeration. It is classified as a Base-level weakness. The product allows user input to control or influence paths or file names that are used in filesystem operations.
How can CWE-73 be exploited?
Attackers can exploit CWE-73 (External Control of File Name or Path) to read files or directories, modify files or directories. This weakness is typically introduced during the Architecture and Design, Implementation phase of software development.
How do I prevent CWE-73?
Key mitigations include: 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
What is the severity of CWE-73?
CWE-73 is classified as a Base-level weakness (Medium abstraction). It has been observed in 3 real-world CVEs.